So lassen sich Hybrid-Architekturen produktiv entwickeln

Der unaufhaltsame Fortschritt der Integration von Halbleitern hat viele Jahre lang die Grenzen zwischen verschiedenen Typen von Bauteilen verwischt. Indem ein Bauteiltyp mit IP einer anderen Art versehen wird, kann aus einem Sensor eine Inferenz-Engine zum Maschinenlernen werden, ein Mikrocontroller dazu gebracht werden, sich wie ein Anwendungsprozessor zu verhalten, oder ein nicht-flüchtiger Speicher einen sicheren hardwarebasierten Vertrauensanker liefern – eine Fähigkeit, für die normalerweise ein spezielles Secure-Element erforderlich wäre.

Ende 2019 sind die Grenzen noch weiter aufgehoben worden, indem zwei Arten von Systemen zusammengeführt worden sind, die fast völlig verschiedene Attribute haben: ein FPGA und Prozessoren, auf denen Echtzeitanwendungen in einer Linux-Umgebung laufen. Ein FPGA ist eine programmierbare Hardwarestruktur, die die Parallelverarbeitung mehrerer gleichzeitiger Tasks unterstützt, während ein Prozessor eine Hardwareplattform zur Ausführung einer festen Befehlssatzarchitektur (engl. Instruction Set Architecture, ISA) ist und die serielle Verarbeitung von Befehls-Threads übernimmt.

Die Einführung des Microchip PolarFire SoC FPGA im Jahr 2019 hat diese beiden Bauteiltypen zusammengeführt. So ist ein gemeinsames System-on-Chip mit den folgenden Merkmalen entstanden:

