embedded power for your project embedded power for your project

| Home | Software | Services | Support | Contact |

 Embedded Prozessor
   8-Bit Prozessoren
   16-Bit Prozessoren
   32-Bit Prozessoren
   64-Bit Prozessoren
   ARM
   DSPs
   FPGA
   Intel
   MIPS
   PowerPC
 Tool Information
   BDM/JTAG tool
   Emulator
   Hardware design
   Logikanalysator
   Eval Boards
   Simulator
   Compiler
   Real Time OS
   Software Tools
   Debugger
 Services
   Consulting
   Support
   Systemdesign
   Verkauf
   Links
   Literatur

 embedded
    emulation technology review

Emulatortechnologie im dritten Jahrtausend.

Berichte vom Verschwinden der In-Circuit-Emulatoren (ICE) sind verfrüht. Diese leistungsstarken Debug-Tools sind immer wieder die einzigen Tools die wirklich helfen, auch wenn das Drumherum etwas langwierig und kompliziert ist.

Für die meisten Praktiker ist ein echtes ICE (In-Circuit Emulator) das leistungsstärkste Debug-Tool. Kein anderes Tool erreicht den weiten Bereich der Möglichkeiten der Chip-Emulation, die gerade in der Hardware/Software Interaktion ihre Stärken hat. Die Geburtsstunde des Emulators war fast gleichzeitig mit dem Aufkommen der Mikroprozessoren, da diese Prozessoren überwiegend in Anwendungen eingesetzt werden, die verschieden von herkömmlichen Computern sind und findige Ingenieure haben durch die Emulation einen Eingriff in sonst unerreichbare Resourcen gefunden.

Zweck jeden Debugging-Tools ist die Steuerung und Einsicht in die Resourcen des Prozessors. Echte Emulatoren machen dies indem sie den Mikroprozessor mit spezieller Hardware ersetzen, die sowohl die eigentlichen Funktionen des Prozessors ersetzt, wie auch diese Operationen dem Benutzer einsehbar macht.

Tradionelle Emulatoren bieten viele Debugging Merkmale, die allen Debug-Tools gemeinsam sind: Breakpoints, Einzelschrittausführung, Möglichkeit sowohl Register als auch Speicher anzusehen und zu verändern. Natürlich soll auch der Source Code passend zum Breakpoint dargestellt werden, und Datenwerte sind in den jeweiligen Datentypen entsprechender Darstellung einsehbar.

Im Gegensatz zu anderen Debug Tools beinhaltet ein ICE einige Features die nur mit Hardware erreicht werden können: Echtzeit-Trace, RAM Emulation, verschachtelte Breakpoints, und andere Features helfen bei der Suche nach den eher schwierigen Problemen im Zusammenhang mit Echtzeitfehlern oder komplizierten Interaktionen innerhalb des Codes.

Positionierung

In alten Tagen waren Emulatoren ein Muss für seriöse Entwicklungsarbeit, aber wegen der Kosten - sowohl Kaufpreis als auch die Entwicklung, um einen Emulator zu bauen - wurden diese Tools auf dem Markt anders positioniert.

Projektmanager möchten komplexere System in weniger Zeit für weniger Geld entwickelt haben. Steigende Gehälter zusammen mit hohem Anteil Softwarekosten sollten eigentlich dazu führen, daß die Kosten für ein gutes Tool irrelevant werden. Statt dessen stehen wir vor der perplexen Situation, mehr Aufgaben mit weniger Mitteln zu erfüllen.

Obendrein sind die Chip-Verkäufer weniger tolerant gegenüber teuren Entwicklungs-Systemen. Früher haben sie die Entwicklung von ICEs mitgetragen, heutzutage ist das selten geworden. Exotische Prozessoren bekommen keinen Emulator-Support.

Aber Entwickler brauchen diese Tools wie die Luft zum Atmen, denn kraft Definition ist Software fehlerbehaftet. Also bringen mehr und mehr Prozessorhersteller on-board Hilfsmittel auf ihre CPUs. Auf diese Weise wurden seit Mitte der 90er Jahre die JTAG / BDM tools zum oft einzigen Debug-Tool, welches von einem PC gesteuert über einen seriellen Bus mit dem Prozessor kommuniziert.

