SVD file for E310-G000


I’m looking for a SVD file to generate Rust bindings for E310-G000 (I’ve become fed up with hand writing them :slight_smile:. Before writing one myself I thought I’d ask if someone has already written one. Any other equivalent format that can be converted to SVD would also be good…

Also I think I found two documentation bugs:

// NOTE: Sifive docs put plic.target_en[15871] at 0x0C1E_FF80
assert_eq!(address(&plic.target_en[15871]), 0x0C1F_1F80);

pwm0cmp0 interrupt is 40 according to documentation and pwm0cmp3 is 44, I think there is an off by one error somewhere.


I also planned to prepare a SVD file for E310, to be used by the GNU MCU Eclipse debug plug-ins to display the peripherals.

Thanks David:

pwm0cmp0 interrupt is 40 according to documentation and pwm0cmp3 is 44, I think there is an off by one error somewhere.

You’re right, there is an off by one. It should be:

#define INT_PWM0_BASE 40
#define INT_PWM1_BASE 44
#define INT_PWM2_BASE 48

We will correct the docs.

// NOTE: Sifive docs put plic.target_en[15871] at 0x0C1E_FF80
assert_eq!(address(&plic.target_en[15871]), 0x0C1F_1F80);

I don’t follow, what code / docs are you quoting here?

Looks like I was looking at an outdated version of the E31 Coreplex manual… Sorry for wasting your time.

Fabien Chouteau from AdaCore wrote some SVD for the E310 as part of the Ada toolchain port:

Thanks for the link, saved me some time with the GPIO registers. I’m thinking we need a new format based on JSON that is less verbose (i.e describing backup registers or pmu memory registers as an array), allows describing CSR’s, is composable (allows including external files) and is easily convertible to SVD. For now I’ll just bite the bullet…

Here’s my work in progress svd file. Some PLIC registers and OTP registers are missing and some fields are missing enumerated values.

The projects generated by the latest GNU MCU Eclipse SiFive1 C/C++ project template include a package that fully defines the current SiFive devices, including the FE310-G000.

The peripheral definitions are in a new format called XSVD, based on JSON.

These JSON files were already used to generate the device-peripherals.h files for all SiFive devices; for example the FE310 file is:

The specs for this new format are obviously inspired by ARM SVD, but adapted to the more modern JSON format.

The next version of GNU MCU Eclipse will fully support the XSVD format in the debug plug-ins to populate the Peripheral Views.

1 Like

Hi @dvc, please see the XSVD specs.

1 Like

Any update on this? We really need this. Because SiFive doesn’t provide these files, others have written them and they are likely to be incompatible with each other. It would be very useful if you could provide them.

I see XSVD mentioned a few times, even the Freedom Studio docs mention them but the download doesn’t contain them. However, even though cleaning up SVD is much needed, many tools already support SVD and so switching to a different (but semantically very similar) file format hinders adoption.

Alternative languages heavily depend on SVD files to generate register descriptors. These languages include Ada, Rust and Go. All three have support for the FE310 or are working on it, and missing SVD files is a major limitation.

1 Like

Are the ones which @ilg pointed at workable?

There’s also from the Rust RISC-V team currently used for all the rust abstractions on top of the hifive1 and hifive1-revb

AFAICS it’s fairly complete, I2C was made working recently.

1 Like

Those are all good projects but what I would really like to see is SVD files provided by SiFive. Including these externally-written files, however good they may be, is a problem for

It’s sad to see that SiFive, which has otherwise been awesome when it comes to open source silicon, does not provide these SVD files. Most major silicon vendors do.

I agree. SiFive has been generally performing very odd with some of the hifive1 stuff when it comes to docs.

Also note that there is:

Not sure if this is 1:1 convertible to SVD and if it contains everything needed tho.

CMSIS SVD is ARM technology. I tried to promote something similar for the RISC-V world, but SiFive was not interrested. As a Linux shop, they went for DTS.

XSVD looks it might be useful, and something we should be autogenerating as part of the rocket-chips/firrtl build process.

The place to start would be with the new Chips Alliance Rocket-chip repo at

The XSVD format was created to avoid possible legal clashes with ARM over SVD and to overcome some of the SVD shortcommings.

The two main uses of XSVD are:

  • support the debugger peripheral registers view (GNU MCU Eclipse supports it)
  • generate the device header definitions (the xsvd utility supports this)

The file can be autogenerated from other files, but this requires caution, otherwise generating device headers may lead to funny results.

This is not an XSVD specific problem, the same happened with ARM SVD, some vendors chose to autogenerate them and then complained that the peripheral registers look funny in the debugger; not to mention that generating headers from them was not practical.

For these cases the xsvd utility has a patching feature, and the recommended workflow is to generate an intitial version of the file then prepare a set of patches to fix some issues that cannot be covered by the auto generator.

If the community decides to use the XSVD format for RISC-V devices, I don’t mind maintaining the xsvd utility.

I also plan to add XSVD support to Visual Studio Code debugging, when porting the GNU MCU Eclipse plug-ins to VSC.

1 Like

Hi All,

Thank you for your feedback. We do have plans to generate SVD files for all Freedom Metal BSPs as we have the necessary information in the DTS files and it is mostly a matter of outputting in the proper format. As such, SVD will be an output file from the Freedom-devicetree-tools utility which we use to generate Freedom Metal BSPs from DTS files:

Please feel free to follow this repository for the latest developments. I can’t commit to an exact timeline as there is a long backlog of items that the team are working through, but hopefully in the next 3 months or so we will have SVD file generation.

1 Like

If someone with C++ skills were to contribute SVD output support via PR to that repo, would that be welcome?

Asking just in case someone (not me) is up for it. :smile: