06:40 <_florent_> feldim2425: soc_core.py/SoCCore is still used indeed, but the logic has been rewritten and moved to soc.py, it's mostly providing a retro-compatibility layer now and the aim in the future is to switch designs to LiteXSoC directly

06:43 <_florent_> [Matt]: when testing https://github.com/enjoy-digital/pcie_analyzer/blob/master/ac701.py we indeed had issues calibrating all the modules together on the AC701

06:43 <tpb> Title: pcie_analyzer/ac701.py at master · enjoy-digital/pcie_analyzer · GitHub (at github.com)

06:43 <_florent_> you can try to reduce the DRAM IOs to https://github.com/enjoy-digital/pcie_analyzer/blob/master/ac701.py#L91-L120

06:43 <tpb> Title: pcie_analyzer/ac701.py at master · enjoy-digital/pcie_analyzer · GitHub (at github.com)

06:45 <_florent_> or use the PHYPadsReducer on the ddram_pads, like done here: https://github.com/enjoy-digital/litex_vexriscv_smp/blob/master/genesys2.py#L80

06:45 <tpb> Title: litex_vexriscv_smp/genesys2.py at master · enjoy-digital/litex_vexriscv_smp · GitHub (at github.com)

06:45 <_florent_> but with PHYPadsReducer(platform.request("ddram"), [0, 1, 2, 3])

06:47 <_florent_> this will use half the data pads and should allow you to get it working, i'll work on improving the flexibility of the calibration soon but don't have an AC701 to test.

12:14 <[Matt]> _florent_: Ahah! Many thanks, Florent. (I've been swapping pins this morning; there are 6 working bytes, 2 non-working. Had indeed wondered about reducing to 32b width, thanks!)

12:16 <[Matt]> _florent_: Do you have a suspicion re the calibration problem? (BTW I am happy to help test on AC701, in future.)

13:40 <[Matt]> _florent_: FWIW, PHYPadsReducer w/ [4, 5, 6, 7], plus cmd_latency=1 works on my AC701. (Thanks again!) Any combination that includes byte lanes 0 or 1 fails.

18:01 <felix_> when i tried to get the ddr3 dram running on the ac701 in early 2018 i didn't get it working; iirc the issue is likely that litedram doesn't do read leveling on artix7

18:04 <felix_> having 6 out of 8 byte lanes working sounds like what i was seeing back then

18:09 <felix_> for read leveling the odelay blocks are used that are only present on the high performance i/o banks, but a7 doesn't have those; k7 does have those. a7 has some other i/o logic for the ds/dqs interfaces, but last time i looked, litedram didn't use those

19:07 <[Matt]> felix_: Merci! (Do you mean write levelling? This build is appearing to do read levelling but not WR.) Naively, would no WL mean getting corruption of written data? (I see zero for those lanes no matter what I write, it's quite strange, not just random/broken data.)

19:14 <_florent_> A "real" write leveling is indeed not possible on Artix7 with the current PHY (that is only using ISERDESE2/ODERDESE2 + IODELAYs) since the ODELAYs are not present on Artix7, so we are using a phase shifted clock, but with a 64-bit SODIMM it's difficult to have a phase shift that works for all modules.

19:14 <_florent_> The read leveling is similar to the one on Kintex7

19:14 <[Matt]> Ahhh

19:16 <[Matt]> _florent_: Can you tell me a little more about the dedicated dqs logic? (I'm assuming MIG uses this!)

19:16 <[Matt]> er, that felix_ mentioned ;)

19:18 <zyp> _florent_, IIRC you mentioned etherbone can now be used at sys clock rates below 125MHz, was that so?

19:18 <[Matt]> Another experiment I found interesting was to restrict to a 16-bit i/f, using only the two "bad" bytes, and RL failed to find a preferred delay on either (whereas it does on the other "good" bytes)

19:19 <_florent_> the MIG uses PHASER_IN/OUT primitives, it shoudl be possible to use them but this is not really documented: https://www.xilinx.com/support/answers/42026.html

19:19 <[Matt]> Cheers!

19:21 <felix_> ah, seems that mixed up read leveling and write leveling

19:22 <felix_> the MIG-generated code is helpful to understand how those blocks work

19:24 <_florent_> zyp: yes, the UDP/IP stack will still runs at 125MHz but the Etherbone is now running in sys_clk (down to 125MHz/4=31.25MHz theorically)

19:26 <zyp> good

19:34 <_florent_> felix_: in fact the Artix7 boards with > 32-bit DDR3 are not very common, most of the Artix7 boards have 16 or 32-bit which is working fine with the current approach, so i haven't spend that much time looking PHASER_IN/OUT blocks, this is limiting mostly for the AC701

19:49 <zyp> _florent_, the 125MHz domain still doesn't meet timing on the ecp5 (colorlight)?