<somlo>
_florent_: re. endianness, that was a good idea, so I replicated your experiment by diff-ing the dut.v generated by litex_sim.py for vexriscv and mor1kx
<somlo>
and you're right, there's nothing different at all except for the actual CPU module being linked into the design
<somlo>
is it possible that endianness as we see it with the 'mr' command (one byte at a time) is simply a result of how the CPU data pins are connected to the rest of the surrounding verilog?
<somlo>
i.e. of how they're exposed by the CPU's internal wiring?
<_florent_>
somlo: i also think it's just how data are organized on the interface for big/little endian architectures, here is test with vexriscv vs lm32:
<somlo>
_florent_: ok, I'll write something up about this in issue #314; also, I would like to have memcpy-"like" functionality for >64 CSRs that "just works" regardless of cpu endianness, and knowing where/why the bytes are flipped was a precondition to even beginning to think about that :)
<somlo>
is there anything already in the works for ecp5/trellisboard?
<_florent_>
somlo: not yet, but i could help. Since the Nexys4DDR has a SD Card slot, maybe you should first test things on it, then switch to the trellisboard.
<somlo>
yeah, on nexys4ddr it should be "xc7", for which we already have SDPHYIOS7
<somlo>
I'm guessing it's a matter of figuring out what the ECP5 equivalent of "IBUFG" and "IDDR[2]" blocks are, and instantiating them instead :)
<daveshah>
The IBUFG shouldn't be needed at all as it will be promoted anyway
<daveshah>
The IDDR equivalent is IDDRX1F
<somlo>
daveshah: thanks! so, just assign the clkfb pad directly to sd_fb, and fiddle around some with IDDRX1F
<daveshah>
Yeah
<somlo>
I'll do what _florent_ said and get something working on nexys4ddr first, so I know it's not some unrelated stupid thing I did when it won't work on the trellisboard, then I'll take a stab at an ECP5 SDPHYIO, unless somone pre-empts me before then :)