10:45 <keesj> and i would read writew as write word (e.g. something that is dependent on the architecture but still I would in current days expect it to be at least 32 bits

13:09 <somlo> _florent_: ok, then I'll go with csr_wr_u8, csr_wr_u16, etc.

13:11 <somlo> Another silly question: is it ever worth dealing with cases where CSR_ALIGNMENT != sizeof(unsigned long) ?

13:11 <somlo> and by that I mean is there any reason to expect or support 64-bit CSR alignment on a 32-bit CPU?

13:11 <somlo> I'd vote "No" to keep things simple, but then I don't know what I don't know :)

13:17 <somlo> keesj: https://en.wikipedia.org/wiki/Word_(computer_architecture)

13:19 <somlo> but yeah, "word" is an overloaded term, I've heard it used as "xlen is the cpu word size, typically 32 or 64 bits"

17:24 <_florent_> somlo: for the CSR alignment, i don't see usecases for that so also vote no :)

17:25 <_florent_> somlo: great if you do the renaming on the csr functions

17:25 <somlo> _florent_: I'm testing a patch, if it works will post a PR shortly

17:27 <somlo> _florent_: I'd like the new litex/soc/software/include/hw/common.h to look something like this: https://pastebin.com/T5LgGxrS :)

17:27 <tpb> Title: [C] #ifndef __HW_COMMON_H #define __HW_COMMON_H #include /* To ove - Pastebin.com (at pastebin.com)

17:32 <_florent_> that seems fine, thanks. Maybe just update line 7 with new csr_rd/wr names

17:33 <somlo> oh, yeah, will do :)

17:35 <somlo> I'm also working on the observation that, in practice, CSR subregisters are stored in native CPU endianness, but I can't pinpoint where in the migen code that's actually happening, so I'd like some help finding that out... Also, would be nice if I could figure out what exactly happens if there's no CPU specified -- what endianness would CSR subregister slices have then ?

17:41 <_florent_> somlo: i'll have a look, sorry for not having done that yet

17:44 <somlo> _florent_: thanks! if we end up updating common.h, I want to point at it for the CSR.md documentation's "software programmer's API" section, and this is the last bit of mystery I'm aware of (there's probably mysterious things I don't know about, but that's a whole different problem altogether :D )

17:48 <_florent_> :) i'll try to find the explanation later today or tomorrow

18:23 <_florent_> somlo: can you explain what you mean with "CSR subregisters are stored in native CPU endianness"? If i have csr_data_width=8, and a CSR of 32-bits, is it the order of the 4 subregisters, or the location of the 8-bit of the subregister in the 32-bit data?

18:42 <somlo> _florent_: "CSR subregisters are stored in native cpu endianness" only has meaning for csr_data_width 16, 32, or 64

18:43 <somlo> i.e. if more than just one byte is stored in an aligned subregister

18:44 <somlo> _florent_: https://github.com/litex-hub/linux-on-litex-vexriscv/pull/60#issuecomment-563313683

18:44 <tpb> Title: RFC: update liteeth driver to automatically calculate hwreg offsets by gsomlo · Pull Request #60 · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

18:45 <somlo> look at the table of results there, and for the difference between e.g. vexriscv and mor1kx at csr_data_width 16 or 32

18:45 <_florent_> ok thanks

18:46 <somlo> *across* subregisters, the lesser bits are stored at lesser addressed subregisters (big-endian *like*)

18:46 <somlo> but I'm wondering *within* a subregister that's wider than 8

19:12 <somlo> _florent_: but actually even when csr_data_width is 8, a memory dump of a 32-bit aligned subregister on vexriscv is "ab 00 00 00" and on mor1kx the same one is "00 00 00 ab"

19:13 <somlo> so it *appears* subregisters are stored in native CPU endianness within their aligned xlen-sized "container"