> > Maybe you should go read the RGMII standard, and then think about how > > your hardware actually works. > > > > RGMII always has a variable clock, with different clock speeds for > > 10/100/1G. So your board design is just plain normal, not > > special. Does the standard talk about different delays for different > > speeds? As you say, other drivers apply the same delay for all > > speeds. Why should your hardware be special? > > > > RGMII has been around for 25 years. Do you really think your RGMII > > implementation needs something special which no other implementation > > has needed in the last 25 years? > > I do not intend to violate the regulations of the RGMII standard and aim to > maintain the same delay across all speeds. But the RX programming swap bit > can only introduce a delay of 180 degrees. Should I assume the 1G speed > clock to calculate and determine if this bit should be enabled for all > speeds? Lets rewind a bit. The RGMII standard specified which edge you sample on. Since it is defined, no other driver has a configuration like this, they just setup there hardware to be standards compliant. Why do you need the ability to break the standard, and sample on the wrong edge? I can think of two reasons: 1) You have a PHY which is broken, it also samples on the wrong edge. This is a workaround for that broken PHY. 2) You have a board with a clock line driver inserted between the RGMII output pins and the PHY, and this line driver includes a NOT? This line driver is causing the clocking to break the RGMII standard. You are working around this broken board design by getting the MAC to invert the clock. Is there a third reason? Lets first understand the details of why you need to be able to invert the clock. Andrew
