I’m looking for a SVD file to generate Rust bindings for E310-G000 (I’ve become fed up with hand writing them . 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.
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…
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.
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.
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 github.com/posborne/cmsis-svd.
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.
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.
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.
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.