From the basics to the prototype

III. SDK components

The SDK for arm and RISC page is downloaded separately from open-isa.org. The core is an almost identical software package for both sides (Figure 4, above) on execution and application level (middleware and demo_apps).

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Essentially, the arm side differs here only by one more example for mbedtls. The middleware contains packages for fat_fs, mbed_tls, multi-core calculation, sd_mmc, USB, WiFi with BLE and thread as well as wolfssl.

The build environment is much more proprietary on both sides (Figure 5). The lowest common denominator for integer computation is GNU at the terminal level: for the RISC cores the pulp compiler riscv32-unknown-elf [8], for the arm cores arm-none-eabi [9,**], can be a source for gcc and gdb.
Then cmake is the build tool of choice on both sides. The target connection is on the RISC side with openocd, on the arm side with JLinkGDBServer (Figure 5). An openocd connection to the arm side would have to be configured in individual cases. A precompiled openocd version of open-isa.org is also used, since the canonical 0.10.0 does not recognize the RIC5Y core.

There are also third-party accesses to the arm page such as IAR, Keil and Segger, as well as Eclipse access to the RISC side [7]. A user would have to configure the Eclipse access to the arm side himself.

The structure of a build directory in the SDK is standard: a directory with tool configurations, c-code and header for hardware configuration, clock configuration and the application to run. Two application reports in the documentation accompany the commissioning of a multi-core or Bluetooth application.

Tool chain and code example

For the commissioning of the Vega-Board the booting core must first be set in an openocd connection, then either the arm or the RISC side can be written, executed and analyzed via the respective hardware interface.

For the fast proof-of-concept, one of the standard examples (Figure 4, above) is translated with the present cmake script and written to the chip via the respective gdb derivative and tested. On the arm side, the clean script has to be executed before the build script.

Due to the lack of RISC-V-trace, a performance comparison in cycles or absolute timing between the RISC and the arm side is not possible. Static code analysis for the respective application can also be performed without the actual hardware (gdb $sim target).

For this purpose the hello_world was extended by pseudo-random arithmetic: the program dices out an elementary instruction of the I-class (add, sub, mul, div, xor, or, and) on the c-level in each step and applies it in an endless loop to random 32-bit values. The code metrics in asm and binary are interesting: the RISC page has 27 lines less asm code (gdb $ disas) but a machine command sequence 54 bytes longer (Figure 4, bottom; gdb $ gdumb /r) than the arm page.

1. From the basics to the prototype
2. I. RISC-V principles according to ISA specification
3. I. Behaviour in the environment
4. I. Interrupt and extension model
5. II. Design and verification according to DVCon Europe
6. III. Prototyping with the Vega-board
7. III. SDK components
8. IV. Conclusion