Suchen

Die Suche nach des Pudels Kern Hilfsmittel und Werkzeuge für das Multicore-Debugging

| Autor / Redakteur: Jens Braunes * / Sebastian Gerstl

Reichte im Consumer-Markt oft das Aufspüren falsch geschriebener Variablen, ist das Debugging industrieller Multicore-Systeme weitaus komplizierter. Vom Hersteller gelieferte Hilfestellung entfalten oft nur in Kombination mit leistungsstarken Tools volle Wirkung. Ein Beitrag über derzeitige Grenzen und Möglichkeiten verschiedener Lösungsansätze.

Firmen zum Thema

Blockschaltbild der AURIX Multicore-Architektur von Infineon: Ein Beispiel für ein heterogenes Multicore-System, bei dem verschiedene, speziell auf eine Aufgabe zugeschnittene Kerne zum Einsatz kommen. Komplexe Anwendungen aus Industrie- oder Automotive-Bereichen stellen spezielle Anforderungen an Multicore-Architekturen, die sich sich wesentlich vom aus der Windows-, Linux- und Android-Welt bekannten homogenen Multicore-Ansatz unterscheiden.
Blockschaltbild der AURIX Multicore-Architektur von Infineon: Ein Beispiel für ein heterogenes Multicore-System, bei dem verschiedene, speziell auf eine Aufgabe zugeschnittene Kerne zum Einsatz kommen. Komplexe Anwendungen aus Industrie- oder Automotive-Bereichen stellen spezielle Anforderungen an Multicore-Architekturen, die sich sich wesentlich vom aus der Windows-, Linux- und Android-Welt bekannten homogenen Multicore-Ansatz unterscheiden.
(Bild: PLS)

Beim Debugging industrieller Multicore-Systeme geht es nicht mehr nur um das Aufspüren falsch geschriebener Variablen, sondern um die Bewältigung von Verklemmungen, Ressourcenkonflikten oder Timing-Problemen in Echtzeitapplikationen. Dieser Paradigmenwandel stellt für Chiphersteller und Toolanbieter eine gewaltige Herausforderung dar, zumal die heutzutage üblicherweise verfügbaren On-Chip-Debug-Funktionen erst mit entsprechend leistungsfähigen externen Werkzeugen ihre volle Wirksamkeit entfalten.

Wenn man nur den Consumer-Markt betrachtet, sind Multicore-Systeme schon seit zehn Jahren im Mainstream angekommen. Bei den tief eingebetteten Systemen, wie wir sie vor allem in Industrieanwendungen oder bei Automotive-Steuerungen finden, wurde der Technologiewechsel hingegen erst in den letzten Jahren vollzogen, und das auch recht zögerlich. Ein Grund dafür waren sicherlich die hohen Anforderungen an Sicherheit, Zuverlässigkeit und Echtzeit, die in den genannten Bereichen nun einmal absoluten Vorrang genießen.

Aber auch das umfangreiche Portfolio an bewährten und gut getesteten Softwaremodulen für Singlecore-Systeme, deren Portierung auf mehrere heterogene Kerne einen nicht zu unterschätzenden Aufwand bedeutete, bremste hier sicherlich einen schnelleren Vormarsch aus.

Multicore ist nicht gleich Multicore

Beim aus der Windows-, Linux- und Android-Welt bekannten homogenen Multicore-Ansatz können Tasks und Prozesse dynamisch erzeugt werden, die dann je nach Last auf einem beliebigen Kern zur Ausführung kommen. Das ist möglich, weil die verwendeten Prozessoren über identische Rechenkerne verfügen. Jeder Kern ist in der Lage und auch geeignet, zugewiesene Tasks gleichermaßen auszuführen.

Komplexe vernetzte Industrial- und Automotive-Anwendungen erfordern allerdings in der Regel festgelegte Abarbeitungszeiten für einzelne Tasks und garantierte Antwortzeiten. Deshalb kommen hier zumeist heterogene Multicore-Systemen mit mehreren speziell auf eine bestimmte Aufgabe zugeschnittenen Kernen zum Einsatz., wie das Beispiel der AURIX-Mikrocontroller aus dem Hause Infineon verdeutlicht (siehe Bild oben). Zwar stammen die drei Hauptkerne allesamt aus der TriCore-Architekturfamilie, jedoch sind nur zwei davon als sogenannte Performancekerne (P-Cores) für normale rechenintensive Aufgaben vorgesehen. Die dritte, als Economy-Kern (E-Core) bezeichnete Zentraleinheit übernimmt vorrangig die Verwaltung der Peripherals und allgemeine, weniger Rechenleistung erforderliche Aufgaben.

Für sicherheitskritische Tasks wurde einer der P-Cores und der E-Core mit einem zusätzlichen speziellen Lockstep-Core ausgestattet, der im Hintergrund die gleichen Operationen wie der eigentliche Kern ausführt. Mittels Vergleich der Ergebnisse wird die Zuverlässigkeit der Berechnungen so ständig kontrolliert. Tritt eine Abweichung auf, muss die Applikation, das Steuergerät, und/oder das sicherheitskritische System gegebenenfalls in einen sicheren Zustand zurückversetzt werden.

Komplexe Zeitsteueralgorithmen sowie die effiziente und parallele Verarbeitung von Signalen unterstützt ein vierter „Kern“, das sogenannte Generic Timer Module (GTM). Völlig andersartig als die TriCore-Kerne, ist das GTM dennoch über einen eigenen Befehlssatz programmierbar. Dadurch können auch Tasks darauf ausgeführt werden.

Bei so einem komplexen System sollte man hinsichtlich der Verteilung der Applikationslasten auf die Rechenkerne logiscehrweise nicht allein auf das Betriebssystem vertrauen. Vielmehr muss bereits während des Softwareentwurfs klar sein, welcher Kern welche Aufgaben zu übernehmen hat.

(ID:43763028)