| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 00:03 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 00:07 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 00:59 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Remote host closed the connection) | 01:00 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 01:00 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 01:05 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 01:53 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 240 seconds) | 03:32 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 03:51 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Remote host closed the connection) | 04:40 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 04:41 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 04:45 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 04:59 | |
| *** Degi_ <[email protected]> has joined #litex | 04:59 | |
| *** Degi_ is now known as Degi | 05:00 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 05:13 | |
| *** Melkhior <Melkhior!~Melkhior@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has joined #litex | 06:38 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Remote host closed the connection) | 06:47 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 06:47 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 06:52 | |
| *** rektide <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 07:17 | |
| *** rektide <[email protected]> has joined #litex | 07:18 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:4e51:afaf:57de:c8fc> has joined #litex | 07:22 | |
| _florent_ | Thanks for sharing somlo, it looks interesting. | 07:37 |
|---|---|---|
| _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:44 |
| _florent_ | somlo: so for rocket, the full installation is now required (--config=full) | 07:45 |
| _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 | 07:46 |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 08:39 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 08:44 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has joined #litex | 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 | 08:45 |
| _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:24 |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #litex | 10:24 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has joined #litex | 10:24 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 10:24 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has joined #litex | 10:24 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has joined #litex | 10:25 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has joined #litex | 10:25 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has joined #litex | 10:25 | |
| *** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has joined #litex | 10:25 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has joined #litex | 10:25 | |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has joined #litex | 10:25 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #litex | 10:25 | |
| *** bluecmd <bluecmd!~bluecmd@2001:470:69fc:105::1d44> has joined #litex | 10:25 | |
| *** willcode4[m] <willcode4[m]!~willcode4@2001:470:69fc:105::e1b3> has joined #litex | 10:25 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has joined #litex | 10:25 | |
| *** amstan <amstan!~amstan@2001:470:69fc:105::1e9> has joined #litex | 10:25 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has joined #litex | 10:25 | |
| *** CarlFK <CarlFK!~carlfk@2001:470:69fc:105::5d8> has joined #litex | 10:25 | |
| *** nrossi[m] <nrossi[m]!~nrossimat@2001:470:69fc:105::1:4527> has joined #litex | 10:25 | |
| *** mikolajw <mikolajw!~mikolajtc@2001:470:69fc:105::3b02> has joined #litex | 10:25 | |
| _florent_ | leons: If you can share some code/provide some waveforms, I could try to help | 10:25 |
| *** donc <donc!~donc@user/donc> has joined #litex | 10:25 | |
| leons | _florent_: Thanks! I'm currently trying to investigate and reproduce this with a much simpler design and see where the problem lies | 10:26 |
| _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:40 |
| 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:47 |
| leons | I'm calculating the effective speed as: bytes_written / cycle_count * (1 / clk_freq) in bytes/s | 10:48 |
| leons | This gives me approx. 1.6GiB/s, whereas the BIST shows a write speed of ~6.1GiB/s | 10:49 |
| *** MoeIcenowy <MoeIcenowy!~MoeIcenow@2604:a880:2:d1::1d1:f001> has quit IRC (Quit: ZNC 1.7.2+deb3 - https://znc.in) | 11:14 | |
| *** MoeIcenowy <MoeIcenowy!~MoeIcenow@2604:a880:2:d1::1d1:f001> has joined #litex | 11:15 | |
| _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:22 |
| _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:23 |
| *** MoeIcenowy <MoeIcenowy!~MoeIcenow@2604:a880:2:d1::1d1:f001> has quit IRC (Quit: ZNC 1.7.2+deb3 - https://znc.in) | 11:43 | |
| *** MoeIcenowy <[email protected]> has joined #litex | 11:44 | |
| 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 | 11:45 |
| 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? | 12:02 |
| _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:04 |
| _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:05 |
| leons | _florent_: makes sense, thank you! | 13:08 |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 13:19 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 240 seconds) | 13:24 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 13:38 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 13:42 | |
| somlo | florent: (re. --config=full) -- makes sense, thansk! | 14:22 |
| somlo | _florent_: commit 33024402 (soc: raise an error if adding a SoCRegion with incoherent cache configuration) is killing Rocket builds | 14:31 |
| 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:32 |
| 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:33 |
| 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 :) | 14:59 |
| somlo | * s/recommending/suggesting/ (still need my morning coffee, don't have the best words yet :D) | 15: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:00 |
| 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? | 16:41 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 17:12 | |
| *** donc <donc!~donc@user/donc> has quit IRC (Quit: Client closed) | 17:34 | |
| *** essele <[email protected]> has joined #litex | 17:36 | |
| *** essele_ <[email protected]> has quit IRC (Read error: Connection reset by peer) | 17:36 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has joined #litex | 17:40 | |
| *** r4d10n <[email protected]> has joined #litex | 17:45 | |
| *** nelgau <nelgau!~nelgau@bras-base-mtrlpq2848w-grc-34-174-89-119-57.dsl.bell.ca> has quit IRC (Ping timeout: 240 seconds) | 17:45 | |
| *** r4d10n[m]1 <r4d10n[m]1!~r4d10nmat@2001:470:69fc:105::1:6255> has joined #litex | 17:56 | |
| *** r4d10n <[email protected]> has quit IRC (Quit: Client closed) | 18:48 | |
| 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:53 |
| zyp | it's not currently supported, but there's a draft for it: https://github.com/litex-hub/litespi/pull/56 | 19:56 |
| zyp | although IMO the easiest way to support multiple chip selects would be to simply make cs wider throughout the entire stack | 20:02 |
| 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:03 |
| 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:05 |
| 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:35 |
| 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:36 |
| 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:38 |
| 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:40 |
| r4d10n[m]1 | Could anyone suggest what I might be doing wrong ? | 20:42 |
| _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:44 |
| _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:45 |
| _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:46 |
| r4d10n[m]1 | _florent_: okay... will try right away and get back to you... | 20:47 |
| 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.... | 20:59 |
| 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:25 |
| _florent_ | r4d10n[m]1: are you using litex_term in safe mode (--safe)? | 21:33 |
| r4d10n[m]1 | _florent_: nope | 21:34 |
| _florent_ | r4d10n[m]1: ok, can you try it? (it will be slower but should work) | 21:35 |
| r4d10n[m]1 | ok... tryin now... | 21:36 |
| 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:37 |
| r4d10n[m]1 | _florent_: in safe mode, it has crossed 14% now... very slow... | 21:43 |
| 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 ? | 21:44 |
| r4d10n[m]1 | _florent_: that worked ! we have Liftoff and linux has booted... :) | 22:10 |
| r4d10n[m]1 | i will try swapping the m2 slots and report updates... thanks for the support | 22:11 |
| somlo | _florent_, cr1901: "rom" is only not cached on Rocket, I should have been more precise, sorry for the false alarm :) | 22:15 |
| somlo | and it's now outside the policy enforcement region used in the patch added by _franck_ (but again, only on rocket :) | 22:19 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!