<_florent_>
tnt: not really, that's mostly to simplify user code and to avoid some common migen mistakes (ex Modules not integrated in designs since declared as self.my_module = XY instead of self.submodules.my_module = XY).
<tnt>
_florent_: I could swear that before the CSR "storage" register would end up in the main 'sys' domain, whatever the clock domain of the module its in is. (i.e. even if gone through a ClockRenamer). But now, I got the csr bus signals in the normal 'sys' domain and then the CSR storage regs in whatever domain the block is in (which obviously doesn't work ...)
<_florent_>
Hmm, this does not work yes. That's probably related to the collection order of the modules and the fact that CSR are modules are now directly collected (and then ClockRenamer applied on them). I'm going to look at it.
<tnt>
And is that a "recent" change ? ( Ok like ... < 1y not sure when I updated last TBH :) Or am I crazy and it was like that before ?
<tnt>
My previous litex was from sep2022 it seems.
<_florent_>
Use if LiteXModule is relatively recent yes and only the cores converted to it will exhibit the issue.
<_florent_>
I think I understand what is going on, I'm looking at it.
<tnt>
Not sure if that's a useful data point but it doesn't do it for all the CSRs. Like it seems to be only for the ones that are in a submodule of the module that has the clockrenamed applied to it.
<_florent_>
Thanks for reporting! This probably explains a strange behavior I saw and hadn't traced down yet, I should have look more closely at the generated code.
<_florent_>
In fact with LiteXModule, we have to do an exception for CSR since the CSR collection is a specific.
<_florent_>
and ClockRenamer shall not apply to them.
<tnt>
_florent_: Yup, just confirmed this seems to fix all of that.
<tnt>
And TBH this was complete luck I stumbled into that while poking in the generated verilog for an unrelated reason :)
<tnt>
I cherry picked the commit on top of 2023.04 (trying to stick to tags). and now it all looks good.