Echtzeit-SoC-Systeme mit hohem Datendurchsatz entwickeln

Moderne SoC-Software besteht meist aus mehreren Anwendungen. Diese reichen von Echtzeitanwendungen wie Automotive-Motorsteuerungen bis zu hochauflösendem Video Streaming mit hohem Datendurchsatz. Die Entwicklung von Hybridsystemen wird zu einer Herausforderung, da SoCs immer mehr für hohen Datendurchsatz mit einer steigenden Zahl an Prozessor-Cores und Schnittstellen mit hoher Bandbreite ausgelegt werden. Um Echtzeitverarbeitung zu erzielen (weniger als 1 µs Jitter mit Antwortzeiten im µs-Bereich), muss eine sorgfältige Abwägung und Systempartitionierung erfolgen. Auch zukunftssichere Strategien sind erforderlich, da SoCs immer komplexer werden. Um Hybrid-SoC-Systeme optimal entwickeln zu können, gibt es drei Ansätze: Asymmetric Multi-Processing (AMP), Hypervisor und Symmetric Multi-Processing (SMP) mit Core-Isolation (Bild 1).

Bild 1: Vergleich zwischen AMP, Hypervisor und SMP mit Core-Isolation.Altera

Asymmetrisches Multi-Processing

AMP ist die Anbindung mehrerer Betriebssysteme (OS) an physikalisch unterschiedliche Prozessor-Cores. Ein Beispiel ist der Betrieb eines BareMetal OS für Echtzeitaufgaben auf dem ersten Core und die Ausführung eines umfassenden OS wie Embedded Linux auf den anderen Cores. Die anfängliche Portierung der Betriebssysteme auf die Cores ist meist sehr einfach. Nur der Start-up-Code und das Ressourcen-Management, zum Beispiel für Speicher, Cache und Peripherie, sind fehleranfällig. Wenn mehrere Betriebssysteme auf die gleiche Peripherie zugreifen, wird das Verhalten nicht-deterministisch und kann sehr viel Aufwand beim Debuggen verursachen. Daher ist meist eine Schutzarchitektur wie ARM-Trustzone erforderlich.

Für noch mehr Komplexität sorgt der Nachrichtenaustausch (Message Passing) zwischen den Betriebssystemen, der gemeinsame Speichernutzung erfordert und zusammen mit anderen Schutzmechanismen verwaltet werden muss. Da der Cache-Speicher nicht von verschiedenen Betriebssystemen gemeinsam genutzt werden kann, erfolgt der Nachrichtenaustausch über Speicherregionen ohne Cache, was Verzögerungen und Jitter hinzufügt. Hinsichtlich der Skalierbarkeit ist dies auch eine schlechte Software-Architektur, da eine umfangreiche Re-Portierung erforderlich ist, sobald die Anzahl der Kerne steigt.

Hypervisor

Ein Hypervisor ist eine Softwareschicht auf unterer Ebene, die direkt auf der Hardware läuft und mehrere unabhängige, darüber befindliche Betriebssysteme verwaltet. Obwohl die anfängliche Portierung ähnlich zu AMP ist, bietet der Hypervisor den Vorteil, dass er die komplizierten Details des Ressourcen-Managements und des Nachrichtenaustausches ausblendet. Ein Nachteil ist der Performance-Overhead aufgrund der zusätzlichen Softwareebene, die den Durchsatz und die Echtzeit-Performance verschlechtert.

Symmetrisches Multi-Processing

SMP mit Core-Isolation betreibt ein OS auf mehreren Cores mit interner Core-Partitionierung. Ein Beispiel ist die Anweisung an das SMP OS, eine Echtzeitanwendung auf dem ersten Core zu unterstützen und den Rest der Nicht-Echtzeitanwendungen auf den verbleibenden Cores. Dieser Ansatz ist skalierbar, da das SMP OS sich nahtlos auf eine steigende Anzahl von Cores portieren lässt. Da alle Cores durch ein OS verwaltet werden, findet der Nachrichtenaustausch zwischen den Cores im L1 Daten-Cache statt, was eine schnellere Kommunikation und weniger Jitter garantiert.

Core-Isolation kann einen Core für die Echtzeit-Anwendung reservieren, um Auswirkungen von anderen Cores mit hohem Datendurchsatz abzuschirmen. Dies ermöglicht den geringen Jitter und die Datenantwort in Echtzeit. Hierbei handelt es sich generell um eine gute Entscheidung bezüglich der Software-Architektur, da Entwickler die Betriebssysteme frei wählen können, anstatt fehleranfällige, Low-Level-Software neu zu erfinden, um mehrere Betriebssysteme verwalten zu können. Die anfängliche Portierung mag etwas aufwändig sein, wenn mehrere Betriebssysteme involviert sind. Beginnt man aber mit einer SMP-Architektur ist der Aufwand wesentlich geringer.

Optimierung eines Echtzeit-SoC mit SMP und hohem Datendurchsatz

