Autor: Jens Braunes, PLS Programmierbare Logik & Systeme GmbH<\/p>\n
Beim Debugging tief eingebetteter Multicore-Systeme geht es nicht mehr nur um das Aufsp\u00fcren von falschen Variablenwerten. Auf der Tagesordnung stehen vielmehr Deadlocks, Ressourcenkonflikte oder Timing-Probleme. F\u00fcr den Entwickler bedeutet das eine gro\u00dfe Herausforderung, die nur durch geeignete Unterst\u00fctzung durch On-Chip-Debugfunktionen im engen Zusammenspiel mit leistungsf\u00e4higen Softwarewerkzeugen gemeistert werden kann. Der folgende Beitrag stellt solche L\u00f6sungen vor und zeigt ihre M\u00f6glichkeiten, aber auch ihre Grenzen. \u00a0\u00a0<\/strong><\/p>\n Wenn man nur den Consumer-Markt betrachtet, sind Multicore-Systeme schon seit zehn Jahren im Mainstream angekommen. Bei den tief eingebetteten Systemen hingegen, wie wir sie vor allem in Industrieanwendungen oder bei Automotive-Steuerungen finden, wurde der Technologiewechsel erst in den letzten Jahren vollzogen, und das auch recht z\u00f6gerlich. Ein Grund daf\u00fcr sind sicherlich die hohen Anforderungen an Sicherheit, Zuverl\u00e4ssigkeit und Echtzeit, die in den genannten Bereichen nun einmal absoluten Vorrang genie\u00dfen. Aber auch das umfangreiche Portfolio an bew\u00e4hrten und gut getesteten Softwaremodulen f\u00fcr Singlecore-Systeme, deren Portierung auf mehrere Kerne einen nicht zu untersch\u00e4tzenden Aufwand bedeutete, bremste hier sicherlich einen schnelleren Vormarsch aus. Und nicht zu vergessen:<\/p>\n Multicore ist nicht gleich Multicore<\/strong><\/p>\n Beim aus der Windows-, Linux- und Android-Welt bekannten Multicore-Ansatz k\u00f6nnen Tasks und Prozesse dynamisch erzeugt werden, die dann je nach Last auf einem beliebigen Kern zur Ausf\u00fchrung kommen. Das ist m\u00f6glich, weil die verwendeten Prozessoren \u00fcber identische Rechenkerne verf\u00fcgen, es sich also um homogene Multicore-Systeme handelt. Jeder Kern ist in der Lage und auch geeignet, zugewiesene Tasks gleicherma\u00dfen auszuf\u00fchren.<\/p>\n Industrial- und Automotive-Anwendungen erfordern allerdings in der Regel festgelegte Abarbeitungszeiten f\u00fcr einzelne Tasks und garantierte Antwortzeiten. Deshalb kommen hier zumeist heterogene Multicore-Systemen mit mehreren speziell auf eine bestimmte Aufgabe zugeschnittenen Kernen zum Einsatz, wie das Beispiel der AURIX\u2122-Mikrocontroller aus dem Hause Infineon verdeutlicht (s. Abbildung 1,\u00a0PDF<\/a>). Zwar stammen die drei Hauptkerne allesamt aus der TriCore-Architekturfamilie, jedoch sind nur zwei davon als sogenannte Performancekerne (P-Cores) f\u00fcr normale rechenintensive Aufgaben vorgesehen. Die dritte, als Economy-Kern (E-Core) bezeichnete Zentraleinheit \u00fcbernimmt vorrangig die Verwaltung der Peripherals und allgemeine, weniger Rechenleistung erforderliche Aufgaben. F\u00fcr sicherheitskritische Tasks wurde einer der P-Cores und der E-Core mit einem zus\u00e4tzlichen Lockstep-Core ausgestattet, der im Hintergrund die gleichen Operationen wie der eigentliche Kern ausf\u00fchrt. Tritt beim Vergleich der Ergebnisse eine Abweichung auf, so arbeitet das System nicht mehr zuverl\u00e4ssig. Es muss \u00a0gegebenenfalls in einen sicheren Zustand zur\u00fcckversetzt werden.<\/p>\n Komplexe Zeitsteueralgorithmen sowie die effiziente und parallele Verarbeitung von Signalen unterst\u00fctzt ein vierter „Kern“, das sogenannte Generic Timer Module (GTM). V\u00f6llig andersartig als die TriCore-Kerne, ist das GTM dennoch \u00fcber einen eigenen Befehlssatz programmierbar. Dadurch k\u00f6nnen auch Tasks darauf ausgef\u00fchrt werden.<\/p>\n Wenn es also um die Verteilung der Applikationslasten auf die Rechenkerne geht, kann man hier kaum auf das Betriebssystem vertrauen. Vielmehr muss bereits w\u00e4hrend des Softwareentwurfs klar sein, welcher Kern welche Aufgaben zu \u00fcbernehmen hat.<\/p>\n Vor allem Applikationen, die ihre einzelnen Aufgaben mit hohen Echtzeitanforderungen und verteilt auf unterschiedliche Rechenkerne abarbeiten, stellen f\u00fcr Debugging, Test und Systemanalyse oftmals eine gro\u00dfe Herausforderung dar. So wirken sich die im Normalfall zumeist ziemlich gro\u00dfen Abh\u00e4ngigkeiten zwischen den auf unterschiedlichen Kernen ausgef\u00fchrten Tasks nat\u00fcrlich auf das Stop-Go-Debugging aus. Man kann nicht einfach unbedacht einen Kern anhalten, w\u00e4hrend alle anderen weiterlaufen. Mitunter m\u00fcssen auch die restlichen Kerne und die Peripherals gleichzeitig angehalten werden, damit die Applikation nicht g\u00e4nzlich au\u00dfer Tritt und in einen undefinierten Zustand ger\u00e4t. Ein wirklich gleichzeitiges Anhalten ist aber bei heterogenen Kernen mit unterschiedlicher Taktung und Ausf\u00fchrungs-Pipelines kaum m\u00f6glich. 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, beispielsweise wenn parallel noch andere Anwendungen laufen, die zu diesen Zeitpunkt nicht debuggt werden sollen oder d\u00fcrfen. Die genannten Anwendungsszenarien machen deutlich, wie wichtig ein flexibles, synchrones Run-Control f\u00fcr die Multicore-Debug-Infrastruktur ist.<\/p>\n 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 f\u00fcr die Beobachtung der Kommunikation zwischen den Kernen eine wichtige Rolle. Oftmals ist es w\u00fcnschenswert, den jeweiligen Systemzustand zu einem bestimmten Zeitpunkt mit Hilfe des extern angeschlossenen Debuggers aus dem Target-System auslesen zu k\u00f6nnen. Allerdings w\u00fcrde ein Anhalten der Applikation das Systemverhalten unter Umst\u00e4nden so grundlegend ver\u00e4ndern, dass es nichts mehr mit dem ohne angeschlossenen Debugger zu tun h\u00e4tte. Daraus folgt: F\u00fcr eine effiziente nicht-intrusive Systembeobachtung ist Tracen unerl\u00e4sslich.<\/p>\n Doch zuerst noch einmal zur\u00fcck zum Thema synchrones Run-Control. Hierf\u00fcr sind schnelle Signalwege zwischen den Kernen not\u00adwendig, die sich nur mit Debug-Hardware direkt auf dem Chip realisieren lassen. Stop- und Go-Signale von extern \u00fcber die Debug-Schnittstelle zu \u00fcbermitteln, w\u00fcrde bei den heutzutage \u00fcblichen hohen Taktfrequenzen viel zu lange dauern. Die Applikation k\u00e4me unweigerlich au\u00dfer Tritt.<\/p>\n Nun bietet jeder Chip-Hersteller seine eigene On-Chip Debug-L\u00f6sung an. Infineon beispielsweise nennt sie OCDS (On-Chip Debug System). Ein wichtiger Bestandteil darin ist ein Trigger-Switch, der Halt- und Suspend-Signale einzeln konfigurierbar systemweit verteilt. Damit lassen sich einzelne Rechenkerne und Peripherieeinheiten ohne Beeinflussung der restlichen Funktionsgruppen ganz gezielt gleichzeitig anhalten und wieder starten. Zus\u00e4tzlich k\u00f6nnen einzelne Trigger-Leitungen des Trigger-Switches auch \u00fcber Pins nach au\u00dfen gef\u00fchrt werden. Das ist eine interessante Option, um beispielsweise ein Oszilloskop anzuschlie\u00dfen, oder gar ein Break von au\u00dferhalb des Chips auszul\u00f6sen.<\/p>\n Neben der AURIX-Familie von Infineon gibt es nat\u00fcrlich noch eine Reihe anderer Multicore-Mikrocontroller, die den Industrial- und Automotive-Sektor abdecken, darunter beispielsweise die Freescale MPC57xx-Familie oder SoCs auf Basis der Arm-Cortex-R-Architektur. Werfen wir als erstes einen Blick auf CoreSight\u2122 [1], der On-Chip Debug-Hardware von Arm.<\/p>\n F\u00fcr die Verteilung der Break- und Go-Signalen zwischen den Kernen wird eine sogenannte Cross-Trigger-Matrix (CTM) mit daran angeschlossenen Cross-Trigger-Interfaces (CTI) genutzt. Kan\u00e4le 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\u00fcr das Run-Control zwischen Kern und CTM wahlweise entweder weiterleiten oder blockieren. Aufgrund der notwendigen Handshake-Mechanismen zwischen den beteiligten Komponenten kommt es dabei zu Signalverz\u00f6gerungen von mehreren Takten. Wie gro\u00df diese Verz\u00f6gerungen tats\u00e4chlich sind, h\u00e4ngt von der jeweiligen Implementierung und nat\u00fcrlich der Taktung der einzelnen Komponenten ab. Komplett vermeiden l\u00e4sst sich der beim synchronen Anhalten entstehende Schlupf von einigen wenigen, typischerweise im einstelligen Bereich angesiedelten Befehlen jedoch nicht. Ob allerdings der jeweilige Arm-Controller diese Hardwareunterst\u00fctzung bietet, obliegt dem Chip-Hersteller. Er ist frei in der Entscheidung, ob er die notwendigen CoreSight-Komponenten \u00fcberhaupt auf dem Chip implementiert (siehe Abbildung 2,\u00a0PDF<\/a>).<\/p>\n Auch von den Power-Architecture-basierten Controllern der MPC57xx-Familie wird das synchrone Run-Control hardwareseitig unterst\u00fctzt. Die daf\u00fcr verantwortliche Einheit hei\u00dft DCI (Debug and Calibration Interface). Der Vorteil gegen\u00fcber der Arm-L\u00f6sung: Wie beim Trigger-Switch des AURIX sind auch beim DCI die Peripherieeinheiten gleich mit angeschlossen, was ein Anhalten des gesamten Systems und nicht nur der Kerne erlaubt.<\/p>\n Freilich w\u00e4re es Entwicklern am liebsten, wenn sie sich mit solchen unterschiedlichen Gesichtspunkten gar nicht erst im Detail auseinandersetzten m\u00fcssten. Debugger verbergen deshalb die unn\u00f6tigen Details bez\u00fcglich der Konfiguration des synchronen Run-Controls hinter einer leicht zu bedienenden Oberfl\u00e4che. Ein Beispiel daf\u00fcr ist der Multi-Core Run-Control-Manager in der Universal Debug Engine (UDE) der Firma PLS (siehe Abbildung 3,\u00a0PDF<\/a>). Darin lassen sich Kerne zu Run-Control-Gruppen zusammenfassen, die dann beispielsweise an einem Breakpoint synchron angehalten und danach auch wieder synchron gestartet werden k\u00f6nnen.<\/p>\n Gerade wenn es um Echtzeitanwendungen geht, gibt es neben dem synchronen Run-Control noch eine weitere wichtige Grundvoraussetzung f\u00fcr eine genaue und zuverl\u00e4ssige Systemanalyse: den On-Chip-Trace. Nat\u00fcrlich \u00a0steht diese Technologie auch bei den oben genannten Multicore-Controllern zur Verf\u00fcgung. Freescale beispielsweise setzt f\u00fcr seine \u00a0MPC57xx-Familie auf Nexus [2], Infineon nutzt daf\u00fcr die Multi-Core Debug Solution (MCDS) [3] und Arm bietet das bereits bekannte CoreSight. Allen gemein ist die M\u00f6glichkeit, Trace f\u00fcr mehrere Kerne parallel aufzuzeichnen, bei MCDS ist dies allerdings auf maximal zwei ausw\u00e4hlbare Kerne limitiert. Zeitstempel erlauben die zeitliche Zuordnung der Trace-Daten, um die genaue Abfolge von Ereignissen zu rekonstruieren. Damit lassen sich zum einen Deadlocks und Race Conditions aufsp\u00fcren, zum anderen aber auch Flaschenh\u00e4lse in der Kommunikation.<\/p>\n Eine gro\u00dfe Herausforderung besteht nun darin, die aufgezeichneten Trace-Daten zum Debugger zu \u00fcbertragen, der dann die weitere Analyse vornimmt. Entweder werden diese auf dem Chip in einem Trace-Buffer zwischengespeichert und per Debug-Schnittstelle ausgelesen, oder aber \u00fcber ein breitbandiges Interface w\u00e4hrend der Aufzeichnung \u00fcbertragen. Ersteres bietet nat\u00fcrlich eine viel h\u00f6here Bandbreite, aber nur eine sehr begrenzte Speicherkapazit\u00e4t. Letzteres erlaubt zwar eine theoretisch unbegrenzte Beobachtungsdauer, daf\u00fcr kann es aber\u00a0 h\u00e4ufiger zu \u00dcberl\u00e4ufen kommen, wenn mehr Trace-Daten anfallen als \u00fcbertragen werden k\u00f6nnen. In beiden F\u00e4llen schaffen ausgekl\u00fcgelte Filter- und Trigger-Mechanismen Abhilfe, welche die Menge der Trace-Daten einschr\u00e4nken. Auch sogenanntes Cross-Triggering ist damit m\u00f6glich. Damit l\u00e4sst sich beispielsweise der Trace f\u00fcr einen Kern starten, wenn eine Bedingung f\u00fcr einen anderen Kern wahr wird. Hilfreich ist diese Funktion \u00a0beispielsweise, um Kommunikationen zwischen den Kernen zu debuggen. Bei MCDS und CoreSight z\u00e4hlt Cross-Triggering zu den Standardfunktionen. Allerdings konkurriert das bei CoreSight mit dem synchronen Run-Control, da beide die gleichen Hardwareressourcen verwenden. Freescale hingegen musste seine Nexus-Implementierung extra um eine propriet\u00e4re Einheit, die sogenannte Sequence Processing Unit (SPU), erweitern, da im Nexus-Standard Cross-Triggering nicht vorgesehen ist.<\/p>\n Auch bei der zielgerichteten Beobachtung des Systemverhaltens mittels Trace sowie der anschlie\u00dfenden Auswertung und Analyse sind die F\u00e4higkeiten des Debuggers gefragt. F\u00fcr die Erstellung von Trace-Aufgaben stellt die UDE beispielsweise ein grafisches Werkzeug zur Verf\u00fcgung, mit dem sich selbst komplexe Cross-Trigger recht einfach konfigurieren lassen. Das Ganze funktioniert f\u00fcr verschiedene On-Chip Trace-Systeme, ohne dass sich der Anwender um die technischen Details k\u00fcmmern muss. Verschiedene Ansichten, die beispielsweise die parallele Ausf\u00fchrung von Code auf mehreren Kernen visualisieren, erleichtern die Trace-Auswertung. Falls gew\u00fcnscht oder ben\u00f6tigt, 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\u00fcr die Systemanalyse und -optimierung von allgemeinem Nutzen.<\/p>\n Ohne die Unterst\u00fctzung durch geeignete Hardware auf dem Chip w\u00e4re das Multicore-Debugging f\u00fcr tief eingebettete Systeme nur sehr m\u00fchsam zu bewerkstelligen. Auch ein moderner Debugger st\u00f6\u00dft unweigerlich an seine Grenzen, wenn es um synchrones Anhalten und Starten von mehreren Kernen geht. Wirklich synchrones Run-Control wird \u00fcberhaupt erst durch geeignete On-Chip Debug-Hardware mit konfigurierbaren Cross-Triggern m\u00f6glich. \u00c4hnliches gilt f\u00fcr die umfassende Systemanalyse von Multicore-Applikationen. Ohne On-Chip-Trace sind auch hier die Grenzen des Machbaren schon schnell erreicht. Zwar folgen die Chiphersteller keinem einheitlichen Standard, wenn es um On-Chip-Debugging geht, jedoch kommen moderne Debugger durchaus gut damit zurecht. Und moderne Debugger wie die UDE erlauben dem Entwickler eine einfache Nutzung der Funktionen, so dass er sich nur selten mit den Chip-spezifischen Besonderheiten besch\u00e4ftigen muss.<\/p>\n [1]\u00a0 ARM Ltd:\u00a0CoreSight Debug and Trace<\/em><\/a><\/strong><\/p>\n [2]\u00a0\u00a0Nexus 5001 Forum<\/a><\/strong>:\u00a0IEEE-ISTO 5001\u2122-2012, The Nexus 5001\u2122 Forum Standard for a Global Embedded Processor Debug Interface<\/em><\/p>\n [3]\u00a0 A. Mayer, H. Siebert, C. Lipsky:\u00a0Multi-Core Debug Solution IP<\/em>; Whitepaper,\u00a0 IPextreme, 2007<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Multicore \/Mikrocontroller.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nTief eingebettetes Debugging<\/h2>\n
On-Chip Debugger<\/h2>\n
Spuren mit Trace verfolgen<\/h2>\n
Fazit<\/h2>\n
Quellen<\/h2>\n
\nMulticore – unsere Trainings & Coachings<\/h2>\n
\nMulticore – Fachwissen<\/h2>\n