| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** gatecat <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 01:51 | |
| *** gatecat <[email protected]> has joined #litex | 02:01 | |
| *** Degi_ <[email protected]> has joined #litex | 02:41 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 02:42 | |
| *** Degi_ is now known as Degi | 02:42 | |
| MoeIcenowy | _florent_: thanks for the tip | 02:53 |
|---|---|---|
| MoeIcenowy | I do have some ECP5 board, but it's Colorlight i5, thus no DDR memory | 02:54 |
| *** gatecat <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 03:56 | |
| *** gatecat <[email protected]> has joined #litex | 04:00 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has joined #litex | 04:59 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has quit IRC (Remote host closed the connection) | 06:29 | |
| *** FabM <[email protected]> has joined #litex | 06:59 | |
| _florent_ | MoeIcenowy: we could collaborate on this, but I have limited time currently to work on this, so if you could: | 07:19 |
| _florent_ | 1) find the Gowin's equivalent of each primitive used in ECP5DDRPHY and IO renaming | 07:19 |
| _florent_ | 2) Do an initial version of the GW2ADDRPHY based on ECP5DDRPHY + finding from 1) | 07:19 |
| _florent_ | 3) Prepare a platform/target for the primer 20k (which I think you are using) and verify the build with GW2ADDRPHY | 07:20 |
| _florent_ | I could help if difficulties during these steps of to also do some tests on hardware when the primer 20k boards will be available | 07:21 |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has joined #litex | 07:46 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has quit IRC (Remote host closed the connection) | 07:51 | |
| MoeIcenowy | _florent_: well I am doing them | 07:55 |
| MoeIcenowy | (and I found that there're still many things TODO before doing DDR | 07:55 |
| *** ilia__s0 <[email protected]> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 11:56 | |
| *** ilia__s0 <[email protected]> has joined #litex | 14:18 | |
| *** Shatur95 <[email protected]> has joined #litex | 14:21 | |
| *** Shatur95 <[email protected]> has quit IRC (Client Quit) | 14:21 | |
| *** Shatur <[email protected]> has joined #litex | 14:22 | |
| Shatur | Hi! Is it possible to use my own ip core written in verilog / systemverilog with litex? | 14:25 |
| *** esteves <[email protected]> has joined #litex | 14:35 | |
| *** esteves <[email protected]> has quit IRC (Client Quit) | 14:38 | |
| _florent_ | Hi Shatur, sure: https://github.com/enjoy-digital/litex/wiki/Reuse-a-(System)Verilog,-VHDL,-(n)Migen,-Spinal-HDL,-Chisel-core | 14:42 |
| Shatur | Oh, I somehow missed it, thank you! | 14:49 |
| MoeIcenowy | _florent_: I did a simple port of ECP5DDRPHY to GW2A, and surely it does not work now | 14:56 |
| MoeIcenowy | how could I disable L2 fully? | 14:56 |
| _florent_ | MoeIcenowy: It's already not that bad it it compiles :) | 15:08 |
| MoeIcenowy | currently if I write 0x55555555, then I got 0xff 0x55 for most words, but sometimes the 0x55 could be other thing like 0x0f, 0x04, 0xff, etc | 15:10 |
| _florent_ | MoeIcenowy: To disable the L2, you can set --l2_size=0 and add some checks to be sure you are disabling it here: | 15:10 |
| _florent_ | MoeIcenowy: you Soc needs to use this: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1566-L1567 | 15:11 |
| MoeIcenowy | oh I used `l2_cache_size = kwargs.get("l2_size", 0)` and it surely loads some default value | 15:11 |
| MoeIcenowy | I switched to use a picorv32 core and add `--l2_size=0`, the mem_read behavior looks right | 15:12 |
| _florent_ | MoeIcenowy: but there is also an initial calibration that needs to succeeds before being able to access the DRAM | 15:12 |
| MoeIcenowy | it can get different value in different reads | 15:12 |
| MoeIcenowy | _florent_: is there any debugging facility for that calibration | 15:12 |
| _florent_ | MoeIcenowy: for the read, you can try to do a large dump and compare various dumps | 15:13 |
| _florent_ | MoeIcenowy: if similar, that's already a good sign | 15:13 |
| MoeIcenowy | hahahahaha for a start the requirement is always low | 15:13 |
| MoeIcenowy | currently one DQ group totally broken (marked L on schematics), but another DQ group seems to be at least slightly working | 15:14 |
| MoeIcenowy | I start to wonder whether I got the DQS/DM pins wrong... | 15:15 |
| _florent_ | :) but yes, being able to read a DRAM is already a very good step: this means the initialization work, command work and read path is almost working | 15:17 |
| _florent_ | For the debug, the read leveling is already displayed during the calibration | 15:18 |
| MoeIcenowy | _florent_: but I got nothing meaningful | 15:18 |
| MoeIcenowy | all lines are `|00000000| delays: -` | 15:19 |
| MoeIcenowy | maybe some skew is beyond software calibration, and needs to be tweaked in HW? | 15:19 |
| _florent_ | in https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitedram/sdram.c, I would recommend checking you did the equivalent of what is done for SDRAM_PHY_ECP5DDRPHY | 15:19 |
| _florent_ | and for more debug, I would recommend using LiteScope in the PHY, to be able to observe the parallel signals and DFI interface | 15:20 |
| _florent_ | have you tried doing some writes and see it it affect the read dump? | 15:20 |
| MoeIcenowy | it does affects | 15:21 |
| MoeIcenowy | and around ~80% bytes are right when I write all 55 or all aa | 15:21 |
| _florent_ | Good, then that's really not bad for a first test. What's probably missing now is the latency/delay adjustments | 15:23 |
| _florent_ | With LiteScope, you should be able to have more visibility on this | 15:23 |
| MoeIcenowy | how does LiteScope pass data? etherbone? | 15:24 |
| _florent_ | it can be done over UART/Ethernet/PCIe, etc... | 15:24 |
| _florent_ | is the Ethernet already up on your board? | 15:25 |
| MoeIcenowy | not up, when I enable etherbone some problems in gowin support of LiteX start to raise | 15:25 |
| MoeIcenowy | mainly about clock constrainting | 15:25 |
| _florent_ | OK, then you can use UART | 15:25 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 15:26 | |
| _florent_ | If you set the UART to Crossover + UARTBone with --with-uart=crossover+uartbone | 15:26 |
| _florent_ | you'll be able to use LiteScope and CPU UART over the same UART | 15:26 |
| MoeIcenowy | looks like magic | 15:27 |
| _florent_ | for LiteScope, you can follow: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC | 15:27 |
| _florent_ | you can create a list of signal you want to observe: analyzer_signals = [module0.foo, module1.bar, etc...] | 15:28 |
| _florent_ | and add this to the design: | 15:29 |
| _florent_ | https://www.irccloud.com/pastebin/dWyeQ9R8/ | 15:29 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 15:29 |
| _florent_ | then with the SoC built with --with-uart=crossover+uartbone --csr-csv=csr.csv | 15:29 |
| _florent_ | use the CPU UART: litex_term crossover | 15:29 |
| _florent_ | use LiteScope: litescope_cli | 15:30 |
| _florent_ | ah sorry, you need to open the litex_server before using litex_term/litescope_cli: litex_server --uart --uart-port=/dev/ttyUSBX | 15:30 |
| _florent_ | for litescope_cli use, you can type --help and/or have a look at the wiki page | 15:31 |
| MoeIcenowy | --with-uart does not exist, is it --uart-name ? | 15:33 |
| _florent_ | indeed, sorry | 15:33 |
| MoeIcenowy | _florent_: BTW officially Tang Primer 20K comes as a SoM and a base board, but the SoM has too little functionality | 15:44 |
| MoeIcenowy | what should this be handled in LiteX? | 15:44 |
| _florent_ | we could do something similar than with the qmtech boards | 16:00 |
| _florent_ | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/qmtech_5cefa2.py | 16:00 |
| _florent_ | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/qmtech_daughterboard.py | 16:00 |
| _florent_ | ie, define a connector and connector pins for the peripherals of the base board | 16:01 |
| _florent_ | this could be regrouped in a single platform file, but using a connector would ease reading/reviewing the code I think, while also simplifying use of other base board / SoM | 16:02 |
| MoeIcenowy | _florent_: the problem is that I don't think the baseboard will be reused | 16:04 |
| *** swetland <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 16:18 | |
| *** Shatur <[email protected]> has quit IRC (Quit: Konversation terminated!) | 16:37 | |
| MoeIcenowy | _florent_: how to decipher sdram_debug command output | 16:37 |
| MoeIcenowy | BTW I think maybe we need to implement some kind of write leveling, consider there's a WSTEP for DQS of GW2 | 16:40 |
| _florent_ | MoeIcenowy: if the baseboard will not be reused, that's maybe not worth splitting the platform file. | 17:04 |
| _florent_ | MoeIcenowy: I don't remember if WSTEP was present on ECP5 or not. If this is additional on GW2, this could make sense to the the write leveling yes. | 17:04 |
| MoeIcenowy | _florent_: currently I found that the data at 0x0, 0x8 is okay but 0x4, 0xc is bullshit | 17:11 |
| MoeIcenowy | is it possible that something get wrong when handling BL8? | 17:11 |
| _florent_ | if latency/timing are not correct, you'll only have a part of the BL8 burst written/read correctly, so yes | 17:12 |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has joined #litex | 19:13 | |
| *** xenador77 <xenador77!~xenador77@user/xenador77> has quit IRC (Remote host closed the connection) | 22:13 | |
| *** MoeIcenowy <MoeIcenowy!~MoeIcenow@2001:19f0:7002:866:c2b3:ebb5:95e:be08> has quit IRC (Read error: Connection reset by peer) | 23:26 | |
| *** MoeIcenowy <[email protected]> has joined #litex | 23:50 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!