Integrierter Emulator erlaubt Zugriff auf die internen Bus-Strukturen Prozessor hilft beim Aufspüren von Software-Fehlern

Bei komplexen Anwendungen finden sich häufig hoch integrierte Schaltungen, die mehrere durch ein Bus-System verbundene Kompo-nenten enthalten („System on a Chip“, SoC). Um die Fehlersuche zu vereinfachen, bietet Infineon spezielle Mikrocontroller an, bei denen der Emulator bereits enthalten ist.

Integrierter Emulator erlaubt Zugriff auf die internen Bus-Strukturen

Bei komplexen Anwendungen finden sich häufig hoch integrierte Schaltungen, die mehrere durch ein Bus-System verbundene Kompo-nenten enthalten („System on a Chip“, SoC). Um die Fehlersuche zu vereinfachen, bietet Infineon spezielle Mikrocontroller an, bei denen der Emulator bereits enthalten ist.

Durch den verstärkten Einsatz von Tools zur automatischen Codegenerierung, die aus Modell-basierenden Designs C-Code generieren, lassen sich viele wertvolle Arbeitsstunden bei der Software-Entwicklung einsparen. Vom Entwickler werden dabei bestehende Bibliothekselemente in einer grafischen Entwicklungsumgebung zu einer Applikation zusammengefasst und dann auf Simulationsebene („Simulation in the Loop“, SIL) sowie später im System („Processor in the Loop“, PIL) auf ihre Funktion hin getestet. Die Wiederverwendbarkeit dieser generischen modularen Bibliothekselemente bzw. der daraus resultierenden modularen Software-Sequenzen erhöht die Effizienz in der Entwicklungsphase und die Qualität der kompletten Applikations-Software.

Diese Entwicklungsmethode kann auf der anderen Seite zu strukturellen Problemen führen; beispielsweise zu ineffizienter Benutzung der unterschiedlichen Speicherbereiche in einem Mikrocontroller, zu erhöhten Latenzzeiten sowie zu weiterer Abstraktion des Design-Prozesses von der Hardware.

Alternativ lassen sich Applikationssysteme auch ohne unterschiedliche Hardware-Versionen bzw. ohne Veränderung der Basis-Software anpassen und optimieren. Gängige Methodik hierfür ist der Einsatz von Kalibrierungsvariablen, die Funktionen zur Laufzeit an- und abschalten. Ein weiterer Anwendungsfall ist z.B. die Anpassung von Regelungs- bzw. Funktions-Parametern, die nach eingestelltem Arbeitspunkt aus zuvor in nicht-flüchtigem Speicher abgelegten Tabellen ausgelesen und dynamisch an die Applikation zurückgegeben werden.

Der Software-Entwickler stützt sich dabei auf Techniken der Fehlersuche und der Emulation; beispielsweise auf die Aufzeichnung des Programmflusses in Echtzeit im realen System (Program Trace), der Beobachtung der Veränderung von Variablen und Daten, Latenzzeit-Messungen sowie auf die Fehlersuche in Programmabläufen und Algorithmen.

Herausforderung Multi-Core-Systeme

Beim Debuggen komplexer integrierter Multi-Core-Systeme (SoC) treten bei hohen Taktraten einige besondere Herausforderungen auf. Der Größenzuwachs des nicht-flüchtigen Embedded-FLASH/SRAM-Speichers und die verkleinerten Chipstrukturen haben die Realisierung von „Superscalar System on a Chip“-Mikrocontrollern ermöglicht, bei denen interne, breite, schnelle Busverbindungen benutzt werden, um mehrere Prozessoren und Co-Prozessoren miteinander zu verbinden. Der Anschluss von Analyse-Tools zur Überwachung der internen Busse dieser „Deeply Embedded Controller“ kann auf physikalischer Ebene problematisch sein. In vielen Fällen sind die zu überwachenden Busse nicht nach außen geführt oder die verwendeten Taktraten oder Umgebungsbedingungen begrenzen die Länge der Anschlusskabel.

