07:37 <_florent_> Thanks for sharing somlo, it looks interesting.

07:44 <_florent_> somlo: BTW, I added install configurations support to litex_setup to avoid installing all the CPUs for the standard installation (some of them were pretty large and I don't necessarily want LiteX to competes with Vivado on this :))

07:44 <_florent_> somlo: this is https://github.com/enjoy-digital/litex/commit/a6e2a529dc34292ad665474993d7acad013292fb

07:45 <_florent_> somlo: so for rocket, the full installation is now required (--config=full)

07:46 <_florent_> somlo: and I just updated the linux-on-litex-rocket's README with this: https://github.com/litex-hub/linux-on-litex-rocket/commit/b49d8f86983be96266dd4e204e8309b23e74a056

08:45 <leons> Is there any documentation on how to use the LiteDRAM native interface? I'm asking as I managed to build a core which appears to use it correctly (writes and reads work) but it has really awful performance compared to the BIST, so I'm wondering whether I'm doing something entirely wrong

10:24 <_florent_> Hi leons, sorry I indeed need to document it. The BIST provide an example to understand it, but agree it's not enough :) This is basically a simplified AXI with 1 channel for cmds, 1 for writes, 1 for reads.

10:25 <_florent_> leons: If you can share some code/provide some waveforms, I could try to help

10:26 <leons> _florent_: Thanks! I'm currently trying to investigate and reproduce this with a much simpler design and see where the problem lies

10:40 <_florent_> If anyone here has a Kria KV260 Vision AI Starter Kit taking dust and want to sell it, feel free to contact me. I'm trying to get some to add LiteX support to it and Zynq MPSoC support with ilia__s

10:47 <leons> _florent_: This is the simplest DRAM benchmark I could come up with :) it's a bit faster than my other code, but still nowhere near reported BIST values

10:47 <leons> https://gist.github.com/lschuermann/8e230e57c2a674299aa1a62e5e9b21eb

10:48 <leons> I'm calculating the effective speed as: bytes_written / cycle_count * (1 / clk_freq) in bytes/s

10:49 <leons> This gives me approx. 1.6GiB/s, whereas the BIST shows a write speed of ~6.1GiB/s

11:22 <_florent_> leons: you have a shared FSM for the control and data paths, which will already reduce efficiency by 50%. For maximum efficiency, you have to decouple the control and data paths. (in one cycle, LiteDRAM can accept the next command and previous write data)

11:23 <_florent_> So you can change this and after this I would recommend looking at the waveform, in simulation with litex_sim --with-sdram or with LiteScope on hardware

11:23 <leons> florent: oh, that makes sense!

11:45 <leons> _florent_: oh wow. I think that just pushed it up to 7.9 GiB/s...? I'll need to validate that, but if that is indeed the case that's amazing :) It does make sense though, I imagine it's way more efficient if it can properly pipeline commands and writes

12:02 <leons> A more general question, if I have a component which writes a bunch of data to memory and occasionally needs to read a few bytes to search for the next free slot, should I use the same or a different port for writing and reading? Is there any significant resource utilization / performance difference?

13:04 <_florent_> leons: great. From a user perspective, using a different port will probably be easier (Read/Write arbitration/multiplexing will be directly integrated in LiteDRAM)

13:05 <_florent_> leons: I think you are using a relatively large FPGA, so the additional resource usage with this should be negligible (and as said just before, you'll probably use same amount of logic while doing this externally)

13:08 <leons> _florent_: makes sense, thank you!

14:22 <somlo> florent: (re. --config=full) -- makes sense, thansk!

14:31 <somlo> _florent_: commit 33024402 (soc: raise an error if adding a SoCRegion with incoherent cache configuration) is killing Rocket builds

14:32 <somlo> It complains that "rom region in io region, it can't be cached: origin: 0x10000000, size: 0x00020000, mode r, cached: true, linker: false"

14:33 <somlo> it's' true that I'm accessing the rom as uncacheable through the mmio port, but what's wrong with that, if it works? :)

