Suchen

Die Suche nach des Pudels Kern

Hilfsmittel und Werkzeuge für das Multicore-Debugging

Seite: 2/3

Firmen zum Thema

Tief eingebettetes Debugging

ARM Core-Sight Debug- und Trace-Architektur mit Cross-Trigger-Einheiten: Moderne Multicore-Architekturen liefern bereits auf dem Chip selbst hardwarenahe Möglichkeiten zum Debugging mit.
ARM Core-Sight Debug- und Trace-Architektur mit Cross-Trigger-Einheiten: Moderne Multicore-Architekturen liefern bereits auf dem Chip selbst hardwarenahe Möglichkeiten zum Debugging mit.
(Bild: PLS)

Vor allem Applikationen, die ihre einzelnen Aufgaben mit hohen Echtzeitanforderungen und verteilt auf unterschiedliche Rechenkerne abarbeiten, stellen für Debugging, Test und Systemanalyse oftmals eine große Herausforderung dar. So wirken sich die im Normalfall zumeist ziemlich großen Abhängigkeiten zwischen den auf unterschiedlichen Kernen ausgeführten Tasks natürlich auf das Stop-Go-Debugging aus. Man kann nicht einfach unbedacht einen Kern anhalten, während alle anderen weiterlaufen.

Mitunter müssen auch die restlichen Kerne und die Peripherals gleichzeitig angehalten werden, damit die Applikation nicht gänzlich außer Trittin einen undefinierten Zustand gerät. Dumm nur, dass bei heterogenen Kernen mit unterschiedlicher Taktung und Ausführungs-Pipelines ein gleichzeitiges Anhalten gar nicht so einfach ist. Deshalb wird es in der Praxis immer einen gewissen Zeitversatz geben, mit dem man als Entwickler leben muss. Manchmal kann das Anhalten eines kompletten Multicore-Systems sogar fatale Folgen haben, zum Beispiel, wenn parallel noch andere Anwendungen laufen, die zu diesen Zeitpunkt nicht debuggt werden sollen oder dürfen. Die genannten Anwendungsszenarien lassen erahnen, wie wichtig ein flexibles, synchrones Run-Control für die Multicore-Debug-Infrastruktur ist.

Ein zweiter, bedeutsamer Aspekt ist die Analyse des Laufzeitverhaltens, und zwar ohne dabei selbiges zu beeinflussen. Diese nicht-intrusive Systembeobachtung spielt nicht nur bei echtzeitkritischen Anwendungen, sondern auch bei Profiling-Aufgaben oder der Kommunikationsbeobachtung zwischen den Kernen eine wichtige Rolle. Oftmals ist es wünschenswert, den jeweiligen Systemzustand zu einem bestimmten Zeitpunkt mit Hilfe des extern angeschlossenen Debuggers aus dem Target-System auslesen zu können. Ein Anhalten der Applikation würde das Systemverhalten unter Umständen allerdings so grundlegend verändern, dass es nichts mehr mit dem Zustand ohne angeschlossenen Debugger zu tun hätte. Daraus folgt: Für eine effiziente nicht-intrusive Systembeobachtung ist Tracen unerlässlich.

On-Chip Debugger

Doch zuerst noch einmal zurück zum Thema synchrones Run-Control. Hierfür sind schnelle Signalwege zwischen den Kernen not¬wendig, die sich nur mit Debug-Hardware direkt auf dem Chip realisieren lassen. Stop- und Go-Signale von extern über die Debug-Schnittstelle zu übermitteln, würde bei den heutzutage üblichen hohen Taktfrequenzen viel zu lange dauern. Die Applikation käme unweigerlich außer Tritt.

Nun bietet jeder Chip-Hersteller erfahrungsgemäß seine eigene On-Chip Debug-Lösung an. Infineon beispielsweise nennt sie OCDS. Ein wichtiger Bestandteil dieses OCDS ist der implementierte Trigger-Switch, der Halt- und Suspend-Signale einzeln konfigurierbar systemweit verteilt. Der Trigger-Switch erlaubt es, einzelne Rechenkerne und Periphiereieeinheiten ohne Beeinfussung der restlichen Funktionsgruppen ganz gezielt gleichzeitig anzuhalten bzw. wieder zu starten. Zusätzlich können einzelne Trigger-Leitungen des Trigger-Switches auch über Pins nach außen geführt werden. Die ermöglicht interessante Optionen wie beispielsweise den Anschluss eines Oszilloskops oder die externe Auslösung eines Breaks.

Neben der AURIX-Familie von Infineon gibt es natürlich noch eine Vielzahl anderer Multicore-Mikrocontroller, die den Industrial- und Automotive Sektor abdecken, darunter beispielsweise SoCs auf Basis der ARM-Cortex-R-Architektur oder Freescales MPC57xx-Familie. Werfen wir als erstes einen Blick auf den CoreSight-Baukasten [1] von ARM.

Für die Verteilung der Break- und Go-Signale zwischen den Kernen wird eine sogenannte Cross-Trigger-Matrix (CTM) mit daran angeschlossenen Cross-Trigger-Interfaces (CTI) genutzt (siehe Bild). Kanäle in der CTM leiten die Signale im Broadcast-Modus an die angeschlossenen CTIs weiter. Diese sind wiederum direkt mit den Kernen verbunden und so konfigurierbar, dass sie die Signale für das Run-Control zwischen Kern und CTM wahlweise entweder weiterleiten oder blockieren. Aufgrund der notwendigen Handshake-Mechanismen zwischen den beteiligten Komponenten kommt es dabei üblicherweise zu Signalverzögerungen von mehreren Takten. Wie groß diese Verzögerungen tatsächlich sind, hängt von der jeweiligen Implementierung und natürlich der Taktung der einzelnen Komponenten ab.

Komplett vermeiden lässt sich der beim synchronen Anhalten entstehende Schlupf von einigen wenigen, typischerweise im einstelligen Bereich angesiedelten Befehlen jedoch auch durch die CTM nicht. Außerdem ist es dem jeweiligen Chip-Hersteller seitens ARM freigestellt, ob er die notwendigen CoreSight-Komponenten überhaupt auf dem Chip implementiert.

Auch von den Power-Architecture-basierten Controllern der MPC57xx-Familie wird das synchrone Run-Control bereits hardwareseitig unterstützt. Die dafür verantwortliche Einheit heißt DCI (Debug and Calibration Interface). Der Vorteil gegenüber der ARM-Lösung: Wie beim Trigger-Switch des AURIX sind auch beim DFI die Peripherieeinheiten gleich mit angeschlossen, was ein Anhalten des gesamten Systems und nicht nur der Kerne erlaubt.

(ID:43763028)