UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
1,234 Views
Registered: ‎01-02-2012

RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Dear FPGA-Experts,

we have a board with RGMII RX_CLK connected to a non-global IO.
Setting the PHY (TI DP83867), so that it outputs the RX_CLK center-aligned (with 2 ns delay) and routing the RX_CLK through BUFIO/BUFMR, the interface seems to work stable at least at room temperature. 

However, the STA is telling another story (as far as I understand):

@FAST corner analysis => FPGA-internal clock path delay = ~2 ns & data path delay = ~0.5 ns
@SLOW corner analysis => FPGA-internal clock path delay = ~7 ns & data path delay = ~1.5 ns

Data-path does not vary much, because the routing to IDDR is minimal, on the other hand RX_CLK is running through buffers and unavoidable long nets, hence the huge 5 ns variation!?

Considering the 8/2 = 4 ns period of data signals, this 5 ns variation is a deal-breaker, right? 

Can this be fixed somehow, for instance using IDELAYs on the data lines, in order to equalize the delay amount?
Using IDELAYs with max. delay (TAP value = 31) 
@FAST corner analysis => FPGA-internal clock path delay = ~2 ns & data path delay = ~3.5 ns
@SLOW corner analysis => FPGA-internal clock path delay = ~7 ns & data path delay = ~4.3 ns
Slow corner indicates still ~2,7 ns difference :(

report_timing -from a7_phy_rx_d* -delay_type min
INFO: [Vivado 12-2286] Implicit search of objects for pattern 'a7_phy_rx_d*' matched to 'port' objects.
Resolution: To avoid ambiguous patterns, provide proper objects using get commands e.g. [get_nets xyz].
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -1L, Delay Type: min.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 2 CPUs
INFO: [Timing 38-78] ReportTimingParams: -from_pins  -max_paths 1 -nworst 1 -delay_type min -sort_by slack.
Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2018.3 (win64) Build 2405991 Thu Dec  6 23:38:27 MST 2018
| Date         : Wed Dec 19 18:53:52 2018
| Host         : PC-001-80-1 running 64-bit Service Pack 1  (build 7601)
| Command      : report_timing -from a7_phy_rx_d* -delay_type min
| Design       : elog_a7_top
| Device       : 7a200ti-fbv676
| Speed File   : -1L  PRODUCTION 1.23 2018-06-13
------------------------------------------------------------------------------------

Timing Report

Slack (VIOLATED) :        -2.735ns  (arrival time - required time)
  Source:                 a7_phy_rx_d_i[2]
                            (input port clocked by ob_phy_rx_clk  {rise@2.000ns fall@6.000ns period=8.000ns})
  Destination:            ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_23[2].rgmii_rx_data_in/D
                            (rising edge-triggered cell IDDR clocked by ob_phy_rx_clk  {rise@2.000ns fall@6.000ns period=8.000ns})
  Path Group:             ob_phy_rx_clk
  Path Type:              Hold (Min at Slow Process Corner)
  Requirement:            0.000ns  (ob_phy_rx_clk fall@6.000ns - ob_phy_rx_clk fall@6.000ns)
  Data Path Delay:        4.318ns  (logic 4.318ns (100.000%)  route 0.000ns (0.000%))
  Logic Levels:           2  (IBUF=1 IDELAYE2=1)
  Input Delay:            0.000ns
  Clock Path Skew:        6.828ns (DCD - SCD - CPR)
    Destination Clock Delay (DCD):    6.828ns = ( 12.828 - 6.000 ) 
    Source Clock Delay      (SCD):    0.000ns = ( 6.000 - 6.000 ) 
    Clock Pessimism Removal (CPR):    -0.000ns
  Clock Uncertainty:      0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock ob_phy_rx_clk fall edge)
                                                      6.000     6.000 f  
                         input delay                  0.000     6.000    
    U2                                                0.000     6.000 r  a7_phy_rx_d_i[2] (IN)
                         net (fo=0)                   0.000     6.000    a7_phy_rx_d_i[2]
    U2                   IBUF (Prop_ibuf_I_O)         1.442     7.442 r  a7_phy_rx_d_i_IBUF[2]_inst/O
                         net (fo=1, routed)           0.000     7.442    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_d_i_IBUF[2]
    IDELAY_X1Y114        IDELAYE2 (Prop_idelaye2_IDATAIN_DATAOUT)
                                                      2.877    10.318 r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/idel.rxd_gen[2].IDELAYE2_inst/DATAOUT
                         net (fo=1, routed)           0.000    10.318    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rxd_delayed_2
    ILOGIC_X1Y114        IDDR                                         r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_23[2].rgmii_rx_data_in/D
  -------------------------------------------------------------------    -------------------

                         (clock ob_phy_rx_clk fall edge)
                                                      6.000     6.000 f  
    W1                                                0.000     6.000 f  a7_phy_rx_clk_i (IN)
                         net (fo=0)                   0.000     6.000    a7_phy_rx_clk_i
    W1                   IBUF (Prop_ibuf_I_O)         1.517     7.517 f  a7_phy_rx_clk_i_IBUF_inst/O
                         net (fo=2, routed)           2.059     9.576    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_clk_i_IBUF
    BUFMRCE_X1Y3         BUFMR (Prop_bufmr_I_O)       0.103     9.679 f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/bufmr_rgmii_rx_clk/O
                         net (fo=2, routed)           1.292    10.971    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rxc_bufmr_out
    BUFIO_X1Y9           BUFIO (Prop_bufio_I_O)       1.532    12.503 f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/bufio_rgmii_rx_clk2/O
                         net (fo=3, routed)           0.324    12.828    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rxc_bufr_out2
    ILOGIC_X1Y114        IDDR                                         f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_23[2].rgmii_rx_data_in/C
                         clock pessimism              0.000    12.828    
                         clock uncertainty            0.035    12.863    
    ILOGIC_X1Y114        IDDR (Hold_iddr_C_D)         0.191    13.054    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_23[2].rgmii_rx_data_in
  -------------------------------------------------------------------
                         required time                        -13.054    
                         arrival time                          10.318    
  -------------------------------------------------------------------
                         slack                                 -2.735    




