01:40 <xobs> If someone is bored and is looking for a project to help with litex: https://interrupt.memfault.com/blog/code-size-deltas

01:40 <tpb> Title: Tracking Firmware Code Size | InterruptTracking Firmware Code Size (at interrupt.memfault.com)

09:31 <lambda> _florent_: sorry, didn't have any time to follow up with the litedram interface yesterday. so do I understand correctly that wdata_ready is only ever asserted after (cmd_ready & cmd_valid)? so for a write, I can assert cmd_valid until cmd_ready, then assert wdata_valid until wdata_ready?

11:17 <pdp7> anyone know if the ECP5 with LiteDRAM uses hard IP for SDRAM interface?

11:45 <gregdavill> pdp7: It's all soft IP doing the heavy lifting. The only hard IP is the I/O registers (DQS and DLL blocks).

11:58 <daveshah> For SDRAM there are no ecp5 specific primitives used at all

12:08 <pdp7> thanks daveshah and greg

15:52 <somlo> _florent_: I saw you applied a bunch of spi-mode sdcard patches, including an spi-mode set of pins for the nexys4ddr; there's no gatware-side changes that I could see, so I'm wondering how I'd go about using the sdcard slot on the nexys4ddr in spi mode with the new software driver?

15:53 <somlo> (not that that's going to help me with the trellisboard, just being curious :)

16:49 <sajattack[m]> hey _florent_ glad you got sdcard booting merged, just noticed the sd card pins are under _mister_sdram_module_io. Maybe a quick patch to just rename it _mister_io or something is in order?

16:50 <sajattack[m]> somlo: I believe it's a bios change

17:08 <somlo> sajattack[m]: there's this: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/main.c#L398

17:08 <tpb> Title: litex/main.c at master · enjoy-digital/litex · GitHub (at github.com)

17:09 <somlo> which presumes something generates "CSR_SPISDCARD_BASE" in include/generated/csr.h

17:09 <somlo> and so far I couldn't find where that happens :)

17:50 <pdp7> anyo think it is feasible to modify the litex-hub/fpga_101 tutorial to use the ice40 Fomu instead of Nexys4DDR?

18:49 <awygle> daveshah: we're actually using the DLL and DQS blocks now? what about for e.g. DDR2?

18:49 <daveshah> Only for DDR3

18:49 <daveshah> DDR2 isn't supported for ECP5 atm

18:50 <daveshah> But for DDR3 the DDRDLL, DQSBUF and DQS I/O/T DDR primitives are all used

18:59 <awygle> i see

19:00 <awygle> are those likely to be necessary for DDR2?

19:00 <daveshah> Yes, probably

19:01 <daveshah> I don't think DDR2 should involve masses of changes

19:01 <daveshah> But I don't know of any boards with it that could be used for testing

19:02 <awygle> idk what any of those primitives actually do tho. was hoping to do it with just the DDR and/or SERDES primitives.

19:03 <daveshah> The problem with the non DQS primitives is you can't do both 4:1 input and output at the same time

19:03 <daveshah> Just using the DDR primitives as 2:1 would work fine at lower rates though

19:03 <awygle> you're saying you can't have an ISERDES and OSERDES on the same pin?

19:04 <daveshah> You mean IDDRX2F and ODDRX2F? No that's not officially allowed

19:04 <daveshah> I don't know whether that's a hardware limitation or just a Diamond limitation

19:05 <awygle> hm. weird.

19:08 <awygle> is that in the docs somewhere or just diamond will yell at you?

19:09 <sajattack[m]> somlo: maybe this commit is useful to you https://github.com/litex-hub/linux-on-litex-vexriscv/commit/2d232e9cb1932d0add2926fe8afb1b15f1993fb1

19:09 <tpb> Title: make/soc_linux: add SPI SDCard support and enable it on Nexys4DDR/De1… · litex-hub/linux-on-litex-vexriscv@2d232e9 · GitHub (at github.com)

19:19 <somlo> sajattack[m]: ah, that's the part I was wondering about, thanks!

19:39 <sajattack[m]> _florent_: would it make sense to either have the sdclk command effect spi sd cards or add another one

20:29 <_florent_> somlo: the SDCard in SPI mode is using the SPIMaster of LiteX. That's not replacing the current work with LiteSDCard, but that's convenient for minimal SDCard support with very low resource usage.

20:30 <sajattack[m]> ok

20:30 <_florent_> sajattack[m]: for now the clock is not configurable with the SPIMaster, but i'll work on that

20:30 <sajattack[m]> thanks

20:31 <_florent_> sajattack[m]: ah, for the sdclk command, was it the argument when building linux-on-litex-vexriscv or the command from the BIOS?

20:32 <sajattack[m]> yeah the command in the bios, I was looking at it thinking maybe I could use it with the spisd and then realized it was different

20:33 <sajattack[m]> but it seems my particular sdcard only works at 400khz anyways

20:33 <_florent_> that's the default setting here: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py#L119

20:33 <tpb> Title: linux-on-litex-vexriscv/soc_linux.py at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)

