08:42 <MoeIcenowy> strange... got initial LiteX working on Sipeed Tang Nano 20K

08:42 <MoeIcenowy> when using SDCard, block 0 could be correctly read, but when reading block 1 it hangs

13:00 <_florent_> MoeIcenowy: It could hang if the DMA is not able to complete (accessing a wrong location) or if the CPU crash. Maybe try to increase SRAM (if enough BRAM for it).

13:03 <_florent_> ipredictaroomba: 100Mbps = 25MHz * 4-bit, since the datapath is converted to 32-bit for the wishbone interface, it should be 25/(32/4)=3.125MHz

13:11 <zyp> RMII is 50MHz * 2-bit

13:28 <_florent_> zyp: thanks yes, my bad, min sys_clk_freq will be similar

19:24 <ipredictaroomba> For an RMII board can I just use the ref clock as the system clock on a udp module?

22:45 <somlo> looks like I'll have to rework the rocket variants

22:46 <somlo> with properly configured H extensions, a 4-core design no longer fits on the nexys video (requires 141518 of 133800 LUTs);

22:47 <somlo> similarly, an H-enabled "full" single-core wants 106% TRELLIS_COMB on ecp5

22:49 <somlo> so it seems we need a "fpu" variant (what "full" *used* to be before adding H to it), in order to still be able to run a distro like Fedora on ecp5

22:49 <somlo> I'll make a 2-core "full" (h-enabled) variant for the nexys-video, that should fit

22:50 <somlo> I hate how variants are "mushrooming", and I'm torn between just going for it and spending some time trying to demand-build rocket verilog driven by the litex build command line

22:51 <somlo> although adding a dependency on chisel, the "mill" scala build system, etc, etc. also seems like a loathsome option :(

22:51 <somlo> maybe I'll sleep on it...

22:52 <somlo> I'm also thinking of getting rid of the "linux" (no-FPU) variant

22:53 <somlo> anyone who wants a light-weight riscv option already uses 32-bit vexriscv, so not sure fpu-less linux-capable rocket is worth keeping around