We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 65736

GMII to RGMII Bridge v4.0a - GMII to RGMII bridge does not meet the minimum requirement given in the RGMII Spec Standard


The RGMII specification would need a would need a minimum value of 1ns for TsetupR/TholdR. 

This will compute for a total data valid window of 2ns. Does the GMII to RGMII IP comply with this specification?


The GMII to RGMII IP does not meet the minimum requirement as recommended by the specification.

How does it fail: It fails because it cannot meet the input setup/hold constraints as specified in the RGMII v2 spec. 

When you change the input delay values to match the spec, HOLD violations are seen on the path from the input pin to the IDDR element. This timing path is within the IOB which implies a fixed route and component delays.

It also implies the following:

  1. That there are not many options available, apart from adjusting the DLEAY values on these paths.
  2. In the worst case where you are not able to come up with DELAY values which will satisfy setup/hold for all of the input data-paths, you will have to relax the input constraints. This could lead to a reduced valid data-window.

Margins: Worst case HOLD slack is negative 1.229 ns which is seen on the path rx_ctl pin to its corresponding IDDR element.

The worst case data window size is 1.915 ns which is 85 ps less than the spec mentioned data-window of 2 ns.

How to minimize this issue: As mentioned before, this failing timing path is in IOB. As such, you do not have a lot of control over how the routing is done. 

In order to close timing, you have the following options:

  • Adjust the delay values on the input paths until setup/hold is met on that path.
  • Relax the input constraints. The valid window will reduce but you will be able to correctly sample all input transitions, and will not see any dropped frames so the design will work.
  • The Clock to the IDDR can be directly sourced from the BUFIO bypassing the BUFG/BUFR.
  • In extreme cases where the skew between the clock and data is more than what can be compensated for by the IDLEAY on the RX Data-lines, add an IDELAY component on the RX clock path (At present the design does not include this)
AR# 65736
Date Created 10/19/2015
Last Updated 01/06/2016
Status Active
Type General Article