Die JTAG und BDM Kabel verdrängten traditionelle Emulatoren weil sie reichhaltige Leistungsmerkmale zu einem wesentlich günstigeren Preis bieten. Größere Projekte bedeuten mehr Programmierer und es ist schwierig, jeden mit einem high-end-tool auszustatten, aber kaum etwas spricht gegen einige hundert Euros für ein JTAG Kabel mit Software-Debugger, wenn obendrein schon ein PC am Arbeitsplatz vorhanden ist.

Ein JTAG / BDM Kabel gibt dem Anwender die Möglichkeit, nach Belieben die Firmware auf dem Zielsystem zu starten und anzuhalten, dabei alle CPU und über Datenbus verbundene Resourcen zu inspizieren. Zusammen mit einem Source-Level-Debugger ergibt sich eine Umgebung, die dem Codeview von Microsoft ähnelt.

Aber JTAG-BDM Debug hat den ICE noch nicht ersetzt; die Rolle des Emulators hat sich vom generellen Entwicklungstool zum Spezialgerät für schwierige Fälle verschoben. Das hängt natürlich auch mit dem zunehmenden Einsatz von 32-bit Prozessoren zusammen, denn bei 8-bit Prozessoren gibt es oft weder JTAG noch BDM, sondern eben "nur" den guten alten Emulator.

Neue Hardware zum Laufen bringen? Ein Emulator, zusammen mit einem Logikanalysator oder Oszilloskop gibt präzise Kontrolle über alle Systemsignale. Anstelle Speicherprobleme durch einen Systemcrash auf die Spur zu kommen, einfach den Emulator anschließen, der Scope Loops erzeugt, mit denen das Timing in allen Stufen eines Speicherzugriffs einfach zu verifizieren ist. Ähnlich geht es mit komplexen I/O Problemstellungen.

Emulatoren helfen im schwierigen Zusammenspiel Hardware / Software. Auf manchen CPUs, wie in der 68k Familie, sorgt ein wilder Pointer mit read oder write auf eine nichtexistierende Speicheraddresse für ein hängendes System, wo es kaum möglich ist, solch einen Fehler mit einfachen Tools zu finden. Mit einem ICE wird solch ein Zustand schnell erkannt, und man kann auch einfach auf (zu) langen Buszyklen anhalten. Dann nur einige Instruktionen zurück im Code und man findet die Ursache des Problems.

Letztendlich ist aber die wesentliche Rolle eines ICE, um sich von den billigen hochfunktionellen JTAG Tools abzuheben, die Diagnose von Echtzeit-Problemen.

Traditionelle Debug Strategien versagen meistens in der Dimension Zeit. Manchmal sind Interrupt-Routinen so harmlos und langsam, daß man mit Einzelschritt arbeiten kann, aber meist werden Interrupt Service Routinen in Mikrosekunden abgearbeitet und können, nein, dürfen oft unter keinen Umständen angehalten oder verzögert werden. Bestenfalls verliert man nur Daten an einer Schnittstelle, schlimmstenfalls wird das zu debuggende System neu gestartet oder verriegelt und man kommt nie an die interessante Stelle im Code. Mit einem Emulator-Trace dagegen wird eine ISR einfach aufgezeichnet, ohne die Systemeigenschaften zu verändern.

Überlegen wir mal, was passiert, wenn man einen komplexen Breakpoint in einem Software-Debugger setzt, der mit einem JTAG oder BDM auf ein Target verbunden ist. Um an einer Stelle, wo ein Wert 0x19 auf eine Variable test geschrieben wird, anzuhalten, muß die Software/JTAG Kombination so lange Einzelschritte ausführen, bis die Bedingung erfüllt ist. Mit einem Emulator werden komplexe Breakpoints in Echtzeit erreicht, der Emulator beobachtet Buszyklen nur, ohne das System zu verlangsamen.

