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

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

08.11.2010 David Kleidermacher * |

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Green Hills Software Ltd

Green Hills Software, Inc

mehr weniger

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.
(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
(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
(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)
(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.