report_timing -from a7_phy_rx_d* -delay_type max
INFO: [Vivado 12-2286] Implicit search of objects for pattern 'a7_phy_rx_d*' matched to 'port' objects.
Resolution: To avoid ambiguous patterns, provide proper objects using get commands e.g. [get_nets xyz].
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -1L, Delay Type: max.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 2 CPUs
INFO: [Timing 38-78] ReportTimingParams: -from_pins  -max_paths 1 -nworst 1 -delay_type max -sort_by slack.
Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2018.3 (win64) Build 2405991 Thu Dec  6 23:38:27 MST 2018
| Date         : Wed Dec 19 18:53:58 2018
| Host         : PC-001-80-1 running 64-bit Service Pack 1  (build 7601)
| Command      : report_timing -from a7_phy_rx_d* -delay_type max
| Design       : elog_a7_top
| Device       : 7a200ti-fbv676
| Speed File   : -1L  PRODUCTION 1.23 2018-06-13
------------------------------------------------------------------------------------

Timing Report

Slack (MET) :             2.604ns  (required time - arrival time)
  Source:                 a7_phy_rx_d_i[1]
                            (input port clocked by ob_phy_rx_clk  {rise@2.000ns fall@6.000ns period=8.000ns})
  Destination:            ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in/D
                            (rising edge-triggered cell IDDR clocked by ob_phy_rx_clk  {rise@2.000ns fall@6.000ns period=8.000ns})
  Path Group:             ob_phy_rx_clk
  Path Type:              Setup (Max at Fast Process Corner)
  Requirement:            4.000ns  (ob_phy_rx_clk rise@10.000ns - ob_phy_rx_clk fall@6.000ns)
  Data Path Delay:        3.478ns  (logic 3.478ns (100.000%)  route 0.000ns (0.000%))
  Logic Levels:           2  (IBUF=1 IDELAYE2=1)
  Input Delay:            0.000ns
  Clock Path Skew:        2.120ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    2.120ns = ( 12.120 - 10.000 ) 
    Source Clock Delay      (SCD):    0.000ns = ( 6.000 - 6.000 ) 
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock ob_phy_rx_clk fall edge)
                                                      6.000     6.000 f  
                         input delay                  0.000     6.000    
    V1                                                0.000     6.000 r  a7_phy_rx_d_i[1] (IN)
                         net (fo=0)                   0.000     6.000    a7_phy_rx_d_i[1]
    V1                   IBUF (Prop_ibuf_I_O)         0.460     6.460 r  a7_phy_rx_d_i_IBUF[1]_inst/O
                         net (fo=1, routed)           0.000     6.460    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_d_i_IBUF[1]
    IDELAY_X1Y98         IDELAYE2 (Prop_idelaye2_IDATAIN_DATAOUT)
                                                      3.017     9.478 r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/idel.rxd_gen[1].IDELAYE2_inst/DATAOUT
                         net (fo=1, routed)           0.000     9.478    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rxd_delayed_1
    ILOGIC_X1Y98         IDDR                                         r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in/D
  -------------------------------------------------------------------    -------------------

                         (clock ob_phy_rx_clk rise edge)
                                                     10.000    10.000 r  
    W1                                                0.000    10.000 r  a7_phy_rx_clk_i (IN)
                         net (fo=0)                   0.000    10.000    a7_phy_rx_clk_i
    W1                   IBUF (Prop_ibuf_I_O)         0.284    10.284 r  a7_phy_rx_clk_i_IBUF_inst/O
                         net (fo=2, routed)           0.792    11.077    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_clk_i_IBUF
    BUFMRCE_X1Y3         BUFMR (Prop_bufmr_I_O)       0.033    11.110 r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/bufmr_rgmii_rx_clk/O
                         net (fo=2, routed)           0.429    11.539    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rxc_bufmr_out
    BUFIO_X1Y5           BUFIO (Prop_bufio_I_O)       0.483    12.022 r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/bufio_rgmii_rx_clk/O
                         net (fo=2, routed)           0.098    12.120    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rxc_bufr_out
    ILOGIC_X1Y98         IDDR                                         r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in/C
                         clock pessimism              0.000    12.120    
                         clock uncertainty           -0.035    12.084    
    ILOGIC_X1Y98         IDDR (Setup_iddr_C_D)       -0.002    12.082    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in
  -------------------------------------------------------------------
                         required time                         12.082    
                         arrival time                          -9.478    
  -------------------------------------------------------------------
                         slack                                  2.604    

 