"Harte" Echtzeitsysteme versagen manchmal wenn ein Event nicht am richtigen Zeitpunkt eintrifft. Mit den Triggermöglichkeiten eines Emulators ist es ein Leichtes, den entsprechenden Trace aufzuzeichnen, wenn z.B. eine ISR eine Maximalzeit überschreitet oder bestimmte Programmteile nicht ausgeführt werden. Messungen der Systemauslastung und zeitliches Verhalten werden ein leichtes.

Der Punkt ist, daß Echtzeit ein wichtiger Faktor in einigen Embedded Systemen ist und Echtzeit-Entwickler die richtigen Tools benötigen, um in der Zeit-Dimension so einfach zu arbeiten, wie mit Funktionen und Variablen. Heutzutage kann nur ein Emulator diese Rolle erfüllen.

Support

Die dunkle Seite des Verkaufs von Emulatoren ist der Kundenservice und Support. Ein Emulator an sich ist komplex, muß mit third-party software zusammenarbeiten und das ganze auf der Hardware des Kunden, mit unter Umständen hunderten von Verbindungsstellen. Targets die ohne ICE prima funktionieren, zeigen mit ICE merkwürdige Funktionsstörungen, weil kritisches Design am Rande von Spezifikationen das System empfindlich gegen Störungen macht.

Kunden sind ziemlich frustriert, denn nach Investition einiger -zigtausend Euro in einen Emulator, haben sie nun ein Tool was überaus kompliziert in der Bedienung und sehr empfindlich im mechanischen Umgang ist. Obendrein werden manchmal redesigns notwendig, nur damit mit einem ICE gearbeitet werden kann.

Kunden, die keine Emulatorexperten sind und Verkäufer, die sich nicht auf individueller Kundenhardware zurechtfinden, tragen nicht zur Eindämmung der Probleme bei. Nur zu oft sitzt beim Kunden ein Softwareingenieur ohne irgendwelche Kenntnisse der Target-Hardware, und dann soll der Support des Emulatorhersteller mit gezielten Fragen herausfinden ob nicht die Target-Taktfrequenz mit der Emulatorspezifikation übereinstimmt. Gerade in Zeiten, wo am Support bei den Herstellern gespart wird, eine Gleichung, die nicht auf geht!

Emulatorhersteller haben die Herausforderung, die wirklich smarten Ingenieure zu finden, die anhand weniger Hinweise über das Telefon eine treffende Diagnose zur Behebung eines Hardware/Software Problems geben können, aber die dennoch gerne an der Hotline arbeiten. Manchmal müssen auch die Entwickler einige Tage im Monat den Support sicherstellen und oft existiert ein gestaffelter Ansatz, wo einfache Probleme vom Support bearbeitet werden, die hartnäckigen Probleme an das eigentliche Engineering weitergereicht werden.

Vorbei sind die Tage, an denen Emulatorhersteller Applikationsingenieure zum Kunden geschickt haben, um Hardware/Software Wehwehchen zu kurieren. Heutzutage gibt es Support nur noch über Telefon oder Internet. Dies reduziert die Supportkosten für Hersteller und Kunden, aber es verhindert auch, daß der Hersteller eine tiefere Erkenntnis über die wahren Zustände auf der Kundenhardware erlangt.

Denn in etwa 50% der Supportfälle liegt das Problem bei der Kundenhardware. Mangelhafte Abschlußwiderstände an CPU-pins, niedrige Clock Spannungen und Signalreflexion machen einen Einsatz des ICE unmöglich oder abhängig von zufälligen Bedingungen. Darüber liegt die inherente Komplexität moderner Hochleistungssystem mit vielfältigsten Fehlermöglichkeiten sowohl beim Tools-Hersteller als auch beim Kunden. Mit einem ICE auf eine Kundenhardware aufzusetzen, ist zu einer Herausforderung an Systemdesign und für Ingenieure vor Ort geworden. Die eigentliche Entwicklung gerät dabei oft ins Hintertreffen.

