Design-Praxis RISC-V
Von den Grundlagen bis zum Prototyp
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).
Jobangebote+ passend zum Thema
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.
- Von den Grundlagen bis zum Prototyp
- I. RISC-V Prinzipien nach ISA-Spezifikation
- I. Verhalten in der Umgebung
- I. Interrupt- und Erweiterungsmodell
- II. Design und Verifikation nach DVCon Europe
- III. Prototyping mit dem Vega-Board
- III. SDK-Komponenten
- IV. Fazit
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Entwicklungstools
C/C++-Toolchain für RISC-V
The RISC-V Foundation
Calista Redmond wird neuer CEO
ST Microelectronics legt vor
Stellar-MCUs mit ersten Armv8-R-CPUs Cortex-R52
Cypress Semiconductor
Secure PSoC 64
Hardware-/Software-Entwicklung
»Hyper-Debugging« mit UDE
Maker Board verbindet Welten
Ryzen-Board mit Arduino-Controller
Praxistest Debug&Trace
Auf Spurensuche
Systemdesign / embedded-Test-Design
Abstraktion als Explorationskatalysator
