05:33 <awygle> does LiteDRAM with the Wishbone frontend use the pipelined mode, or the cti/bte registered mode, or the "classic" mode? or does it care?

08:18 <_florent_> awygle: currently it's using the classic mode (since it was not a bottleneck with the CPUs supported initially and since we are using the native ports when high throughput is required for DMAs), but we are planning to support pipelined mode in the near future since there are a few cases were it would be useful and would simplify things.

09:01 <awygle> _florent_: do you know how you will use the pipelined mode with the inherently bursty DRAM? it seemed to me that cti/bte would be a better match

09:03 <awygle> but it does seem that pipelined mode is much more commonly used so if there is a way to make it work that would be nice

09:13 <_florent_> LiteDRAM's native interfaces already support bursts (the native interface will aggregate accesses to the DRAM when possible), so supporting Wishbone pipelined will mostly consist or revisiting the Wishbone frontend that convert Wishbone to LiteDRAM's native interface. I'm not well aware of the Wishbone specification regarding bursts, but we have a current need for it with VexRiscv SMP DMA interface, so will have a

09:13 <_florent_> closer look.

09:17 <awygle> All right, thank you

09:36 <tnt> awygle: having distinct address can actually be nice fro DRAM because despite burts, you can still do random access within columns as part of the same burst.

09:37 <tnt> so you can do things like 0 1 2 3 16 17 18 19 in a single burst for instance

10:08 <awygle> the problem is there's no way of knowing when the "burst" is over with pipelined wishbone. so you either must require all transactions be a full burst or not support bursts at all. unless I misunderstand the spec.

13:09 <SpaceCoaster> When I use etherbone I set sys_clk_freq to 125e6 but then my sdram doesn’t work :-) The code is https://github.com/derekmulcahy/litespi/blob/ecp5_and_colorlight/examples/colorlight.py

13:09 <tpb> Title: litespi/colorlight.py at ecp5_and_colorlight · derekmulcahy/litespi · GitHub (at github.com)

13:10 <SpaceCoaster> I guess I need separate clocks for cpu/Ethernet/sdram. Is this possible and is there an example. Thanks.

13:14 <zyp> IIRC the sys clock and ethernet phy clocks are already separate, I believe the sys clock just needs to be fast enough to keep up with the phy block

13:14 <_florent_> SpaceCoaster: with recent changes, it's not longer requires for the sys_clk to be >= 125MHz to use Etherbone

13:14 <zyp> _florent_, ah, the data path width stuff is merged now?

13:18 <_florent_> zyp: not yet, the mac/ip/udp layers will still work at 125MHz but Etherbone that is already using a 32-bit data path can run with a lower clock (should work down to 31.25MHz)

13:19 <SpaceCoaster> Well that worked! Is there a way to tweak the sdram clock this board has 200 MHz sdram chips and I was wondering if 139 Mbps writes and 115 Mbps reads is the limit.

13:20 <_florent_> SpaceCoaster: Ah great!

13:21 <_florent_> SpaceCoaster: we indeed currently working on a 1:2 PHY that will allow dram_clk = 2xsys_clk

13:21 <SpaceCoaster> BTW I am assuming Mbps is mega BYTES per second

13:22 <_florent_> SpaceCoaster: this has already been validated on some boards (Minispartan6 with 80MHz sys_clk/160MHz sdram_clk, DE10Nano with 50/100MHz), but we need to do more testing and also validate this on ECP5 boards

13:23 <_florent_> SpaceCoaster: no, this is bits per second, this is not really the DRAM speed, but the speed seen by the CPU, which is currently limited by the softcore/wishbone bus

13:24 <_florent_> SpaceCoaster: the real DRAM speed that you could have with a DMA is a lot higher

13:26 <_florent_> SpaceCoaster: basically for a SDRAM: number of data bits * freq * 80-90% efficiency if you use simple access patterns (incrementing address).

13:49 <SpaceCoaster> Thanks that makes sense.

13:52 <SpaceCoaster> I noticed that the spi flash speed with LiteSPI is 1/4 of the cpu speed. Is that configurable?

13:59 <SpaceCoaster> Or is that the same deal as for the sdram? Is it the speed seen by the CPU?

14:34 <_florent_> SpaceCoaster: i would need to check, but that's also probably the speed seen by the CPU

17:34 <SpaceCoaster> _florent_: I have a firmware library for accessing the flash and a RemoteClient app for doing the same. Does the LiteX ecosystem have a place for peripheral libraries and examples?

17:48 <SpaceCoaster> Dumb stuff like read/erase/write but it is useful as documentation.

20:33 <_florent_> SpaceCoaster: nice, that would be useful. In a first time if you host it somewhere, we could add a link to it in https://github.com/enjoy-digital/litex/wiki/Tutorials-Resources#useful-resources

20:33 <tpb> Title: Tutorials Resources · enjoy-digital/litex Wiki · GitHub (at github.com)

20:34 <_florent_> SpaceCoaster: and later it could make sense indeed to have a place for these kind if examples, the main issue is to maintain them :)