Worauf es in der Praxis ankommt
On-Chip-Infrastrukturen für Debugging und Test
Fortsetzung des Artikels von Teil 3
Spurensuche – Systembeobachtung durch Trace
Heutige Mikrocontroller bieten neben der traditionellen Debugging-Unterstützung, also Stop-Go-Betrieb und Speicher lesen/schreiben, inzwischen oftmals auch On-Chip-Trace, um das Systemverhalten zur Laufzeit ohne dessen Beeinflussung beobachten und auch exakt messen zu können. Allerdings ist dafür ein erheblicher Mehraufwand auf der Hardware- und Toolseite nötig. Aufgrund der benötigten Chipfläche sind Trace-Einheiten, die sich direkt an die Cores und Busse ankoppeln und anschließend die aufgezeichneten Daten zum Debugger übertragen müssen, recht teuer. Die Chiphersteller versuchen daher ein wirtschaftliches akzeptables Trade-Off für ihre Implementierungen zu finden, was natürlich wiederum direkte Konsequenzen für die Anwendung hat:
- Die Beobachtbarkeit der internen Abläufe ist begrenzt. So steht bei CoreSight-Implementierungen beispielsweise häufig nur der Program-Trace zur Verfügung, den Daten-Trace sparen manche Chiphersteller aus Kostengründen komplett ein. Oder aber in Multicore-Systemen kann nur eine begrenzte Auswahl der Kerne gleichzeitig beobachtet werden, wie es bei Infineons MCDS (Multi-Core-Debug-Solution) der Fall ist.
- Vor der Übertragung der aufgezeichneten Trace-Daten zum Debugger werden diese zunächst in einem Chip-internen Trace-Speicher gepuffert. Die Übertragung der Daten zum Debugger erfolgt dann zwar über die relativ kostengünstige Debug-Schnittstelle, jedoch muss dafür ausreichende Chipfläche für den Speicher bereitgestellt werden. Oder die Trace-Daten werden direkt nach ihrer Erzeugung zum Debugger übertragen. Da dafür oftmals eine spezifische Trace-Schnittstelle von Nöten ist, gehen damit aber wiederum ein erhöhter Aufwand und Kosten einher. .
Insbesondere der zweite Punkt verdient aus Anwendersicht etwas mehr Aufmerksamkeit. Wie beschrieben, können die Trace-Daten entweder in einem Chip-internen Speicher abgelegt werden, oder über eine Schnittstelle mit ausreichender Bandbreite direkt zum Debugger übertragen werden. Im ersten Fall wird die Aufzeichnungszeit durch die sehr beschränkte Größe des internen Trace-Speichers - wir reden von wenigen KByte bis maximal 2 MByte - stark eingeschränkt. Je nach Applikation und Art der aufgezeichneten Daten sind hier nur wenige Millisekunden Aufzeichnungszeit realistisch, bevor der Speicher komplett gefüllt ist. Damit lässt sich zwar Trace-basiertes Debugging betreiben, also beispielsweise die Historie einer Exception rückverfolgen. Für Trace-basierte Analysen, beispielsweise für die Ermittlung des Code Coverages oder für Profiling, reicht das aber nur in den seltensten Fällen. Eine Ausnahme ist der Compact-Function-Trace von Infineon. Hier werden nur Funktionsein- und -aussprünge aufgezeichnet, was zu sehr geringem Datenaufkommen und damit zu langen Aufzeichnungszeiten führt. Damit lassen sich sowohl Profiling als auch Call-Graph-Analysen mit wenig Trace-Speicher realisieren.
Für längere Aufzeichnungen mit großem Datenaufkommen müssen die Traces zwangsläufig über eine geeignete Schnittstelle zum Debugger übertragen werden. Über viele Jahre hinweg wurden dafür parallele Schnittstellen, wie sie von ARM oder aber vom Nexus-Standard definiert sind, eingesetzt. Natürlich ist das recht teuer, da hier die entsprechende Anzahl von Pins von Nöten ist. Auch ist die mit vertretbarem Hardwareaufwand erzielbare Bandbreite auf etwa 250 MByte/s begrenzt, was bei heutigen Multicore-Systemen mit hohen Taktfrequenzen nicht mehr ausreicht. Seit einigen Jahren sind daher serielle Highspeed-Interfaces auf dem Vormarsch (Bild 4). Diese kommen aufgrund von differenziellen Signalen mit vier Pins, jeweils zwei pro Daten-Lane und zwei für den Takt, aus und erreichen in gegenwärtigen Implementierungen schon etwas höhere Datenraten wie der Parallel-Trace. Es ist bereits absehbar, dass hier bei einigen Bausteinen in Kürze der Sprung in den GByte/s-Bereich erfolgen wird. Aktuell finden wir serielle Trace-Interfaces, die das Xilinx-AURORA-Protokoll nutzen, bei den AURIX-Bausteinen von Infineon und bei der letzten Generation der PowerArchitecture-Familien von NXP und STMicroelectronics. Zukünftig werden serielle Interfaces aber sicherlich auch in die ARM-Welt Einzug halten, dann in Form des HSSTP (High Speed Serial Trace Port), der ebenfalls das AURORA-Protokoll umsetzt.
Zwar sind serielle Highspeed-Interfaces hinsichtlich ihrer Hardware-Umsetzung sowohl Chip- als auch Tool-seitig deutlich aufwendiger und damit auch teurer als parallele Schnittstellen, jedoch führt angesichts der immer leistungsfähiger werdenden Controller mit immer mehr Kernen, komplexerem Interconnect und höheren Taktfrequenzen zukünftig wohl kein Weg daran vorbei. Gerade im Umfeld tief eingebetteter Systeme mit hohen Anforderungen an funktionale Sicherheit und Echtzeit ist umfassender Trace für das Debugging und vor allem für die Systemanalyse ein absolutes Muss.
Jobangebote+ passend zum Thema
- On-Chip-Infrastrukturen für Debugging und Test
- Funktionale Schnittstellen – die bessere Lösung?
- Komplette Debug-IP: ARM CoreSight
- Spurensuche – Systembeobachtung durch Trace
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Systemdesign / Debug & Trace
Universalwerkbank für Mikrocontroller
DESIGN&ELEKTRONIK TechTalk
MCUs werden immer komplexer, was tun?
Debugging für Profis
Branch Coverage für optimierten Code
