| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 00:27 | |
| *** shorne <[email protected]> has joined #litex | 00:27 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 00:35 | |
| *** shorne <[email protected]> has joined #litex | 00:36 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 00:50 | |
| *** bl0x_ <[email protected]> has joined #litex | 01:10 | |
| *** bl0x <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 01:12 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 276 seconds) | 02:05 | |
| *** Degi <[email protected]> has joined #litex | 02:09 | |
| MoeIcenowy | somlo: sounds a normal situation for RGMII | 02:18 |
|---|---|---|
| MoeIcenowy | maybe I should say it's a normal problem for RGMII | 02:18 |
| *** shorne <[email protected]> has joined #litex | 02:57 | |
| *** pbsds <[email protected]> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 03:20 | |
| *** pbsds <[email protected]> has joined #litex | 03:22 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 276 seconds) | 03:33 | |
| *** shorne <[email protected]> has joined #litex | 03:33 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 276 seconds) | 04:17 | |
| *** shorne <[email protected]> has joined #litex | 04:18 | |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 04:48 | |
| *** shorne <[email protected]> has joined #litex | 04:54 | |
| *** zjason`` is now known as zjason | 05:03 | |
| _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:22 |
| _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:23 |
| _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. | 05:25 |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 255 seconds) | 05:49 | |
| *** indy_ is now known as indy | 06:05 | |
| *** shorne <[email protected]> has joined #litex | 07:06 | |
| somlo | _florent_: I should also try testing sata using my fmc adapter (once I get the fmc pins added to the platform file) | 11:12 |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 11:12 | |
| *** shorne <[email protected]> has joined #litex | 11:18 | |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 13:32 | |
| *** shorne <[email protected]> has joined #litex | 13:38 | |
| *** pacot24 <pacot24!~pacot24@ec2-3-77-160-50.eu-central-1.compute.amazonaws.com> has joined #litex | 13:41 | |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 13:42 | |
| *** shorne <[email protected]> has joined #litex | 13:48 | |
| *** pacot24 <pacot24!~pacot24@ec2-3-77-160-50.eu-central-1.compute.amazonaws.com> has quit IRC (Quit: Client closed) | 14:01 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b11::11> has quit IRC (Ping timeout: 250 seconds) | 15:06 | |
| 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:07 |
| * somlo needs to stop using "quotes" :D | 15:08 | |
| somlo | in linux, once booted, eth0 is rock solid, fwiw | 15:08 |
| 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:09 |
| somlo | the linux liteeth driver doesn't seem to do anything fancy with the phy | 15:15 |
| somlo | as in, no configuration thereof at all, afaict | 15:16 |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 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:18 |
| *** shorne <[email protected]> has joined #litex | 15:20 | |
| 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:21 |
| 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) | 15:22 |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 15:27 | |
| *** shorne <[email protected]> has joined #litex | 15:37 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b11::11> has joined #litex | 15:47 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 255 seconds) | 16:11 | |
| *** shorne <[email protected]> has joined #litex | 16:11 | |
| *** shorne <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 16:55 | |
| *** shorne <[email protected]> has joined #litex | 17:37 | |
| MoeIcenowy | somlo: I think it's local | 23:06 |
| 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:07 |
| 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:38 |
| zyp | RGMII is 4b DDR at 125MHz, so period time is 8ns and each symbol time is at 4ns | 23:46 |
| 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:48 |
| zyp | and probably rise/fall times as well | 23:49 |
| 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:50 |
| zyp | are you sure the DDR buffers in the FPGA are configured correctly wrt. center/edge alignment? | 23:52 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!