Just for the sake of completeness: RGMII i/f is source-synchronous double-data-rate & RX_CLK = 125 MHz.

Thanks in advance!

0 Kudos
9 Replies
Historian
Historian
1,215 Views
Registered: ‎01-23-2009

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Considering the 8/2 = 4 ns period of data signals, this 5 ns variation is a deal-breaker, right? 

I would say so...

Can this be fixed somehow, for instance using IDELAYs on the data lines, in order to equalize the delay amount?

I would doubt it. The IDELAY is PVT compensated, so, as you have seen, adding it actually reduces the PVT variation on the data path (1.5-0.5 for no IDELAY vs. 4.3-3.5 with IDELAY). As a result, the skew between clock and data across PVT between slow and fast actually gets worse...

But even with what you are saying, your clocking is odd... Is the RX_CLK on a non-clock capable I/O or is it on a clock capable I/O but in a different bank. You are showing clocking that goes from the IBUF to the BUFMR to the BUFIO/BUFR - why? This makes some sense if the clock is on a clock capable I/O (CCIO) in the wrong bank, but even so, the BUFMR adds so much delay that I doubt you can make this interface work.

If the clock is on a non-clock capable I/O, then going to the BUFMR is probably the wrong thing to do. You physically cannot go from a non clock-capable I/O directly to the BUFIO/BUFR (there is no such connection) - I don't specifically know if there is or isn't a path from general fabric routing to the BUFMR. If you are using the BUFMR because there is such a connection, I would contemplate other methods.

