Arm TechCon 2019 Arm führt kundenspezifische Instruktionen für Mikrocontroller ein

Extreme Low Power: 32 bit RISC-Mikrocontroller mit 2,5 μW/MHz.
Arms Cortex-M33 kann ab 2020 kostenlos für Lizenznehmer um kundenspezifische Instruktionen erweitert werden.

Manche Algorithmen lassen sich auf Standard-CPUs nur mit vielen Taktzyklen und hohem Energieverbrauch ausführen. Die Lösung im Arm-MCU-Universum waren bislang Koprozessoren. Die neue Möglichkeit, kundenspezifische Befehle zu definieren, ist in vielen Fällen allerdings ein noch besserer Ansatz.

Das RISC-V-ISA ist bekanntlich eine Open-Source-Befehlssatzarchitektur, die Designer in ihren Entwürfen implementieren können.  Da Open Source bedeutet, dass jeder den RISC-V-Standard ISA verwenden kann, passen de facto die meisten Designteams die ISA an: (1) um ihre Implementierungen von anderen zu unterscheiden, (2) Einzigartigkeit zu schaffen, die von Wettbewerbern nicht leicht kopiert werden kann, oder (3) Funktionen hinzuzufügen, die die Leistung steigern, den Energieverbrauch reduzieren und die Code-Dichte verbessern.

Letztendlich gibt es jedoch auch Nachteile einer offenen CPU: Es ist mehr Arbeit nötig, um die restliche Hardware an die CPU anzupassen und es droht eine Fragmentierung durch angepasste CPU-Cores, welche hinsichtlich des Software-Ecosystems zu einer Herausforderung werden kann.

Arm hat bislang keine kundenspezifischen Instruktionen unterstützt, was die oben beschriebenen Nachteile vermeidet. Man hat es geschafft, über viele Jahre das Ecosystem zusammenzuhalten und eine Austauschbarkeit Arm-basierender Chips zumindest was die CPU-Seite und andere von Arm lizensierte IP angeht, ermöglicht.

Auf der anderen Seite konnte man natürlich auch die bei RISC-V beschriebenen Vorteile nur bedingt nutzen, indem man bei der Architektur Armv8-M, die mit Cortex-M33 eingeführt wurde, eine Koprozessor-Schnittstelle implementiert hat, welche Arms Lizenznehmern eine Differenzierung ihrer Mikrocontroller durch die Implementierung entsprechender sehr eng an die CPU angebundene Koprozessoren für bestimmte rechenintensive Workloads ermöglicht. Die Kommunikation mit der Hardware findet unter Verwendung von Anweisungen des Koprozessors statt.

Um die Vorteile von kundenspezifischen Befehlssatz-Erweiterungen auch im Arm-Universum verstehen zu können, soll zunächst etwas detaillierter auf die Koprozessor-Schnittstelle des Cortex-M33 eingegangen werden.

Die externe Koprozessor-Schnittstelle unterstützt bis zu acht separate Koprozessoren  je nach Ihrer Implementierung. Unterstützt wird ein Datentransfer mit niedriger Latenz vom Prozessor zu und von den Beschleunigerkomponenten, die Bandbreite ist bis doppelt so hoch wie die der Prozessorspeicherschnittstelle. Die Übertragung der Registerinhalte des Cortex-M33-Prozessor zum Koprozessor findet mit speziellen Instruktionen (MCR, MCRR, MCRR, MCR2, MCRR2) statt, ebenso die Übertragung der Registerinhalte vom Koprozessor zum Cortex-M33-Prozessor (MRC, MRRC, MRC, MRC2, MRRC2). Dazu gibt es noch die Datenverarbeitungsanweisungen CDP und CDP2. Die regulären und erweiterten Formen der Koprozessoranweisungen, z.B. MCR und MCRR2, haben die gleiche Funktionalität, aber unterschiedliche Kodierungen.

Die idealen Datenübertragungsraten für die Koprozessor-Schnittstelle betragen 32 bit pro Taktzyklus für MCR, MCR2, MRC und MRC2) bzw. 64 bit pro Taktzyklus (MCRR, MCRR2, MRRC und MRRC2). Ideal bedeutet, dass der Koprozessor sofort auf eine Anweisung reagieren kann. Die idealen Datenübertragungsraten sind somit nachhaltig, wenn die entsprechenden Koprozessoranweisungen nacheinander ausgeführt werden.

