Konfiguration komplexer On-Chip-Emulatoren Klare Sicht auf den ARM-Core

Moderne ARM-Cores können Entwickler nur über On-Chip-Emulatorschaltungen wie »CoreSight« debuggen. Doch für die anfallenden Tracedaten steht auf dem Chip nicht genug Speicher zur Verfügung...

Konfiguration komplexer On-Chip-Emulatoren

Moderne ARM-Cores können Entwickler nur über On-Chip-Emulatorschaltungen wie »CoreSight« debuggen. Doch für die anfallenden Tracedaten steht auf dem Chip nicht genug Speicher zur Verfügung, hier ist trickreiche Filterlogik gefragt. Mithilfe aktueller Tools lässt sich die On-Chip-Emulatorlogik inklusive Filterung in weiten Grenzen für die jeweilige Messaufgabe konfigurieren.

Der Trend zu »Systems on Silicon« (SoS), hohen Taktfrequenzen und der Integration mehrerer Prozessorkerne auf einem Chip hat dazu geführt, dass sich heutige High-End-Mikrocontroller ohne Integration von komplexen On-Chip-Emulatoren nicht mehr effizient testen lassen. Kam bei früheren Generationen von Einzelprozessoren für das Filtern und Zwischenspeichern der anfallenden Daten im Entwicklungsprozess noch ausschließlich externe Hardware zum Einsatz, so sind diese Funktionen heute bereits immer häufiger mit auf dem Chip integriert.

On-Chip-Emulatoren lassen sich jedoch nicht nur zur Beseitigung von Softwarefehlern nutzen, eine ganze Reihe weiterer Aktivitäten erfordern dieselben oder ähnliche Strukturen und Mechanismen. Hierzu zählen unter anderem die Optimierung von Parametern und die Bewertung des zeitlichen Verhaltens des Gesamtsystems unter Echtzeitbedingungen und in der realen Umgebung. Solche anspruchsvollen Testaufgaben bedingen umfangreiche Beobachtungsmöglichkeiten für die komplexen Systemzustände. Nur wie lassen sich die Zustände des Systems in Echtzeit verfolgen, ohne dabei dessen Verhalten wesentlich zu beeinflussen?

Traditionelle In-Circuit-Emulatoren (ICE) zur Analyse des anwendungsabhängigen Verhaltens von Prozessoren sowie Logikanalysatoren zur Analyse der Busse oder sonstiger Signalleitungen zwischen Systemkomponenten sind vor allem als Zwischenspeicher großer Datenmengen konzipiert. Die Logik zum Filtern der anfallenden Daten ist auf Grund der großen zu speichernden Datenmengen und der diskreten beziehungsweise auf programmierbarer Logik basierenden Implementierung der ICE in der Komplexität beschränkt.

Für On-Chip-Emulatoren hingegen stellt die Komplexität der integrierten Logik zum Filtern der mit wesent lich höheren Datenraten anfallenden chipinternen Daten aufgrund der verfügbaren Chipdesign-Werkzeuge und der Integration auf dem Chip kein Problem dar. Im Gegenteil: Sie ist mehr oder weniger sogar zwingend notwendig, da die auf dem Chip verfügbare Speicherkapazität für Tracedaten begrenzt ist.

On-Chip-Debugging in ARM-Systemen

Daraus ergeben sich völlig neue Ansatzpunkte zur Implementierung der Software-Unterstützung für derartige Werkzeuge. Hatte früher die Analyse der sehr umfangreichen Datenmengen von Aufzeichnungsdaten nach dem Ende des Mess- oder Testablaufs noch höchste Priorität, so stellt für On-Chip-Emulatoren die Programmierung der komplexen Logik zum Filtern der Trace-Daten vor dem Start der Messaufgabe die größte Herausforderung für die Software-Unterstützung derartiger Systeme dar.

Ohne zu tief in die Details des HTQL-Compilers einzudringen, soll kurz die prinzipielle Funktionsweise erläutert werden. Zunächst wird die HTQL-Quelle einer lexikalischen Analyse unterzogen und in ein compilerinternes, noch zustandsbasiertes Zwischenformat transformiert. Für alle Aktionen in den »THEN«-Blöcken werden dann die nicht negierten Ereignisse und analog für die Aktionen der »ELSE«-Blöcke die negierten Ereignisse bestimmt und über die Zustandsgrenzen hinweg für alle Aktionen eines Typs zusammengefasst. Zähler bzw. deren erzeugte Ereignisse, die hardwareseitig zur Verfügung stehen, repräsentieren die einzelnen Zustände der State-Machine. Auf diese Weise gelingt es, die zustandsbasierte Darstellung in eine kombinatorische Repräsentation (disjunktive Normalform) zu überführen. Mit Hilfe gängiger Techniken des Schaltungsentwurfs werden Optimierungen vorgenommen, um eine bessere Ausnutzung der Emulatorhardware zu erreichen. In der nachfolgenden Phase werden zu jeder zu generierenden Aktion und zu jedem zugehörigen Ereignis die Ressourcen im ESB (Registerbelegungen) bestimmt und, wenn verfügbar, reserviert. Abschließend erfolgt die Ausgabe als TQL-Skript.

Die dritte Stufe und gleichzeitig das eigentliche Nutzerinterface bildet ein maskenbasierter, blockorientierter Editor (Bild 5). Dieser setzt als Frontend auf dem HTQL-Compiler auf und erzeugt aus einer aus vordefinierten Bausteinen zusammengesetzten Messaufgabe den zugehörigen HTQLCode. Die einzelnen Bausteine, welche häufig benötigte Messaufgaben, Definitionen bzw. Grundelemente zur Beschreibung von Zustandsautomaten beinhalten, sind in Bibliotheken zusammengefasst. Diese lassen sich beliebig erweitern oder durch eigene ergänzen. Als Datenformat wurde XML gewählt, um ein hohes Maß an Modularität, Flexibilität und Nutzerfreundlichkeit zu erzielen. Auf Basis der Bibliothekselemente erstellte Analyseaufgaben lassen sich ebenfalls im XML-Format zur späteren Wiederverwendung sichern. Für einen einzelnen Baustein werden dessen Erscheinungsbild im Editor, die Parameter zur Anpassung an die jeweilige Messaufgabe und ein Template des zu erzeugenden HTQL-Codefragments beschrieben. Damit ist es möglich, jedes beliebige HTQL-Konstrukt auch als grafisches Element verfügbar zu machen.

Bei der Implementierung von CoreSight existiert eine große Anzahl von 32-Bit-Registern für die Konfiguration der Emulator-Hardware. Zur Vorbereitung einer konkreten Analyseaufgabe sind diese vorher entsprechend einzustellen. Hierfür sind allerdings sowohl neue Konzepte als auch Werkzeuge zu deren Unterstützung erforderlich. Um einen möglichst hohen Freiheitsgrad bei der Beschreibung von Analyseaufgaben zu haben, hat pls einen »Universal Emulation Configurator« mit drei verschiedenen, hierarchisch aufeinander aufsetzenden Abstraktionsebenen entwickelt (Bild 2). Eine standardisierte Darstellung der internen Debug-Struktur – basierend auf einer Erweiterung der Architektur-Spezifikations-Sprache »IP-XACT« – beschreibt die an die Hardware angepasste Umsetzung. Somit muss der Software-Entwickler die On-Chip-Emulatorstruktur nicht unbedingt im Detail kennen. Die erste Stufe ist eine Assembler-ähnliche Notation und verwendet direkt die Ressourcen der Emulatorhardware. Der Sprachumfang dieser als »Trace Qualification Language« (TQL) bezeichneten Notation orientiert sich stark an der Kombinatorik der Emulatorhardware zur Erzeugung und Auswertung der Triggersignale und Tracedaten (Bild 3). Mittels Assemblieren eines TQL-Skripts lassen sich die Konfigurationsinformationen für die kombinatorischen Verknüpfungen erzeugen, welche als Registerbelegungen in die Register des Moduls geladen werden (Bild 4).