If the clock is truly on a non-clock capable I/O, then you are already paying the penalty for this - paying the additional penalty of going to the BUFMR is probably just making this worse. Your may get better results by going to an MMCM and a BUFG (instead of the BUFIO/BUFR) - the BUFG can clock the IDDR directly. Done this way, part of the clock insertion will be PVT compensated, but the portion of the path from the non-CCIO will not; this may give better results (or it may not). Even if it is better, it may not be "enough better"...

Ultimately, though, this may be a deal breaker. At 125MHz DDR, this interface isn't particularly difficult to manage when done in one of a number of legal methods, but with the clock on a non-CCIO, it is possible that you simply don't have a viable static design. If so, the only options are

  • respin your board
  • try a dynamic phase adjustment approach - take a look at this post (and others) that highlight some of the problems with dynamic phase adjust (or dynamic calibration) approaches.

Avrum

0 Kudos
Voyager
Voyager
1,192 Views
Registered: ‎02-01-2013

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Incidentally, what IP is your RGMII interface associated with: a TEMAC or a GMII-to-RGMII converter? I don't have 18.3 installed on a system yet, but as of 18.2, the TEMAC still did not offer the option to include (or not to include) RGMII clock delays in the MAC. The delays are included in that IP by default, so they should not also be included in PCB routing, or in the PHY.

I find that it's preferable to insert RGMII clock delays in the PHY.  If you include them in the FPGA, the addition of the IDELAY and ODELAY components adds uncertainty to the pathways, which closes the timing eye. A wider eye is a happier eye. The GMII-to-RGMII converter allows you to go that route; the TEMAC doesn't.

Also: The best way to assess RGMII timing is to look at the Datasheet Report (Implemented Design -> Report Timing Summary -> [Options] Report Datasheet). The Tx and Rx signals should comply with the RGMII spec: inputs should require no more than 1.0 nS set-up and hold with respect to RXC, and outputs should all launch within +/-0.5 nS each other. That's a much more straightforward way to see your margins (positive or negative) than trying to understand the Timing Analyzer output.

-Joe G.

 

0 Kudos
Explorer
Explorer
1,082 Views
Registered: ‎01-02-2012

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Hi @avrumw

thank you very much for the detailed reply.
RXD & RX_CTL signals are divided into 2 adjacent banks. That's why BUFMR is used to drive BUFIOs. Moreover, BUFMR can be driven from general fabric routing. Next BUFG is simply too far away: Using BUFG dramatically worsens the case here. 
I have found a trick for a small improvement: Using IDELAYs with 0 tap value: In that case they introduce a bit longer delays at the slow corner.

However, one thing I still do not understand: 
Setting the PHY (TI DP83867), so that it outputs the RX_CLK center-aligned (with 2 ns delay) and using no IDELAYs (@FAST/SLOW corner analysis => FPGA-internal clock path delay = ~2/7 ns & data path delay = ~0.5/1.5 ns; ), the interface seems to work stable at least at room temperature with over ~10 devices. Center-aligned RX_CLK would compensate a theoretical skew of -2 to +2...?
So, I assume the room-temp condition is close to fast corner case and ~1.5 ns skew (2 - 0.5 ns) is tolerated...? 
If I add the IDELAYs with tap value 31, it stops working. Although the skew range becomes even more close to the -2 to +2 range (2 - 3.5 = -1.5 ns & 7 - 4.3 = 2.7 ns). Where is my mistake?

Below is the XDC:

############################################################
# For Setup and Hold time analysis on RGMII inputs         #
############################################################ 
# Receiver clock period constraints
set ob_phy_rx_clk [get_clocks -of [get_ports a7_phy_rx_clk_i]]

# Define a virtual clock to simplify the timing constraints
create_clock   -name [current_instance .]_ob_phy_rgmii_rxc -period 8
set ob_phy_rgmii_rxc [current_instance .]_ob_phy_rgmii_rxc 

