Als ARM ankündigte, aufgrund regulatorischer Bedenken auf den Zusammenschluss mit Nvidia zu verzichten, atmete mehr als nur ein Embedded-Entwickler vor Freude auf. Probleme mit Sanktionssicherheit und Co. waren nun nicht mehr zu befürchten – so dachte man sich das zumindest.

Die praktische Erfahrung des in diesem Bereich seit Jahren tätigen Autors lehrt allerdings, dass die Freude hier stark verfrüht ist. Grund dafür ist vor allem, dass sich US-Sanktionen im Allgemeinen nicht nur gegen bestimmte Unternehmen richten. Sie haben stattdessen eine Neigung zum Bubble-up, was bedeutet, dass sie die gesamte Wertschöpfungskette gleichermaßen tangieren, meist inklusive der Banken, die in US-Dollar operieren.

Die Nutzung von RISC-V in der Implementierung von GigaDevice schafft an dieser Stelle in mehrerlei Hinsicht Abhilfe: Neben der Möglichkeit, die Controller dollarfrei direkt aus China zu beziehen, führt das außerdem zur Nutzung einer quelloffenen Architektur und auf Wunsch sogar einer Value Chain komplett ohne US- und EU-Beteiligung.

Was ist RISC?

Ganz analog zur Parabel bezüglich des „no true Scotsman“ gilt, dass RISC (Reduced Instruction Set Computer) eigentlich ein nichtssagender Term ist. Wir betrachten hier spezifisch Systeme auf Basis der RISC-V-ISA – ein einst von der Universität Berkeley festgelegtes Designschema, das einen Mikrocontroller bzw. Mikroprozessor und einer oder mehrerer optionaler Erweiterungen mit zusätzlichen Funktionen beschreibt.

Interessant ist an RISC-V vor allem, dass die Standardisierungsorganisation nicht nur quelloffen arbeitet, sondern dass sie die von ihr erarbeiteten Spezifikationen explizit kostenlos, also ohne von Seiten der Mikrocontrollerhersteller einzufordernde Lizenzgebühren, zur Verfügung stellt.

Zu beachten ist allerdings, dass Manager diesen Zusammenhang oft als „der Mikrocontroller ist kostenlos“ lesen. In der Beratungspraxis des Autors waren diesbezügliche Anfragen fast an der Tagesordnung. Hier nochmals im Klartext: RISC-V-Mikrocontroller kosten natürlich Geld. Dieses Geld geht an den Hersteller des Siliziums, und wird (im Allgemeinen) nicht mit dem Standardisierungsgremium geteilt.

Gemeinsames und Unterschiedliches

Der Exkurs über die Unkostenlosigkeit von RISC-V-Controllern informiert uns darüber, dass die Wertschöpfungskette, die am Ende zum verkaufsfertigen Chip führt, von durchaus komplexer Natur ist. Beginnen wir ganz am Anfang des in Abbildung 1 gezeigten Flows – bei der Standardisierungsorganisation.

Aus Sicht des Standardisierungsgremiums ist ein RISC-V-Mikrocontroller ein Mikrocontroller, der entweder 32 oder 64 Bit lange Register aufweist – 8- und 16-Bitter sind von der Architektur ausgeschlossen. Im Kern stehen außerdem 32 Register zur Verfügung, die in Assembler Staatsbürger erster Klasse darstellen. Eins dieser Register ist dabei ein sogenanntes 0-Register, das analog zu MIPS zwar beschreibbar ist, die in ihm abgelegten Werte aber nicht remanent speichert. Liest man das 0-Register aus, bekommt man immer 0 zurück. Das beschleunigt manche Assembler-Kommandos. Interessant ist in diesem Zusammenhang außerdem, dass RISC-V immer eine Little-Endian-Affäre darstellt; Big-Endian-RISC-V-Controller sind nicht vorgesehen, was Aufwand mit Swizzeling und Co. reduziert. Unterschiedliche Prozessoren bedienen allerdings unterschiedliche Bedürfnisse. Wer mit seinem RISC-V-Controller nur grundlegende MSR-Aufgaben bewältigen möchte, hat an einem DSP-Erweiterungsbefehlssatz nur wenig Freude.

Das Standardisierungsgremium begegnet diesem Problem durch das Konzept der ISA-Basis, die einen Grundstock von Assembler-Sprachinstruktionen und einem grundlegenden Speicherlayout darstellt. Zum Zeitpunkt der Drucklegung gibt es dabei die in Tabelle 1 gezeigten Kandidaten – als „frozen“ gelten dabei die beiden Versionen RV32I und RV64I. RV32E und RV128I sind derzeit offen, können vom Standardisierungsgremium also noch mit Änderungen bedacht werden.

Im nächsten Schritt bekommt diese Basisarchitektur als RISC-V Extension bezeichnete Befehlssatzerweiterungen eingeschrieben, die dem jeweiligen Core zusätzliche Assembler- oder sonstige Funktionen beibringen bzw. einschreiben. Auch hier gilt, dass das Feld sehr weit ist; Tabelle 2 zeigt einige besonders wichtige Kandidaten.

Auch hier gilt, dass die RISC-V-Architektur für Erweiterungen der Chiphersteller offen ist. Der Standard sieht im Adressraum leere Bereiche vor, in denen sie hauseigene Erweiterungen – beispielsweise für einen Befehlssatz, der bestimmte mathematische Aufgaben sehr schnell erledigt – unterbringen dürfen. Die RISC- V Foundation spricht in diesem Zusammenhang auch von Guaranteed Non-standard Encoding Spaces, was darauf hinweist, dass zukünftige offizielle Erweiterungen diesen für den Chipentwickler bzw. seine privaten Erweiterungen vorgesehenen Speicherbereiche niemals tangieren werden.

Für uns ist eine „tiefergehende Analyse“ der Assemblersprache hier allerdings nicht interessant – Hennessy und Patterson [1] bieten eine zwar langatmige, aber im Allgemeinen brauchbare Besprechung des Themas. Interessanter ist der in Abbildung 1 gezeigte dritte Schritt, der für einen Embedded-Entwickler von wesentlich höherer Bedeutung ist. Denn Mikrocontroller kommen im Allgemeinen nicht wegen ihrer überragenden Rechenleistung zum Einsatz, sondern werden vielmehr deshalb verwendet, weil man mit Elementen der realen Welt zu interagieren versucht. Hierfür sind logischerweise Peripheriegeräte verantwortlich, die beispielsweise einen GPIO-Pin oder einen I²C-Bus implementieren und im Speicher abbilden. Der Standard macht Entwicklern an dieser Stelle überhaupt keine Vorschriften, weshalb sich die Hersteller der Chips im Allgemeinen frei zwischen ihren Vorstellungen bewegen dürfen.

Warum gerade GigaDevice?

Aus der soeben gemachten Feststellung, dass das Design der Peripheriegeräte alleinige Verantwortung des Chipherstellers ist, folgen einige praktische Feststellungen. Erstens gilt, dass ein Wechsel zwischen RISC-Controllern verschiedener Hersteller nicht einfach ist – wer im Moment ein Produkt auf Basis eines SiFive-Chips verwendet, muss beim Umstieg auf einen GigaDevice GD32VF also zumindest den Code umschreiben, der...