liteeth: MII clock frequency detection is hacky and unreliable

[sbourdeauducq]

As the MII/GMII clock detection is intermittently not working on my board (selecting the wrong mode) I had a look at the code and found several problems:

• contrary to what the comment says the counter reset does need a clock domain transfer. This has nothing to do with the speed of the reset, but making sure that the reset is deasserted at all flops at the same time.
• clock domain transfer of a bus is a complex problem and is not a matter of simply inserting MultiReg on it, as not all bits travel at the same time through the double-latch. Since this is a simply a counter here, using Gray code is one solution (like it's done in the async FIFOs, and the RTIO core for reading the timestamp counter value in the CPU domain). Without Gray coding, large errors can appear every time there is a carry on a high-order bit in the counter.
• timing stuff based on the time spent in printf is a gross and fragile hack. I would put the whole clock detection and MII/GMII switching mechanism in gateware anyway.

[sbourdeauducq]

Here's an example of a gateware frequency meter: https://github.com/m-labs/tdc-core/blob/master/core/tdc_freqc.vhd Double latching the counter output directly is correct here as the value has been stationary for enough cycles when it is read in the system clock domain.

[enjoy-digital]

Thanks for the feedback. I should have spent more time on that.

I've implemented another solution that in fact avoids most of the resynchronizations. (it only requires a pulse resynchronization from eth_rx to sys_clk).

For now it's still assisted by software, I will probably move all the detection to the gateware in the future.

[sbourdeauducq]

That's better, but the software timing is still fragile (proportional to the execution time of just a few C statements); additionally, it breaks if you don't netboot the board or if you switch between MII and GMII modes after the board has booted (unless the runtime implements eth_mode_detection as well). Solving those problems correctly sounds more difficult than putting the mode switch in gateware.

[enjoy-digital]

OK, mode switch is now done in gateware (I've just kept the MII/GMII printf in software). I've tested dynamic mode switch while pinging the board (unpluging the cable from a 100Mbps switch and plugging it to a 1Gbps switch, and the reverse). Thanks for insisting.

[sbourdeauducq]

Good, thanks a lot! :+1: