Entwicklungstools Potenzial von Emulations-Chips voll erschließen

Optimierte Hochleistungswerkzeuge und spezielle "Emulation Devices"
Optimierte Entwicklungswerkzeuge machen die Fähigkeiten der Emulations-Chips voll nutzbar.

Eine Idee macht Schule: Nach Infineon bieten seit Kurzem auch Freescale und STMicroelectronics für ausgewählte High-End-Mikrocontroller wie ihre MPC57xx- bzw. SPC57x-Familien spezielle »Emulation Devices« für die Entwicklung an. Optimierte Hochleistungswerkzeuge wie PLS‘ Universal Emulation Configurator (UEC) sollen Anwendern nun dabei helfen, das Potenzial dieser hochkomplexen Bausteine voll auszuschöpfen.

Bei den neuen Emulation Devices für MPC57xx bzw. SPC57x handelt es sich um äußerst komplexe Bausteine, die zusätzlich zum eigentlichen Serienchip noch eine komplexe, mit den Controller-Cores und den internen Bussen des Serienchip verbundene Emulationslogik, einen Trace-Speicher sowie eine serielle, auf dem Aurora-Protokoll basierende Hochgeschwindigkeitsschnittstelle mitbringen (Bild 1).

Die Kapazität des On-Chip-Trace-Speichers fällt wegen der begrenzten Chipfläche mit 1 MB vergleichsweise klein aus. Um die Speicherkapazität optimal ausnutzen zu können, ist deshalb eine programmierbare Logik zur Trace-Qualifizierung und Filterung vorgeschaltet. Der Programmfluss der einzelnen Cores kann aufgezeichnet werden (Instruction Pointer Trace). Außerdem ist Daten-Trace auf allen internen Bussen möglich. Eine ausgefeilte Trigger-Logik umfasst Zeitgeber, Zähler und eine Zustandsmaschine. Neben den Aufzeichnungsfunktionen sind zudem Aktionen wie Programmunterbrechung u.ä. steuerbar.

Unübersichtliche Emulationslogik im Griff

Die Emulationslogik umfasst mehrere hundert Register. Es liegt auf der Hand, dass deren Programmierung durch Setzen von einzelnen Registerwerten nicht praktikabel ist und auch ein gewöhnlicher Konfigurationsdialog nicht ausreicht. Zur Beschreibung von Mess­aufgaben wird deshalb beim Universal Emulation Configurator die Komplexität der Emulationslogik durch drei unterschiedliche Abstraktionsniveaus bei der Konfiguration gekapselt.

Die erste Stufe ist die Trace Qualification Language (TQL). Als Assembler-ähnliche Sprache dient sie als Anpassungsschicht zwischen den mehr Hardware-unabhängigen folgenden Schichten und der auf dem Chip vorhandenen Emulations-Hardware. TQL-Ausdrücke werden direkt in Inhalte für die Register der Emulationslogik übersetzt.

Die nächste Stufe ist eine hochsprachenähnliche Notation, die High Level Trace Qualification Language (HTQL). Sie bietet dem Entwickler die Möglichkeit, die Konfiguration der Emulationslogik auf Basis einer Zustandsmaschine zu beschreiben. Die Kernkonstrukte einer in HTQL beschriebenen Zustandsmaschine sind die „Zustandsmarken“, welche die einzelnen Zustände repräsentieren. Zugehörige if-then-else-Konstrukte lösen unter den angegebenen Bedingungen Aktionen und die Zustandsübergänge (goto) aus. Für die Initialisierung einer Trace-Konfiguration wird der Beschreibung der Zustandsmaschine ein Deklarationsteil vorangestellt, der jedoch vom HTQL-Compiler nicht ausgewertet, sondern direkt nach TQL transferiert wird. In dieser Stufe lässt sich bereits eine gute Abstraktion der konkreten Hardware-Realisierung erzielen.

Die dritte Abstraktionsstufe zur Konfiguration der Emulationslogik bildet schließlich ein grafischer Editor. Er ist als Add-in innerhalb der Universal Debug Engine von PLS realisiert. Damit stehen dem Entwickler die Funktionen eines Debugger und die Möglichkeiten der neuen Emulation Devices parallel und integriert zur Verfügung. Der Editor basiert auf Dialogschablonen und gestattet durch Zusammenfügen und Parametrierung von Definitions-, Signal-, Zustands- und Aktionsblöcken die Definition einer Messaufgabe. Die Koppelung zwischen den Blöcken erfolgt dabei über Signalnamen. Der flexible Editor dient als Eingabewerkzeug für den HTQL-Compiler und erzeugt aus der grafischen Repräsentation einer Zustandsmaschine direkt den zugehörigen HTQL-Code. Häufig gebrauchte Konfigurationen sind in vordefinierten Blöcken in einer Bibliothek abgelegt. Diese kann geändert oder mit eigenen Elementen ergänzt werden.

Um ein möglichst hohes Maß an Modularität, Flexibilität und Nutzerfreundlichkeit zu erzielen, wurde als Datenformat XML gewählt. Analyseaufgaben, die auf Basis der Bibliothekselemente erstellt wurden, lassen sich ebenfalls im XML-Format sichern und laden. Ein Block wird neben den ergänzenden Informationen für den Nutzer im Wesentlichen durch drei Komponenten beschrieben. Dabei handelt es sich um das grafische Erscheinungsbild, die Definition der Parameter sowie um das Template für den zugehörigen HTQL-Codeabschnitt.

Auf diesem Weg ist es möglich, jedes beliebige HTQL-Konstrukt auch als grafisches Element verfügbar zu machen. Die Blöcke können beliebig ausgewählt, angeordnet und verknüpft werden. Einmal definierte Signalnamen und Zustände stehen in den anderen Blöcken sofort zur Parametrierung zur Verfügung. Ebenso kann der gesamte Symbolvorrat der vom Debugger geladenen Applikation während der Parametrierung genutzt werden. Bild 2 zeigt den Editor mit einem Ausschnitt aus einer Messaufgabe.