Integrierter Emulator erlaubt Zugriff auf die internen Bus-Strukturen
Prozessor hilft beim Aufspüren von Software-Fehlern
Fortsetzung des Artikels von Teil 1
Zugriff auf interne Bus-Strukturen
Die Lösung für diese Problematik ist die monolithische Integration des Emulators im Bondout-Silizium, das zu einem so genannten „Emulation Device“ (ED) wird (Bild 2). Das „Emulation Device“ integriert neben dem Serienbaustein mit all seiner Funktionalität, den Peripherie-Blöcken und I/Os zusätzlich einen 512-Kbyte-SRAM-Speicher, mehrere Blöcke zur Bus-Überwachung sowie eine lokale CPU mit eigenem Speicher zur Emulator-Kontrolle (in diesem Fall ein weiterer PCP2-Controller). Externe Tool-Anbindungen sind durch schnelle serielle Interfaces wie USB, JTAG oder CAN realisiert.
Jobangebote+ passend zum Thema
Der zusätzliche Schaltungsteil wird auch als „Emulation Extension Chip“ (EEC) bezeichnet. Falls eine Maskenänderung des Serienbausteins nötig ist, kann dieser EEC-Teil in unveränderter Weise an einen definierten Verbindungspunkt des „Emulation Devices“ angeflanscht werden.
Ein allgemeines Problem mit traditionellen Bondout-Bausteinen war deren Gehäusegröße, die die Integration in ein Serien-Steuergerät unmöglich machte. Das „Emulation Device“ wurde so entwickelt, dass es im direkten Austausch mit einem Serien-Baustein eingesetzt werden kann. Es besitzt die gleiche Anschluss-Belegung wie der Serien-Baustein, ist jedoch um eine Gruppe zusätzlicher Pins auf der Gehäuseunterseite ergänzt. Auf der Gehäuseoberseite wurde ein weiterer Anschluss angebracht, auf dem die zusätzlichen Signale über einen optionalen Stecker verfügbar sind (Bild 3). Im Vergleich zu einem traditionellen Emulator bietet das „Emulation Device“ folgende zusätzliche Funktionen:
- Trace von TriCore-Programm, -Daten und -Status,
- Trace von PCP-Programm, -Daten und -Channel,
- volle Transparenz aller Multi-Master-Busse,
- hohe Kompression der gespeicherten Trace-Daten,
- zeitliche Kohärenz aller Trace-Daten,
- zentrale Zeitbasis zur Erstellung von Zeitstempeln,
- Logikanalysator-Funktionen,
- Nutzung von Trigger-Funktionen zur Steuerung der Programm-Ausführung und zur De-/Aktivierung des Trace-Mechanismus,
- Definition von Code- und Daten-Adressbereichen durch Komparatoren,
Maskierungsoptionen für Daten-Komparatoren, - Zähler für Zeit und Events mit Trigger-Funktion,
- zusätzliche I/Os,
- zentrale Steuerung zum simultanen oder selektiven Starten oder Stoppen von Prozessor-Kernen.
Das „Emulation Device“ bietet zusätzlich spezielle Reset-Modi, mit denen die unterschiedlichen Reset-Arten beim Debugging und der Kalibrierung eingesetzt werden können (Ausnahme: „Power on Reset“). Der 512 Kbyte große SRAM-Speicher auf dem EEC setzt sich aus mehreren Blöcken zusammen, die für unterschiedliche Verwendungszwecke konfiguriert werden können. Dies ermöglicht den Einsatz des „Emulation Device“ für unterschiedliche Anwendungsfälle:
- Im Logikanalysator-Modus wird das SRAM benutzt (in Zusammenhang mit den Algorithmen zur Trace-Komprimierung), um den Programm- und Datenfluss auf allen internen Bussen beider Prozessor-Kerne aufzuzeichnen.
- Im Software-Entwicklungs-Modus wird das SRAM benutzt, um Programm-Code abzuspeichern und bei häufigen Programm-Änderungen die Programmierung des Flash-Speichers zu vermeiden. Im SRAM gibt es keine Einschränkungen bezüglich der Anzahl möglicher Software-Breakpoints.
- Bei der Kalibrierung mit Overlay-Speicher wird im SRAM eine temporäre Kopie der Kalibierungskonstanten abgelegt. Wird auf die Kalibrierungsdaten zugegriffen, wird von der Overlay-Hardware anstatt des Zugriffs auf den internen Flash-Speicher ein Zugriff auf den EEC-SRAM-Speicher durchgeführt. Externe Kalibrierungs-Tools können über das JTAG-Interface bzw. über USB oder CAN auf die SRAM-Blöcke lesend und schreibend zugreifen.
- Beim Rapid-Prototyping wird das SRAM als Zwischenspeicher zwischen externer Rapid-Prototyping-Hardware und dem Mikrocontroller genutzt. Aufgrund der Anforderungen bezüglich der Latenzzeit (<3 ms) kommt die USB-Schnittstelle hierbei nicht zum Einsatz. Besser geeignet ist das JTAG-Interface mit einer Latenzzeit von ca. 2 µs.
- Im Daten-Logger-Modus wird der SRAM-Speicher entweder zur fortlaufenden Speicherung von Applikationsdaten oder zur Aufzeichnung von System-Zuständen in besonderen Fehlerfällen benutzt.
Das „Emulation Device“ wird zur Laufzeit durch den Host-PC konfiguriert. Das Interface ist dabei durch einen gemeinsamen Standard so definiert, dass mehrere Software-Tools gleichzeitig über die Schnittstelle kommunizieren können. Nachdem der auf einem parallelen Bus-Interface basierende NEXUS-Trace-Port hier nicht anwendbar ist, wird nur die Software-API benutzt. Der Software-Support für das Emulationskonzept besteht aus einem „Device Access Server“ (DAS). Dieses Interface erlaubt von der Host-PC-Seite aus, mehreren Tool-Instanzen über eine einzige Kommunikationsverbindung (USB, JTAG) mit dem „Embedded Host“ zu kommunizieren. Der DAS erlaubt auch, mehrere Prozessor-Kerne innerhalb des „Embedded Host“, so dass auch auf zukünftige größere „System on a Chip“-Bausteine per DAS zugegriffen werden kann. Der DAS unterstützt auch den XCP-Protokollstandard, der die Verbindung von Kalibrierungs-Tools und Tools zur Datenerfassung unabhängig von der physikalischen Verbindung (CAN, FlexRay, USB, JTAG) ermöglicht.
Die Fehlersuche und Kalibrierung von hochintegrierten SoC-Mikrocontrollern wird zukünftig mit steigenden Takt-Raten schwieriger werden. Durch den Einsatz eines „Embedded Emulation Device“ kann der Software-Entwickler komplette Transparenz über die internen Vorgänge des Mikrocontroller erlangen und so feststellen, ob die Software zuverlässig arbeitet und alle Funktionen in einer Umgebung mit harten Echtzeit-Anforderungen korrekt abgearbeitet werden können
Autor
Simon Brewerton ist bei Infineon Technologies als Principal Engineer im Bereich Automotive Systems tätig.
simon.brewerton@infineon.com
Stephan Janouch, Elektronik automotive
- Prozessor hilft beim Aufspüren von Software-Fehlern
- Zugriff auf interne Bus-Strukturen
