On Fri, Jul 17, 2020 at 10:44:19PM +0200, John Crispin wrote: > in regards to the sgmii clk skew. I never understood the electrics fully I > am afraid, but without the patch it simply does not work. my eletcric foo is > unfortunately is not sufficient to understand the "whys" I am afraid. Do you happen to know what frequency the clock is? Is it 1.25GHz or 625MHz? It sounds like it may be 1.25GHz if the edge is important. If the clock is 1.25GHz, the "why" is because of hazards (it has nothing to do with delays in RGMII being propagated to SGMII). Quite simply, a flip-flop suffers from metastability if the clock and data inputs change at about the same time. Amongst the parametrics of flip-flops will be a data setup time, and a data hold time, referenced to the clock signal. If the data changes within the setup and hold times of the clock changing, then the output of the flip-flop is unpredictable - it can latch a logic 1 or a logic 0, or oscillate between the two until settling on one state. So, if data is clocked out on the rising edge of a clock signal, and clocked in on the rising edge of a clock signal - and the data and clock edges arrive within the setup and hold times at the flip-flop that is clocking the data in, there is a metastability hazard, and the data bit that is latched is unpredictable. One way to solve this is to clock data out on one edge, and clock data in on the opposite edge - this is used on buses such as SPI. Other buses such as I2C define minimum separation between transitions between the SDA and SCL signals. These solutions don't work with RGMII - the RGMII TXC clocks data on both edges. The only solution there is to ensure a delay is introduced between the data and clock changes seen at the receiver - which can be done by introducing delays at the transmitter or at the receiver, or by serpentine routing of the traces to induce delays to separate the clock and data transitions sufficiently to avoid metastability. If the clock is 625MHz (as with some Marvell devices for SGMII) then both clock edges are used, and both edges are used just like RGMII. Therefore, the same considerations as RGMII apply there to ensure that the data setup and hold times are not violated. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
