02:18 <MoeIcenowy> somlo: sounds a normal situation for RGMII

02:18 <MoeIcenowy> maybe I should say it's a normal problem for RGMII

05:22 <_florent_> mithro: The PCIe test infrastructure from Alex Forencich seems interesting yes (as his other repos :)), for now LitePCIe is tested with a simple Python model/unit-test and tests on hardware.

05:23 <_florent_> mithro: I'm currently reworking the Ultrascale(+) PHY integration and will probably add some unit-tests for this. But not sure I'll have time now to do a test of cocotbext-pcie.

05:25 <_florent_> somlo: Good for the tests on the STLV7325, I also have one v1 if you need more support. I remember testing SATA and that it was not working directly (but haven't investitaged), I could have a closer look. SATA is generally very easy to get working, so maybe the maybe the GTX/pinout is not correct, we could do some low level test to verify this, like generating the clock pattern and check it with a scope.

11:12 <somlo> _florent_: I should also try testing sata using my fmc adapter (once I get the fmc pins added to the platform file)

15:07 <somlo> _florent_: how "sensitive" is RGMII to the delay parameter(s) for rx and tx? I don't have a lot of (any?) detailed experience with that, but during tftpboot the transfer of data looks like it's "stuttering" (much more so than on other boards like trellis, ecpix5, or nexys-video)

15:07 <somlo> is it more like once I get some values that work at all it's unlikely to get better if I move away from that? Or is it a matter of "tuning" to "optimize" behavior, even once it "sort-of" "works" :)

15:08 <somlo> in linux, once booted, eth0 is rock solid, fwiw

15:09 <tnt> Some phy have programmable delays and so you need the bootloader/kernel/hardware to agree. It's possible that linux configures the phy suitably but not the bootloader ?

15:15 <somlo> the linux liteeth driver doesn't seem to do anything fancy with the phy

15:16 <somlo> as in, no configuration thereof at all, afaict

15:18 <somlo> being physically away from the board atm, but thinking about it anyway, I'm just wondering if and how much it'd be worth spending time compiling bitstream with various small deviations from the timeout values I've discovered got the ethernet to work in the first place (tx_delay = rx_delay = 1e09) vs. the defaults (2e09 for both) where it didn't work *at all* :)

15:21 <somlo> I.e., is there a *method* to this, or is it just "try something, and if it works, try something else to see if it could work *better*" (which is what I've been doing so far with it) :)

15:22 <somlo> and, finally, is "better" an intrinsic local property of my phy configuration, or does it depend on the rest of the network gear it's connected to (in the latter case things would be really messy, so I'm hoping that isn't it)

23:06 <MoeIcenowy> somlo: I think it's local

23:07 <MoeIcenowy> it's about the trace length between the PHY and MAC

23:07 <MoeIcenowy> (and in our case, the MAC is just the FPGA

23:38 <somlo> ok, so I'll experiment with values around 1e-9 (from like 0.5e-9 to 1.5e-9) -- we know 2e-9 does not work, and 0 doesn't, either

23:46 <zyp> RGMII is 4b DDR at 125MHz, so period time is 8ns and each symbol time is at 4ns

23:48 <zyp> so I figure you need to adjust the skew so all four data lines hit within the 4ns window with reasonable margins for jitter

23:49 <zyp> and probably rise/fall times as well

23:50 <zyp> and if the data lines are mismatched, that makes it a harder target to hit, but I'm not sure it's likely that they're significantly mismatched

23:52 <zyp> are you sure the DDR buffers in the FPGA are configured correctly wrt. center/edge alignment?