_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
gatecat has quit [Ping timeout: 240 seconds]
gatecat has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<MoeIcenowy> _florent_: thanks for the tip
<MoeIcenowy> I do have some ECP5 board, but it's Colorlight i5, thus no DDR memory
gatecat has quit [Ping timeout: 256 seconds]
gatecat has joined #litex
xenador77 has joined #litex
xenador77 has quit [Remote host closed the connection]
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
<_florent_> MoeIcenowy: we could collaborate on this, but I have limited time currently to work on this, so if you could:
<_florent_> 1) find the Gowin's equivalent of each primitive used in ECP5DDRPHY and IO renaming
<_florent_> 2) Do an initial version of the GW2ADDRPHY based on ECP5DDRPHY + finding from 1)
<_florent_> 3) Prepare a platform/target for the primer 20k (which I think you are using) and verify the build with GW2ADDRPHY
<_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
xenador77 has joined #litex
xenador77 has quit [Remote host closed the connection]
<MoeIcenowy> _florent_: well I am doing them
<MoeIcenowy> (and I found that there're still many things TODO before doing DDR
ilia__s0 has quit [Quit: The Lounge - https://thelounge.chat]
ilia__s0 has joined #litex
Shatur95 has joined #litex
Shatur95 has quit [Client Quit]
Shatur has joined #litex
<Shatur> Hi! Is it possible to use my own ip core written in verilog / systemverilog with litex?
esteves has joined #litex
esteves has quit [Client Quit]
<Shatur> Oh, I somehow missed it, thank you!
<MoeIcenowy> _florent_: I did a simple port of ECP5DDRPHY to GW2A, and surely it does not work now
<MoeIcenowy> how could I disable L2 fully?
<_florent_> MoeIcenowy: It's already not that bad it it compiles :)
<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
<_florent_> MoeIcenowy: To disable the L2, you can set --l2_size=0 and add some checks to be sure you are disabling it here:
<MoeIcenowy> oh I used `l2_cache_size = kwargs.get("l2_size", 0)` and it surely loads some default value
<MoeIcenowy> I switched to use a picorv32 core and add `--l2_size=0`, the mem_read behavior looks right
<_florent_> MoeIcenowy: but there is also an initial calibration that needs to succeeds before being able to access the DRAM
<MoeIcenowy> it can get different value in different reads
<MoeIcenowy> _florent_: is there any debugging facility for that calibration
<_florent_> MoeIcenowy: for the read, you can try to do a large dump and compare various dumps
<_florent_> MoeIcenowy: if similar, that's already a good sign
<MoeIcenowy> hahahahaha for a start the requirement is always low
<MoeIcenowy> currently one DQ group totally broken (marked L on schematics), but another DQ group seems to be at least slightly working
<MoeIcenowy> I start to wonder whether I got the DQS/DM pins wrong...
<_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
<_florent_> For the debug, the read leveling is already displayed during the calibration
<MoeIcenowy> _florent_: but I got nothing meaningful
<MoeIcenowy> all lines are `|00000000| delays: -`
<MoeIcenowy> maybe some skew is beyond software calibration, and needs to be tweaked in HW?
<_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
<_florent_> and for more debug, I would recommend using LiteScope in the PHY, to be able to observe the parallel signals and DFI interface
<_florent_> have you tried doing some writes and see it it affect the read dump?
<MoeIcenowy> it does affects
<MoeIcenowy> and around ~80% bytes are right when I write all 55 or all aa
<_florent_> Good, then that's really not bad for a first test. What's probably missing now is the latency/delay adjustments
<_florent_> With LiteScope, you should be able to have more visibility on this
<MoeIcenowy> how does LiteScope pass data? etherbone?
<_florent_> it can be done over UART/Ethernet/PCIe, etc...
<_florent_> is the Ethernet already up on your board?
<MoeIcenowy> not up, when I enable etherbone some problems in gowin support of LiteX start to raise
<MoeIcenowy> mainly about clock constrainting
<_florent_> OK, then you can use UART
FabM has quit [Quit: Leaving]
<_florent_> If you set the UART to Crossover + UARTBone with --with-uart=crossover+uartbone
<_florent_> you'll be able to use LiteScope and CPU UART over the same UART
<MoeIcenowy> looks like magic
<_florent_> you can create a list of signal you want to observe: analyzer_signals = [module0.foo, module1.bar, etc...]
<_florent_> and add this to the design:
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<_florent_> then with the SoC built with --with-uart=crossover+uartbone --csr-csv=csr.csv
<_florent_> use the CPU UART: litex_term crossover
<_florent_> use LiteScope: litescope_cli
<_florent_> ah sorry, you need to open the litex_server before using litex_term/litescope_cli: litex_server --uart --uart-port=/dev/ttyUSBX
<_florent_> for litescope_cli use, you can type --help and/or have a look at the wiki page
<MoeIcenowy> --with-uart does not exist, is it --uart-name ?
<_florent_> indeed, sorry
<MoeIcenowy> _florent_: BTW officially Tang Primer 20K comes as a SoM and a base board, but the SoM has too little functionality
<MoeIcenowy> what should this be handled in LiteX?
<_florent_> we could do something similar than with the qmtech boards
<_florent_> ie, define a connector and connector pins for the peripherals of the base board
<_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
<MoeIcenowy> _florent_: the problem is that I don't think the baseboard will be reused
swetland has quit [Quit: Connection closed for inactivity]
Shatur has quit [Quit: Konversation terminated!]
<MoeIcenowy> _florent_: how to decipher sdram_debug command output
<MoeIcenowy> BTW I think maybe we need to implement some kind of write leveling, consider there's a WSTEP for DQS of GW2
<_florent_> MoeIcenowy: if the baseboard will not be reused, that's maybe not worth splitting the platform file.
<_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.
<MoeIcenowy> _florent_: currently I found that the data at 0x0, 0x8 is okay but 0x4, 0xc is bullshit
<MoeIcenowy> is it possible that something get wrong when handling BL8?
<_florent_> if latency/timing are not correct, you'll only have a part of the BL8 burst written/read correctly, so yes
xenador77 has joined #litex
xenador77 has quit [Remote host closed the connection]
MoeIcenowy has quit [Read error: Connection reset by peer]
MoeIcenowy has joined #litex