Multicore Software-Architekturen für die nächste Generation von Embedded-Systemen

Martina Hafner

Anbieter zum Thema

Moderne Multicore-SoCs bieten Softwareentwicklern eine hohe Leistungsfähigkeit, die gesteuert und kontrolliert werden muss. Der erste Schritt ist, die unterschiedlichen Architekturen und ihre Vor- und Nachteile zu verstehen. Die richtige Entscheidung kann zu erfolgreichen Designs für viele kommende Produktgenerationen führen.

Moderne Multicore-SOCs: Sie bieten Softwareentwicklern eine hohe Leistungsfähigkeit, die geeignet gesteuert und kontrolliert werden will. Der erste Schritt ist das richtige Verstehen der Plattform-Architekturen und ihrer jeweiligen Vor- und Nachteile.
Moderne Multicore-SOCs: Sie bieten Softwareentwicklern eine hohe Leistungsfähigkeit, die geeignet gesteuert und kontrolliert werden will. Der erste Schritt ist das richtige Verstehen der Plattform-Architekturen und ihrer jeweiligen Vor- und Nachteile.
(Bild: Clipdealer)

Stellen Sie sich vor, Sie sind im Jahr 2020 leitender Softwareentwickler für ein neues Embedded-Design. Sie machen sich Gedanken zu dem Mikroprozessor, der von den Hardwareentwicklern ausgewählt wurde und fragen sich, wie Sie daraus die maximale Leistung für das ehrgeizigste Projekt herausholen können, das sich Ihr Unternehmen jemals erdacht hat.

Dieses System-on-Chip verfügt über Dutzende universeller Prozessor-Cores; eine Speicherbandbreite mit Hunderten von GBit/s über mehrere Speicher-Controller hinweg; 64-Bit-Adressierung; mehrere 10-GBit-Ethernet-Schnittstellen; einen RAID-Beschleuniger; einen Paket-Deduplizierer; eine Kompressionseinheit; drei Cache-Ebenen; unzählige Peripherie (USB, UART, SD Card etc.).

Ferner eine Regular Expression Pattern Matching Engine; Paket-Scheduling und Routing-Infrastruktur; Hypervisor-Beschleunigung; eine Security Engine mit Unterstützung für Symmetric, Public Key und Hashing; und umfangreiche On-Chip-Debug-Funktionen. Die Chip-Referenzdokumentation umfasst mehrere tausend Seiten.

Bild 1: Blockdiagramm des Multicore-Prozessors QorIQ P4080 von Freescale
Bild 1: Blockdiagramm des Multicore-Prozessors QorIQ P4080 von Freescale
(Green Hills Software)

Sie meinen, dass es sich um ein Szenario in zehn Jahren handelt? Weit gefehlt. Ich habe gerade die Funktionen beschrieben, die sich bereits heute auf Highend-Multicore-Netzwerkprozessoren von Cavium (OCTEON II), Freescale (QorIQ), LSI (Axxia) und NetLogic (XLP) befinden. Das Blockdiagramm des Freescale P4080 gibt dazu einen beeindruckenden Überblick (Bild 1).

Bild 2: On-Chip-Debugging-Architektur des Freescale QorIQ
Bild 2: On-Chip-Debugging-Architektur des Freescale QorIQ
(Green Hills Software)

Jedes seiner Subsysteme ist äußerst komplex. Allein der Freescale P4080 verfügt über umfangreiche Debugging-Eigenschaften, sofern ein Debugger vorhanden ist, um diese alle zu nutzen: On- und Off-Chip-Befehls- und Daten-Trace, Performance Counter, Inter-Core Cross Trigger, anwenderprogrammierbare Performance- und Engine-Überwachungs-Events, welche die Trace-Logik erweitern, etc. (Bild 2).

Ausgeklügelte Software sorgt für das volle Potenzial

Diese Bausteine programmieren sich leider nicht von selbst. Um das volle Potenzial dieser Datenverarbeitungsriesen zu nutzen, ist einiges an ausgeklügelter Software erforderlich. Dieser Beitrag wird das Gesamtproblem nicht lösen, aber wir beschreiben die Softwareebene, welche die Plattform steuert: die Betriebssysteme und Hypervisoren, auf denen alles andere aufbaut. Der leitende Softwareentwickler muss zumindest die wichtigsten Optionen verstehen und zwischen ihnen eine Abwägung treffen können.

Bei allen folgenden Optionen gehen wir davon aus, dass das Design nicht echtzeitfähige Software enthält (z.B. Management- und Zustandsüberwachung; Routing-Protokolle für die Steuerungsebene wie OSPF; Mensch-Maschine-Schnittstellen) wie auch Echtzeit-Verarbeitung durchführt (z.B. schnelle Datenverarbeitung und Gerätetreiber mit niedriger Latenzzeit).

Option 1: Linux SMP

Linux wird gerne für die Steuerung von Netzwerk-Einrichtungen verwendet, ist aber kein Echtzeit-Betriebssystem. Deshalb kann es keine Garantie über Worst-Case-Reaktionszeiten bieten. Die Millionen von Codezeilen überfordern Datenverarbeitungsanwendungen, die eigentlich minimale Laufzeiten erfordern und eng gekoppelt mit Hardware-Beschleunigern arbeiten müssen.

Bild 3 zeigt die SMP-Architektur von Linux (Symmetric Multiprocessing)
Bild 3 zeigt die SMP-Architektur von Linux (Symmetric Multiprocessing)
(Green Hills Software)

Trotzdem können Entwickler Linux sowohl für Steuerungs- als auch Datenverarbeitungsaufgaben einsetzen, indem sie eine SMP-Lösung integrieren, die die Verarbeitungs-Threads mit den Cores verknüpft. Bild 3 zeigt die Linux-SMP-Architektur.

Option 2: RTOS SMP

Aufgrund ihrer Echtzeit-Eigenschaften und niedrigen Latenzzeit sind Echtzeit-Betriebssysteme in Netzwerkeinrichtungen und vielen anderen Multicore-basierten Embedded-Systemen beliebt. Ein nicht echtzeitfähiges Betriebssystem kann keine Echtzeit-Aufgaben ausführen, ein Echtzeit-Betriebssystem (RTOS) hingegen schon.

Bild 4:Eine Multicore-Architectur mit RTOS (Integrity) SMP
Bild 4:Eine Multicore-Architectur mit RTOS (Integrity) SMP
(Green Hills Software)

Ein SMP-RTOS wie Green Hills Softwares INTEGRITY oder Intels VxWorks stellt damit einen Ersatz für das Linux aus Option 1 dar (Bild 4).

Option 3: Lightweight Executive

SMP wird zu einer Performance-Herausforderung, sobald mehrere Cores beteiligt sind. OS-Dienste erfordern schützendes Kernel-Locking, was die Latenzzeit erhöht, sobald mehrere Cores versuchen, diese Dienste gleichzeitig in Anspruch zu nehmen.

Während einige Entwickler SMP als einfache Lösung zur Verwaltung vieler Cores sehen, wollen andere die Cores unter ihren Software-Teams aufteilen. Dabei soll sich jedes Team auf sein spezifisches Projekt konzentrieren. Wenn jedes Team sein eigenes unabhängiges Betriebssystem unterhält, das für deren spezielle Anforderungen ausgelegt ist, wird auch die Projektentwicklung effizienter. Für Datenverarbeitungsaufgaben wird dann anstatt eines kompletten Betriebssystems eine einfache Laufzeitumgebung bevorzugt.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Alle vorher genannten Prozessorhersteller bieten zu diesem Zweck eine Lightweight-Executive-Lösung (LWE), was nichts anderes ist als etwas Initialisierungscode, Gerätetreiber und eine Superloop ohne Threads. Außerdem stehen optimierte Bibliotheken bereit, die bereits für die LWEs ausgelegt sind und die verschiedenen Beschleuniger verwalten.

Bild 5: Aufteilung der Systemsoftware in Steuerungs-OS und LWEs (Light Weight Executive)
Bild 5: Aufteilung der Systemsoftware in Steuerungs-OS und LWEs (Light Weight Executive)
(Bild: Green Hills Software)

Beim Einsatz von LWEs kann die Steuerungsebene über Linux oder ein RTOS verwaltet werden, was zu einer AMP-Umgebung führt (Asymmetric Multiprocessing). Wenn die Steuerungsebene unter einem OS mit SMP (Symmetric Multiprocessing) über einem Teil der Cores läuft, dann liegt eine Kombination aus SMP und AMP vor (Bild 5).

Anstelle einer vom Chip-Anbieter bereitgestellten LWE, bietet ein einfacher Echtzeit-Microkernel wie Green Hills Software μ-velOSity oder Express Logics ThreadX eine ähnliche Funktion durch einen unabhängigen Softwareanbieters.

Option 4: Linux und RTOS

Bild 6: Hybrid-Software-Architektur für Multicore-Systeme aus Linux und RTOS
Bild 6: Hybrid-Software-Architektur für Multicore-Systeme aus Linux und RTOS
(Green Hills Software)

Embedded-Entwickler mussten sich früher zwischen Linux und einem RTOS entscheiden. Multicore-Prozessoren hosten heutzutage beides. Ähnlich wie in der Option 3 läuft Linux im SMP-Modus auf Steuerungsebene, während das RTOS den Echtzeit-Teil verwaltet – entweder im SMP- oder AMP-Modus (Bild 6).

Option 5: Virtualisiertes Modell

Ein Vorteil der Option 2 (RTOS SMP) gegenüber den Optionen 3 und 4 ist, dass ein einziges hochzuverlässiges Betriebssystem die Hardware komplett steuert. Bei den Optionen 3 und 4 hat das OS der Steuerungsebene keine direkte Kontrolle über die Echtzeit-Cores und umgekehrt. Die Programme auf Steuerungs- und Datenebene können sich dabei gegenseitig beeinträchtigen. So kann eine fehlerbehaftete DMA, die durch die LWE programmiert wurde, das OS der Steuerungsebene korrumpieren.

Ein weiteres Beispiel betrifft die Verwaltung kryptographischer Schlüssel: Schadsoftware in Linux kann auf kritische Algorithmen und Parameter zugreifen, die über ein Sicherheits-Subsystem auf anderen Cores gesteuert werden. Das System weist somit eine Ressourcenaufteilung auf, aber es mangelt an einer Isolierung und Zugriffskontrolle auf diese Ressourcen.

Zum Glück wird Hardware-Hypervisor-Support in diese Multicore-Prozessoren integriert. Der Freescale P4080 unterstützt z.B. die Hypervisor-Mode-Erweiterungen der Power Architecture ISA 2.06, was eine komplette Virtualisierung von Gast-Betriebssystemen mit minimalem Overhead ermöglicht.

Schutz durch strenge Partitionierung

Virtualisierungssoftware und Hardware kann die Option 4 in ein streng partitioniertes System verwandeln, das weiterhin flexibel genug ist, verschiedene Betriebssysteme für Aufgaben auf Steuerungs- und Datenebene zu betreiben. Einige Echtzeit-Betriebssysteme bieten eine integrierte Virtualisierung, was eine zusätzliche Hypervisor-Ebene erübrigt.

Bild 7: Multicore-Architektur mit Linux- und RTOS-Partitionierung mittels Virtualisierung
Bild 7: Multicore-Architektur mit Linux- und RTOS-Partitionierung mittels Virtualisierung
(Green Hills Software)

In Bild 7 betreibt der Green Hills INTEGRITY Multivisor die hochleistungsfähigen Echtzeit-Threads mit geringer Latenzzeit direkt, während Linux SMP und dessen Applikationssoftware in einer virtuellen Maschine ausgeführt werden.

Ein Hypervisor-verwaltetes System bietet gegenüber der herkömmlichen AMP-Aufteilung der Arbeitslast wichtige Vorteile. Eine Virtualisierung bietet die Flexibilität, die Zuweisung der Betriebssysteme für die Steuerungs- und Datenebene auf die Cores zu ändern. Im Normalbetrieb möchte der Entwickler z.B. nur einen einzigen Core zur Steuerungsfunktion nutzen und alle anderen Cores für die Datenverarbeitung.

Das System lässt sich jedoch in einen Wartungsmodus versetzen, in dem Linux alle vier Cores (SMP) nutzen darf, während die Datenverarbeitung kurzzeitig gedrosselt wird. Die Virtualisierungsebene kann die Neuzuteilung der Cores im Hintergrund übernehmen, was ein statisches AMP-System nicht vermag.

Hypervisor bietet Integrierten IPC-Ablauf

Die prozessinterne Kommunikation (IPC – Interprocess Communication) ist ein weiterer Vorteil eines Hypervisors. Die Steuerungs- und Echtzeit-Subsysteme müssen miteinander kommunizieren. So müssen Routing-Änderungen auf Steuerungsebene an die entsprechenden Einheiten der Datenebene kommuniziert werden.

Bei einem AMP-System wird ein eigener IPC-Ablauf mit neuen Backplane-Gerätetreibern für die Betriebssysteme auf Steuerungs- und Datenebene implementiert. Im Gegensatz dazu bietet ein Hypervisor einen integrierten IPC-Ablauf, der es virtualisierten Gastsystemen erlaubt, die bestehenden Schnittstellen (z.B. einen Ethernet-Treiber) ohne Änderungen zu nutzen. Linux denkt dabei, es sendet Daten über eine Netzwerk-Interfacekarte (NIC); die NIC ist aber virtualisiert und deren Datentransfer wird im Hintergrund für den Hypervisor-integrierten Backplane-Datenaustausch umgewandelt.

Die richtige Architektur für Ihr Design

Wenn Sie nach einer Softwareplattform suchen mit nur einem Betriebssystem, ist ein Single-SMP-Betriebssystem (Optionen 1 oder 2) die richtige Wahl. Wenn Ihr System keine Echtzeit- oder hohen Sicherheitsanforderungen hat und zukünftige Produktgenerationen nicht mit diesen Anforderungen aufwarten, ist Linux SMP vollkommen ausreichend.

Wenn das System aber eines Tages diese Art von Performance oder Zuverlässigkeit benötigen sollte, ist ein RTOS eine sichere und zukunftssichere Investition. Erfordert das Design das Software-Ecosystem von Linux und die Funktionen eines RTOS (oder LWE), ist ein Hybrid-AMP-Modell (Optionen 3 oder 4) die geeignete Wahl. Sollten Sie diese Hybrid-Architektur bevorzugen und der Prozessor bietet einen Hypervisor-Modus, sollte man die Vorteile der Option 5 für mehr Zuverlässigkeit, Core-Management-Flexibilität und einfachere Anwendung nutzen.

Viele andere Faktoren können die Entscheidung für die richtige Architektur beeinflussen. Die Qualität der integrierten Softwareentwicklungstools, Betriebssysteme, Hypervisor und Mikroprozessoren wird oft übersehen. Die Multicore-Hardware-Debugging-Funktionen (wie die des P4080) müssen von den Systemanalyse-Tools voll genutzt werden, damit diese ihre Daten in nützliche Informationen zum Auffinden von Fehlern, Leistungsengpässen und zur Visualisierung des Systemverhaltens aufbereiten können. Genau diese Tools machen den Unterschied, wenn es darum geht, sein Produkt schnell im Markt einzuführen oder durch zu hohe Komplexität den Überblick zu verlieren.

Kommerziell-Strategische Aspekte

Eine stabile Unternehmensführung und Vertrauen in die Anbieter von Systemsoftware ist eine weitere wichtige Erwägung. Die Marktkonsolidierung und ein harter Wettbewerb erschweren heute langfristige Entscheidungen über Anbieter, denen man den Erfolg heutiger und zukünftiger Projekte anvertraut.

Neben finanziellen und unternehmerischen Gesichtspunkten müssen Entwickler auch die Verfügbarkeit integrierter und über Drittanbieter erhältlicher Middleware-Stacks und Treiber sowie die Zusammenarbeit zwischen dem Prozessor- und dem Software-Anbieter mit beachten. Hält sich ein Anbieter an offene API-Standards und bietet er langfristigen Support für alle führenden Multicore-Prozessorfamilien, kann sich der Entwickler auf lange Zeit seine Flexibilität wahren.

* * David Kleidermacher ...ist CTO bei Green Hills Software

Artikelfiles und Artikellinks

(ID:24136440)