14:59 <somlo> maybe a warning instead of a flat-out error would be more helpful (unless we want to get fancy with marking regions like e.g. the rom as "cached-optional", which I'm definitely *not* recommending :)

15:00 <somlo> * s/recommending/suggesting/ (still need my morning coffee, don't have the best words yet :D)

16:00 <somlo> _florent_: and I noticed commit #5c278ae4 which fixes the issue by placing "rom" outside the "enforced range" for any of the cached/uncached policies -- thanks!

16:41 <leons> Are the number of cycles from when a write transaction was accepted (wdata.ready & wdata.valid) to when it is committed to memory known/constant in LiteDRAM, or is there at least an upper bound?

19:53 <SpaceCoaster> I have two devices (flash and psram) on one SPI bus, they have different cs pins. Can I setup the signals to use these both with LiteSPI?

19:56 <zyp> it's not currently supported, but there's a draft for it: https://github.com/litex-hub/litespi/pull/56

20:02 <zyp> although IMO the easiest way to support multiple chip selects would be to simply make cs wider throughout the entire stack

20:03 <zyp> that way the frontends would be responsible for selecting which device they want to talk to and the rest of the stack would just pass it on

20:05 <zyp> which would allow e.g. a single MMAP frontend to pick device based on the accessed address

20:05 <SpaceCoaster> Thanks, I will take a look. Is QSPI working for flash?

20:05 <zyp> yes

20:35 <cr1901> somlo: > by placing "rom" outside the "enforced range" for any of the cached/uncached policies

20:35 <cr1901> Wait what, ROM isn't cached anymore?

20:36 <r4d10n[m]1> Hello folks...On Acorn CLE-215+... I was facing issues with loading Linux, with Litex boot getting stuck at Uploading Image file....

20:38 <r4d10n[m]1> I just recompiled the bitstream on Vivado 2019.1, flashed it via the PCIe interface... new version bitstream is loaded fine (from the compile time in info header)...

20:40 <r4d10n[m]1> now there are errors in memtest.... http://pastebin.com/kZjL4nKC... dmesg output: http://pastebin.com/dWhXVxzs

20:40 <tpb> Title: [ 5145.915729] litepcie 0000:02:00.0: [Removing device][ 5157.578247] pci 0000 - Pastebin.com (at pastebin.com)

20:42 <r4d10n[m]1> Could anyone suggest what I might be doing wrong ?

20:44 <_florent_> cr1901: _franck_ added a check on SoC Regions and we found an inconsitency on Rocket with it

20:44 <_florent_> cr1901: ROM is still cached

20:45 <_florent_> r4d10n[m]1: Hi, that's probably related to the write latency calibration

20:45 <cr1901> ahhh thanks

20:45 <_florent_> r4d10n[m]1: try to set this to False and re-generate the design:

20:46 <_florent_> https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/s7ddrphy.py#L145

20:46 <_florent_> if working, I think I'll disable it on Artix7

20:47 <r4d10n[m]1> _florent_: okay... will try right away and get back to you...

20:59 <r4d10n[m]1> Another issue to report - while compiling buildroot afresh for kernel/rootfs, i got an "Incorrect selection of kernel headers: expected 5.15.x, got 5.14.x"... I had to do a make menuconfig and change the Custom Kernel Headers series to 5.14.x in the Toolchain menu....

21:25 <r4d10n[m]1> _florent_: disabling write latency calibration helped... memtest is now OK...

21:25 <r4d10n[m]1> however back to the old problem of loading kernel Image.... stuck at 3%... PC also hangs....

21:33 <_florent_> r4d10n[m]1: are you using litex_term in safe mode (--safe)?

21:34 <r4d10n[m]1> _florent_: nope

21:35 <_florent_> r4d10n[m]1: ok, can you try it? (it will be slower but should work)

21:36 <r4d10n[m]1> ok... tryin now...

21:37 <r4d10n[m]1> one thing i noticed is that when trying to use linux_2021_03_29.zip from the prebuilt bitstreams, upload is going till 11% before getting stuck

21:43 <r4d10n[m]1> _florent_: in safe mode, it has crossed 14% now... very slow...

21:44 <r4d10n[m]1> my mobo has two m2 slots... on the present slot which has acorn, i think it shares with SATA SSD and hence is reported only to work at x2 in the BIOS... could that sharing be the issue ?

22:10 <r4d10n[m]1> _florent_: that worked ! we have Liftoff and linux has booted... :)

22:11 <r4d10n[m]1> i will try swapping the m2 slots and report updates... thanks for the support

22:15 <somlo> _florent_, cr1901: "rom" is only not cached on Rocket, I should have been more precise, sorry for the false alarm :)

22:19 <somlo> and it's now outside the policy enforcement region used in the patch added by _franck_ (but again, only on rocket :)