CSR ordering support in generated files

[AndrewD]

Add CSR_ORDERING constants and update access functions. Unchanged behaviour with default csr_ordering="big".

Can use --csr-ordering little on command line or parser.set_defaults(csr_ordering="little").

Note that this only affects the addressing of CSR that are 64bit or wider.

This is a proof of concept implementation - only confirmed by inspection so far.

[trabucayre]

Hi,
I have updated/rebased/squashed this PR here.

What is your objective? I'm agree highest word is by default written in lowest address but it seems coherent with CSR policy?
using little and big seems confusing because for endianness this at Byte level and this may add some issue with kernel.

[AndrewD]

This only affects the way csr longer than 32bits work. Currently those csr are ordered big endian on little endian (by default) CPUs like riscv.

For example:

• add a field to the end an existing csr that results in a > 32 bit CSR. The word for the new field is placed first so the binary API of the peripheral changes. This resulted in a bug to track down and is just not intuitive to me: a longer csr should be compatible (but will still shift subsequent csr).
• 64 bit values such as the dma address for sdcard need the words to be written in non-native order resulting in ugly code in Linux/nuttx drivers.

Does this help clarify the intention?

[AndrewD]

updated/rebased/squashed this PR here.

Thanks! I looked at rebasing this yesterday but decided to leave it until later due to the conflicts.

[AndrewD]

Also note that by default this has no effect on the generated gateware, but it will be require driver changes if the csr_ordering is changed.
I have a separate change that adds the correct information to device tree so the Linux SD card driver could support both options.