In vielen Fällen kann von dem externen Datenzugriff, der auf dem externen Bus sichtbar ist, nicht auf den exakten kompletten Programmfluss zurückgeschlossen werden. Verstärkt wird dieser nachteilige Effekt beispielsweise noch aufgrund interner Cache-Speicher und durch „Core Pipeline“-Effekte. Auf der Code-Seite ist die Decodierung von Instruktionszugriffen wegen der internen sequentiellen Adress-Inkrementierung bei heute eingesetzten „Burst ModeFlash“-Speichern komplizierter. Das prinzipielle Problem beim Anschluss eines Debuggers bzw. Emulators ist die Längenbegrenzung der Anschlusskabel, bedingt durch die zwischenzeitlich erreichten hohen Taktraten. Beispielsweise beträgt eine typische Signal-Laufzeit 2 ns bei einem 150-MHz-Mikrocontroller und einer Leitungslänge von 50 cm (unter der Annahme, dass 30 % der Takt-Periode für die Signal-Flanken benötigt werden). Ein Takt-Zyklus entspricht hier nur noch umgerechnet 6,67 ns; damit ist eine Verzögerung von 2 ns über die Tool-Anbindung nicht mehr zu vernachlässigen und macht somit eine exakte Analyse des Siliziums in Echtzeit gegebenenfalls unmöglich.

Um die Signal-Laufzeit des Emulator-Anschlusses in einem tolerierbaren Bereich zu erhalten, dürfte deshalb die Tool-Anbindung bzw. die zugehörige Kabellänge ein Maß, bezogen auf das obige Beispiel, von 16 cm nicht überschreiten. Damit wandert allerdings die notwendige Emulator-Hardware zur Analyse in die unmittelbare Nähe des zu testenden Bausteins und ist damit auch den Einflüssen wie dem entsprechenden Steuergerät unterworfen. Handelt es sich z.B. um ein Motor-Steuergerät, kann die Temperatur den Spezifikationsbereich des Emulators überschreiten.

Ein Beispiel einer echten SoC-Implementierung ist der 32-bit-Mikrocontroller TC1796 von Infineon. Die 32-bit-TriCore-CPU hat eigene getrennte 64-bit-Busse für Code und Daten und ist über eine Bridge mit den 32 bit breiten System-Bussen verbunden, um Datenzugriffe auf die Peripherie-Sub-Systeme zu ermöglichen (Bild 1). Der „Peripheral Control Processor“ (PCP2) ist ein weiterer 32-bit-Prozessor auf demselben monolithischen Silizium, mit eigenem Code und eigenen Daten-Bussen in Harvard-Architektur mit einer 32-bit-Datenschnittstelle zum Peripherie-Bus (SPB). Im TC1796 läuft das Prozessor-Sub-System mit maximal 150 MHz und das Peripheral-Sub-System mit maximal 75 MHz. Es gibt also zwei getrennte, unterschiedliche Takt-Bereiche.

Der TC1796 wird in einem 416-Pin-BGA-Gehäuse („Ball Grid Array“) angeboten und bietet ein Standard-JTAG-Debugger-Interface. Um die komplette Palette der Anforderungen hinsichtlich Emulation und Überwachung des Programms und des Daten-Flusses für diesen Mikrocontroller abzudecken, ist es notwendig, die Daten-Transaktionen auf den internen Bussen überwachen zu können. Der 2 Mbyte große integrierte Flash-Speicher ist über einen 64-bit-Bus und über lokale Cache-Speicher an die CPU angeschlossen, so dass die Programm-ausführung aus den internen Speicherbereichen bedeutend schneller als von externen Speichern (via 32 bit Zugriffsbreite) möglich ist. Diese Komplexität aus mehreren Rechnerkernen und mehreren Bussen hat zur Folge, dass prinzipiell nur ein Bondout-Baustein den notwendigen Grad an Transparenz erfüllen könnte, um alle Anforderungen bezüglich Debugging verwirklichen zu können. Bei einem Takt von 150 MHz ist die Periodendauer von 6,67 ns zu kurz, um die Daten mit einem externen Bondout-Controller zu lesen, zu decodieren, die Entscheidung über eine eventuelle Break-Bedingung zu treffen und ggf. den Prozessor anzuhalten.