Vergleicht man die Alternativen, bietet SMP mit Core-Isolation die beste Architektur, um Echtzeit-SoC-Systeme mit hohem Durchsatz zu optimieren. Unsere Architektur ist ähnlich dem System in Bild 3, das I/O-Daten am SoC empfängt. Die Daten werden von den Prozessoren verarbeitet und mit geringem Jitter und kurzer Latenzzeit an das I/O-System zurückgesendet. Der SoC besteht aus mehreren Cores, die gleichzeitig auch andere Anwendungen mit hohem Datendurchsatz verarbeiten. Eine Echtzeitantwort (Schleifenzeit) setzt sich aus folgenden Bestandteilen zusammen:

• Übertragung neuer Daten von I/Os (DMA) an den Systemspeicher,
• Prozessor erkennt die neuen Daten im Systemspeicher (Core-Isolation),
• Kopieren der Daten in einen privaten Speicher (memcpy),
• Verarbeitung/Berechnen der Daten,
• Ergebnis in den Systemspeicher zurückkopieren (memcpy),
• Übertragung des Ergebnisses zurück an die I/Os (DMA).

Bild 2: Memcpy- und DMA-Performance mit/ohne Cache-Kohärenz.Altera

Da sich der Jitter und die Latenz über diese sechs Stufen addieren, muss jeder Schritt optimiert werden. Bei einem RTOS wie VxWorks mit Core-Isolation kann die Abfrage-/Interrupt-Antwort im ns-Bereich erfolgen. Die Datenberechnung ist anwendungsspezifisch und gut vorhersagbar. Deshalb konzentrieren wir uns auf die Abwägung zwischen DMA (Direct Memory Access) und memcpy. Es gibt zwei Möglichkeiten, Daten zu übertragen: mit oder ohne Cache-Kohärenz. Beide Methoden haben unterschiedliche Auswirkungen bei DMA und memcpy. Trotz der Cache-Kohärenz (mit dem ARM Cache Coherency Port, ACP), die zu einem längeren Pfad für die DMA-Ausführung führt, muss der Prozessor nur auf den L1-Cache zugreifen, um die übertragenen Daten zu erhalten (Bild 2). Die memcpy-Zeit ist daher mit Cache-Kohärenz wesentlich kürzer und dominiert die geringe Verschlechterung der DMA-Performance. Für den Entwickler bedeutet das, dass der Cache-kohärente Datentransfer aufgrund des direkten Cache-Zugriffs mit wesentlich kürzerer Latenz und weniger Jitter durchgeführt wird.

Fallstudie: Best-Practice SoC-Design

Bild 3: Experimentelles Referenzdesign.Altera

Ein komplettes System lässt sich mit einem Referenzdesign demonstrieren, das ein Cyclone V SoC FPGA-Entwicklungskit verwendet. Es besteht aus einem Dual-Core ARM Cortex-A9 Subsystem (HPS) und einem 28-nm-FPGA in einem Baustein. Die Hardware- und Softwarearchitekturen sind in Bild 3 dargestellt und weiter unten zusammengefasst.

Hardwarearchitektur:

• Zwei DMAs zum Datentransfer von den FPGA I/Os zum ARM-Prozessor und umgekehrt,
• beide DMAs sind an den ACP angeschlossen, um Daten direkt zum/vom ARM-Prozessor-Cache zu übertragen,
• Echtzeitsteuerungs-IP initiiert die Nachrichtenweiterleitung zwischen den ARM-Prozessoren und den DMA Engines auf schnellstmögliche Art,
• Jitter-Überwachung für Echtzeit-Performance durch direkte Messung der DMA-Signale mit einer Genauigkeit von ±6,7 ns.

Softwarearchitektur:

• RTOS VxWorks läuft im SMP-Modus auf den Dual-Core ARM-Prozessoren,
• Core-Isolation weist die Echtzeitanwendung auf den ersten Core zu und den Rest der Nicht-Echtzeitanwendungen auf den zweiten Core,
• die Echtzeitanwendung fragt kontinuierlich Daten von den I/Os ab, verarbeitet diese und sendet das Ergebnis zurück an die I/Os,
• die Nicht-Echtzeitanwendungen beanspruchen den ARM-Core und andere I/Os, indem kontinuierlich FTP-Transfers und Datenentschlüsselung stattfinden.

Ergebnisse

Bild 4: Experimentelle Ergebnisse der Echtzeitschleife und des Jitters.Altera

Die Experimente wurden mit verschiedenen Datengrößen von 32 bis 2048 Byte durchgeführt. Jede Größe wurde millionenfach ausgeführt, um das Histogramm der Schleifenzeit zu erstellen und den Jitter zu analysieren (Unterschied zwischen maximaler und minimaler Schleifenzeit). Selbst mit umfangreichem FTP-Datenverkehr auf dem zweiten Core, werden bei Millionen von Testläufen eine Latenz im µs-Bereich und weniger als 300 ps Jitter erzielt (Bild 4). Es treten zwar Jitter-Schwankungen bei verschiedenen Größen auf, die aber innerhalb von 200 ps unter Kontrolle gebracht wurden.

Die gleiche FTP-Anwendung läuft auf VxWorks SMP und nutzt beide Cores, was die Latenz fast verdoppelt. Diese Technik verschlechtert also den Datendurchsatz und es muss eine Abwägung zwischen Durchsatz und Echtzeitanwendung erfolgen. Aber auch bei einer AMP-Lösung zeigt sich aufgrund der Partitionierung der Cores die gleiche Verschlechterung – und das bei geringerer Skalierbarkeit.

(jj)