Machine-readable register description files for SiFive chips

In Rust Embedded Working Group we use SVD files for different MCUs to generate Rust peripheral access bindings with svd2rust tool. These files are normally provided by vendor. However, for SiFive chips we do not have anything like this so far and the only SVD for FE310-G000 chip was created by hand. This approach is time-consuming and error-prone.

In our RISC-V team we are trying to provide Rust support for different chips available on the market. We also have plans for supporting FU540. This chip is much more complicated compared to FE310, so it will be incredibly helpful if you provide register descriptions for it. For FE310 chips it would also be useful to have register descriptions provided by vendor to check that our hand-written version does not have bugs. Having an SVD description is not mandatory, I hope that any other machine-readable format will also work for us.

Additionally, some people use SVD files with gdb to improve debugging experience.


yes please !

I was looking around for what’s the status of SVD like system in RISCV, for code generation templating. I think the concern is that SVD is an ARM technology and there may be legal issue in using it.

However I also saw that there is XSVD which is a rework of the Arm CMSIS SVD, but cleaned, extended and rewritten in JSON instead of XML.

You may want to look into this project instead and see if SiFive would be more interested in this tech instead.


That’s a good suggestion.
I don’t think we particularly care what format it’s in, anything machine-readable will do, it’s the correctness and completeness of the info that matters :slight_smile:

Not sure if worth a seperate post. However this has application beyond generating HAL code for projects. For example, I recently have to update a ST serial bootloader loader program to support a new stm32 chip.

e.g. In stm32flash sourceforge page… it keeps track of what devices it can program based off AN2606 pdf. However the pdf file cannot be parsed easily. This is annoying. It would be better if this page can be updated via a json dataset released by the vendor (e.g. ST micro).

const stm32_dev_t devices[] =
  /* ID   "name"                              SRAM-address-range      FLASH-address-range    PPS  PSize   Option-byte-addr-range  System-mem-addr-range   Flags */
  /* F0 */
  {0x440, "STM32F030x8/F05xxx"              , 0x20000800, 0x20002000, 0x08000000, 0x08010000,  4, p_1k  , 0x1FFFF800, 0x1FFFF80F, 0x1FFFEC00, 0x1FFFF800, 0},
  {0x442, "STM32F030xC/F09xxx"              , 0x20001800, 0x20008000, 0x08000000, 0x08040000,  2, p_2k  , 0x1FFFF800, 0x1FFFF80F, 0x1FFFC800, 0x1FFFF800, F_OBLL},

Key thing to note. Such json file for above application would include extra metadata for vendor specific extra information, as 0x440 ID field in the example code is the ID code the stm32 rom bootloader is looking for. Which is not a register field, but rather what the bootloader rom will report to the user when requested. Thus is a proprietary vendor specific value.

Oh btw, I really like the stm32 rom bootloader. Quite handy. Hopefully the riscv community would come to a good standard for rom bootloaders, so that field programming of fresh chips doesn’t require a JTAG programmer.