set_false_path -rise_from [get_clocks $ob_phy_rgmii_rxc] -fall_to $ob_phy_rx_clk -setup
set_false_path -fall_from [get_clocks $ob_phy_rgmii_rxc] -rise_to $ob_phy_rx_clk -setup
set_false_path -rise_from [get_clocks $ob_phy_rgmii_rxc] -rise_to $ob_phy_rx_clk -hold
set_false_path -fall_from [get_clocks $ob_phy_rgmii_rxc] -fall_to $ob_phy_rx_clk -hold
set_multicycle_path -from [get_clocks $ob_phy_rgmii_rxc] -to      $ob_phy_rx_clk -setup  0
set_multicycle_path -from [get_clocks $ob_phy_rgmii_rxc] -to      $ob_phy_rx_clk -hold  -1

## The values below are not achievable: Hold violation @Slow-Corner is INEVITABLE
#set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -max -1.50 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}]
#set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -max -1.50 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}] -clock_fall -add_delay
#set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -min -2.50 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}]
#set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -min -2.50 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}] -clock_fall -add_delay

## Specify the input delays  
set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -max  1.30 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}]
set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -max  1.30 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}] -clock_fall -add_delay
set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -min  0.85 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}]
set_input_delay -clock [get_clocks $ob_phy_rgmii_rxc] -min  0.85 [get_ports {a7_phy_rx_d_i[*] a7_phy_rx_dv_i}] -clock_fall -add_delay

Due to 2 ns delayed RX_CLK, data lines require input delays of max. -1.5 and min. -2.5 ns for defining a proper 1 ns transition window. But, my small data transition window (using IDELAYs with tap value 0, the trick mentioned above) is after the clock edge, max. 1.3 and min. 0.85 ns. So, the rgmii2gmii conversion should not work properly according to my understanding: At least the rising edge and falling edge samples must be swapped, right? How can this work?

report_timing -from a7_phy_rx_d* -delay_type min
INFO: [Vivado 12-2286] Implicit search of objects for pattern 'a7_phy_rx_d*' matched to 'port' objects.
Resolution: To avoid ambiguous patterns, provide proper objects using get commands e.g. [get_nets xyz].
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -1L, Delay Type: min.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 2 CPUs
INFO: [Timing 38-78] ReportTimingParams: -from_pins  -max_paths 1 -nworst 1 -delay_type min -sort_by slack.
WARNING: [Timing 38-164] This design has multiple clocks. Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path.
Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2018.3 (win64) Build 2405991 Thu Dec  6 23:38:27 MST 2018
| Date         : Fri Jan  4 11:27:09 2019
| Host         : PC-001-80-1 running 64-bit Service Pack 1  (build 7601)
| Command      : report_timing -from a7_phy_rx_d* -delay_type min
| Design       : elog_a7_top
| Device       : 7a200ti-fbv676
| Speed File   : -1L  PRODUCTION 1.23 2018-06-13
------------------------------------------------------------------------------------

Timing Report