So haben ICE Hersteller keine Scheu, die Kundenhardware in-house zu begutachten, allerdings ist dies nicht immer ein gangbarer Weg, denn oft läßt sich die Kundenhardware nicht aus einer umfangreichen komplexen Peripherie - von der Telefonzentrale zum Hardwaresimulator - trennen und damit wird ein Versand unmöglich. Obendrein wird diese Stufe des Supports oft erst gewählt, wenn es wirklich brennt und die Tage auf dem Versand - am besten noch mit internationalem Zoll - wirklich schmerzhaft sind.

So sind also Emulatoren die kompliziertesten Debug Tools im Einsatz. Jedes Projekt sollte Tage wenn nicht Wochen einkalkulieren, bis diese Tools richtig funktionieren. Einige der vorher angeführten Faktoren sind ebenfalls einzubeziehen, so daß rasch eine Checkliste, in etwa wie folgt heraus kommt:

  • Einarbeitungszeit Emulator 2..3 Taqe MINIMUM - Schulung wird durch Hersteller angeboten?
  • Supportpersonal beim Hersteller hat ausreichende Hw/Sw Kenntnisse? Rufen Sie mal an, oder fragen andere Kunden nach ihren Erfahrungen.
  • Wie sieht die Zusammenarbeit mit anderen Third-Party Herstellern, RTOS Herstellern aus? Nichts ist ärgerlicher, wenn sogenannte Herstellerallianzen den Kunden ewig von einer Hotline zur nächsten schicken.
  • Applikationsingenieur des Herstellers sind bereit, ins Haus zu kommen? Wo ist das nächste Büro?
  • Wer sichert bei den eigenen Software-Teams den Support der Hardware? Bei größeren Teams ist es vorteilhaft, einen zentralen Spezialisten für Fragen zu Emulator und Hardware zu haben.
  • Wie gut ist ein Source-Level Software-Debugger integriert?
  • Sind die Features des Emulators eher vom GUI oder von einer Kommandozeile zugänglich?
  • Ist der Software-Debugger eng mit einem Compiler verzahnt?
  • Ist third-party Software anbindbar? Denn wenn ein Echtzeit Betriebssystem eingesetzt werden soll, kommt es vor allem auf die passende RTOS-awareness an.
  • Welche anderen Debug-Strategien sollen zur Anwendung kommen oder sind bereits im Einsatz?
  • Bei Einsatz verschiedener Hardwaregestützter Tools kommt es auf einen einheitlichen Software-Debugger an. Manche Hersteller bieten modulare Debug-Hardware an, beginnend mit JTAG/BDM kann später ein Echtzeittrace hinzugekauft werden.
  • Wie behandelt der Emulator den prozessorinternen Cache? Einige Emulatoren und JTAG Tools arbeiten nur ohne internen Cache.

Viele Emulatorhersteller bieten ihre Hilfe bei Neudesigns und Design-Review an. Dieser Service ist meistens schon im Vorfeld einer Kaufverhandlung zu haben, nutzen sie ihre starke Position als zukünftiger Kunde! Emulatorhersteller sehen viele aktuelle Designs und können oft Tips geben, die ein wenig über den Einsatz des Emulators hinaus gehen. Natürlich müssen die Hinweise des Herstellers auch ernstgenommen werden, sonst ist die Einsetzbarkeit des teuren Tools nicht sicher gestellt.

Welches ICE für unser Projekt?

Wer im technischen Umfeld etwas aussucht, orientiert sich oft an Datenblatt-Merkmalen, sogenannten Features, ob es ein Auto, ein Computer oder ein kleines Elektronik-Gadget ist. Verkäufer mit geschmeidiger Zunge unterstreichen Produktmerkmale als Weg zu unserem Herzen und Geldbeutel. Hier geht Probieren über Studieren und einige Features erweisen sich im täglichen Betrieb als goldwert während andere oft nicht das Papier wert sind, auf dem die Marketingbroschüren gedruckt sind. Was beim Autofahren selbstverständlich ist, sollte auch für einen ähnlich teuren Emulator gelten, erst bei einer Probefahrt zeigt sich, ob das Gerät das taugt, was der Verkäufer uns glauben machen will.

