Implementierung eines Multicore-Frameworks

Bild 1: Das „Mentor Embedded Multicore Framework” in RTOS- oder Bare-Metal-Umgebungen (a) und remoteproc und rpmsg im Linux-Kernel (b). Mentor Graphics

In den letzten Jahren kamen sehr viele Embedded-Designs mit ARM-Kernen zum Einsatz. Einer der Vorteile von ARM ist die Leichtigkeit, mit der Hardwareentwickler von SoC (System-on-Chip) -Designs Computerprobleme auf effiziente Weise lösen, wenn sie Systeme mit heterogenen Kernen verwenden. Mit diesen Kernen können sie einer bestimmten Aufgabe oder Situation die optimale Rechenleistung zuordnen. Obwohl SMP (Synchronous Multiprocessing) -Betriebssysteme die erforderliche Infrastruktur bieten, um die Anwendungslast symmetrisch oder asymmetrisch über mehrere homogene Kerne zu verteilen, erfordert die Nutzung der von heterogenen Prozessoren bereitgestellten Rechenbandbreite eine AMP (Asynchronous Multiprocessing) -Softwarearchitektur.

AMP-Softwarearchitekturen

AMP-Architekturen bestehen üblicherweise aus einer Kombination unterschiedlicher Softwareumgebungen wie Linux, einem Echtzeitbetriebssystem (RTOS) oder Bare-Metal, die auf homogenen oder heterogenen Prozessorkernen laufen. All diese Umgebungen arbeiten zusammen, um die Entwurfsziele der Endanwendung zu erreichen. Typische Designs umfassen einen Softwarekontext auf einem Master-Kern, der bei Bedarf einen Remote-Softwarekontext auf einem Remote-Kern generiert, um die Berechnung auszulagern. Der Master, die Remote-Prozessoren und ihre zugehörigen Softwarekontexte (das heißt Betriebssystemumgebungen) können homogen oder heterogen sein. Um die Komplexität beim Lebenszyklusmanagement mehrerer verschiedener Betriebssystem auf möglicherweise unterschiedlichen Prozessoren effektiv zu bewältigen, ist Software mit neuen, verbesserten Fähigkeiten und Methoden erforderlich.

Zum Managen dieser komplexen Mehrkernumgebungen wird eine Softwareimplementierung wie ein strukturiertes Multicore-Framework benötigt. In diesem Artikel bezieht sich der Begriff Multicore-Framework auf das „Mentor Embedded Multicore Framework” (MEMF) von Mentor Graphics. Das beschriebene Framework ist jedoch nicht auf ARM-Architekturen oder heterogene Systeme beschränkt. Dieses Konzept lässt sich auch mit PPC oder IA-Kernen einsetzen. Mentors Multicore-Framework ist eine kommerzielle Implementierung von OpenAMP – einem neuen API-Standard, der unter dem Dach der The Multicore Association (MCA) verwaltet wird.

remoteproc und rpmsg

Um sicherzustellen, dass Entwickler Rechenprobleme mit heterogenen SoCs effizient lösen, ist eine Standardisierung der wichtigsten Funktionen erforderlich. Auf diese Weise bietet das Multicore-Framework zwei entscheidende Funktionen zur Unterstützung von AMP-Systementwicklern:

• remoteproc. Die remoteproc-Komponente und -API hilft, das Lebenszyklusmanagement von Remote-Prozessoren und ihren zugehörigen Softwarekontexten zu verwalten. Es ermöglicht die Kontrolle der Reset-, Lade-, Ausführungs-, und Reboot-Zustände der Prozessoren und Kerne.
• rpmsg. Eine rpmsg-Komponente und -API unterstützt Remote-Messaging und ermöglicht die Interprozesskommunikation (IPC) zwischen den Betriebssystemen in der AMP-Umgebung.

Um diesen Ansatz mithilfe des Linux-Betriebssystems zu veranschaulichen, wird – wenn der Entwickler eine weitere Task starten, stoppen oder ausführen möchte – der remoteproc-Befehl verwendet. Muss eine Anwendung mit einer anderen Anwendung kommunizieren, werden rpmsg-APIs verwendet, die als Teil des Mainstream-Linux in allen derzeitigen Kernel-Distributionen zu finden sind. Die Komplexität beim Managen von heterogenen Hardware- und Softwareumgebungen verdeckt das Multicore-Framework durch eine vereinfachte Anwendungsebene und indem es dem Anwender eine vereinfachte Schnittstelle auf Anwendungsebene zur Verfügung stellt.

Das Multicore-Framework von Mentor Graphics

Bild 1a zeigt ein Software-Architektur-Diagramm des Multicore-Frameworks von Mentor Graphics und seine Verwendung in RTOS- oder Bare-Metal-Umgebungen. Wie dargestellt, enthält das Framework eine gut abstrahierte Portierungsschicht, bestehend aus einer Hardware-Schnittstellenschicht und einer Abstraktionsschicht des Betriebssystems. Diese erlaubt Designern die einfache Portierung des Frameworks auf andere Prozessoren und Betriebssysteme. Bild 1b illustriert die im Linux-Kernel vorhandenen Infrastrukturen von remoteproc und rpmsg. Die remoteproc- und rpmsg-Treiber sind Kernel-Space-Treiber, die Dienste für die Treiber der remoteproc-Plattform und rpmsg-Anwendergeräte zur Verfügung stellen. Die remoteproc-Plattformtreiber gestatten Remote-Lebenszyklusmanagement und die Treiber für die rpmsg-Anwendergeräte stellen den Benutzeranwendungen IPC-Services zur Verfügung.

Bild 2: AMP-Konfiguration, die von einem Multicore-Framework (MEMF) unterstützt wird. Mentor Graphics

Das Multicore-Framework ermöglicht nicht nur die Interoperabilität von RTOS- und Bare-Metal-Umgebungen mit Linux-remoteproc/rpmsg-Infrastrukturen in AMP-Architekturen, sondern bietet auch die Workflows und Laufzeit-Infrastruktur, um Linux in AMP-Konfigurationen als Remote-Betriebssystem zu packen und zu booten. Bild 2 zeigt verschiedene AMP-Konfigurationen, die das Framework unterstützt.

Beaufsichtigte und unbeaufsichtigte AMP

Das Multicore-Framework eignet sich sowohl für unbeaufsichtigte als auch für beaufsichtigte AMP-Architekturen. Um die nachfolgenden Anwendungsfälle zu demonstrieren, wurde eine Zync-7000-MPSoC-Hardwareplattform von Xilinx verwendet. Diese verfügt neben einer FPGA-Fabric über vier ARM-Cortex-A53-Kerne und zwei ARM-Cortex-R5-Kerne (Bild 3).

Eine unbeaufsichtigte AMP (unsupervised AMP, uAMP) -Architektur eignet sich für Anwendungen, die keine starke Trennung zwischen den beteiligten Betriebssystemen erfordern. In dieser Architektur laufen die Betriebssysteme nativ auf den im System vorhandenen Prozessoren. Wie in Bild 3a dargestellt, stellt das Multicore-Framework eine einfache und effektive Infrastruktur zur Verfügung, mit der der Master-Softwarekontext auf einem Master-(Boot)-Prozessor den Lebenszyklus und die Offload-Berechnungen für andere Rechenressourcen verwalten kann, die in typischen uAMP-Systemen in einem SoC vorhanden sind.

Bild 3: Anwendungsszenarien eines Multicore-Frameworks (MEMF): uAMP-Architektur (a) und sAMP-Architektur (b). Mentor Graphics

Eine beaufsichtigte asymmetrische Multiprocessing-(supervised AMP, sAMP) Architektur eignet sich für Anwendungen, die eine Trennung von Softwarekontexten und Virtualisierung von Systemressourcen in einem AMP-System benötigen. In sAMP-Architekturen laufen die beteiligten Gastbetriebssysteme auf virtuellen Gastmaschinen, die von einem Hypervisor (Virtual Machine Monitor) verwaltet und festgelegt werden. Der Hypervisor stellt der virtuellen Maschine Isolations- und Virtualisierungsdienste zur Verfügung. Mit dem Multicore-Framework können sAMP-Architekturen Berechnungen auf den im SoC vorhandenen heterogenen Rechenressourcen managen. Wie Bild 3b zeigt, lässt sich das Multicore-Framework auf zwei Arten einsetzen:

• Der Gastbetriebssystemkontext kann es für das unbeaufsichtigte Managen von heterogenen Rechenressourcen nutzen.
• Alternativ kann das Framework aus dem Hypervisor heraus für das beaufsichtige Management von heterogenen Rechenressourcen verwendet werden. Dies gestattet es dem Hypervisor, Interaktionen zwischen dem Gastbetriebssystem und beteiligten Remote-Kontexten zu überwachen.

Schlussfolgerung

Der beschriebene Multicore-Framework-Ansatz eignet sich besonders für Anwendungen, die eine bedarfsgesteuerte Verlagerung von Rechenfunktionen an spezialisierte Kerne auf einem Multiprocessing-Chip erfordern. Im Falle von stromsparenden Geräten optimiert das Framework den Stromverbrauch durch bedarfsgerechtes Hoch- und Herunterfahren von Rechenressourcen. Das Framework bietet auch eine einfache Möglichkeit zur Konsolidierung von Embedded-Systemen mit einem Kern auf leistungsfähigere Multiprocessing-SoCs. Mit sehr geringem Aufwand erlaubt das Framework die Migration von bestehender Software, die ursprünglich für Ein-Kern-Halbleiter entwickelt wurde, sodass sie problemlos mit erweiterten Systemfunktionen interagieren kann, die für neuere, leistungsfähigere Muliprocessing-Chips entwickelt wurden.

Schließlich erleichtert das Framework die Implementierung von fehlertoleranten Architekturen. Zum Beispiel kann das Framework einen zertifizierten RTOS-Kontext (Master) aktivieren, der kritische Systemfunktionen handhabt, um das Handling des Linux-Kontextes unkritischer Systemfunktionen zu verwalten.

(jj)