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.