Forum Discussion

Jodok's avatar
Jodok
Icon for New Contributor rankNew Contributor
2 years ago

Cyclone 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

Fpga Devkit

19 Replies

Show More
  • Jodok's avatar
    Jodok
    Icon for New Contributor rankNew Contributor
    2 years ago

    So 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 Setup0.244
    Input to Register Hold0.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 Setup521
    Input to Register Hold0
    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?

    • AshleyDoh's avatar
      AshleyDoh
      Icon for New Contributor rankNew Contributor
      4 months ago

      Hey, were you able to make any progress on this? I seem to be having the same issue.

      • Jodok's avatar
        Jodok
        Icon for New Contributor rankNew Contributor
        4 months ago

        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.