Durchblick bei Multicore

Redakteur: Martina Hafner

Klassische Anwendungen für Multicore-Designs sind in der Netzwerktechnik, Medizintechnik und Verteidigung zu finden, also in Bereichen, in denen dedizierte Aufgaben mit hoher Rechenleistung

Firmen zum Thema

( Archiv: Vogel Business Media )

Am Beginn steht das klassische „Ei-Henne“-Problem. Zum einen möchte der Entwickler maximale Visibilität der auf dem Chip zur Verfügung stehenden Ressourcen, auf der anderen Seite steht die hohe Integrationsdichte der Komponenten. Das heißt, viele der verwendeten Einzelkomponenten in einem System können nicht mehr separat über Stecker getestet werden, sondern müssen sich Anschlüsse teilen. Im Gegenzug, um alle Funktionen zu gewähren, muss jede Komponente einzeln und im Verbund testbar sein. Welche Anforderungen muss also die Debug-Schnittstelle erfüllen? Was heißt eigentlich Multicore-Debugging in der Praxis?

Klassische Anwendungen für Multicore-Designs sind in der Netzwerktechnik, Medizintechnik und Verteidigung zu finden, also in Bereichen, in denen dedizierte Aufgaben mit hoher Rechenleistung zu lösen sind. Die Auslagerung von Teilen der Applikation in Hardware, zum Beispiel in FPGAs oder in andere CPUs, erlaubt es spezielle, flexible Lösungen zu erstellen. So ist beispielsweise die Unterstützung neuer oder kundenspezifischer Protokolle nicht zwangsläufig mit Änderungen der Hardware verbunden. Der objektorientierte Ansatz, die Funktion den Daten zuzuordnen, gewinnt damit eine neue Dimension. Des Weiteren verliert die Aussage „die Hardware ist zu teuer und unflexibel“ damit an Gewicht – ein weiterer Schritt beim Zusammenwachsen der beiden programmierbaren Welten. Zur Verteilung der Ressourcen in der Entwicklung von Multicore-Anwendungen werden Ansätze von Betriebssystemen zur Aufteilung der Systemlast beziehungsweise Dateilast eingesetzt.

Bildergalerie

Die synchrone Kontrolle aller Prozessoren ist elementar

Die Interpretation des Begriffs Multicore-Debugger reicht von der Unterstützung verschiedener Prozessoren bis zum simultanen Debuggen von Prozessen auf verteilten CPUs. Die Erwartung an einen Debugger wird maßgeblich durch die auf dem Chip verfügbaren Ressourcen gesetzt, zum Beispiel Cache-Control, Trace-Funktion, das heißt, zum Debuggen eines „Virtex II Pro“ mit bis zu vier integrierten IBM-PowerPC-405-Prozessoren, die Synchronisation von vier separaten Instruction-Caches und Daten-Caches zuzüglich aller anderen zum Core gehörigen Register. Run-Control, das gemeinsame Starten und Stoppen der verschiedenen Prozessoren ohne zeitlichen Versatz ist essenziell zum Debuggen einer Applikation ebenso wie die Kontrolle über jede einzelne CPU (Bild 1).

Die Problematik der nicht synchronisierten Prozesse verdeutlicht folgendes Beispiel: In einem Multiprozessorsystem, das Shared-Memory und Cache verwendet, wird die Cache-Konsistenz über das MESI-Protokoll (Modified, Exclusive, Shared, Invalid) sichergestellt:

• CPU 1 modifiziert internen Cache mit neuen Daten,

• CPU 2 Breakpoint,

• CPU 2 Run,

• CPU 2 Speicher auslesen,

• CPU 1 reagiert nicht auf den Lesezugriff, da die CPU angehalten wurde,

• CPU 2 modifiziert daraufhin den eigenen Cache,

• CPU 1 wird wieder gestartet.

Die Daten im Cache von CPU 2 sind nach dem Starten der CPU 1 inkonsistent gegenüber den in der Zwischenzeit modifizierten Daten in CPU 2. Der Übergang des Cache-Status von Modified auf Shared erfolgt durch eine externe Cache-Line-Leseanforderung. Bei erfolgreicher Ausführung schreibt die CPU die Daten daraufhin wieder in den Speicher („Snoop Copyback“). Den gesamten Vorgang kann man sich wie folgt vorstellen: Alle stehen in einer Reihe. Einer stellt eine Frage. Wenn der, der die Frage beantworten kann, schläft („No Snooping“), so wird der Fragesteller sich die Antwort selber geben. Nach dem Erwachen verfügen beide über einen unterschiedlichen Wissensstand. Eine Möglichkeit, dies zu verhindern, ist, beide CPUs anzuhalten und anschließend synchronisiert zu starten. Die synchrone Kontrolle aller CPUs in der Scan-Chain ist aus diesem Grund elementar in einer Multicore-Umgebung.

Anbindung des Debuggers über die JTAG-Schnittstelle