• die Ressourcen, die man von einem FPGA mittlerer Dichte erwarten würde, mit bis zu 461k Logikelementen, bis zu 1420 18 × 18 Mathematikblöcken, bis zu 33 Mbit Anwender-SRAM, acht voll konfigurierbaren PLL, einer Hochgeschwindigkeits-DDR4-Schnittstelle mit bis zu 1,6 Gbit/s sowie Multi-Protokoll-Transceivern mit einer Datenrate bis 12,7 Gbit/s und zwei fest verdrahteten PCIe-Gen2-Endpunkten/Root-Ports. Hergestellt im ausgereiften Low-Power SONOS 28-nm-Prozess, erreicht es einen bemerkenswert geringen Energieverbrauch.
• ein Multi-Core-Anwendungsprozessor, bestehend aus einem Quad-Core 64 Bit RISC-V Core-Cluster (RV64GC Application Core: 64 Bit RISC-V mit 2 × 32 kByte L1 Cache mit Fehlerkorrekturcode (ECC) und Unterstützung für virtuellen Speicher, sowie ein getrennter 64-Bit-RISC-V-Monitor-Core, ein RV64IMAC: 64-Bit RISC-V mit 32 Bit Integer-Registern, Multiplikation/Division sowie Unterstützung für Atomic Mode und Compressed Mode. Alle fünf Kerne arbeiten mit einer Geschwindigkeit bis 625 MHz. Zu den direkten I/O-Features des Prozessors gehören zwei Gigabit Ethernet-Controller, ein USB 2.0 On-The-Go-Controller und zwei CAN-Schnittstellen.

Das heißt, dass Entwickler elektronischer Systeme nun die Option haben, einen einzelnen Chip einzusetzen, der sowohl den geringen Energieverbrauch, die hohe thermische Effizienz und die hohe Sicherheit eines FPGA als auch die deterministischen Fähigkeiten zur Codeausführung eines schnellen Prozessors bietet.

Diese Hybrid-Architektur verlangt, dass das Team der Systementwickler beide Welten beherrscht: die des FPGA und die des Mikroprozessors. Was also sind die Herausforderungen bei der Integration dieser beiden Typen von Hardwaresystemen bei der Entwicklung eines gemeinsamen, zuverlässigen Endprodukts? Diese hybride SoC-Plattform bietet einzigartige Fähigkeiten und Vorteile in Anwendungen und Systemen für den Betrieb in Umgebungen mit extremen Temperaturen, Inferenz mit künstlicher Intelligenz (KI) an der Edge, sicherheitsbewussten Anwendungen, Systemen für Luft- und Raumfahrt sowie in Kommunikationsinfrastrukturen. Aber lohnen sich die Schwierigkeiten bei der Kombination dieser beiden Produkttypen, um diese Vorteile zu erreichen?

Die hybride Prozessor/FPGA-Architektur verstehen

Zentraler Bestandteil des PolarFire SoC FPGA ist ein deterministischer, kohärenter CPU-Cluster aus 4+1 RISC-V-Kernen (Bild 1). RISC-V ist eine freie und offene Funktionsspezifikation für die Befehlssatzarchitektur (ISA) eines Prozessors. Dahinter steht ein wachsendes Ökosystem von Entwicklern, Spezifikationen, Software und weiteren Ressourcen.

Für den CPU-Cluster im PolarFire SoC hat Microchip in Zusammenarbeit mit SiFive eine eigene Hardwarearchitektur entwickelt. Ein besonderes Merkmal der Implementierung durch Microchip ist die Freiheit, die CPU-Sprungvorhersage auszuschalten und das Speicher-Subsystem völlig deterministisch auszuführen.

Das beseitigt alle Schwankungen bei der Ausführungszeit, bewahrt gleichzeitig die hohe Rechenleistung der vier RISC-V-Kerne und nutzt die deterministischen Features des PolarFire FPGA.

Der fünfte Kern, ein Monitor-Kern, übernimmt das Management des Boot-Prozesses und der Systemkonfiguration. Im Gegensatz zu den Kernen der Anwendungsprozessoren unterstützt er keinen virtuellen Speicher.

Alle Speicher des SoC arbeiten mit ECC zur Erkennung von Einzelfehlern und bieten ein hohes Maß an Datenintegrität – ein Muss in sicherheitskritischen Anwendungen, z.B. bei Systemen für die Luft- und Raumfahrt.

Ein wesentliches Merkmal des SoC FPGA ist sein geringer Energieverbrauch: Bild 2 zeigt einen Vergleich des Energieverbrauchs des PolarFire SoC als Funktion der Belastung des CoreMark-Prozessors im Vergleich zu herkömmlichen Arm-Cortex-A-Mikroprozessorkernen.

In batteriebetriebenen Systemen ist das ein klarer Vorteil, aber nicht nur dort. Ein geringer Energieverbrauch kann in allen Systemen dazu führen, dass keine Kühlkörper oder Lüfter benötigt werden. Dadurch sinken Systemkosten, Größe und Gewicht und die Zuverlässigkeit verbessert sich.

Speicheraufteilung unterstützt Echtzeitbetrieb unter Linux

Neben dem FPGA-Teil mittlerer Dichte des PolarFire SoC hat Microchip auch eine Architektur implementiert, die eine deterministische Multiprocessing-Fähigkeit in Echtzeit ermöglicht. Um Betriebssystemsoftware auf einem Multi-Core-System auszuführen, haben die Hersteller von MPU die Wahl zwischen zwei Typen von Multiprocessing-Architekturen:

• Beim symmetrischen Multiprocessing (SMP) teilen sich alle Kerne den Hauptspeicher. Die Kerne beim SMP sind homogen – das Betriebssystem behandelt alle gleich. Mit dieser Architektur kann der Hersteller die Leistung eines Geräts mit nur einem Kern erhöhen, indem er identische Kerne hinzufügt.
• Beim asymmetrischen Multiprocessing (AMP) behandelt das Betriebssystem die Kerne unterschiedlich und sie teilen sich nicht denselben Speicher und die Peripherie. So kann der Systementwickler bestimmte Arten von Aufgaben einem Kern zuweisen, während die übrigen Kerne z.B. weiter das Betriebssystem ausführen.

Bestimmte Merkmale einer typischen SMP-Architektur, wie die Sprungvorhersage und Cache Misses, verhindern, dass das SoC deterministisch arbeiten kann. Die Ausführungszeit ist inkonsistent und sie kann nicht gewährleistet werden, da jeder Kern periodischen Interrupts ausgesetzt ist.

Im Gegensatz hierzu erlaubt es die AMP-Implementierung dem Anwender, einen Teil des Cache-Speichers herauszunehmen und ihn ausschließlich einer Echtzeitanwendung zuzuweisen. Das PolarFire SoC unterstützt sowohl SMP- als auch AMP-Modi und lässt dem Anwender die Freiheit der Wahl oder erlaubt sogar ein Umschalten bei Field-Updates.

Wenn der AMP-Modus im SoC konfiguriert ist, kann die Echtzeitanwendung auf einem der Anwendungskerne laufen, also einem Echtzeit-Kern, bei dem die Sprungvorhersage ausgeschaltet worden ist (Bild 3).

Diese Hardwarestruktur unterstützt die voll-deterministische Ausführung der Echtzeitfunktionen neben dem Linux OS. Zusätzlich sind die Ausführungszeiten des Interrupt Service Routing (ISR) deterministisch – ein Anspruch, der bei einer SMP-Architektur auf einem äquivalenten Quad-Core-Mikroprozessor auf der Grundlage der Arm-Cortex-A-Technologie nicht mit der gleichen Selbstverständlichkeit erhoben werden kann.

Erfolgreiche Entwicklung hybrider FPGA/MPU-Systeme

Ein hybrides FPGA/MPU SoC bietet die einzigartige Möglichkeit, die Anforderungen bestimmter Arten von Anwendungen mit einem einzigen Chip zu erfüllen. Eine Anwendung, die z.B. gleichzeitig lokale Inferenz mit einem Modell zum Maschinenlernen ausführt und in Echtzeit den Betrieb eines sicherheitskritischen Motors steuert, kann die KI-Funktionen im FPGA des PolarFire SoC und die sicherheitskritische Steuerung mit den Multi-Core-Prozessoren implementieren.

Das Vorhandensein eines FPGA und einer MPU auf demselben Chip bedeutet jedoch, dass das Entwicklerteam in zwei verschiedenen Entwicklungsumgebungen arbeiten muss. Beide Werkzeugketten des PolarFire SoC münden in einen Konfigurator, der Folgendes erzeugt:

• Die Software-Konfiguration – die C-Datenstrukturen zur Initialisierung der Memory Map – die in der integrierten Entwicklungsumgebung (IDE) SoftConsole verwendet werden
• Die Hardware-Konfiguration – eine sog. Komponente – für die Libero FPGA IDE

Die Interaktion zwischen den beiden IDE zeigt Bild 4.

Die Simulation der Entwicklungen erfolgt ebenfalls mit getrennten Werkzeugen: Renode für die Software auf dem Multi-Core-Prozessorteil und ModelSim für den FPGA-Teil des SoC. Der On-Chip-Debugging-Mechanismus kommuniziert über eine JTAG-Schnittstelle mit den Debugging-Werkzeugen:

• C-Code kann mit einem herkömmlichen openOCD-Debugger untersucht werden
• Das FPGA-Debugging-Werkzeug ist spezialisierter, da in der Komponente standardmäßig ein Debugging-Mechanismus eingebettet ist, um einen dynamischen Zugang zu den internen Nodes der FPGA-Matrix zu gestatten. Ein spezielles Werkzeug, Smartdebug, nutzt diese interne Debugging-Schaltung, um eine intuitive Möglichkeit zum Debugging des FPGA-basierten Teils der Anwendung bereitzustellen.

Interessanterweise sind die Bedingungen zur Portierung einer Anwendung in die RISC-V-Umgebung ähnlich wie die bei einer Arm-Umgebung. Genauso, wie zwei verschiedene Geräte auf Arm-Core-Basis niemals dieselbe Memory Map haben, ist sie auch bei verschiedenen RISC-V-basierten Systemen unterschiedlich. Damit ist der Aufwand bei der Portierung von einem Arm-Kern auf einen anderen im Prinzip der gleiche, wie von einem Arm-Kern auf einen RISC-V-Kern.

Eine entwicklerfreundliche Betriebs- und Entwicklungsumgebung

Das PolarFire SoC bietet damit den Vorteil, dass es in einem Chip sowohl programmierbare Hardwarefähigkeiten als auch eine Hochleistungs-Multi-Core-Plattform für Softwareanwendungen integriert. Diese Hybrid-Architektur bringt mit sich, dass mit zwei Entwicklungsumgebungen parallel gearbeitet wird, aber Microchip hat großen Aufwand getrieben, um dem Anwender einen umfassenden Satz von Werkzeugen an die Hand zu geben, die sehr gut integriert sind und den Entwicklerteams ein produktives Arbeiten ermöglichen bei:

• Erstellen oder Migration des Systems
• Simulation der Entwicklung
• Programmierung der Hardwareressourcen im FPGA-Teil des Chips und der Anwendungssoftware, die auf dem Prozessor-Cluster läuft
• Debugging des Systems

Umfassender technischer und Vertriebs-Support für OEM, die Anwendungen auf dem Microchip PolarFire SoC FPGA entwickeln, ist bei den Anwendungsingenieuren und Embedded-Computing-Fachleuten von Future Electronics auf der ganzen Welt verfügbar. (neu)