Nur wenige Projekte verwenden ICEs als einzige Debug Tools, oft wird eine Entwicklungsumgebung aufgebaut, in die sich das Tool einfügen muß.

Emulatoren können für Performance-Analyse und Code Abdeckung eingesetzt werden, die allerdings, von Prozessorarchitektur abhängig, neue Probleme aufwerfen können. Denn Emulatoren sehen nur Bus-Prefetch, und gerade bei modernen Architekturen mit tiefen Pipelines ist der Prefetch oft verschieden von der Ausführung im CPU Core. Jumps, Calls, und Interrupts entwerten die Annahmen und es ist oft schwierig, zu sehen, was die CPU wirklich macht. Hier tut sich einiges bei Halbleiterherstellern, einige Chips haben einen internen Echtzeittrace, basierend auf wirklich ausgeführtem Code. Eine weitere Alternative sind Tools die den Code instrumentieren. Hier wird eine geringe Performance-Penalty gegen die Gewissheit über ausgeführten Code eingetauscht.

Genau betrachtet wird die mechanische Verbindung zum Zielsystem: Surface Mount und vor allem BGA sind schwierige Technologien für mechanische Aufsätze. Es gibt allerdings einige Spezialisten für Adapter die es auch gestatten, einige hundert Kontaktpunkte von BGA Footprints an einen Emulator weiterzureichen. Für eine zufriedenstellende Adapterlösung müssen oft einige Targets geopfert werden.

Die Verbindung vom Emulator zum Host PC - oder gar zu einer Unix Workstation - geschieht am besten über Ethernet Netzwerkanschluß. Heutzutage kaum teurer als eine serielle Verbindung gelangen download Daten und Trace upload schnell und einfach auf den Host. Einige Tools haben auch ein USB Interface, dies ist vor allem für mobiles Debugging interessant. Lösungen mit RS232 sind antiquiert und Parallelport funktioniert nicht auf allen PCs, also Hände weg.

Selbst wenn sie schnelle CPUs verwenden, ist ein ICE noch nicht ganz aus der Welt, moderne Emulatoren halten unter entsprechendem Design-Aufwand bis 100 MHz Schritt und bieten die gesamte Debug-Kraft eines Emulators. Allerdings muß das Target Board bei hohen Geschwindigkeiten auch die Last eines Emulators unterstützen, sonst kann der Aufwand beim Hersteller noch so hoch sein, wenn die Kunden-Hardware zu empfindlich ist.

Also bleibt unter dem Strich die Empfehlung, gerade bei modernen Designs früh und oft mit den Tools Herstellern zu sprechen, um nicht plötzlich mit geht nicht, gibt es nicht konfrontiert zu sein. Wenn ein ICE physikalisch nicht passt, dann muß auf jeden Fall der Anschluß für ein JTAG/BDM tool stimmen!

Aus der ICE Zeit wird On-Chip Debugging

Kein Tool kommt einem ICE in Stärke der Debug-Fähigkeiten nahe, nur echte Emulatoren können schnell und geradlinig komplizierte Hardware/Software Probleme aufdecken. Obwohl die Luft bei modernen Hochgeschwindigkeitsdesigns sehr dünn geworden ist, erfreuen sich In-Circuit Emulatoren noch großer Popularität, auch wenn es nicht mehr jedem Entwickler vergönnt ist, mit so einem schnellen und effektiven Tool arbeiten zu können.
Moderne Mikrokontroller bekommen immer mehr Debug-Fähigkeiten on-chip, so daß es bald vollwertige on-chip Debugger geben wird, die die Funktionen eines Emulators ohne die Schwierigkeiten der physikalischen Adaption ausführen können. ARM hat mit dem erweiterten ETM Debug Module ein gutes Echtzeit-Trace on-chip und schnelle Debug Verbindungen wie NEXUS überwinden die Nachteile der langsamen JTAG Verbindung.

In-Circuit Emulator - Features und Fachbegriffe

  • Breakpoints