Slack (MET) :             0.003ns  (arrival time - required time)
  Source:                 a7_phy_rx_dv_i
                            (input port clocked by _ob_phy_rgmii_rxc  {rise@0.000ns fall@4.000ns period=8.000ns})
  Destination:            ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rx_ctl_in/D
                            (rising edge-triggered cell IDDR clocked by ob_phy_rx_clk  {rise@0.000ns fall@4.000ns period=8.000ns})
  Path Group:             ob_phy_rx_clk
  Path Type:              Hold (Min at Slow Process Corner)
  Requirement:            -4.000ns  (ob_phy_rx_clk fall@-4.000ns - _ob_phy_rgmii_rxc rise@0.000ns)
  Data Path Delay:        2.189ns  (logic 2.189ns (100.000%)  route 0.000ns (0.000%))
  Logic Levels:           2  (IBUF=1 IDELAYE2=1)
  Input Delay:            0.850ns
  Clock Path Skew:        6.821ns (DCD - SCD - CPR)
    Destination Clock Delay (DCD):    6.821ns = ( 10.821 - 4.000 ) 
    Source Clock Delay      (SCD):    0.000ns = ( 8.000 - 8.000 ) 
    Clock Pessimism Removal (CPR):    -0.000ns
  Clock Uncertainty:      0.025ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.050ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns
  Timing Exception:       MultiCycle Path   Setup -end   0    Hold  -start -1  
  Clock Domain Crossing:  Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path.

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock _ob_phy_rgmii_rxc rise edge)
                                                      0.000     0.000 r  
                         ideal clock network latency
                                                      0.000     0.000    
                         input delay                  0.850     0.850    
    R1                                                0.000     0.850 r  a7_phy_rx_dv_i (IN)
                         net (fo=0)                   0.000     0.850    a7_phy_rx_dv_i
    R1                   IBUF (Prop_ibuf_I_O)         1.434     2.284 r  a7_phy_rx_dv_i_IBUF_inst/O
                         net (fo=1, routed)           0.000     2.284    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_dv_i_IBUF
    IDELAY_X1Y120        IDELAYE2 (Prop_idelaye2_IDATAIN_DATAOUT)
                                                      0.755     3.039 r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/idel_ctl.obm_idel_inst/DATAOUT
                         net (fo=1, routed)           0.000     3.039    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/D_0
    ILOGIC_X1Y120        IDDR                                         r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rx_ctl_in/D
  -------------------------------------------------------------------    -------------------

                         (clock ob_phy_rx_clk fall edge)
                                                     -4.000    -4.000 f  
    W1                                                0.000    -4.000 f  a7_phy_rx_clk_i (IN)
                         net (fo=0)                   0.000    -4.000    a7_phy_rx_clk_i
    W1                   IBUF (Prop_ibuf_I_O)         1.517    -2.483 f  a7_phy_rx_clk_i_IBUF_inst/O
                         net (fo=3, routed)           2.059    -0.424    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_clk_i_IBUF
    BUFMRCE_X1Y2         BUFMR (Prop_bufmr_I_O)       0.103    -0.321 f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rxc_routing.bufmr2_rgmii_rx_clk/O
                         net (fo=1, routed)           1.292     0.971    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rxc_bufmr_out2
    BUFIO_X1Y9           BUFIO (Prop_bufio_I_O)       1.532     2.503 f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rxc_routing.bufio2_rgmii_rx_clk/O
                         net (fo=3, routed)           0.317     2.821    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/C
    ILOGIC_X1Y120        IDDR                                         f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rx_ctl_in/C
                         clock pessimism              0.000     2.821    
                         clock uncertainty            0.025     2.846    
    ILOGIC_X1Y120        IDDR (Hold_iddr_C_D)         0.191     3.037    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rx_ctl_in
  -------------------------------------------------------------------
                         required time                         -3.037    
                         arrival time                           3.039    
  -------------------------------------------------------------------
                         slack                                  0.003    




report_timing: Time (s): cpu = 00:01:15 ; elapsed = 00:00:40 . Memory (MB): peak = 5162.141 ; gain = 0.000
report_timing -from a7_phy_rx_d* -delay_type max
INFO: [Vivado 12-2286] Implicit search of objects for pattern 'a7_phy_rx_d*' matched to 'port' objects.
Resolution: To avoid ambiguous patterns, provide proper objects using get commands e.g. [get_nets xyz].
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -1L, Delay Type: max.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 2 CPUs
INFO: [Timing 38-78] ReportTimingParams: -from_pins  -max_paths 1 -nworst 1 -delay_type max -sort_by slack.
WARNING: [Timing 38-164] This design has multiple clocks. Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path.
Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2018.3 (win64) Build 2405991 Thu Dec  6 23:38:27 MST 2018
| Date         : Fri Jan  4 11:27:47 2019
| Host         : PC-001-80-1 running 64-bit Service Pack 1  (build 7601)
| Command      : report_timing -from a7_phy_rx_d* -delay_type max
| Design       : elog_a7_top
| Device       : 7a200ti-fbv676
| Speed File   : -1L  PRODUCTION 1.23 2018-06-13
------------------------------------------------------------------------------------

Timing Report

Slack (MET) :             0.027ns  (required time - arrival time)
  Source:                 a7_phy_rx_d_i[1]
                            (input port clocked by _ob_phy_rgmii_rxc  {rise@0.000ns fall@4.000ns period=8.000ns})
  Destination:            ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in/D
                            (rising edge-triggered cell IDDR clocked by ob_phy_rx_clk  {rise@0.000ns fall@4.000ns period=8.000ns})
  Path Group:             ob_phy_rx_clk
  Path Type:              Setup (Max at Fast Process Corner)
  Requirement:            0.000ns  (ob_phy_rx_clk fall@4.000ns - _ob_phy_rgmii_rxc fall@4.000ns)
  Data Path Delay:        0.765ns  (logic 0.765ns (100.000%)  route 0.000ns (0.000%))
  Logic Levels:           2  (IBUF=1 IDELAYE2=1)
  Input Delay:            1.300ns
  Clock Path Skew:        2.120ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    2.120ns = ( 14.120 - 12.000 ) 
    Source Clock Delay      (SCD):    0.000ns = ( 4.000 - 4.000 ) 
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.025ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.050ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns
  Timing Exception:       MultiCycle Path   Setup -end   0    
  Clock Domain Crossing:  Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path.

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock _ob_phy_rgmii_rxc fall edge)
                                                      4.000     4.000 f  
                         ideal clock network latency
                                                      0.000     4.000    
                         input delay                  1.300     5.300    
    V1                                                0.000     5.300 r  a7_phy_rx_d_i[1] (IN)
                         net (fo=0)                   0.000     5.300    a7_phy_rx_d_i[1]
    V1                   IBUF (Prop_ibuf_I_O)         0.460     5.760 r  a7_phy_rx_d_i_IBUF[1]_inst/O
                         net (fo=1, routed)           0.000     5.760    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_d_i_IBUF[1]
    IDELAY_X1Y98         IDELAYE2 (Prop_idelaye2_IDATAIN_DATAOUT)
                                                      0.305     6.065 r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/idel.rxd_gen[1].obm_idel_inst/DATAOUT
                         net (fo=1, routed)           0.000     6.065    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rxd_delayed_1
    ILOGIC_X1Y98         IDDR                                         r  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in/D
  -------------------------------------------------------------------    -------------------

                         (clock ob_phy_rx_clk fall edge)
                                                      4.000     4.000 f  
    W1                                                0.000     4.000 f  a7_phy_rx_clk_i (IN)
                         net (fo=0)                   0.000     4.000    a7_phy_rx_clk_i
    W1                   IBUF (Prop_ibuf_I_O)         0.284     4.284 f  a7_phy_rx_clk_i_IBUF_inst/O
                         net (fo=3, routed)           0.792     5.077    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/a7_phy_rx_clk_i_IBUF
    BUFMRCE_X1Y3         BUFMR (Prop_bufmr_I_O)       0.033     5.110 f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rxc_routing.bufmr_rgmii_rx_clk/O
                         net (fo=1, routed)           0.429     5.539    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rxc_bufmr_out
    BUFIO_X1Y5           BUFIO (Prop_bufio_I_O)       0.483     6.022 f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rxc_routing.bufio_rgmii_rx_clk/O
                         net (fo=2, routed)           0.098     6.120    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rgmii_rxc_bufr_out
    ILOGIC_X1Y98         IDDR                                         f  ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in/C
                         clock pessimism              0.000     6.120    
                         clock uncertainty           -0.025     6.095    
    ILOGIC_X1Y98         IDDR (Setup_iddr_C_D)       -0.002     6.093    ob_mac_inst/gmii2rgmii_wrap_inst/gmii2rgmii_inst/rx_data_01[1].rgmii_rx_data_in
  -------------------------------------------------------------------
                         required time                          6.093    
                         arrival time                          -6.065    
  -------------------------------------------------------------------
                         slack                                  0.027    

 

 

0 Kudos
Explorer
Explorer
1,081 Views
Registered: ‎01-02-2012

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Hi @jg_bds,

