Design-Praxis RISC-V

Von den Grundlagen bis zum Prototyp

10. März 2019, 19:51 Uhr | Dr. Constantin Tomaras, Ressortredakteur für Systemdesign, DESIGN&ELEKTRONIK

Fortsetzung des Artikels von Teil 6

III. SDK-Komponenten

Das SDK wird für arm- und RISC-Seite separat von open-isa.org heruntergeladen. Den Kern bildet ein für beide Seiten nahezu identisches Softwarepaket (Bild 4, oben) auf Ausführungs- und Anwendungsebene (middleware und demo_apps).

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Im Wesentlichen unterscheidet sich die arm-Seite hier nur um ein weiteres
Beispiel für mbedtls. Die Middleware enthält u.a. Pakete für fat_fs, mbed_tls, Vielkernrechnung, sd_mmc, USB, WiFi mit BLE und Thread sowie wolfssl.

Die build-Umgebung fällt auf beiden Seiten erheblich proprietärer aus (Bild 5). Den kleinsten gemeinsamen Nenner für integer-Rechnung bildet GNU auf Terminalebene: für die RISC-Kerne kann der pulp-Compiler riscv32-unknown-elf [8], für die arm-Kerne arm-none-eabi [9,**], eine Quelle für gcc und gdb sein.
Dann ist cmake auf beiden Seiten das build-Tool der Wahl. Die Zielverbindung erfolgt auf RISC-Seite mit openocd, auf arm-Seite mit JLinkGDBServer (Bild 5). Eine openocd-Verbindung zur arm-Seite müsste im Einzelfall konfiguriert werden. Auch kommt eine vorkompilierte openocd-Version von open-isa.org zum Einsatz, da die kanonische 0.10.0 den RIC5Y-Kern nicht erkennt.

Darüber hinaus gibt es third-party-Zugänge zur arm-Seite wie IAR, Keil und Segger, sowie Eclipse-Zugang zur RISC-Seite [7]. Den Eclipse-Zugang zur arm-Seite müsste ein Anwender noch selbst konfigurieren.

Die Struktur eines build-Verzeichnis' im SDK ist Standard: ein Verzeichnis mit Tool-Konfigurationen, sowie c-code und header für Hardware-Konfiguration, clock-Konfiguration und der auszuführenden Anwendung. Zwei Applikationsberichte in der Dokumentation begleiten bei der Inbetriebnahme einer Vielkern- oder Bluetooth-Anwendung.

Werkzeugkette und Code-Beispiel

Für die Inbetriebnahme des Vega-Boards muss zunächst in einer openocd-Verbindung der bootende Kern gesetzt werden, danach ist entweder die arm- oder die RISC-Seite über das jeweilige Hardwareinterface schreib-, ausführ- und analysierbar.

Für den schnellen proof-of-concept wird eines der Standardbeispiele (Bild 4, oben) mit dem vorliegenden cmake-Skript übersetzt und über das jeweilige gdb-Derivat auf den Chip geschrieben und getestet. Auf der arm-Seite muss im Auslieferzustand vor dem build-Skript allerdings noch einmal das clean-Skript ausgeführt werden.

Mangels RISC-V-trace ist zunächst kein Performanzvergleich in Zyklen oder absolutem Timing zwischen der RISC- und der arm-Seite möglich. Statische Codeanalyse für den jeweiligen Anwendungsfall, kann auch ohne die eigentliche Hardware (gdb $sim target) erfolgen.

Dazu wurde das hello_world um pseudo-zufällige Arithmetik erweitert: das Programm würfelt auf c-Ebene in jedem Schritt einen Elementarbefehl der I-Klasse aus (add, sub, mul, div, xor, or, and) und wendet ihn in Endlosschleife auf zufällige 32-Bit-Werte an. Die Code-Metrik in asm und Binärsequenz ist interessant: die RISC-Seite besitzt zwar 27 Zeilen weniger asm-Code (gdb $ disas) aber eine um 54 bytes längere Maschinenbefehlssequenz (Bild 4, unten; gdb $ gdumb /r) als die arm-Seite.