Die meisten Debug Tools erlauben verschiedene Arten von Breakpoints. Emulatoren bieten sowohl Software als auch Hardware unterstützte Breakpoints. Für einen Software Breakpoint ersetzt das Tool den Befehl an der gewünschten Adresse mit einem Exception Code der zu einem speziellen Breakpoint handler verzweigt. Software Breakpoints können also nur in RAM gesetzt werden. Für Code in Flash oder gar selbstmodifizierenden Code und in einigen anderen Fällen, wenn z.B. eine Checksum berechnet wird, hilft nur ein Hardware Breakpoint weiter. Hier hält der Emulator wenn die gewünschte Adresse ausgeführt wird.

  • Verschachtelte Breakpoints / Triggers

Versteckte Software Bugs zeigen sich oft erst mit dem Eintreffen vieler bestimmter Bedingungen. Verschachtelte Breakpoints arbeiten wie State Machines, wenn Bedingung A und Zustand B dann warte auf Event C zum Start eines Trace und halte wenn Bedingung D eintrifft. Auf diese Weise können fast beliebig seltenen Bedingungen erfasst werden, und das alles ohne das Zielsystem in seiner Arbeit zu beeinträchtigen.

  • Real-time trace

Wie ein Logikanalysator zeichnet ein Emulator alle Busaktivät in Echtzeit auf. Emulatoren zeigen aufgezeichnete Buszyklen als disassemblierten Machinencode oder gar als original C/C++ source code. Die Größe eines Trace wird als Tiefe (Anzahl Maschinenzyklen; typisch sind 128K bis 8MB) und Breite angegeben. Breite über 100 bits sind leicht erreicht; address bus (32 bits), data bus (16 .. 32 bits), CPU status (8 .. 16 bits), timestamp (32 bits oder mehr), und vom Anwender definierte external inputs (8 .. 16 bits). Einige Embedded Systems tolerieren keine Breakpoints; hier hilft nur ein Trace, durch gezielten Einsatz von Trigger, um zu sehen was auf dem Target passiert.

  • Trace filter / qualification

Tiefe trace buffer enthalten eine Menge Information, aber wer möchte schon hundertausende Zeilen Code analysieren? Also werden Filter gebraucht, die Aufzeichnung von Trace nach Regeln begrenzen, wie bestimmter Adressbereich oder gewisse Datenpattern, und das alles in Echtzeit.

  • Timestamp

Es ist natürlich genau so wichtig zu sehen was im Trace steht, als auch wann dies aufgezeichnet wurde. Gerade bei gefilterten Trace sieht man einfach die Unregelmäßigkeiten, die auf eine Störung hin deuten.

  • Timers

Manchmal ist es auch der Einsatz von Timer sinnvoll, in Verbindung mit Trigger für start und stop Bedingungen. Trace oder Breakpoint kann vom Eintreffen eines Events oder Ablauf eines Timers getriggert sein. Gerade für die Suche nach verlängerten Interrupt Service Routine ist dieses Feature Gold wert.

  • Emulator RAM

Normalerweise nimmt der Emulator einige Executionszyklen vom Zielsystem um auf Systemspeicher zuzugreifen. Eigenes Shadow RAM ist Speicher im ICE welches als Overlay den Systemspeicher ersetzt. Emulator RAM ist ohne Cycle-Stealing anzeigbar und gestattet auch die Emulierung von Flash Speicher auf dem Target.


Vielen Dank für Ihr Interesse und stellen Sie uns weitere Fragen. Wir freuen uns auf Ihr Embedded Projekt!

Mit freundlichen Grüßen vom Embedded Experten

Simulator Simulation Vorausentwicklung Softwareteam ohne Hardware Einarbeitung in Enticklungswerkzeuge Software

| Home | Products | Services | Support | Impressum |

Embedded Systems Technoloy Center 2006 - Alle Marken, Warenzeichen und Handelsnamen sind Eigentum der jeweiligen Inhaber.

© BK media systems 2002, 2016.

All trademarks and registered names are property of their respective owners. German law requires Impressum