_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
CarlFK has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #litex
<xobs> If someone is bored and is looking for a project to help with litex: https://interrupt.memfault.com/blog/code-size-deltas
<tpb> Title: Tracking Firmware Code Size | InterruptTracking Firmware Code Size (at interrupt.memfault.com)
Degi_ has joined #litex
Degi has quit [Ping timeout: 250 seconds]
Degi_ is now known as Degi
_whitelogger has joined #litex
gregdavill has quit [Remote host closed the connection]
gregdavill has joined #litex
_whitelogger has joined #litex
_whitelogger has joined #litex
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 250 seconds]
_whitelogger has joined #litex
_florent_ has quit [Ping timeout: 256 seconds]
daveshah has quit [Ping timeout: 272 seconds]
pdp7 has quit [Ping timeout: 240 seconds]
_florent_ has joined #litex
daveshah has joined #litex
pdp7 has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<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?
_whitelogger has joined #litex
futarisIRCcloud has joined #litex
<pdp7> anyone know if the ECP5 with LiteDRAM uses hard IP for SDRAM interface?
<gregdavill> pdp7: It's all soft IP doing the heavy lifting. The only hard IP is the I/O registers (DQS and DLL blocks).
<daveshah> For SDRAM there are no ecp5 specific primitives used at all
gregdavill has quit [Ping timeout: 246 seconds]
<pdp7> thanks daveshah and greg
_whitelogger has quit [Remote host closed the connection]
_whitelogger_ has joined #litex
<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?
<somlo> (not that that's going to help me with the trellisboard, just being curious :)
<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?
<sajattack[m]> somlo: I believe it's a bios change
<tpb> Title: litex/main.c at master · enjoy-digital/litex · GitHub (at github.com)
<somlo> which presumes something generates "CSR_SPISDCARD_BASE" in include/generated/csr.h
<somlo> and so far I couldn't find where that happens :)
dasdgw42 has joined #litex
<pdp7> anyo think it is feasible to modify the litex-hub/fpga_101 tutorial to use the ice40 Fomu instead of Nexys4DDR?
<awygle> daveshah: we're actually using the DLL and DQS blocks now? what about for e.g. DDR2?
<daveshah> Only for DDR3
<daveshah> DDR2 isn't supported for ECP5 atm
<daveshah> But for DDR3 the DDRDLL, DQSBUF and DQS I/O/T DDR primitives are all used
CarlFK has joined #litex
<awygle> i see
<awygle> are those likely to be necessary for DDR2?
<daveshah> Yes, probably
<daveshah> I don't think DDR2 should involve masses of changes
<daveshah> But I don't know of any boards with it that could be used for testing
* awygle has a board with it that needs testing
<awygle> idk what any of those primitives actually do tho. was hoping to do it with just the DDR and/or SERDES primitives.
<daveshah> The problem with the non DQS primitives is you can't do both 4:1 input and output at the same time
<daveshah> Just using the DDR primitives as 2:1 would work fine at lower rates though
<awygle> you're saying you can't have an ISERDES and OSERDES on the same pin?
<daveshah> You mean IDDRX2F and ODDRX2F? No that's not officially allowed
<daveshah> I don't know whether that's a hardware limitation or just a Diamond limitation
<awygle> hm. weird.
<awygle> is that in the docs somewhere or just diamond will yell at you?
<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)
<somlo> sajattack[m]: ah, that's the part I was wondering about, thanks!
<sajattack[m]> _florent_: would it make sense to either have the sdclk command effect spi sd cards or add another one
<_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.
<sajattack[m]> ok
<_florent_> sajattack[m]: for now the clock is not configurable with the SPIMaster, but i'll work on that
<sajattack[m]> thanks
<_florent_> sajattack[m]: ah, for the sdclk command, was it the argument when building linux-on-litex-vexriscv or the command from the BIOS?
<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
<sajattack[m]> but it seems my particular sdcard only works at 400khz anyways
<tpb> Title: linux-on-litex-vexriscv/soc_linux.py at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)
<sajattack[m]> yeah
<sajattack[m]> I was messing with that and it only works at 400
<_florent_> with the SDCard i tested, 16MHz was fine
<sajattack[m]> I tried 25MHz and 4MHz
<pdp7> _florent_: has anyone ever talked about doing an ASIC with Linux-on-LiteX-VexRiscv?
<_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
<sajattack[m]> col
<sajattack[m]> *cool
<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)
<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 :)
<daveshah> No, no special wiring is needed for it
<daveshah> It's the same pins but with different functions
<_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.
<somlo> daveshah: so it *should* work on the trellisboard, if we add the right pads to the platform file?
<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
<daveshah> Yeah
<pdp7> Staf thinks the VexRiscV with SDRAM would be doable
<_florent_> somlo: SPI-mode for SDCard the kind of simple and minimal mode. It uses 1 wire for the datas instead of the 4.
<_florent_> somlo: i also tested it on ULX3S today, so it will work on the Trellisboard :)
<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
<somlo> ok, I have to try it out now
<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
<_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.
<pdp7> That is good to hear
<daveshah> I suspect you'd have to reduce the cache size a bit to get it to fit into Staf's constraints
<daveshah> SRAM is comparatively expensive in ASICs compared to FPGAs
<daveshah> But it would be a cool project!
rohitksingh has joined #litex
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #litex
rohitksingh_ has joined #litex
rohitksingh_ has quit [Remote host closed the connection]
<pdp7> _florent_ Staf wasn't sure if posting on litex-linux mailing list was appropriate so I thought I'd ping irc first
<pdp7> sounds like it is reasonable idea
<pdp7> I'm wondering how the emulator would work
<pdp7> in ASIC context
<daveshah> Probably not something you'd want burnt into ROM forever
<daveshah> More like just load it from SPI flash like everything else imo
<pdp7> good iea
<pdp7> *idea
<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
<pdp7> thanks for the insight, do you know of an RV system that is doing SPI XIP?
<daveshah> picosoc does
<daveshah> I think LiteX supports it too
<somlo> ha, it's fat16 only... gotta reformat my sdcard...