Calculate skew timing with Cyclone V and ksz9031

Posting the solution here for the community's future reference.

Regarding the PCB traces, resistors etc.

Typically we take into account the track lengths on PCB, line impedance and capacitive loading. All of which are inter-related. The track delay data you have is quite impressive and has pretty high tolerance to variations. Therefore, track delay can be ignored from analysis.

TX Timing

Examining the RGMII 2.0 spec: (see attached)

At the transmitter, TX_CTL & TXD are sent edge-aligned to TXC by the transmitter. However at the receiving end, the TXC signal is center-aligned to data. According to the spec, the skew can be achieved by PCB trace routing or by an internal delay in the transmitting or receiving node.

Assuming the following:

• With the HPS we can’t add 2.0 ns of delay to TXC
• The customer hasn’t added the skew via PCB
• All tracks on PCB are delay matched
• Paths are delay matched within the PHY package

Then the only option is to add the delay within the PHY.

Here’s what we publish wrt TX:

The PHY allows for internal delays on TX_CLK via MMD register 2.8. The goal would be to center-align the signals to TX_CLK by delaying TX_CLK.

As a default, the PHY adds a 15*0.06ns = 0.900 ns delay to TX_CLK. However to center-align, TX_CLK should be delayed 1.65 ns.

Therefore if the customer sets MMD register 2.8[9:5] to int(1.65/0.06) = 27 or 1.62ns. This will provide a Tsu of 1.47 ns and Th of 1.53 ns. This should easily meet the TsetupR & TholdR requirements of 1.0 ns.

RX Timing

Examining the RGMII 2.0 spec:

Like the Tx timing, the PHY sends its data edge aligned to RXC. At the receiving end, the RXC signal is center-aligned to data. According to the spec, the skew can be achieved by PCB trace routing or by an internal delay in the transmitting or receiving node.

Assuming the following:

• With the HPS we can’t add 2.0 ns of delay to RXC
• The customer hasn’t added the skew via PCB
• All tracks on PCB are delay matched
• Paths are delay matched within the PHY package

Then the only option is to add the delay within the PHY.

Here’s what we publish wrt RX:

As before, the PHY allows for internal delays on RX_CLK via MMD register 2.8. The goal would be to center-align the signals to RX_CLK by delaying RX_CLK.

Examining Table 4-6 from above, as a default, the PHY adds a 15*0.06ns = 0.900 ns delay to RX_CLK. However to center-align, RX_CLK should be delayed 2.00 ns. Therefore if the customer sets MMD register 2.8[4:0] to int(2.0/0.06) = 33 or 1.98ns. This will provide a Tsu of 1.98 ns and Th of 2.02 ns. This should easily meet the TsetupR & TholdR requirements of 1.0 ns.

Final Notes

The above analysis is fairly simplistic. It doesn’t take into account duty-cycle distortion, jitter, IO skew, PCB skew, or variations over PVT. Here’s a TI appnote the tries to address some of these concerns.

https://www.ti.com/lit/an/snla243/snla243.pdf

Lastly, the customer can scope these signals & validate the clock-data relationships.