It would be great if SVD format could be extended to cover awkward peripherals like 16550-compatible UARTs which are, after all, pretty ubiquitous in embedded systems.
These UARTs have multiple different registers defined at the same address. Which definition applies depends on whether you are reading or writing, and how DLAB (Divisor Latch Access Bit) within the LCR (Line Control Register) is set.
I think there is nothing to stop an SVD file from defining multiple registers at a given address, as long as the consumer of the SVD data supports this. So you'd perhaps think that we could just define all these registers and let the user figure out which one is currently applicable. However, this gives a problem that one of these overlapped registers also has read side-effects (the Receive Buffer Register, RBR, will pop data out of the receive FIFO when read). So we should set <readAction> to be <modifyExternal> on that register. In an IDE displaying a peripheral registers window, for example, that would prevent it from reading the register in order to avoid that window screwing with the operation of the device. Since, with LCR set differently, that same address is used for the DLL (Divisor Latch LSB) register, that would prevent users from ever being able to see the contents of DLL!
My proposal to deal with this would be to add an optional <condition> field that could be applied to a register definition and which could explain this modal behaviour. The text within that field could be of the form register.bitfield==0xnn. The register and bitfield referred to in the condition must exist within the device containing the register to which the condition is being applied.
So for the 16550-compatible UART example you could have:
<register><name>RBR</name><description>Receiver Buffer Register</description><addressOffset>0x0</addressOffset><condition>LCR.DLAB==0x0</condition><fields>...
Would this change, or something similar, be considered?
Thanks,
Chris
Hi,
It would be great if SVD format could be extended to cover awkward peripherals like 16550-compatible UARTs which are, after all, pretty ubiquitous in embedded systems.
These UARTs have multiple different registers defined at the same address. Which definition applies depends on whether you are reading or writing, and how DLAB (Divisor Latch Access Bit) within the LCR (Line Control Register) is set.
I think there is nothing to stop an SVD file from defining multiple registers at a given address, as long as the consumer of the SVD data supports this. So you'd perhaps think that we could just define all these registers and let the user figure out which one is currently applicable. However, this gives a problem that one of these overlapped registers also has read side-effects (the Receive Buffer Register, RBR, will pop data out of the receive FIFO when read). So we should set
<readAction>to be<modifyExternal>on that register. In an IDE displaying a peripheral registers window, for example, that would prevent it from reading the register in order to avoid that window screwing with the operation of the device. Since, with LCR set differently, that same address is used for the DLL (Divisor Latch LSB) register, that would prevent users from ever being able to see the contents of DLL!My proposal to deal with this would be to add an optional
<condition>field that could be applied to a register definition and which could explain this modal behaviour. The text within that field could be of the formregister.bitfield==0xnn. The register and bitfield referred to in the condition must exist within the device containing the register to which the condition is being applied.So for the 16550-compatible UART example you could have:
<register><name>RBR</name><description>Receiver Buffer Register</description><addressOffset>0x0</addressOffset><condition>LCR.DLAB==0x0</condition><fields>...Would this change, or something similar, be considered? Thanks, Chris