Schwerpunkte

Heterogene Multicore-Prozessoren

Einheitlich für mehr Vielfalt

17. September 2020, 07:00 Uhr   |  Manne Kreuzer

Einheitlich für mehr Vielfalt
© PLS

Jens Braunes, PLS

Moderne System-on-Chip-Bausteine verbinden unterschiedliche Cores von der CPU über GPU bis hin zu TPU. Was das für die Entwicklung, Fehlersuche und das Testen bedeutet, erklärt Jens Braunes, Product Marketing Manager bei PLS.

Markt&Technik: Sind eigentlich unterschiedliche Reifegrade der Cores zu beobachten?

Jens Braunes: Das lässt sich pauschal nicht so einfach beantworten. Fakt ist, dass die Zahl heterogener Multicore-SoCs, die Standard-Core-Architekturen mit Spezial-Cores kombinieren, gerade bei Embedded Systemen in den letzten Jahren deutlich zugenommen hat. Dass bei der hohen Innovationsgeschwindigkeit mitunter auch Technologien, die schon eine ganze Weile im Einsatz sind, mit  technologischen Neuerungen kombiniert werden, liegt in der Natur der Sache. Nehmen wir als Beispiel die Aurix-Familie von Infineon. Hier wurde zum einen ein auf der TriCore-Architektur basierendes Multicore-System geschaffen, und zum anderen durch die GTM (Generic Timer Module) von Bosch die Leistungsfähigkeit im Bereich  komplexer Timer und Signalgenerierung enorm gesteigert. Auch die nächste Generation des Aurix verspricht erneut einen Innovationsschub. Denn dann werden mit einem zusätzlichen ARC-Core von Synopsis auch KI-Anwendungen unterstützt.

Erhöhen die unterschiedlichen Architekturen nicht zu stark die Komplexität?

Die Kombination von unterschiedlichen Core-Architekturen an sich ist eigentlich unkritisch. Einzeln für sich genommen sind die Cores ja funktional auch gut getestet. Aber ein ganz wichtiger Aspekt bei diesen heterogenen Multicore-Systemen, den man nicht unterschätzen darf, ist der mitunter immense Aufwand der Systemintegration. Mehrere Cortex-Cores aus dem „Arm-Baukasten“ auf einem SoC zu vereinen, ist in der Regel noch unproblematisch. Sollen aber zusätzliche, für bestimmte Aufgaben optimierte Arm-fremde Cores integriert werden, kann es für die Entwickler sehr schnell richtig anspruchsvoll werden. Im Normalfall  bedarf es etlicher spezifischer Anpassungen durch geeignete Wrapper, um sie inklusive aller Kommunikationspfade und einem zusätzlichen Power-Management in ein Gesamtsystem zu integrieren. Und auf dem Weg dorthin lauert so manche Tücke: Taktdomänen müssen synchronisiert werden, unterschiedliche Busse müssen miteinander kommunizieren können, etc. etc.

Wie sieht es mit dem Determinismus aus, wenn unterschiedliche Cores unterschiedliche Wach/Schlaf-Zustände gleichzeitig haben?

Wirklichen Determinismus gibt es in Embedded Systemen eigentlich gar nicht. Durch Sensoren, Aktoren und die Kommunikation nach außen ist das System ja immer auch Teil der realen Welt. Abgesehen davon: Im System selbst, wo Cores zum Zwecke des Energiesparens dynamisch herunter getaktet und gänzlich schlafen gelegt werden, gibt es immer geeignete Signalisierungen und Synchronisationsmechanismen. Damit lässt sich der gewünschte „Determinismus“ wieder herstellen. Im Grunde sind hier aber auch die Entwickler gefragt, denn wie gut die Synchronisierung tatsächlich funktioniert, hängt letztendlich ganz stark von der  Software-Architektur ab. Der Schlüssel liegt in der Partitionierung und Modularisierung. Entscheidend ist, dass Funktionen, die auf unterschiedlichen Cores ausgeführt werden, möglichst unabhängig voneinander sind, also möglichst wenig miteinander kommunizieren müssen. Es macht keinen Sinn, einen Core schlafen zu legen, um ihn sofort wieder aufzuwecken, weil ein anderer Core ständig Daten abfordert. Das spart weder Energie, noch hilft es der Performance. 

Ist das Debugging solcher heterogenen Bausteine ein Albtraum oder gibt es Tricks dafür?

Ob das Debugging zum Albtraum wird, hängt wie gesagt ganz wesentlich davon ab, wie die Softwarearchitektur der Embedded-Applikation aussieht. Manche Entwickler machen es sich hier vielleicht schwerer als es unbedingt sein müsste, aber so etwas kommt ja fast überall vor. Fakt ist: Sicherlich stellen solche Bausteine hohe Anforderungen an die Entwicklungswerkzeuge, nicht zuletzt an den Debugger. Aber die Herausforderungen sind in der Regel gut beherrschbar.

Was sind die  wichtigsten Grundvoraussetzungen, um die Entwickler beim Debugging und Testen ihrer Software zu unterstützen?

Zum einen muss das Embedded System ein geeignetes, in Hardware realisiertes Debug-System bieten. Es reicht hier nicht, einen JTAG-Konnektor bereitzustellen. Auch die Signalisierung von Debug-Ereignissen, wie das Anhalten von Cores oder das Wiederloslaufen, muss direkt auf dem Chip erfolgen. Die Entwicklung und Integration der dafür benötigten Logik ist zwar erfahrungsgemäß etwas aufwendig, aber gerade bei komplexen Multicore-Systemen kann es fatale Folge haben, wenn hier an der falschen Stelle gespart wird. Auch Trace ist gerade für die Untersuchung von Synchronisationsproblemen und Inter-Core-Kommunikation ein wichtiges Feature. Mit der Aufzeichnung des Programmablaufs, also der ausgeführten Instruktionen, lässt sich gerade bei Multicore-Applikationen das Laufzeitverhalten sehr genau analysieren. Gerade wenn es um die Partitionierung und die Optimierung der Datenflüsse geht, erweist sich Daten-Trace in der Regel als äußerst hilfreich. Nur bleibt er unserer Erfahrung nach beim Hardware-Design aus Kostengründen noch immer oft auf der Strecke. Leider. Denn unbestritten sind viele Probleme bei der Verwendung von Multicore-Systemen, ob mit einheitlichen Cores oder mit heterogenen Cores, auf den Datenaustausch zurückzuführen.

Zum anderen?

Natürlich muss auch beim Tool-Hersteller ein fundiertes Wissen über die verschiedenen Core-Architekturen und deren Debug-Systeme vorhanden sein beziehungsweise ständig weiter auf- und ausgebaut werden. Dies setzt einen kontinuierlichen sehr intensiven Informationsaustausch mit den Entwicklungsingenieuren der jeweiligen Halbleiter-Hersteller voraus. Viele Chip-Hersteller holen übrigens schon beim Design von neuen High-end-Bausteinen unterstützend Debugger-Hersteller Firmen wie PLS ins Boot, um gemeinsam über die On-Chip-Debug-Funktionen zu beraten. Unser erklärtes Ziel ist es, dass sich die Anwender unserer Werkzeuge mit den in der Frage angesprochen „Tricks“ gar nicht erst auseinandersetzen müssen, sondern sich der Debugger im Hintergrund selbstständig darum kümmert.

Lassen sich die unterschiedliche Strukturen der Cores in den Tools vereinheitlicht darstellen oder sollte man für jeden Core lieber einen eigenen Monitor, mit einer spezialisierten Darstellung haben?

Das kommt sehr auf den jeweiligen Anwendungsfall an. Oftmals interessiert sich der Anwender nur wenig für die jeweilig benutzte Prozessorarchitektur. Dann benutzt er zum Beispiel für den Quellcode, für Variable oder aber auch für gemessene  Performance-Parameter gerne generalisierte Ansichten. Das einheitliche Look-And-Feel unserer UDE kommt dieser typischen Vorhaltensweise übrigens sehr entgegen. Wird es dann architektur- und corespezifisch, dann sind allerdings sehr wohl auch spezielle Ansichten im Debugger notwendig. Bestes Beispiel dafür sind die architekturspezifischen CPU-Register. Inwieweit man einen zweiten Monitor für die Darstellung von Target-Informationen benutzt, kommt  sicherlich auf die persönliche Vorliebe des Entwicklers an.

Auf welche Strategie setzt hier PLS?

Unsere UDE bietet mit ihrer Benutzeroberfläche viele Möglichkeiten zur Individualisierung inklusive der Unterstützung von mehreren Monitoren. Wir verfolgen dabei allerdings die Philosophie einer Systemsicht und nicht einer Core-Sicht. Der Debugger betrachtet das gesamte, also  alle Cores beinhaltende Embedded System. Dementsprechend gibt es auch nur eine gemeinsame Oberfläche, die sofort eine konsistente Sicht auf das Embedded System liefert. Mit vorgefertigten Konfigurationen für die von der UDE unterstützten Mikrocontroller und Embedded Systemen und natürlich auch für die jeweiligen Entwicklungsboards kann der Entwickler mit der UDE sehr schnell und ohne Aufwand zu einer passenden, für sich optimalen Arbeitsumgebung gelangen. Unsere Kunden schätzen das sehr. Uns geht es dabei nicht nur um ständig neue Funktionen für das Debugging und die Laufzeitanalyse,  wir arbeiten auch kontinuierlich an der Verbesserung der Tool-Usability. Eine unserer Hauptaufgaben sehen wir hierbei darin,  Entwicklern bei Systemen mit immer mehr Cores den Überblick zu wahren und wo immer möglich weiter zu verbessern.

Wie kann man als Tool-Hersteller den Entwicklern dabei helfen, die Unterschiede der Cores zu meistern?

Es gibt eine ganze Reihe von Möglichkeiten, wie das Debug-Tool Entwicklern beim besseren Verstehen und beim optimierten Ausnutzen von Cores unterstützen kann. So hilft beispielsweise die Darstellung im Debugger, die Master-Slave-Beziehungen zwischen den einzelnen Cores zu erkennen. Das ist wichtig, um beispielsweise den Boot-Prozess zu analysieren und Fehler im Startverhalten oder nach dem Reset zu untersuchen. Ein zweiter wichtiger Punkt ist natürlich die Konformität aller durch den Debugger dargestellten Werte mit den jeweiligen Manuals der Halbleiterhersteller. Ganz wesentlich ist dabei die Visualisierung aller Register, also sowohl die der eigentlichen Cores also auch die der Peripherals. PLS betreibt hier einen besonders hohen Aufwand, um mit der UDE eine einheitliche und mit den verfügbaren Dokumentationen konsistente Darstellung bieten zu können.

Seite 1 von 2

1. Einheitlich für mehr Vielfalt
2. Interview Teil 2

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Verwandte Artikel

pls Programmierbare Logik & Systeme GmbH