08:28 <_florent_> xobs, somlo: following our recent discussions, i just added io_regions (uncached regions) to SoCCore/CPU to replace shadow_base (it's still possible to use shadow_base to avoid breaking designs but no longer recommended)

08:28 <_florent_> https://github.com/enjoy-digital/litex/commit/a4ef9b29b9781f576caba316c7920c902a8d8c8f

08:28 <tpb> Title: soc_core/cpu: add io_regions and deprecate shadow_base (with API retr… · enjoy-digital/litex@a4ef9b2 · GitHub (at github.com)

08:30 <_florent_> this should be easier to apprehend, instead of adding shadow base to io peripherals automatically, we now just check that the io peripherals is in an IO region defined by the user or the CPU

08:32 <_florent_> somlo: this should solve the case where you wanted shadow_base = 0 for Rocket since now you can just define your own io_regions in the Rocket wrapper

08:49 <xobs> florent: Awesome!

08:54 <_florent_> xobs: for vexriscv, i added and io_region that is equivalent to what we had with a shadow_base of 0x80000000, but from what we discussed previously, i don't think that's correct and we should reduce it

08:55 <_florent_> https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv/core.py#L83

08:55 <tpb> Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)

08:56 <_florent_> xobs: can you check? and eventually tell me what you think the real io_regions for vexriscv should be?

09:00 <xobs> _florent_: I'm happy with those regions. In general, it looks like vexriscv configurations assume 0xf0000000-0xffffffff is an ioregion, but I see at least one place where they have a special case for litex: https://github.com/SpinalHDL/VexRiscv/blob/6fc5406901fcd34d2fa166761a588fea1b38cddf/src/main/scala/vexriscv/demo/Linux.scala#L280

09:00 <tpb> Title: VexRiscv/Linux.scala at 6fc5406901fcd34d2fa166761a588fea1b38cddf · SpinalHDL/VexRiscv · GitHub (at github.com)

09:09 <_florent_> xobs: thanks, the special case for litex seems to be for ethernet (0xB) and spiflash (0x5) for linux-on-litex-vexriscv, we'll see in the future if it's useful to reduce to strictly these regions in the VexRiscv wrapper

09:15 <xobs> Oh, so /that's/ where those regions come from!

09:26 <xobs> florent: how well does the wishbone2csr bridge handle clock domain crossing?

09:34 <xobs> Hmm... I think I asked that before, and in looking at it now the answer appears to be "not well". I think I may need to put a PulseSynchronizer on the .re lines. Maybe on the .we lines as well.

09:47 <_florent_> xobs: since there is no handshake on the csr bus, that's difficult to do cdc on it. The best is whether to have a wishbone csr before the wishone2csr, or do the CDC on the CSR register signals (we, re, storage, status...)

09:50 <xobs> I think in my USB stack, signals are slow enough that it'll be fine to just get the we and re pulses to cross. But it'll require some rework. Maybe. (Famous last words.)

14:47 <somlo> _florent_: thanks, works like a charm. Once https://github.com/enjoy-digital/rocket-litex-verilog/pull/2 is applied, I'll send a litex PR to redo the Rocket map at the same time as we switch to updated verilog built for that new map

14:47 <tpb> Title: RFC: Place MMIO below 0x8000_0000, and L1-cached RAM above 0x8000_0000 by gsomlo · Pull Request #2 · enjoy-digital/rocket-litex-verilog · GitHub (at github.com)

14:48 <somlo> _florent_: basically this: https://pastebin.com/v7VYmTQB (plus updating the verilog submodule)