Forum Discussion
New ContributorCyclone V: reaching RGMII Data to Clock output skew of +/- 500ps
What is best practice to reach the 500ps Data to Clock output Skew of RGMII specification v2.0 on a Cyclone V?
Trying synthesizing a TSE MAC with RX-Clock to TX-Clock loopback fails because of timing missmatch. Applying a 2ns delay at the PHY and with the constrains made, the FPGA has 600ps setup and 900ps hold time budget for TX-path. The worst failing path is from the back-looped RX-Clock Pin to one of the TX-Data output Pins with a mismatch of 360ps.
For more timing details please see my other post: Re: Cyclone V TSE MAC timing closure - Intel Community
The Cyclone V device datasheet states in Table 48 RGMII Timing Characteristics: Td (TX_CLK to TXD/TX_CTL output data delay) -0.85ns ..+0.15ns. So with the correct Clock to Data Delay it should be possible to reach the 500ps output Skew.
Any help on this would be greatly appreciated!
Jodok
19 Replies
JodokSo here is what I belive to found out so far:
Asymmetric Delays for Rx/Tx Path seem to be benefitial. I only can guess that is because the fpga can not synthesize negative delay on data trace. This I belive is because in my design the Rx-clk is looped-back as Tx-clk and can not be delayed freely.
create_clock -period 8.000 -name PHY0_RX_CLK -waveform {1.750 6.250} [get_ports PHY0_RX_CLK]
create_clock -period 8.000 -name PHY0_RX_CLK_VIRT
create_generated_clock -name PHY0_TX_CLK_VIRT -phase 100.0 -source [get_ports PHY0_RX_CLK] [get_ports PHY0_TX_CLK]
In this example both Tx and Rx have an external PHY (clk)-Delay of 2.25ns so the data at Rx will arrive in principle to soon. The fpga can now add delay to the Rx-data trace. The PHY delays the clock with 2.25ns on the Tx Path so that in general the data occure to soon. The fpga can now add delay to the Tx-data trace.
With the following constraints, a mildly ok result can be achived.
# ************************************************************** # External components # ************************************************************** # TVX0106 set tSKQ 0.1 # DP83867 set TsetupT 0.55 set TholdT -0.55 set TsetupR 1.05 set TholdR -0.8 # Calculate min / max skew set RxMaxDelay [expr {$TsetupT + $tSKQ}] set RxMinDelay [expr {$TholdT - $tSKQ}] set TxMaxDelay [expr {$TsetupR + $tSKQ}] set TxMinDelay [expr {$TholdR - $tSKQ}] TA Slack: [ns] Input to Register Setup 0.244 Input to Register Hold 0.165 Input to Outupt Setup -0.045 Input to Output Hold -0.084 If a symmetric delay of 2ns for both Tx and Rx Path is used, the following Slack is much worse:
create_clock -period 8.000 -name PHY0_RX_CLK -waveform {2.000 6.000} [get_ports PHY0_RX_CLK]
create_clock -period 8.000 -name PHY0_RX_CLK_VIRT
create_generated_clock -name PHY0_TX_CLK_VIRT -phase 90.0 -source [get_ports PHY0_RX_CLK] [get_ports PHY0_TX_CLK]
TA Slack: [ns] Input to Register Setup 521 Input to Register Hold 0 Input to Outupt Setup -0.15 Input to Output Hold -0.175 To improove timing further I now try to manipulate D5 Delay which is impressively bad documented.
Could somebody please verify my findings.
What else can be done on that?
AshleyDohHey, were you able to make any progress on this? I seem to be having the same issue.
- Jodok
Yes, setting false path to RGMII-TX signals helped me to reach rx-timing. In my configuration, where tx-clk is a loop-back of rx-clk, RGMII-TX signals don't need to be constraint because the signals are driven by ddr-registers.
ShengN_alteraSuper Contributor
Hi,
Seems like there's no problem with the timing equation. Most probably the problem due to some parameter is wrong or missing. I think you may need to open an IPS thread https://www.intel.com/content/www/us/en/support/articles/000057045/ethernet-products.html to get some insights from RGMII expert.