Die ersten Überlegungen gelten der Anbindung des Debuggers. In den letzten Jahren hat sich als Quasi-Standard die JTAG-Schnittstelle etabliert. Diese liest die Informationen durch eine Art überdimensionales Schieberegister, die Scan-Chain, aus. Ursprünglich wurde die Schnittstelle von der „Joint Test Action Group“ zum Testen von Hardwareverbindungen auf der LeiterpIatte entwickelt (Boundary-Scan nach IEEE 1149.1). Die JTAG-Spezifikation beschreibt das Testen von Leiterplatten und deren Verbindung durch das Anlegen von Signalen. Dazu wird die eigentliche Funktion des Chips ausgeschaltet und der zu testende Pin von der internen Logik entkoppelt. Die Anzahl der zu testenden Verbindungen (Pins) bestimmt die Länge der Scan-Chain. Die physikalische Verbindung erfolgt über eine fünfadrige Leitung mit jeweils einem Datenein- und -ausgang zusammen mit Takt und Reset. Als zusätzliches Signal wird die so genannte TMS-Leitung zur Steuerung des TAP-Controllers benötigt. Der TAP-Controller steuert den Datenfluss beziehungsweise erlaubt durch zusätzliche Befehle die Verwendung der JTAG-Schnittstelle als Debug-Schnittstelle. Bei einigen Mikroprozessoren erreicht die Scan-Chain im Debug-Modus eine Länge von mehr als 65 000 Bit, die zyklisch ausgelesen werden müssen. Selbst das einfache Ändern eines Registerwertes gestaltet sich somit relativ komplex und zeitintensiv, da zunächst die komplette Scan-Chain ausgelesen werden muss. Die weiteren Schritte sind, das zu modifizierende Register zu überschreiben und die Informationen wieder in den Mikroprozessor zu transferieren. Nach dem Einlesen der gesamten Scan-Chain werden durch ein weiteres Kommando die Werte in die eigentlichen Datenregister transferiert.

Grundlegend sollte zu Beginn der Hardwareentwicklung die Frage nach den passenden Software-Tools gestellt werden, einschließlich der zu verwendenden Schnittstellen. Die JTAG-Schnittstelle erlaubt verschiedene Verfahren, wenn mehrere Elemente in eine Scan-Chain eingebunden werden sollen. Das Schiebe-Register (“Daisy Chain“) wird durch das Verbinden des Datenausganges mit dem Dateneingang des nächsten Elements verlängert. Grundlegend dafür ist die Versorgung aller Elemente über einen gemeinsamen Takt. Dadurch kann auf weitere JTAG-Ports verzichtet werden. Typischerweise wird bei dieser Methode immer nur ein Element der Scan-Chain angesprochen. Die maximale Geschwindigkeit richtet sich nach dem schwächsten Glied in der Kette.

Simultanes Debugging von bis zu acht verschiedenen Applikationen

Der JTAG-Switch schaltet, wie der Name bereits vermuten Iässt, die verschiedenen Scan-Chains abhängig von der eingestellten Adresse auf einen gemeinsamen Verbinder (Bild 2). Die Vorteile sind:

• Trennung der Scan-Chain in kleinere Segmente,

• durch Segmentierung kann die Datenrate erhöht werden,

• vorteilhaft bei Steckkarten, da die Zuteilung der Adressen dynamisch erfolgt.

Die Nachteile sind:

• zusätzliche Hardware wird benötigt (On-Chip oder Leiterplatte),

• zusätzlicher Aufwand durch die Steuerung der Adressleitungen,

• löst nicht das Problem des simultanen Debuggings.

Mit diesem Ansatz umgeht man das Problem des schwächsten Gliedes in der Kette. Jedoch wird auf der Leiterplatte beziehungsweise dem SOC der JTAG-Switch in Hardware benö-tigt. Der Vorteil liegt in der Skalierbarkeit der Scan-Chain. Eine Einteilung in verschiedene Geschwindigkeitsgruppen ist an dieser Stelle sinnvoll. Die Umschaltung erzeugt den Eindruck von mehreren simultanen Verbindungen. Echtes simultanes Debuggen ist bei diesem Aufbau nicht möglich, da der Switch immer nur eine Verbindung aktiviert.

Das Konzept des JTAG-Servers (Bild 3) erlaubt bis zu 128 Elemente in der Scan-Chain, wovon acht gleichzeitig aktiv sein können. Dies ermöglicht das simultane Debuggen von acht unterschiedlichen Applikationen. Durch den Einsatz des Servers mit dem dazugehörigen Debugger lassen sich die CPUs von einem oder auch von mehreren Benutzern simultan und dennoch unabhängig voneinander steuern. Die offene API des Servers erlaubt die Anbindung eigener Anwendungen, zum Beispiel zum Beschreiben der On-Board- oder On-Chip-Flash-Bausteine oder die Anbindung eigener Analyse-Tools.

Dafür spricht:

• CPUs können gleichzeitig von einem oder mehreren Debuggern bedient werden,

• keine zusätzliche Hardware nötig,

• multiple Elemente in der Scan-Chain, die per Software aktiviert werden,

• synchrones Starten und Stoppen aller CPUs und

• Zugriff auf alle Ressourcen in der Scan-Chain.

Die maximale Geschwindigkeit richtet sich jedoch nach dem schwächsten Glied in der Kette. Der JTAGServer unterstützt jedes Element in der Scan-Chain durch eine eigene „Target Firmware“, diese beinhaltet alle notwendigen Informationen, beispielsweise die Registerstrukturen (Bild 4). Derzeit ist die Firmware für „Virtex II Pro“ von Xilinx für IBM-PowerPC-405, MPC-82xx, MPC85xx, MPC-7xx und MPC74xx als Multicore-Version verfügbar.

Wind River, Tel. +49(0)89 9624450

*Stefan Freundel ist Toolspezialist bei Wind River in Karlsruhe. Kontakt: stefan.freundel@windriver.com

(ID:178755)