Heterogene Multicore-Prozessoren
Einheitlich für mehr Vielfalt
Fortsetzung des Artikels von Teil 1
Interview Teil 2
Wie nutzen das die Anwender?
Aus unserer Erfahrung ist es häufig so, dass nur ein kleiner Teil der Entwickler sich mit den jeweiligen Spezifika der Cores auseinandersetzt und das auch nicht unbedingt muss. Vielmehr spielt die Hochsprachensicht eine größere Rolle. Dann geht es letztendlich darum, die einzelnen Cores für das Debugging synchron und vor allem den Gesamtzustand konsistent zu halten. Viel Aufwand betreiben wir deshalb für das synchrone Run-Control, also das Anhalten beispielsweise am Breakpoint, Steppen und auch Wiederloslaufen der Cores. Nichtsdestotrotz ist es aber manchmal notwendig, doch tiefer ins System zu schauen. Aufgrund der tiefgreifenden SoC-spezifischen Expertise unserer Ingenieure können wir unseren Kunden neben dem eigentlichen Tool-Support natürlich auch einen gewissen Architektur-Support bieten. So beobachten Kunden beim Debugging beispielsweise nicht selten ein unerwartetes Verhalten ihrer Applikation, was sich oft erst durch gezielte Verweise unserer Experte in bestimmte Abschnitte der meiste mehrere tausend Seiten umfassenden Manuals der Halbleiterhersteller erklären lassen.
Steigern die unterschiedlichen Spezial-Cores den Bedarf an Partnern mit Spezialkenntnissen?
Tendenziell ja. Spezial-Cores erfordern selbstverständlich auch Spezialwissen. Dieses notwendige Know-how wird aber typischerweise von den Entwicklungspartnern und Halbleiterherstellern in Form von Bibliotheken den Anwendern bereitgestellt. Damit fällt es Entwicklern leichter, auch ohne aufwändige, detaillierte Einarbeitung in die Thematik von Spezial-Cores einzusteigen und schneller zum Ziel zu kommen. Das eigentliche Know-How verbleibt zunächst erst einmal beim Hersteller der Bibliotheken. Das soll aber nicht heißen, dass sich engagierte Entwickler nicht auch die entsprechende Expertise aneignen können, um ihre Systeme gezielt zu optimieren. Ein bloßes Studium der Manuals ist aber sehr zeitaufwändig. Deshalb spielen entsprechende Trainings von Schulungspartnern eine wesentliche Rolle. Häufig lernt man dabei dann nicht nur die Architektur kennen, sondern auch gleich die Tools. So kann mit dem Debugger beispielsweise ein bestimmtes Architekturverhalten praktisch nachvollzogen werden.
Es ist also Team-Spiel angesagt.
Ja, ich möchte ich an dieser Stelle einen ganz wesentlichen Punkt hervorheben: Gerade bei heterogenen Multicore-SoCs sind zumeist eine ganze Reihe unterschiedlicher Partner involviert; nicht nur die Halbleiterhersteller und IP-Provider, sondern auch andere Tool-Hersteller zum Beispiel für Simulatoren, Codegeneratoren oder Testwerkzeuge. Insofern ist gerade im Bereich der heterogenen Multicore-SoCs das Thema Interoperabilität von enormer Bedeutung. Wir als Debugger-Hersteller leisten unseren Anteil, indem wir den verschiedenen 3rd-Party-Tools eine offene und flexible Schnittstelle zu den Debugger-Funktionen bieten. Wir sehen also unsere Tools nicht als alleinstehende Werkzeuge, sondern auch immer als Teil eines Gesamt-Ecosystems.
Ist es bedenklich, dass immer weniger Entwickler die Prozessorarchitektur vollständig verstehen und so immer abhängiger von der Tool-Chain werden?
Nein, ich denke, das ist ein ganz normaler Prozess. Die meisten heutigen Systeme sind inzwischen viel zu komplex, als dass sie einzelne Entwickler noch in allen Details vollständig verstehen könnten. Das gilt nicht nur für eingebettete, sondern generell für alle Systeme. Speziell im Bereich der Informationstechnologie und gerade bei den Embedded Systemen geht deshalb seit Jahren schon der Trend hin zur Kapselung der Komplexität in Bibliotheken und Tools. Mit dieser Vorgehensweise gelingt es den SoC- und Tool-Herstellern, die Komplexität für den Anwender zu reduzieren. Als Beispiel seien hier nur MCAL oder CMSIS genannt, die eine standardisierte Abstraktionsschicht zwischen der Nutzerapplikation und der eigentlichen Hardware einfügen. Auch Ansätze zur automatischen Code-Generierung für hardwarenahe Funktionen unterstützen hier.
Thema Effizienz - reicht es den Betriebssystemen zu vertrauen oder sollte man händisch die Programme auf den jeweiligen Baustein und seine Core-Mischung optimieren?
Da gibt es keine klare Antwort. Das hängt ganz von der Applikation und vom eingesetzten Betriebssystem ab. Letztlich ist es immer eine Abwägung von Aufwand und Nutzen. Natürlich kann im Einzelfall manchmal eine Optimierung von Hand durchaus sinnvoll sein, beispielsweise um die geforderte Performance für eine ausgewählte Funktion zu erreichen. Nur muss sich solch eine zumeist doch ziemlich zeit- und damit kostenintensive Einzelaktion letztendlich auch rechnen; entweder über eine große Stückzahl, mit der sich das Produkt dann verkaufen lässt, oder über seinen Preis. Bei der Eruierung spielen übrigens auch die Debug-Tools durchaus eine wichtige Rolle, denn man braucht zunächst einmal einen Anhaltpunkt, an welcher Stelle man optimieren will und eine Bewertung dessen, was man optimiert hat. Der Debugger liefert hier wertvolle Dienste, denn er bietet auch Funktionen für das Profiling und zum Beispiel die Visualisierung von Funktionsaufrufen beziehungsweise Call-Trees über die Zeit. Auf der anderen Seite muss man die hohe Komplexität von großen Softwareprojekten beherrschen. Dabei kommt man zwar am Einsatz von standardisierten Software-Komponenten, Entwurfsmustern und Tools, wie sie mit speziell angepassten Betriebssystemen ja verfügbar sind, nicht herum. Aber auch hier lässt sich auf höheren Ebenen an diversen Stellschrauben drehen, um beispielsweise die Auslastung der einzelnen Cores zu optimieren. Die Vergleichsmessungen erfolgen dann häufig mit Bordmitteln der Betriebssysteme, können aber im Debugger aufbereitet und nutzerfreundlich angezeigt werden.
Wie gut läuft alter Code auf neuen heterogenen Multicore-Prozessoren?
Ob Legacy Code einfach beziehungsweise überhaupt auf eine neue, heterogene Multicore-Architektur übertragbar ist, steht und fällt mit dessen Software-Architektur. Ganz wichtig ist hier die Modularisierung des Codes. Also beispielsweise, ob hardwarenahe Funktionen von höheren Funktionen getrennt wurden und wie die Schnittstellen zwischen diesen Funktionen aussehen. Dann kann man die hardwarenahen Funktionen relativ einfach durch neue Funktionen ersetzen, die entsprechend auf die neue Hardware angepasst sind. Wie wichtig das Thema Modularisierung für die Nutzung alten Codes auf neuen heterogenen-Prozessoren ist, zeigt sich auch bei der Verarbeitung von Daten. In den meisten Fällen wechselt man ja von einem Single-Core- auf ein Multicore-System. Eine gut durchdachte funktionale Partitionierung hilft, die einzelnen Funktionen nun auf die mehrere Cores zu verteilen, ohne dass übermäßige Abhängigkeiten und Kommunikation zwischen den Cores auftreten. Denn diese führen häufig zu unerwarteten Performanceeinbußen.
Will man bei einer neuen Architektur als Tool-Anbieter „alte Zöpfe abschneiden“ und neu „auf der grünen Wiese“ beginnen? Oder will man den Kunden mit einer vertrauten Umgebung beim Um-/Einstieg helfen?
Im Fall von PLS trifft ganz klar Letzteres zu. Unser Anspruch ist es, dass unsere Kunden beim Umstieg auf neue Architekturen oder Bausteine ohne lange Umgewöhnungsphase sofort mit der bereits vertrauten Umgebung weiterarbeiten können. Möglich wird dies durch die modulare Architektur von UDE, die uns in die Lage versetzt, sehr schnell und individuell auf die spezifischen Anforderungen neuer Technologien und Komponenten reagieren zu können, ohne dabei das Rad immer wieder neu erfinden zu müssen. Wichtig ist uns dabei auch die Interoperabilität mit anderen Tools. Unsere Software-API, die es Skripten oder 3rd Party-Tools ermöglicht, alle Debugger-Funktionen automatisiert zu benutzen, ist ein ganz wesentlicher Baustein der UDE. Unsere Kunden können sich sicher sein, dass die bewährte Funktionalität auch beim Umstieg auf jede andere von der UDE unterstützte Architektur verlässlich erhalten bleibt.
Jobangebote+ passend zum Thema
- Einheitlich für mehr Vielfalt
- Interview Teil 2
Lesen Sie mehr zum Thema
