01:06 <somlo> zyp: I'm not really sure of anything at all: so far all I have to go on is an excel spreadsheet with the pin-port mapping and some rather dense verilog that converts the gmii ethernet demo used with the v1 board to rgmii

01:06 <somlo> if anything, that's where I might find some answers, once I train my pattern-matching wetware for what to look for :)

01:06 <somlo> but no schematics (yet)

04:04 <hansfbaier> somlo: There is a schematic for the previous version of the STLV7325 board though

04:15 <hansfbaier> somlo: Where exactly did you configure the delays that made the ethernet work?

13:32 <somlo> _florent_: follow-up question, what's the meaningful resolution on e.g. s7rgmii phy's rx_delay and tx_delay? I.e., if I want to "sweep" the [0.9e-9 .. 1.3e-9] range to find where my tftp transfer is "least choppy" when netbooting

13:33 <somlo> should I try increments of 0.1e-9, 0.05e-9, etc? I don't have an intuitive feeling for how fine is no longer worth bothering with :)

13:33 <somlo> *fine grained

18:45 <somlo> hansfbaier: (on the off chance that you end up reading the logs): the previous version of the stlv7325 uses gmii (8 tx, 8 rx pins)

18:48 <somlo> the new version uses rgmii (4 tx, 4rx); so the phy delays (currently at https://github.com/gsomlo/litex-boards/blob/gls-stlv7325-v2/litex_boards/targets/sitlinv_stlv7325_v2.py#L90-L91) are naturally different

19:23 <_florent_> somlo: The I/ODELAYs have 32 taps on 7-Series, so you could just make test the taps around the one that "work"

19:23 <_florent_> somlo: https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/s7rgmii.py#L67-L70

19:24 <_florent_> somlo: if you print iodelay_tap_average, you'll get the increment you can test

19:29 <somlo> _florent_: thanks, that makes sense (for rx_delay); looks like tx_delay works a bit differently

19:30 <somlo> https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/s7rgmii.py#L169-L175

19:31 <somlo> but besides eyeballing the tftp "spinner" and deciding it's "too choppy", maybe I should try using iperf to measure (and optimize) the delays for each direction (tx vs. rx) independently of each other...

20:14 <somlo> _florent: for tx_delay the valid range is [0 .. 8.0e-9], so that tx_phase can go from 0 to 360

20:26 <somlo> guess the resolution there depends on what granularity the phase parameter can be at, in a xilinx `create_clkout(...)` call

20:27 <somlo> it's from 0 to 360, but what happens when you feed it a decimal like 67.5? Does it end up rounding to the nearest integer, or can it handle sub-unit resolution on phase?