cyanobyte

[jordens]

cyanobyte might also be interesting to look at here. Since it's a templating language (instead of an OO representation) the result could well be slim enough to match ARTIQ.

[airwoodix]

Thanks for the hint! I wasn't aware of this. Templating is a great idea indeed. However, cyanobyte does a bit too much for what regdesc is/was supposed to be: just a register calculator / register arithmetic code generator. In particular for ARTIQ coredevice drivers, I have the feeling that it's more interesting to keep most of the ARTIQ specifics outside of the template.
In particular, by now, cyanobyte seems to struggle to support SPI, though it should be no issue. This probably comes from the transport layer, not the calculation one.

[jordens]

The other area where register map descriptions are used heavily is SVD. E.g. through svd2rust. If there was an easy way to edit/create SVDs, it would be a nice intermediate format.

[airwoodix]

Indeed. My understanding is that SVDs are really meant for devices with memory-mapped peripherals so it's a bit of a twist to use this format here. A naive template and svd2rust nevertheless lead to somewhat usable Rust bindings (see e1d0018). The current approach fails if the described register's address space is not contiguous (due to the simplistic way of calculating the memory block's size). That's fixable but not efficient.
For embedded targets, having the full register map on the stack could probably become an issue but I guess that some state is necessary if the peripheral has no readback mechanism (like the ADF5356 for example).

[jordens]

Ah. I was being ambiguous and misleading there. Sorry. What I actually meant was svdtools and it's yaml language to describe register maps. The context is somewhat different (programmatic editing/patching of SVDs originally) but it can just as well create register maps from yaml.