*** tpb has joined #litex | 00:00 | |
*** HoloIRCUser has joined #litex | 00:51 | |
*** HoloIRCUser2 has quit IRC | 00:51 | |
*** HoloIRCUser1 has joined #litex | 00:52 | |
*** HoloIRCUser has quit IRC | 00:55 | |
*** Skip has quit IRC | 02:38 | |
*** Degi has quit IRC | 03:59 | |
*** Degi has joined #litex | 04:00 | |
_florent_ | dkozel: ok good, thanks for the feedback. For the speed, you should be able to go up to 13Gbps by changing the buffering configuration. | 05:17 |
---|---|---|
_florent_ | dkozel: for wishbone examples, you can look at: | 05:17 |
_florent_ | https://github.com/enjoy-digital/liteeth/blob/master/liteeth/frontend/etherbone.py#L384-L509 | 05:17 |
tpb | Title: liteeth/etherbone.py at master · enjoy-digital/liteeth · GitHub (at github.com) | 05:17 |
_florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/wishbone2csr.py | 05:17 |
tpb | Title: litex/wishbone2csr.py at master · enjoy-digital/litex · GitHub (at github.com) | 05:17 |
_florent_ | i was also planning to create a similar example for the wiki, i could speed this up | 05:19 |
*** tcal has quit IRC | 05:21 | |
*** _tcal has quit IRC | 05:22 | |
*** HoloIRCUser has joined #litex | 05:54 | |
*** HoloIRCUser1 has quit IRC | 05:54 | |
_florent_ | shuffle2: there are indeed some duplications between Migen/MiSoC and LiteX since the projects have a common base (we were collaborating together) but took different directions. I tried to put some efforts in the beginning to avoid MiSoC/LiteX to diverge too much, but it was complicated due to some disagreements (technical and human). | 05:55 |
scanakci | _florent_: I updated my LiteX to recent version. When I use the command --with-sdram, neither Vexriscv nor BP starts executing the binary that I specify with --sdram-init. Both comes to BIOS terminal and that's all. Do I need to change anything else? | 06:14 |
scanakci | The whole command is (./litex_sim.py --with-sdram --sdram-module=MT48LC16M16 --sdram-data-w --sdram-init=boot.bin.uart.simu --output-dir build/trial --cpu-type vexriscv --cpu-variant standard) | 06:17 |
_florent_ | scanakci: indeed, in this case it's still using the BIOS, you can add this: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_sim.py#L356 | 06:18 |
tpb | Title: litex/litex_sim.py at master · enjoy-digital/litex · GitHub (at github.com) | 06:18 |
scanakci | I have that line in my litex_sim. I am using the most recent LiteX commit. | 06:24 |
*** tcal has joined #litex | 06:25 | |
*** HoloIRCUser1 has joined #litex | 06:27 | |
*** tcal_ has joined #litex | 06:28 | |
_florent_ | but you will probably need to modify args.ram_init to args.sdram_init, i will have to check why we have a different behavior between the --ram-init and --sdram-init. | 06:28 |
*** HoloIRCUser has quit IRC | 06:30 | |
_florent_ | scanakci: is it better with this? | 06:49 |
scanakci | Vexriscv attempted to boot program rather than BIOS. | 06:52 |
scanakci | BP is worse (not even printing LiteX logo :) ). It should be related to BP, though. I do not think it is related to LiteX | 06:53 |
scanakci | Thanks for the help. | 06:53 |
*** HoloIRCUser has joined #litex | 06:53 | |
*** HoloIRCUser1 has quit IRC | 06:56 | |
*** HoloIRCUser1 has joined #litex | 07:00 | |
*** HoloIRCUser has quit IRC | 07:02 | |
scanakci | setting the sdram-width to 16 actually started printing the Logo and CPU info for BP. It did not come to Liftoff, though. | 07:14 |
_florent_ | For information, i just merged https://github.com/enjoy-digital/litex/pull/399, so LiteX will now use Python modules instead of git submodules. This will simplify installing external dependencies in the future (and will reduce installation size if no CPU or only some are used), but this also means that if you want to update LiteX, you will have to reinstall it following | 07:18 |
_florent_ | https://github.com/enjoy-digital/litex/wiki/Installation, sorry for the inconvenience. | 07:18 |
tpb | Title: Home · enjoy-digital/litex Wiki · GitHub (at github.com) | 07:18 |
_florent_ | scanakci: ok, maybe it's the same issue you have when testing on hardware. I would probably need to see the code to be able to help more. | 07:26 |
*** HoloIRCUser has joined #litex | 07:57 | |
scanakci | Actually after waiting long enough, It started working. I got an assertion failed. | 07:59 |
scanakci | https://usercontent.irccloud-cdn.com/file/aByTgDCZ/assertion_sdram | 07:59 |
scanakci | Something to debug more tomorrow | 08:00 |
*** HoloIRCUser1 has quit IRC | 08:01 | |
dkozel | _florent_: thanks for the pointers. Yes, I'd like to increase the speed. Are you talking about buffering on host, the FPGA, or both? | 09:46 |
dkozel | I'd like to help with the documentation of the example you make for the wiki. Looking at wishbone2csr I can see how short it is and pretend that I understand what it's doing, but there's so much assumed knowledge that I don't really. | 09:50 |
dkozel | Not a problem! This is a new domain for me, I expect to have to do research and self-learn, but I'd like to leave some documentation behind as I do. | 09:51 |
*** futarisIRCcloud has quit IRC | 09:55 | |
dkozel | Just been looking at the wiki! The outline looks excellent. | 10:18 |
_florent_ | dkozel: any help is welcome for the wiki :) | 10:27 |
_florent_ | dkozel: this should improve the DMA speed: https://github.com/enjoy-digital/litepcie_aller_test/commit/51b055ba85370b44a1e181d4204f8674850ef091 | 10:28 |
tpb | Title: aller: increase max_pending_request and buffering to increase DMA speed. · enjoy-digital/litepcie_aller_test@51b055b · GitHub (at github.com) | 10:28 |
*** rohitksingh has quit IRC | 10:30 | |
*** rohitksingh has joined #litex | 10:31 | |
daveshah | _florent_: I'm going to play with the Alveo DDR4 this afternoon (I got a basic no DRAM SoC working with Vivado) | 11:10 |
daveshah | What is the best way to create a SoC with main RAM and SDRAM, so I can serialboot new init code? | 11:10 |
_florent_ | daveshah: cool, the best way is to add another ram and execute the code from there, i already have this and can prepare a skeleton for you | 11:20 |
zyp | which cpu would be the best bet if I wanted to try porting over some microcontroller code? (from arm cortex-m) is vexriscv the best supported one? | 11:29 |
zyp | targetting ecp5, so space shouldn't be an issue | 11:30 |
daveshah | yeah, vexriscv in its default config is probably roughly Cortex-M3 equivalent | 11:31 |
daveshah | _florent_: thanks, that would be great | 11:31 |
_florent_ | daveshah: i can do it in ~1h | 11:47 |
daveshah | No worries, I've got some other issues to deal with first (like a DQS pinout discrepancy...) | 11:48 |
*** Skip has joined #litex | 13:25 | |
_florent_ | daveshah: https://github.com/enjoy-digital/litedram_init_test, it's for the Arty but the only change you have to do in your target is adding: self.add_ram("firmware_ram", 0x20000000, 0x8000) | 14:37 |
daveshah | _florent_: great, thanks | 14:38 |
daveshah | Just managed to get MPR reads and writes working on the command line so seems the hardware side is alive now | 14:38 |
*** gregdavill has quit IRC | 14:38 | |
daveshah | I'm not properly setting up the RDIMM register though, and memtest isn't working yet, so that is next | 14:40 |
daveshah | https://www.irccloud.com/pastebin/YQVHMpcj/ | 14:40 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 14:40 |
_florent_ | ok, the write leveling ic clearly not centered but the readleveling should work on at least some of the modules | 14:46 |
_florent_ | what are you using for cmd_latency? from the last tests i did, i would recommend using cmd_latency=1 | 14:49 |
_florent_ | but that could be interesting to test with 0 and 1. | 14:50 |
daveshah | I was using 0, I will try 1 once the current build has finished. I guess the register might change the latency situation too? | 14:55 |
*** bunnie has joined #litex | 14:59 | |
daveshah | sorry, what was posted was with latency 1, latency 0 gave less useful results | 15:22 |
daveshah | I am now experimenting with register configuration, I think that is the problem now | 15:23 |
daveshah | Yay, latency=1 and some register init gets half the bytes working | 15:24 |
daveshah | https://www.irccloud.com/pastebin/NU1ZcSRD/ | 15:24 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 15:24 |
daveshah | I think the failing half are related to the address/ba inversion that the register chip does | 15:24 |
*** darren099 has joined #litex | 15:29 | |
_florent_ | daveshah: great for the first modules working, the write leveling does not seem good for the first modules, this could also be the reason | 15:33 |
daveshah | looks like it isn't the address inversion actually, that is the half that is working fine | 15:34 |
daveshah | if I set the register to PLL bypass mode, then write levelling passes for the first 3 bytes but all read levelling fails | 15:35 |
daveshah | https://www.irccloud.com/pastebin/1mB8y6L8/ | 15:35 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 15:35 |
*** HoloIRCUser1 has joined #litex | 17:00 | |
*** HoloIRCUser has quit IRC | 17:03 | |
dkozel | _florent_: I'll do what I can on the wiki. Reviewing existing text for clarity and adding references/crosslinks is probably the most useful thing I can do at the moment | 17:16 |
dkozel | Most/all of the ToDo pages are ones that I'm a prime candidate consumer for | 17:17 |
dkozel | I just rebuilt the Aller image and it didn't enumerate on PCIe this boot. Almost certainly some error in my setup. I'll debug | 17:17 |
*** tcal__ has joined #litex | 17:33 | |
daveshah | Hmm, by playing with a combination of cmd_latency (either 1 or 2) and the register PLL and latency settings, I'm able to get either the first 4 bytes or the last 4 bytes to pass read/write training but never both at the same time | 17:46 |
daveshah | Anyway, enough for me today, if anyone is curious the changes are at https://github.com/daveshah1/litedram/tree/alveo_u250, https://github.com/daveshah1/litex/tree/alveo_u250 and https://github.com/daveshah1/litex-boards/tree/alveo_u250 (the RDIMM related changes need to be made conditional still, and the RCD init code isn't included here) | 17:55 |
tpb | Title: GitHub - daveshah1/litex at alveo_u250 (at github.com) | 17:55 |
*** CarlFK has quit IRC | 18:41 | |
*** rw1nkler has joined #litex | 19:24 | |
zyp | I'm trying to instance a vexriscv with debug support, but I can't get it working properly, wishbone-tool gives me: ERROR [wishbone_tool] invalid configuration: GDB specified but no vexriscv address present in csv file | 20:05 |
zyp | the log from building the soc looks like this: https://paste.jvnv.net/view/bS7Oo and the csr.csv looks like this: https://paste.jvnv.net/view/d4QEc | 20:05 |
zyp | what am I missing? | 20:05 |
tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 20:05 |
zyp | figured out I were missing register_mem("vexriscv_debug", …, so I'm getting closer :) | 20:29 |
*** gregdavill has joined #litex | 21:18 | |
dkozel | Ah yes. I did not recompile the kernel module after rebuilding the gateware so the CSRs likely did not match or similar. | 21:55 |
dkozel | The buffer changes gave an 11% increase in speed, to 9.29 Gbps. | 21:57 |
dkozel | I'll see about what might be limiting on the host and test code side. | 21:58 |
*** CarlFK has joined #litex | 22:03 | |
*** rw1nkler has quit IRC | 22:22 | |
*** futarisIRCcloud has joined #litex | 22:44 | |
*** tcal__ has quit IRC | 23:42 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!