Multicore-Chips und Betriebssysteme
Fehlersuche auf heterogenen, komplexen SoCs leicht gemacht
System-on-Chips sind das Gehirn hinter der Datenverarbeitung und Kommunikation in einer Vielzahl von elektronischen Systemen. Und sie werden immer komplexer. Die Anzahl der CPUs und die verwendeten Architekturen wachsen ständig. Dennoch gibt es Möglichkeiten, den neuen Rechenmonstern Herr zu werden.
Früher war alles besser« – wer kennt diesen gerne zitierten Spruch nicht. Mag man seinen Wahrheitsgehalt zu Recht bestreiten, so gilt zumindest für viele Embedded-Entwickler: »Früher war alles einfacher.« Die meisten Geräte beinhalteten mehr oder weniger einfache Mikrocontroller mit Single-Core- oder im besten Fall Dual-Core-Architekturen, häufig mit Arm-Cortex-M-Cores oder anderen 8-, 16- oder 32-bit-CPUs, bei denen sich die Fehlersuche vergleichsweise einfach gestaltet und für die es zahlreiche »kosteneffiziente« Debugger auf dem Markt gibt.
Heute, im Zeitalter der Konsolidierung von Steuergeräten im Automobil, hochleistungsfähigen Mobilgeräten und KI-Rechenzentren, sieht die Welt anders aus: SoCs wie Qualcomms Snapdragon, Nvidias Drive Orin, AMDs Versal-FPGA-SoCs, aber auch Infineons Aurix TC4x oder der erst kürzlich auf der embedded world präsentierte S32N55 von NXP, der mehrere virtuelle Automotive-Steuergeräte auf einem Chip vereinen wird, integrieren häufig eine Vielzahl von CPUs und Hardware-Beschleunigern unterschiedlichster Architekturen. Spätestens bei der Systemintegration muss es das Ziel für Hersteller von Debuggern und Trace-Tools sein, dem Entwickler eine Sicht auf den gesamten Chip zu geben und alle Cores zu erfassen, egal wie viele es sind und von welcher Architektur. Sie müssen perfekt für Symmetric Multiprocessing (SMP), Asymmetric Multiprocessing (AMP), Arm-big.LITTLE-Systeme und sogar für Multi-Chip-Architekturen funktionieren, bei denen mehrere Multi-Core-SoCs gemeinsam debuggt werden müssen.
Dazu kommt noch die Herausforderung, dass auf den einzelnen CPUs oder CPU-Clustern häufig unterschiedliche Betriebssysteme laufen, die im Extremfall auch noch in einer virtualisierten Umgebung von einem Hypervisor verwaltet werden. Tatsächlich gibt es aber auch dafür Möglichkeiten, diese mithilfe einer sogenannten OS- und Hypervisor-Awareness in die Fehlersuche einzubeziehen; dazu später mehr.
Jobangebote+ passend zum Thema
Debugging eines NXP-Vehicle-Super-Integration-Prozessors
Die Möglichkeiten von modernen Debug- und Trace-Tools sollen in der Folge am Beispiel des oben erwähnten S32N55-SoC von NXP diskutiert werden. Der Chip soll die Entwicklung von zentralen Fahrzeugsteuerungsanwendungen in softwaredefinierten Fahrzeugarchitekturen (SDV) mittels virtuellen Steuergeräten beschleunigen und Echtzeit-Fahrzeugsteuerung, -management und -dienste auf einem Chip integrieren.
Dazu wurden in vier Clustern jeweils vier Arm-Cortex-R52-CPUs integriert (insgesamt also 16), die von einem Arm-Cortex-M7-System-Manager und einem Arm-Cortex-M7-Communication-Manager ergänzt werden. Unterstützt werden Echtzeit-Betriebssysteme wie Zephyr OS und FreeRTOS, Autosar-OSes; dazu kann ein Typ-1-Hypervisor zur Partitionierung des Chips beim Booten genutzt werden (die Partitionierung des Chips erfolgt einmal statisch beim Booten und wird im Betrieb nicht mehr dynamisch verändert). Alle CPUs sind über eine Arm-CoreSight-SoC-600-Infrastruktur mit einem JTAG-Port für Debugging und einer PCIe-Gen4-Schnittstelle für Off-Chip-Trace verbunden.
Architektonisch handelt es sich bei dem S32N55 um ein kombiniertes AMP/SMP-System, bei dem ein oder mehrere SMP-Cluster aus identischen Cores (hier: 4×4 Cortex-R52) von einer Mischung aus Kernen mit anderen CPU-Architekturen für spezielle Aufgaben (hier: zwei Cortex-M7) umgeben sind.
Das Bild zeigt eine Lauterbach-Trace32-Debug-Architektur, die über den JTAG-Port an den S32N55 angeschlossen ist. Der entscheidende Punkt aus Entwicklersicht ist, dass sowohl einzelne Cores als auch Cluster identischer Cores über eine GUI-Instanz der Trace32 PowerView Software debuggt werden können. Dabei spielt es nicht mal eine Rolle, ob sich die Cores des zu testenden Systems auf einem Chip (wie hier) oder auf mehreren Chips befinden. Trace32 AMP realisiert den gleichzeitigen Zugriff auf die verschiedenen Cores/Cluster und steuert deren Start/Stopp-Synchronisation, sodass der Entwickler jederzeit den Blick auf das Gesamtsystem hat, was spätestens im Integrations- und Systemtest unbezahlbar ist.
OS- und Hypervisor-Awareness
Wenn wie in unserem Beispiel im Bild auf einzelnen Clustern unterschiedliche Betriebssysteme laufen, würde die Fähigkeit, alle Anwendungen zu debuggen, ohne Einblicke in die einzelnen OSe natürlich nicht ausreichend sein. Man denke nur an Fehler, die sich aus dem Speichermanagement, der Thread-/Prozessverwaltung oder der Kommunikation zwischen unterschiedlichen Tasks ergeben. Lauterbachs Trace32-Hypervisor- und OS-Awareness-Technologie ermöglicht den Zugriff auf alle Komponenten des Hypervisors, der Betriebssysteme und der Anwendungen: Man kann Systemobjekte wie Tasks, Threads, Semaphore und Mailboxen anzeigen, Task-Breakpoints setzen und Task-Performance-Monitoring durchführen. Wenn das Betriebssystem eine MMU (Memory-Management-Unit) verwenden würde (auf dem S32N55 gibt es keine MMU), könnte der Debugger sogar auf Code und Daten zugreifen, indem er die Informationen aus den MMU-Tabellen des Betriebssystems verwendet und sie durchläuft, um eine gültige logisch-physische Übersetzung zu finden.
Durch die Trace32-Hypervisor-Awareness erkennt und visualisiert der Debugger die virtuellen Maschinen (VMs) des Hypervisors. Es ist damit möglich, mehrere Betriebssysteme gleichzeitig zu debuggen. Wichtigstes Ziel ist das nahtlose Debugging des Gesamtsystems. Das heißt, wenn das System an einem Breakpoint angehalten hat, kann man den aktuellen Zustand jedes einzelnen Prozesses, aller VMs sowie den aktuellen Zustand des Hypervisors und der realen Hardwareplattform überprüfen und ändern.
| Hersteller | Chip | CPU 1 | CPU 2 | Weitere Cores | Multicore Debugging | On-Chip-Trace | Off-Chip-Trace |
|---|---|---|---|---|---|---|---|
| AMD | Zynq Ultrascale+ | 4x Arm Cortex-A53 | 2x Arm Cortex-R5F | MicroBlaze Hard-IP | X | X | X |
| Infineon | AURIX TC4x | 6x TriCore V1.8 | – | PPU (ARC), GTM, SCR (XC800), CSRM (TriCore), cDSP | X | X | X |
| Intel | Xeon Silver | 12x Sapphire Rapids x86 | – | – | X | X | |
| Nvidia | Drive Orin | 12x Arm Cortex-A78AE | 4x Arm Cortex-R52 | – | X | X | X |
| NXP | i.MX8 QuadMax | Arm Cortex-A72 | 4x Arm Cortex-A53 | 2x Arm Cortex-M4, Arm Cortex-M0, Xtensa-LX7 DSP, MicroBlaze Hard-IP | X | X | X |
| Qualcomm | Snapdragon | Qualcomm Armv7/v8 CPUs | – | Qualcomm Hexagon DSPs, Subcontrollers | X | X | X |
| Texas Instruments | AM69Ax | 8x Arm Cortex-A72 | 4x Arm Cortex-R5F | 4x TI-C7x-DSPs, 2x Arm Cortex-M4 | X | X |
Beispiele für komplexe SoCs, auf denen eine Fehlersuche mit modernen Debug- und Trace-Tools auch auf der Gesamtchip-Ebene inkl. Betriebssystemen ohne weiteres möglich ist. Bei Trace32 können alle diese SoCs aus einem identischen User-Interface debuggt werden.
Tracen über PCIe
Manchmal reicht das traditionelle Stop-Mode-Debugging nicht aus. Man nehme nur einmal die sogenannten Heisenbugs, die nur in Echtzeit und im Worst Case auch nur sporadisch auftreten. Oder man will (bzw. muss) für Zertifizierungen im Bereich der funktionalen Sicherheit Code-Coverage- und Timing-Analysen vornehmen, was die Sammlung von Trace-Informationen über einen langen Zeitraum erfordert.
Die von Lauterbachs Trace32-Trace-Erweiterungen bereitgestellten Programmflussdaten zeigen genau, welche Anweisungen ausgeführt wurden und wie lange die Ausführung gedauert hat, ohne die zu testende Anwendung durch irgendeine Art der Instrumentierung zu beeinträchtigen. Der NXP S32N55 stellt hierfür eine PCIe-Gen.-4-Schnittstelle bereit, welche über den Trace32-PCIe-Gen.-4-Preprocessor Datenraten bis zu 16 Gbit/s pro Lane ermöglichen. Warum ist diese hohe Bandbreite wichtig? Nun, die 16 Cortex-R52, die jeweils bis zu 1,2 GHz getaktet werden können, generieren sehr viele Daten, die in Echtzeit über die Trace-Erweiterungen zur weiteren Analyse in den Host-PC geschaufelt werden müssen.
Fazit
Mit entsprechend leistungsfähigen Debug- und Trace-Tools ist auch die Fehlersuche auf sehr komplexen SoCs möglich – vom Unit- über den Integrations- bis hin zum System-Test. Die Tabelle zeigt eine Sammlung von sehr komplexen Chips mehrerer alphabetisch sortierter Hersteller mit Core-Kombinationen unterschiedlichster Architekturen. Alle diese Beispiele können von Lauterbachs Trace32-Tools vollständig debuggt und getracet werden, d. h. der Entwickler bekommt eine vollständige Sicht auf CPUs, Companion-Cores, Betriebssysteme, Hypervisor und Applikationen. (lb)
Lesen Sie mehr zum Thema