thanks for the reply! We are doing the rgmii2gmii conversion outside of the MAC, Xilinx TEMAC is configured to have internal interface which is as you might know GMII-like.

And, as you suggest we are trying to use the clock delay feature of the PHY IC (TI DP83867), which is really nice: Configureable in 0.25 ns steps from 0 to 4 ns. However, I think, a range from -2 to to +2 ns would be more useful...  

0 Kudos
Voyager
Voyager
1,067 Views
Registered: ‎02-01-2013

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

You didn't post the timing report's Datasheet numbers for this interface. I find them to be the best way to assess your hope of getting the interface working. Adjusting the IDELAY values inside the GMII-to-RGMII IP will change the Datasheet numbers. You'll want to adjust them so they comport with the timing expectations of your PHY.

RGMII wants the clock to be delayed--not advanced--since those source-synchronous interfaces originally only launched data and clock at the same time.  Skew was expected to be introduced using routing, which removed the need to do so in the PHY, allowing extremely low-cost PHYs. Today's PHYs usually include clock-delay features, which help in situations like this. 

Between the ~1.5-ns delay you can introduce in the FPGA, and the 4-nS delay from the PHY, you should be able to find a sweet spot.

-Joe G.

 

0 Kudos
Explorer
Explorer
1,059 Views
Registered: ‎01-02-2012

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Hi @jg_bds,

input_setup_hold.PNG

The figures above are using IDELAY tap value = 0 and the XDC given previous post (min 0.85 ns & max 1.30 ns) the interface works at least at room temp.

The figures below are using IDELAY tap value = 31 and the interface does not work at all. In both cases the PHY has 2 ns delay on RX_CLK.

  input_setup_hold2.PNG

0 Kudos
Voyager
Voyager
1,046 Views
Registered: ‎02-01-2013

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Yeah, that's a problem...  In the former case, the interface requires a 3.5-nS valid window--not a whole lot of margin, but there is some. The latter case shows a requirement of a valid window that's greater than 4 nS. That ain't do-able.

Factor-in the PHY variances, and even the former design doesn't work on paper--even though it can/does work nominally. You'll need a re-design, with re-assignments of the RX clock and other interface pins that comply with appropriate Select IO byte-group rules.

An ambitious alternative would be to design a GMII-to-RGMII shim yourself, without the IODELAYs. I don't think there's a way to eliminate the delays from the Xilinx IP: even with the delay values set to 0, the delay blocks introduce uncertainty that leads to an increased valid-window requirement. There's no guarantee that a DIY IP will shrink the requirement to a workable number, but it's the only alternative to a re-spin that I can think of.

-Joe G.

 

0 Kudos
Explorer
Explorer
1,038 Views
Registered: ‎01-02-2012

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

Hi @jg_bds & @avrumw,
we are doing the RGMII to GMII conversion already outside of the MAC. IDELAYs with tap value 0 is better than no IDELAYs (actually it brings the ~0.5ns margin from the first case, no IDELAYs = almost no margin).
According to my understanding allowed ~0.5 ns transition window for the first case is after the RX_CLK edge from ~0.85 ns to ~1.3 ns and 2 ns delayed RX_CLK would require a transition window before the RX_CLK edge from ~ -2.25 ns to ~ -1.75 ns
How does the first case work?

0 Kudos
Highlighted
Voyager
Voyager
1,028 Views
Registered: ‎02-01-2013

Re: RGMII timing closure with RX_CLK being CLOCK_DEDICATED_ROUTE *FALSE*

It's really hard to explain why a 'bad' design works...

Obviously, the signals from the PHY aren't stable for the entire 3.5-nS window required by the FPGA. But complying with the window is required in order to guarantee operation in all chips, at all times, and at all voltages and temperatures. 

Failure to comply with timing rules does not prohibit operation at all times.

All we can tell from the timing information is that the FPGA won't be sampling the data during the ~0.8-nS to ~1.3-nS window after the clock arrives. It's sampling it at some other time--and based on your anecdotal observations of 'working-ness', the signals are sufficiently valid during the precise moment that this chip is sampling them at this voltage and this temperature. 

-Joe G.