Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
Fortsetzung des Artikels von Teil 3
Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
JTAG-Debug-Operationen und Prozessoren, die mit Hunderten von MHz laufen, sind an sich schon asynchrone Funktionen. Ohne Hardware-Unterstützung auf dem Chip wäre es nicht möglich, mit nur einer JTAG-Operation einen Prozessor an einem Haltepunkt zu stoppen und einen anderen Kern zu veranlassen, genau an diesem Punkt anzuhalten. Die Zeitspanne zwischen dem Ausgeben eines JTAG-Befehls und der Antwort des Prozessors, die Tausende von CPU-Zyklen später erfolgt, wird im Allgemeinen als „skid“ bezeichnet.
In der Debug-Praxis bedeutet das, dass man die Kerne völlig unabhängig voneinander debuggt; es gibt keine echte Interaktion zwischen ihnen. Deshalb bringt der simultane Anschluss an mehrere Kerne nicht viel. Selbst wenn der Designer dies macht, kann er nicht gleichzeitig mit beiden Kernen arbeiten. Dies ist eine Einschränkung von JTAG, ebenso wie die Tatsache, dass es keinen formalisierten Hardware-Verbindungsstandard für Multicore-Debugging gibt.
Um dieses Problem zu lösen, bietet der EDGE-Debugger von Mentor Graphics die Möglichkeit, „Synchronization Groups“ zu definieren. Designer können damit eine Gruppe von „Threads“ festlegen, die angehalten werden, wenn ein bestimmter Thread auf einen Haltepunkt stößt. Unterstützt wird dies durch eine Fähigkeit, die der Backend-Transport der Debug-Engine zur Verfügung stellt und mit der mehrere Kerne synchron angehalten werden können. Ist diese Fähigkeit nicht vorhanden, dann wird sie von der Debug-Engine emuliert, indem sie die anderen Kerne der Reihe nach anhält, wenn der eine Kern auf den Haltepunkt gestoßen ist.
Jobangebote+ passend zum Thema
Nexus – zaghafte Akzeptanz
Wie bereits erwähnt ist JTAG ein Kommunikationsmechanismus, der zur Steuerung eines Embedded-Prozessors verwendet wird. Er hat nicht unmittelbar etwas mit Debugging zu tun. Zusätzlich zum JTAG-Anschluss muss auf den Kernen selbst eine Debug-Logik vorhanden sein, die den Kern steuert.
Anders verhält es sich mit Nexus. Nexus ist gewissermaßen das Gegenstück zu JTAG. Das „Nexus 5001 Forum“ ist ein Industrieverbund, der einen Standard (IEEE-ISTO 5001) entwickelt hat, der einen solchen Debug-Logikblock zur Unterstützung der Embedded-Entwicklung definiert. Er enthält Funktionsmerkmale, mit denen z.B. der im Kern integrierte Speicher während des Betriebs ausgelesen und beschrieben werden kann.
Obwohl das vorteilhaft ist, hat der Standard nicht direkt etwas mit Multicore-Debugging zu tun – außer der Tatsache, dass er einen zusätzlichen Hochgeschwindigkeits-Kommunikationsmechanismus definiert, der unter mehreren Kernen aufgeteilt werden kann, z.B. zur Übertragung von Echtzeit-Trace-Daten. Leider erfolgt die Adaption von Nexus nur sehr langsam, so dass dieser Standard noch keine so große installierte Basis hat wie andere Technologien. Vielleicht kommt Nexus mit dem Wachstum von Multicore richtig in Schwung.
Standards senken Kosten
Aus der Perspektive der Siliziumanbieter ist ganz klar, was sie von Industriestandards für den Anschluss und das Debugging von Embedded-Targets erwarten. Siliziumanbieter wenden sehr viel Zeit und Geld auf, um ein „Ökosystem“ zu „züchten“, das ihr Produkt umgibt und mit Mehrwert ergänzt. Deshalb wenden sie sehr viel Zeit auf, Echtzeit-Betriebssysteme, Entwicklungswerkzeuge und Verbindungs-Support für ihre Prozessoren bzw. Controller anzupassen. Unter Umständen müssen sie Lizenzgebühren an Werkzeuganbieter zahlen, die mit ihren proprietären Hardware-Entwicklungen die Siliziumanbieter nur zögerlich unterstützen. Diese Zeit und dieses Geld wären besser angelegt, wenn man es entweder in die Geldbeutel der Aktionäre steckt oder in Forschung und Entwicklung investiert.
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
- Multicore-geeignete Debugger
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