20:33 <sajattack[m]> yeah

20:34 <sajattack[m]> I was messing with that and it only works at 400

20:34 <_florent_> with the SDCard i tested, 16MHz was fine

20:34 <sajattack[m]> I tried 25MHz and 4MHz

20:36 <pdp7> _florent_: has anyone ever talked about doing an ASIC with Linux-on-LiteX-VexRiscv?

20:36 <_florent_> the plan is to add dynamic clock divider to the SPIMaster and do the initialization at 400KHz, get the maximum support freq from the initialization, and reconfigure the divider

20:37 <sajattack[m]> col

20:37 <sajattack[m]> *cool

20:38 <somlo> _florent_: I assume that SPI-mode SDCard is only supported on a very specific subset of Xilinx boards (I think it's even mentioned in the nexys4ddr manual that it's used internally to load bitstream off the sdcard as an option)

20:39 <somlo> and so unless one's board is specifically wired for it, it's not available -- just so I don't waste time thinking about it in regards to the trellisboard :)

20:39 <daveshah> No, no special wiring is needed for it

20:40 <daveshah> It's the same pins but with different functions

20:41 <_florent_> pdp7: that would be great to create an ASIC, but for a first one it should be something very simple with simple clocking, so maybe something similar to the SoC we are using on boards with SDRAM.

20:43 <somlo> daveshah: so it *should* work on the trellisboard, if we add the right pads to the platform file?

20:43 <pdp7> Yes, that is thought. I met Staf, chips4makers, recently. He is doing 350nm tapeout in July. He asked me about possibility of RV Linux as he saw me talking about the HaD badge

20:43 <daveshah> Yeah

20:43 <pdp7> Staf thinks the VexRiscV with SDRAM would be doable

20:43 <_florent_> somlo: SPI-mode for SDCard the kind of simple and minimal mode. It uses 1 wire for the datas instead of the 4.

20:44 <_florent_> somlo: i also tested it on ULX3S today, so it will work on the Trellisboard :)

20:44 <pdp7> But he is not familiar with it or LiteX. So basically he could help with the tape out (his project is retro 6502) but needs people interested in working on this Linux chip which would go on the water too

20:44 <somlo> ok, I have to try it out now

20:45 <pdp7> Basically, as long as there is nothing special about Linux-on-LiteX-VexRiscv, like hard FPGA IP, Staf thinks it is possible. I'm very much a newbie so I thought I would raise the to see if there is interest

20:48 <_florent_> pdp7: what is difficult when creating an ASIC are the clocking/IOs/Analog/Memories. If you have a design that is fully synchronous (the case of the Linux-on-LiteX-Vexriscv SoC with SDRAM), with synchronous memories and simple IOs, it should not be too complicated.

20:49 <pdp7> That is good to hear

21:05 <daveshah> I suspect you'd have to reduce the cache size a bit to get it to fit into Staf's constraints

21:06 <daveshah> SRAM is comparatively expensive in ASICs compared to FPGAs

21:06 <daveshah> But it would be a cool project!

22:03 <pdp7> _florent_ Staf wasn't sure if posting on litex-linux mailing list was appropriate so I thought I'd ping irc first

22:03 <pdp7> sounds like it is reasonable idea

22:22 <pdp7> I'm wondering how the emulator would work

22:22 <pdp7> in ASIC context

22:30 <daveshah> Probably not something you'd want burnt into ROM forever

22:30 <daveshah> More like just load it from SPI flash like everything else imo

22:32 <pdp7> good iea

22:32 <pdp7> *idea

22:33 <daveshah> If the pressure on area was really high some kind of SPI XIP might be an option too but that would carry a performance cost

23:00 <pdp7> thanks for the insight, do you know of an RV system that is doing SPI XIP?

23:03 <daveshah> picosoc does

23:03 <daveshah> I think LiteX supports it too

23:59 <somlo> ha, it's fat16 only... gotta reformat my sdcard...