| *** tpb has joined #litex | 00:00 | |
| *** _whitelogger has quit IRC | 00:24 | |
| *** _whitelogger has joined #litex | 00:27 | |
| *** rohitksingh has joined #litex | 00:36 | |
| *** scanakci has quit IRC | 05:04 | |
| *** CarlFK has joined #litex | 07:08 | |
| *** m4ssi has joined #litex | 08:07 | |
| 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 | 10:46 |
|---|---|---|
| *** rohitksingh has quit IRC | 12:24 | |
| somlo | _florent_: ok, then I'll go with csr_wr_u8, csr_wr_u16, etc. | 13:10 |
| somlo | Another silly question: is it ever worth dealing with cases where CSR_ALIGNMENT != sizeof(unsigned long) ? | 13:12 |
| somlo | and by that I mean is there any reason to expect or support 64-bit CSR alignment on a 32-bit CPU? | 13:12 |
| somlo | I'd vote "No" to keep things simple, but then I don't know what I don't know :) | 13:12 |
| somlo | keesj: https://en.wikipedia.org/wiki/Word_(computer_architecture) | 13:18 |
| 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" | 13:20 |
| *** xobs has quit IRC | 13:23 | |
| *** synaption[m] has quit IRC | 13:24 | |
| *** bunnie[m] has quit IRC | 13:24 | |
| *** john_k[m] has quit IRC | 13:24 | |
| *** nrossi has quit IRC | 13:24 | |
| *** nrossi has joined #litex | 14:53 | |
| *** john_k[m] has joined #litex | 15:09 | |
| *** xobs has joined #litex | 15:09 | |
| *** bunnie[m] has joined #litex | 15:09 | |
| *** synaption[m] has joined #litex | 15:09 | |
| *** synaption[m] has quit IRC | 15:47 | |
| *** xobs has quit IRC | 15:47 | |
| *** nrossi has quit IRC | 15:47 | |
| *** bunnie[m] has quit IRC | 15:47 | |
| *** john_k[m] has quit IRC | 15:47 | |
| *** nrossi has joined #litex | 15:57 | |
| *** john_k[m] has joined #litex | 16:19 | |
| *** xobs has joined #litex | 16:19 | |
| *** synaption[m] has joined #litex | 16:19 | |
| *** bunnie[m] has joined #litex | 16:19 | |
| *** m4ssi has quit IRC | 16:21 | |
| _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:26 |
| somlo | _florent_: I'm testing a patch, if it works will post a PR shortly | 17:26 |
| somlo | _florent_: I'd like the new litex/soc/software/include/hw/common.h to look something like this: https://pastebin.com/T5LgGxrS :) | 17:28 |
| tpb | Title: [C] #ifndef __HW_COMMON_H #define __HW_COMMON_H #include /* To ove - Pastebin.com (at pastebin.com) | 17:28 |
| _florent_ | that seems fine, thanks. Maybe just update line 7 with new csr_rd/wr names | 17:33 |
| somlo | oh, yeah, will do :) | 17:34 |
| 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:36 |
| _florent_ | somlo: i'll have a look, sorry for not having done that yet | 17:42 |
| 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:45 |
| _florent_ | :) i'll try to find the explanation later today or tomorrow | 17:49 |
| _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:24 |
| 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:45 |
| 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:46 |
| _florent_ | ok thanks | 18:46 |
| somlo | *across* subregisters, the lesser bits are stored at lesser addressed subregisters (big-endian *like*) | 18:47 |
| somlo | but I'm wondering *within* a subregister that's wider than 8 | 18:47 |
| 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" | 19:13 |
| *** john_k[m] has left #litex | 19:48 | |
| *** john_k[m] has quit IRC | 19:48 | |
| *** rohitksingh has joined #litex | 20:01 | |
| *** rohitksingh has quit IRC | 20:12 | |
| *** rohitksingh has joined #litex | 20:13 | |
| *** rohitksingh has quit IRC | 20:33 | |
| *** CarlFK has quit IRC | 21:02 | |
| *** rohitksingh has joined #litex | 21:12 | |
| *** rohitksingh has quit IRC | 21:55 | |
| *** rohitksingh has joined #litex | 23:47 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!