Suchen

Die Suche nach des Pudels Kern

Hilfsmittel und Werkzeuge für das Multicore-Debugging

Seite: 3/3

Firmen zum Thema

Multi-Core Run Control Manger: Die UDE ermöglicht eine Konfiguration des synchronen Haltens und Startens für einzelne Cores oder Core-Gruppen.
Multi-Core Run Control Manger: Die UDE ermöglicht eine Konfiguration des synchronen Haltens und Startens für einzelne Cores oder Core-Gruppen.
(Bild: PLS)

Entwicklern wäre es erfahrungsgemäß freilich am liebsten, wenn sie sich mit solchen unterschiedlichen Gesichtspunkten erst gar nicht im Detail auseinandersetzten müssten. Deshalb kommen für das Debugging von Multicore-Systemen auch zunehmend stark visualisierende Werkzeuge wie beispielsweise die Universal Debug Engine (UDE) von PLS zum Einsatz, bei denen die unnötigen Details bezüglich der Konfiguration des synchronen Run-Controls durch den Debugger verborgen bleiben. Mit Hilfe des integrierten Multi-Core-Run-Controllers der UDE lassen sich nicht nur schnell und einfach beliebige Run-Control-Gruppen definieren (siehe Bild) – die zugehörigen Kerne können auch synchron angehalten und wieder gestartet werden.

Spuren mit Trace verfolgen

Gerade wenn es um Echtzeitanwendungen geht, gibt es neben dem synchronen Run-Control noch eine weitere wichtige Grundvoraussetzung für eine genaue und zuverlässige Systemanalyse: Den On-Chip-Trace. Natürlich steht diese Technologie auch bei den oben genannten Multicore-Controllern zur Verfügung. Freescale beispielsweise setzt für seine MPC57xx-Familie auf Nexus [2], Infineon nutzt dafür die bereits in anderem Zusammenhang erwähnte Multi-Core-Debug Solution (MCDS) und ARM das bereits bekannte CoreSight. Allen gemein ist die Möglichkeit, Trace für mehrere Kerne parallel aufzuzeichnen, bei der MCDS ist dies allerdings auf maximal zwei auswählbare Kerne limitiert. Zeitstempel erlauben die zeitliche Zuordnung der Trace-Daten, um die genaue Abfolge von Ereignissen zu rekonstruieren. Damit lassen sich zum einen Verklemmungen und Race-Conditions aufspüren, zum anderen aber auch Flaschenhälse in der Kommunikation.

Eine große Herausforderung besteht nun darin, die aufgezeichneten Trace-Daten zum Debugger zu übertragen, der dann die weitere Analyse vornimmt. Entweder werden diese auf dem Chip in einem Trace-Buffer zwischengespeichert und per Debug-Schnittstelle ausgelesen, oder aber über ein breitbandiges Interface während der Aufzeichnung übertragen. Ersteres bietet natürlich eine viel höhere Bandbreite, aber nur eine sehr begrenzte Speicherkapazität. Letzteres erlaubt zwar eine theoretisch unbegrenzte Beobachtungsdauer, dafür kann es aber häufiger zu Überläufen kommen, wenn mehr Trace-Daten anfallen, als übertragen werden können. In beiden Fällen schaffen ausgeklügelte Filter- und Trigger-Mechanismen Abhilfe, welche die Menge der Trace-Daten einschränken.

Auch sogenanntes Cross-Triggering ist damit möglich. Damit lässt sich beispielsweise der Trace für einen Kern starten, wenn eine Bedingung für einen anderen Kern wahr wird. Hilfreich ist diese Funktion beispielsweise, um Kommunikationen zwischen den Kernen zu debuggen. Bei der MCDS und bei CoreSight zählt das Cross-Triggering zu den Standardfunktionen. Allerdings konkurriert das Cross-Triggering bei CoreSight mit dem synchronen Run-Control, da beide die gleichen Hardwareressourcen verwenden. Freescale hingegen musste seine Nexus-Implementierung extra um eine proprietäre Einheit, die sogenannte Sequence Processing Unit (SPU) erweitern, da im Nexus-Standard Cross-Triggering nicht vorgesehen ist.

Auch bei der zielgerichteten Beobachtung des Systemverhaltens mittels Trace sowie der anschließenden Auswertung und Analyse sind die Fähigkeiten des Debuggers gefragt. Für die Erstellung von Trace-Aufgaben stellt die UDE beispielsweise ein grafisches Werkzeug zur Verfügung, mit dem sich selbst komplexe Cross-Trigger recht einfach konfigurieren lassen. Das Ganze funktioniert für verschiedenste On-Chip-Trace-Systeme, ohne dass sich der Anwender um die technischen Details kümmern muss. Verschiedene Ansichten, die beispielsweise die parallele Ausführung von Code auf mehreren Kernen visualisieren, erleichtern die Trace-Auswertung. Falls gewünscht oder benötigt, lassen sich mit Hilfe des Debuggers auch Profiling-Informationen gewinnen oder Code-Coverages bestimmen. Diese beiden Optionen sind jedoch nicht Multicore-spezifisch, sondern vielmehr für die Systemanalyse und –optimierung von allgemeinem Nutzen.

Fazit

Ohne die Unterstützung durch geeignete Hardware auf dem Chip wäre das Multi-core-Debugging für tief eingebettete Systeme nur sehr mühsam zu bewerkstelligen. Auch ein moderner Debugger stößt unweigerlich an seine Grenzen, wenn es um synchrones Anhalten und Starten von mehreren Kernen geht. Wirklich synchrones Run-Control wird sogar überhaupt erst durch geeignete On-Chip-Debug-Hardware mit konfigurierbaren Cross-Triggern möglich. Ähnliches gilt für die umfassende Systemanalyse von Multicore-Applikationen. Ohne On-Chip-Trace sind auch hier die Grenzen des Machbaren schon schnell erreicht. Die gute Nachricht: Auch wenn die Chiphersteller bzgl. des On-Chip-Debugging keinem einheitlichen Standard folgen, kommen moderne Debugger damit durchaus gut damit zurecht. Und moderne Debugger wie die UDE erlauben dem Entwickler zudem eine einfache Nutzung der Funktionen, so dass er sich nur selten mit den Chip-spezifischen Besonderheiten beschäftigen muss.

Literaturhinweise:

[1] ARM Ltd: CoreSight Debug and Trace; http://www.arm.com/products/system-ip/debug-trace/

[2] Nexus 5001 Forum: IEEE-ISTO 5001-2012, The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface; http://nexus5001.org

* Jens Braunes ist Software-Architekt bei der PLS Programmierbare Logik & Systeme GmbH in Lauta. Sein Fokus liegt dabei auf dem Design von Softwarekonzepten zur Anwendung von On-Chip-Emulatoren.

(ID:43763028)