Schwerpunkte

Drei aktuelle On-Chip-Trace-Verfahren im Vergleich

Auf den Spuren der Fehler

14. November 2007, 15:37 Uhr   |  Heiko Riessland und Jens Braunes


Fortsetzung des Artikels von Teil 2 .

Neue Möglichkeiten erfordern neuartige Werkzeuge

In Tabelle 3 sind die Eigenschaften bezüglich Trace für IEEE-ISTO 5001 Nexus Standard, ETM und MCDS gegenübergestellt. Alle drei Konzepte geben dem Applikationsentwickler ein mächtiges Werkzeug in die Hand, um das System unter Echtzeit-Bedingungen zu debuggen und das Systemverhalten zu diagnostizieren. ETM und MCDS bieten allerdings gegenüber Nexus mehr Möglichkeiten, die Trace- Aufzeichnung direkt auf dem Chip zu steuern. Durch gezielte Konfiguration der Filter- und Triggerlogik im Vorfeld der eigentlichen Trace-Aufzeichnung ist es möglich, nur die wirklich relevanten Daten zu sammeln. Dies ist notwendig, da sowohl der Trace-Kanal zum Debug-Host als auch die Speicherkapazität des On-Chip-Trace- Speichers einen Flaschenhals im System darstellen. Das Nexus zugrunde liegende Konzept vertraut eher auf die Analysefähigkeiten des Cross-Debuggers, der zur Laufzeit die entsprechenden Konfigurationen der Filter- und Triggerlogik vornehmen soll.

Die Möglichkeit, Trace-Daten direkt auf dem Chip vorzuverarbeiten, stellt eine neue Qualität in Bezug auf die Software-Unterstützung der On-Chip-Trace-Konzepte dar. Um so komplexe Systeme wie MCDS oder ETM/CoreSight für eine Analyseaufgabe zu konfigurieren, ist es allerdings kaum praktikabel, die dafür notwendigen Steuerregister mit entsprechenden Werten manuell per Hand zu beschreiben. Hier bedarf es umfassender Tool-Unterstützung seitens der Debugger-Hersteller, wie sie beispielsweise für die MCDS mit dem Universal Emulation Configurator (UEC) gegeben ist [4].

Aufgrund ihrer Eigenschaft, das Laufzeitverhalten des Systems nicht zu beeinflussen, sind On-Chip-Trace- Lösungen geeignet, um das Zeit- und Ausführungsverhalten echtzeitkritischer Applikationen zu untersuchen. Typische Profiling-Aufgabenstellungen wie Laufzeitmessungen oder Execution- Counting sind ohne zusätzliche Code-Instrumentierung, welche das Echtzeit-Verhalten verfälschen würden, möglich. Der Einsatz von komplexer On-Chip-Trace-Hardware treibt aber auch die Kosten für die Mikrocontroller in die Höhe. Nicht nur die zusätzliche Chip-Fläche, die für die Integration benötigt wird, sondern auch die größere Anzahl von Pins, die für die breitbandigen Debug-Kanäle erforderlich sind, stellen einen nicht zu vernachlässigenden Kostenfaktor dar. Auch aus diesem Grund wird MCDS beispielsweise nur für spezielle ED-Varianten der TriCore-Familie realisiert.

Ferner stellen die zusätzlichen Leitungen der Trace-Kanäle in Umgebungen mit rauhen Umweltbedingungen oftmals ein Problem dar. Die Ideallösung für diesen Fall wäre eine integrierte Debug-Schnittstelle, die maximal ein bis zwei Übertragungsleitungen benötigt, mindestens den Durchsatz der heutigen JTAG-Schnittstellen bietet und auch noch im fertigen Gerät leicht verfügbar ist. Eine solche Schnittstelle ist zurzeit leider noch nicht verfügbar. Einige Prozessor-Hersteller haben allerdings diese Herausforderung erkannt und arbeiten an entsprechenden Lösungen. Bis dahin gilt es in jedem Einzelfall zu prüfen, ob es sich gegebenenfalls lohnt, den höheren Aufwand einer auch im produktiven Gerät zugänglichen JTAG-Schnittstelle einzuplanen, die dann zu jeder Zeit einen Zugriff auf das System und die Nutzung integrierter On-Chip-Trace-Lösungen inklusive Trace-Speicher ermöglicht.

tabelle3_26.jpg
©

Tabelle 3. Gegenüberstellung der Trace-Eigenschaften von Nexus, ETM und MCDS (a) TC1766ED; b) TC1796ED)

Große Fortschritte im Debugging

Mit IEEE-ISTO 5001 Nexus als herstellerunabhängigem Standard, der Embedded Trace Macrocell von ARM sowie Infineons Multi-Core Debug Solution (MCDS) ist es ohne Einflussnahme auf das Echtzeit-Verhalten möglich, das Laufzeitverhalten aufzuzeichnen und interne Systemzustände zu analysieren. Im Gegensatz zu traditionellen Debug-Methoden erlauben die aufgezeigten Verfahren zudem eine weitgehend uneingeschränkte Sicht auf die Systemkomponenten (Cores, Busse), selbst im produktiven Einsatz. Trotz einiger noch zu nehmender Hürden stehen die im Beitrag beschriebenen und gegenübergestellten On-Chip- Trace-Konzepte schon heute für eine völlig neue Qualität des Debuggings und der Systemanalyse.

[1]The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface Version 2.0; http://www.nexus5001.org/standard2.html
[2]Embedded Trace Macrocells Product Overview; http://www.arm.com
[3]Mayer, A.; Siebert, H.; Scheibert, K.: Development Tool Support Architecture for High-Performance Automotive Control Units. Euro DesignCon, 2004.
[4]Braunes, J: Easy Configuration of Complex On-Chip Emulators. ECE Magazin, März 2006.

Dipl.-Inf. Heiko Riessland war nach erfolgreichem Abschluss des Infomationstechnik-Studiums an der Technischen Universität Dresden zehn Jahre in der Entwicklung und im Vertrieb von Software-Entwicklungswerkzeugen und Emulatoren für 16- und 32-bit-Mikrokontroller tätig. Seit fünf Jahren leitet er das Produktmarketing der pls Programmierbare Logik & Systeme GmbH.
heiko.riessland@pls-mc.com
Dipl.-Inf. Jens Braunes ist bei der pls Programmierbare Logik & Systeme GmbH in Lauta für die Software-Unterstützung von On-Chip-Emulatoren zuständig. Zuvor war er an der Technischen Universität Dresden im Bereich der Compiler-Entwicklung für rekonfigurierbare Prozessor-Architekturen tätig.
jens.braunes@pls-mc.com

Seite 3 von 4

1. Auf den Spuren der Fehler
2. Nur die Daten aufzeichnen, die auch benötigt werden
3. Neue Möglichkeiten erfordern neuartige Werkzeuge
4. Für ARM-Cores: Emdedded Trace Macrocell (ETM)

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen