Heterogene SoCs homogen entwickeln

RTOS und Hypervisor für Prozessoren mit MMU und MPU

31. Oktober 2022, 6:00 Uhr | Von Dr. Oliver Kühlert
In hybriden SoCs werden zunehmend heterogene Prozessoren integriert. Softwareentwickler wollen SoCs jedoch wie einen homogenen Baustein behandeln. Ein System mit RTOS und Hypervisor bietet diesen Komfort – auch für Prozessoren mit MPU und MMU
© peopleimages.com/stock.adobe

In hybriden SoCs werden zunehmend heterogene Prozessoren integriert. Softwareentwickler wollen SoCs jedoch wie einen homogenen Baustein behandeln. Ein System mit RTOS und Hypervisor bietet diesen Komfort – auch für Prozessoren mit MPU (Memory Protection Unit) und MMU (Memory Management Unit).

Mit immer fortschrittlicheren Prozessen der Halbleiterfertigung können auf gegebener Chip-Fläche mehr Funktionen integriert und damit eine höhere Wertschöpfung erzielt werden. Den frei werdenden Platz nutzen Halbleiterhersteller für die Integration prozessornativer Interfacelogik und heterogener Prozessorkerne für System on Chips (SoC). Das Ziel sind kleinere elektronische Geräte mit geringerer Energieaufnahme. Neben Anwendungen im Bereich der Konsumelektronik sind es vor allem auf Situationsbewusstsein (Situational Awareness, SA) basierende Steuerungen mit funktionalen Sicherheitsanforderungen. Damit einher geht dann auch der Wunsch zur Bauelementekonsolidierung, um Kosten senken zu können.

Anbieter zum Thema

zu Matchmaker+

Realtime-SoC für funktionale Sicherheit

Märkte für heterogene SoC-Applikationen mit funktionaler Sicherheit finden sich beispielsweise in der industriellen Automatisierung, der kollaborativen Robotik und in der Medizintechnik sowie bei zahlreichen neuen Mobilitätsanwendungen – von autonomen Intralogistik-Fahrzeugen über smarte Bau- und Landmaschinen bis hin zur Elektromobilität, dem Schienenverkehr und der Avionik. All diese Märkte sind Wachstumstreiber für solche heterogenen SoCs. Ein neues Anwendungsfeld, das mit diesen Applikationen eng in Verbindung steht, sind auch funktional sichere taktile 5G-Applikationen und damit schlussendlich auch echtzeitfähige Edge-Server in Campus- und Mobilfunknetzwerken, die mittels TSN (Time-sensitive Networking) über 5G und gegebenenfalls sogar Network Slicing mit ihren autonomen Clients in Echtzeit kommunizieren.

Besonders anschaulich lässt sich der Bedarf an heterogenen SoCs an der Automobilbranche illustrieren: Hier ist es bislang üblich, pro Fahrzeug eine Vielzahl diskreter Steuergeräte einzubauen. Inzwischen befinden sich in einem normalen Kfz über 100 Steuergeräte über das gesamte Fahrzeug verteilt. In der Oberklasse werden teils sogar mehr als 300 Steuergeräte eingebaut. Die Palette der eingesetzten Mikrocontroller reicht von 8- bis zu 32-bit-Prozessoren.

 Typische Mixed-Critical-Applikationen finden sich beispielsweise im Bereich Automobil bei Fahrerassistenzsystemen (ADAS, Advanced Driver Assistance Systems)
Bild 1. Typische Mixed-Critical-Applikationen finden sich beispielsweise im Bereich Automobil bei Fahrerassistenz-systemen (ADAS, Advanced Driver Assistance Systems).
© Who is Danny/stock.adobe.com

Im Zuge der Entwicklung der Elektromobilität und dem zunehmend autonomen Fahren werden die Konzepte der verteilten Steuergeräte jedoch komplett neu überdacht und deutlich höher integrierte Systeme auf Basis heterogener SoCs implementiert. Sie sollen sogar eine friedliche Koexistenz von Applikationen mit und ohne sowie auch abgestufter funktionaler Sicherheit ermöglichen – also Mixed-Critical-Systeme (Bild 1).

SIL-, ASIL- und DAL-zertifizierbar

Die Ultrascale+-MPSoCs von Xilinx enthalten vier MMU- und zwei MPU-basierte Cortex-Prozessorkerne sowie leistungsfähige FPGA-Logik
Bild 2. Die Ultrascale+-MPSoCs von Xilinx enthalten vier MMU- und zwei MPU-basierte Cortex-Prozessorkerne sowie leistungsfähige FPGA-Logik-
© Xilinx/Sysgo

Eine SoC-Familie, die für solche Applikationen unter anderem in unterschiedlichen SIL-, ASIL- und DAL-Leveln zertifizierbar ist, sind die Zynq Ultrascale+ MPSoCs (Multiprocessor System on a Chip) von Xilinx (Bild 2). In ihnen sind sechs Arm-Prozessorkerne, zahlreiche Standard-Interfaces sowie FPGA-Logik zur applikationsspezifischen Auslegung des SoC integriert. Dies ermöglicht es, sie multifunktional einzusetzen – sogar für Retrofit-Anwendungen.

Die PikeOS-Varianten für MMU- und MPU-gestützte Prozessoren können parallel auf dem Ultrascale+ MPSoC betrieben werden und über die Intercore-Kommunikation miteinander kommunizieren – hier ein Avionik-Beispiel
Bild 3. Die PikeOS-Varianten für MMU- und MPU-gestützte Prozessoren können parallel auf dem Ultrascale+ MPSoC betrieben werden und über die Intercore-Kommunikation miteinander kommunizieren – hier ein Avionik-Beispiel
© Sysgo

An Arm-Prozessorkernen mit vollständiger ECC-Unterstützung stehen vier Cortex-A53 mit 64 bit und ein Lockstep-fähiger und damit funktional sicherer Cortex-R5F-Dual-Core mit 32 bit zur Verfügung (Bild 3). Der FPGA bietet je nach Auslegung zwischen 81.000 und 504.000 Logikzellen. Optional ist auch eine Mali-400-MP2-GPU von Arm integriert, die für Grafik oder für AI-Inferenzlogik genutzt werden kann. Zusätzlich ist ein optionaler H.264- und H.265-Codec vorhanden.

Die Einsatzbereiche für dieses MPSoC sind vielfältig und umfassen unter anderem funktional sichere Systeme wie Antriebssteuerungen, grafik- und/oder KI-gestützte Systeme sowie kameraintegrierende Systeme, die Videocodecs für Situationsbewusstsein und Augmented Reality extrem schnell und bei sich autonom bewegenden Systemen auch in deterministischer Echtzeit verarbeiten müssen.

Kollaborative Roboter und autonomes Fahren

In einem kollaborativen Roboter oder autonomen Intralogistik-Fahrzeug kann dieser MPSoC beispielsweise eine Kamera an den integrierten FPGA anbinden, um die Bilddaten zu verarbeiten. Die so aufbereiteten Daten lassen sich dann über die auf dem Cortex-R5F installierte echtzeitfähige Bildverarbeitung mit optional integrierter Inferenzlogik analysieren, um beispielsweise Hindernisse zu erkennen. Je nach integrierter Entscheidungslogik können über den Kommunikationskanal zwischen den Kernen Ergebnisse zum leistungsfähigeren Cortex-A53 geschickt werden. Dort erfolgt dann die übergeordnete echtzeitfähige Steuerung für die autonom gesteuerte Fortbewegung. Bei Kollisionsgefahr wird die Fahrtrichtung in Einklang mit der nun bestmöglichen Route zum Ziel geändert. Um einen Fehler (Single Point of Failure, SPOF) bei der Auswertung der Bilddaten zu korrigieren, könnten die beiden Kerne des Cortex-R5F sogar im Lockstep-Modus arbeiten.

Selbstverständlich kann der Cortex-R5F in Kombination mit dem FPGA auch für Steuerungsaufgaben verwendet werden und beispielsweise Servomotoren direkt ansteuern. Auch können einzelne Tasks einer Applikation auf die unterschiedlichen Ressourcen verteilt werden, um die maximale Leistung bei minimalem Ressourceneinsatz zu erreichen. Ein weiterer interessanter Nutzen ist es, eine Steuerung sowohl auf dem R5-Kern als auch dem A53-Kern auszuführen, um innerhalb eines SoCs eine Redundanz zu schaffen.

Herausforderung Komplexität

Eine der größten Herausforderungen solcher SoCs sind jedoch die hohen Kosten bei der Entwicklung und Pflege solcher heterogenen Systeme. Eine möglichst integrierte Applikationsentwicklung der SoCs wird deshalb gefordert, da nur so Synergieeffekte erzielt werden können, die die einmaligen Kosten (NRE, Non-recurring Engineering) senken und eine effiziente Entwicklung optimal ausbalancierter Echtzeitsysteme erlauben.

Eine große Herausforderung kann es beispielsweise sein, die einzelnen Subsysteme störungsfrei auf einem solchen SoC zu betreiben. Das gilt bei Multi-Core-Implementierungen auch für Cache-Interferenzen. Es sollte zudem beispielsweise – und das ist für die Applikationsentwickler von besonderer Bedeutung – auch einfach möglich sein, Tasks einer Applikation bedarfsgerecht mal dem einen Prozessorkern und mal dem anderen Prozessorkern zuweisen zu können, ohne großen Entwicklungsaufwand dafür betreiben zu müssen.

Prozessoren mit MMU und MPU

Der Unterschied zwischen den Arbeitsspeichermanagement-Systemen ist, dass mit einer MMU virtuelle Adressbereiche in beliebige physische Adressbereiche umgesetzt werden können
Bild 4. Der Unterschied zwischen den Arbeitsspeichermanagement-Systemen ist, dass mit einer MMU virtuelle Adressbereiche in beliebige physische Adressbereiche umgesetzt werden können. Ohne MMU muss jeder Prozess jedoch genau wissen, wohin er im Speicher springen soll.
© Sysgo

Dies ist bei komplexen SoCs wie dem Zynq Ultrascale+ MPSoC nicht trivial, denn bei den Cortex-A53-Prozessorkernen basiert die Arbeitsspeicherverwaltung auf einer Memory Management Unit (MMU), beim Cortex-R5F-Dual-Core auf einer Memory Protection Unit (MPU). Der Unterschied zwischen diesen unterschiedlichen Systemen für das Arbeitsspeichermanagement ist, dass mit einer MMU virtuelle Adressbereiche in beliebige physische Adressbereiche umgesetzt werden können. Die MMU weist einem Prozess also einen konkreten Adressbereich zu.

Das neue PikeOS, Betriebssystem und Hypervisor for MPU von Sysgo, ist für Prozessoren mit Memory Protection Unit (MPU) ausgelegt, bei denen jedem Prozess ein dedizierter Speicherbereich zugewiesen werden muss
Bild 5. Das neue PikeOS, Betriebssystem und Hypervisor for MPU von Sysgo, ist für Prozessoren mit Memory Protection Unit (MPU) ausgelegt, bei denen jedem Prozess ein dedizierter Speicherbereich zugewiesen werden muss
© Sysgo

Ein Controller mit MPU hat diese Zuweisungsfunktion nicht. Die MPU bietet zwar weiterhin den Schutz, dass der eine Prozess dem anderen nicht in denselben Speicherbereich schreiben kann (Bild 4). Ohne MMU muss jeder Prozess jedoch genau wissen, welcher Bereich des Speichers ihm zur Verfügung steht. Das ist konzeptionell komplexer, da jedem Prozess ein dedizierter Speicherbereich zugewiesen werden muss (Bild 5). Die Systemsoftware des RTOS muss also das API der Speicherzuweisung bieten.


  1. RTOS und Hypervisor für Prozessoren mit MMU und MPU
  2. Zwei Welten – in einem SoC

Verwandte Artikel

SYSGO AG