Der Cortex-M33-Prozessor bietet keine Unterstützung für das automatische Speichern und Wiederherstellen der Koprozessor-Register beim Ein- und Austritt zu/von Exceptions, im Gegensatz zu den internen Prozessor-Integer- und Gleitkommaregistern. Jeder Koprozessor-Zustand muss über einen Kontextwechsel von der Software, welche die Anforderungen des Koprozessors kennt, manuell gepflegt werden. Dazu muss vom Entwickler sichergestellt werden, dass der Koprozessor, wenn er sichere Daten enthält, nicht von einer Software zugänglich ist, die in einem nicht sicheren Exception-Handler ausgeführt wird.

Aus dieser Beschreibung wird deutlich, dass die „Krücke“ mit einer eng angebundenen Koprozessor-Schnittstelle gegenüber einem vergleichbaren CPU-ISA diverse Nachteile mit sich bringt, insbesondere die Latenzzeiten bei der Datenübertragung von Registerinhalten von der CPU zum Koprozessor und zurück. Je mehr Daten rüber- und zurückgeschaufelt werden müssen, desto höher die Latenzzeiten.

Um den potentiellen Nachteilen von ISA-Erweiterungen gleich proaktiv zu begegnen, hat sich Arm das in Bild 1 beschriebene Verfahren zur Implementierung ausgedacht. In der CPU-Pipeline wird ein „Custrum Instruction Space“ genannter Bereich neben dem Standard-Befehlssatz für kundenspezifische Befehle freigehalten, je nach Komplexität können dutzende oder sogar hunderte neue Befehle mit deren Opcodes definiert werden. Dieser entspricht dem bereits bekannten Bereich für Koprozessor-Instruktionen. Im Backend können Arms Lizenznehmer dann die Ausführungseinheiten ergänzen, welche die Funktionalität der neuen Befehle abbilden. Dazu wird keine Architekturlizenz benötigt, da die Standard-RTL nicht modifiziert, sondern lediglich in einer Art Sandbox neue RTL ergänzt werden muss. Als Teil der CPU können die kundenspezifischen Instruktionen logischerweise auf alle Registerinhalte zugreifen, ohne dass diese wie im Fall eines Koprozessors in dessen Registersatz  übertragen werden müssen.

Die große Frage ist natürlich, wie Arm eine Fragmentierung der Implementierungen seiner IP verhindern will. Bild 2 zeigt die Arms Ansatz: Mit den Board-Support-Packages (BSP) seiner Lizenznehmer liefern diese Bibliotheken aus, in denen APIs hinterlegt sind, die von jedem Standard-Compiler aufgerufen werden können, der die kundenspezifischen Instruktionen nicht kennt. Hinter den APIs liegen dann die optimierten Algorithmen, die ihrerseits die kundenspezifischen Instruktionen der CPUs nutzen. Da der gesamte Code auf der CPU ohne Koprozessor läuft, entfällt natürlich der Datentransfer der Registerinhalte und die damit verbundenen Latenzzeiten.

Bild 3 zeigt schließlich, wie der Entwicklungsprozess unter Berücksichtigung von kundenspezifischen Instruktionen aussehen wird. Hardware- und Software-Designer arbeiten parallel, um einerseits die RTL und andererseits die softwaretechnische Abbildung zu erstellen.

Für Cortex-M33-Lizenznehmer sind die kundenspezifischen Instruktionen ab 2020 ohne Zusatzkosten verfügbar, in zukünftigen Arm-CPUs nach dem Cortex-M33 wird dies natürlich auch der Fall sein.  „Customization without Fragmentation“ lautet Arms Motto. Mit ST Microelectronics, NXP und Silicon Labs sind bereits drei große Lizenznehmer von Cortex-M-CPUs auf den Zug aufgesprungen, neben Arms eigener Entwicklungsumgebung von Keil ebenfalls der Compilerhersteller IAR.

Nach Arms „Arm Flexible Access“-Programm ist dies der zweite Bereich, wo man vermeintliche Stärken der RISC-V-Konkurrenz aufgreift, diese optimiert  und auf das eigene Geschäftsmodell abbildet. Der Gewinner ist einmal mehr der Kunde und zwar in Form der Lizenznehmer und deren Kunden.