neorv32.svd -- a single source of truth

[biosbob]

i recently looked at the neorv32.svd file -- which miraculously appears to be maintained by hand!!!! i've also noticed that the latest version corresponds to 1.6.4 -- which means it does not reflect the very latest register/field names....

while .svd files are an ARM invention, i have found a few projects in the RISC-V space that work with them; SiFive seems to like them, for instance....

i've also discovered a RISC-V working group RVM-CSI that is presumably addressing this issue -- though i still don't think we'll have something like an .svd file....

having worked with .svd files provided by silicon vendors for their MCUs, i generally regard them as a single source of truth vis-a-vis the names of the peripherals/registers/fields.... more important, perhaps, the .svd can be used as a source file from which low-level C headers are generated....

needless to say, this is exactly the opposite of the process used in this project!!!!! still learning about HDLs and the hardware design process, is it possible to generate an .svd file from information that is already found in some .vhd file???? or perhaps a .vhd file just containing peripheral/register/field names can be produced from a master .svd file????

a short-to-medium term suggestion would be a process like this:

1. maintain neorv32.svd as a single-source of truth
2. generate a (large) neorv32_regs.h using (say) a simple python script
3. reduce most of the current headers (eg neorv32_uart.h) to JUST their function prototypes
4. add #include "neorv32_regs.h" to bring in the register types, field names, etc. removed in the prior step

note that this will NOT impact any of the neorv32_*.c source files, let alone any of the examples....

and (somewhat selfishly), this approach addresses a rather unique need of mine.... specifically, i can use the latest neorv32.svd to generate my own "headers" for my own programming language....

full disclosure: i've been working with a propriety language named Em for the past decade.... while the Em translator ultimately generates standard C/C++, programs written in this higher-level language will frequently out-perform comparable hand-built C/C++ program in time and (especially!) space.... but that's all i can say for now 😉

[stnolting]

Hey @biosbob! Sorry for the late reply - busy times here 😉

i recently looked at the neorv32.svd file -- which miraculously appears to be maintained by hand!!!!

Unfortunately, that is true 🙈

i've also noticed that the latest version corresponds to 1.6.4 -- which means it does not reflect the very latest register/field names....

Oh, seems like I have forgotten to update the version number in there. Actually, the SVD file should be (quite) up-to-date.

i've also discovered a RISC-V working group RVM-CSI that is presumably addressing this issue -- though i still don't think we'll have something like an .svd file....

Thanks for the link! It looks like they are still in a very early stage.

having worked with .svd files provided by silicon vendors for their MCUs, i generally regard them as a single source of truth vis-a-vis the names of the peripherals/registers/fields.... more important, perhaps, the .svd can be used as a source file from which low-level C headers are generated....
needless to say, this is exactly the opposite of the process used in this project!!!!! still learning about HDLs and the hardware design process, is it possible to generate an .svd file from information that is already found in some .vhd file???? or perhaps a .vhd file just containing peripheral/register/field names can be produced from a master .svd file????

I absolutely agree!

I think there is no (feasible) way to generate the SVD file from the VHDL sources. Base addresses and register/bit definitions are scattered across several files and also use different description styles.

ARM and others provide (open-source?) tools to generate C headers from the SVD file. Indeed, this would be a very nice thing! I think we already had a discussion about this here... Anyway, I see some problems here:

• We would need to refactor the entire software framework - or at least all the module's C files as the generated headers might have different layouts and names.
• The SVD-to-header conversion would have to be done by some third-party tool. We would need an open-source version so we can
  • distribute it with this project and
  • also run it in the projects CI pipeline here on GitHub.
• Time and effort. 😅

I would really love to have such a setup! Obviously, keeping the SVD and all the C files in sync is a lot of (error-prone) work.

full disclosure: i've been working with a propriety language named Em for the past decade.... while the Em translator ultimately generates standard C/C++, programs written in this higher-level language will frequently out-perform comparable hand-built C/C++ program in time and (especially!) space.... but that's all i can say for now 😉

Sounds interesting! Keep me/us updated if you like. 😉

[biosbob]

to illustrate my proposal, i've thrown together a very simple python script that generates a new sw/lib/include/neorv32_svd.h from sw/svd/neorv32.svd.... by the way, the .svd file had a number of inconsistencies (missing or misnamed registers/fields)....

the generated neorv32_svd.h is then conditionally included in neorv32_std.h; type and constant defintions currently found in neorv32_<peripheral>.h are likewise conditionally suppressed.... unless the NEORV32_SVD_HEADER preprocessor symbol is defined, however, C program builds are completely backward-compatible....

i'll generate a PR, so at least we can capture/review my "proof-of-concept".... at the end of the day, i can still use the current neorv32.svd file for my own purposes; but designating it as a "single source of truth" adds some discipline to the project while actually reducing effort....

less important for now: the xPack SVD project is basically an JSON-based rendition of the original XML-based SVD from Arm.... once you move into the JSON world, you can then use YAML within the .svd file -- which is much friendlier to humans maintaining this file....

[stnolting]

by the way, the .svd file had a number of inconsistencies (missing or misnamed registers/fields)

Thanks for the hint! Actually I do not use this file at all - I just do some simple syntax checking using an open-source tool provided by ARM (SVDconv).

i'll generate a PR, so at least we can capture/review my "proof-of-concept"

Great! I'm locking forward to it! 👍