cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
shrsmas0
Visitor
Visitor
468 Views
Registered: ‎09-06-2018

Hold Time Violation on AXI 1G/2.5G Ethernet Subsystem with RGMII Interface

Vivado 2020.2 reports the hold time violations between the RGMII RX PADs and the IDELAY2/IDDRs on an XQ7Z045RF900-1Q FPGA. This is due to the virtual clock constraints from the AXI 1G/2.5G Ethernet Subsystem core. Is there any way to get rid of the critical warnings?

timing.png

device.png

Thanks.

Tags (3)
0 Kudos
9 Replies
nanz
Moderator
Moderator
395 Views
Registered: ‎08-25-2009

Hi @shrsmas0 ,

Is this issue reproducible with the example design? Can you please check what the paths are like in our example design and do a comparison? 

Please attach the .xci file to reproduce the issue if it can be reproduced. 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
shrsmas0
Visitor
Visitor
358 Views
Registered: ‎09-06-2018

Hi Nanz,

The default example design doesn't have this issue since the locations of RGMII RX pins are not constrained. It seems that the placer can pick any IOB at its convenience to avoid this problem. However, once I added the 5 RX pin location constraints to the reference design, then the hold time violations are produced by the reference design exactly the same as those in my design.

In my design, I implemented 4 RGMII cores and every one of them has hold time violations on RX PADS. I constrained the example design using the followings which are copied from one of the cores in my design and got the exact hold time violations. I believe I will get the same results using pin locations from any of the other 3 cores but I didn't try. Again, the FPGA part is XQ7Z045RF900-1Q

set_property PACKAGE_PIN D15 [get_ports rgmii_rxc ]
set_property PACKAGE_PIN F17 [get_ports rgmii_txc ]
set_property PACKAGE_PIN E17 [get_ports rgmii_txd[0] ]
set_property PACKAGE_PIN D16 [get_ports rgmii_txd[1] ]
set_property PACKAGE_PIN C16 [get_ports rgmii_txd[2] ]
set_property PACKAGE_PIN C17 [get_ports rgmii_txd[3] ]
set_property PACKAGE_PIN B16 [get_ports rgmii_tx_ctl ]
set_property PACKAGE_PIN B17 [get_ports rgmii_rxd[0] ]
set_property PACKAGE_PIN A17 [get_ports rgmii_rxd[1] ]
set_property PACKAGE_PIN C14 [get_ports rgmii_rxd[2] ]
set_property PACKAGE_PIN C13 [get_ports rgmii_rxd[3] ]
set_property PACKAGE_PIN C12 [get_ports rgmii_rx_ctl ]

0 Kudos
dpaul24
Scholar
Scholar
337 Views
Registered: ‎08-07-2014

@shrsmas0 ,

Whenever possible use clock capable IO pins for rgmii_rxc and rgmii_txc.

But there can be situations where clock capable pins are not available. In that case normal IO pins would also work. But there there would be delays in the clock paths, both rx and tx. In such as cases, for keeping the rgmii_rxd and rgmii_txd aligned with their respective clocks, you can either introduce I/ODELAY primitives in the data path (set to the proper delay tap value) or in the xdc file use set_input_delay/set_output_delay commands. In depth analysis of the failing paths are required to calculate the desired delays.

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

0 Kudos
shrsmas0
Visitor
Visitor
318 Views
Registered: ‎09-06-2018

@dpaul24 

Pin D15 is a clock dedicated pin (SRCC). The hold violation happens only on the virtual clock domain defined on the pin rgmii_rxc by the core. 

create_clock -name [current_instance .]_rgmii_rx_clk -period 8
set rgmii_rx_clk [current_instance .]_rgmii_rx_clk

set_input_delay -clock [get_clocks $rgmii_rx_clk] -max -1.5 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -min -2.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

 

The above input delays can't be relaxed since they are required to reliably capture rx_ctl and rxd by rxc. The difference between the default example design and my design is that the IBUF delays on all rx_ctl and rxd pins in all 4 cores are smaller comparing to those in the example design. Although the file bd_9d5e_mac_0_rgmii_v2_0_if.vdh mentioned that 'Please modify the IODELAY_VALUE according to your design' on the idelay2 on rx_ctl and rxd, but there's no exposed interface for me to do that. 

-- Please modify the IODELAY_VALUE according to your design.
-- For more information on IDELAYCTRL and IODELAY, please refer to
-- the User Guide.
delay_rgmii_rx_ctl : IDELAYE2
generic map (
IDELAY_TYPE => "FIXED"
)
port map (
IDATAIN => rgmii_rx_ctl_ibuf,
DATAOUT => rgmii_rx_ctl_delay,
DATAIN => '0',
C => '0',
CE => '0',
INC => '0',
CINVCTRL => '0',
CNTVALUEIN => "00000",
CNTVALUEOUT => open,
LD => '0',
LDPIPEEN => '0',
REGRST => '0'
);

The IBUF delays on the rx_ctl and rxd pins picked by the example design have range 0.714~0.725ns, but the delay range is 0.598~0.618ns on all 20 rx pins (rx_ctl and rxd[3:0] on all 4 cores) in my design. The IBUF delay difference is the reason that causes hold violation on my design.

 

 

0 Kudos
dpaul24
Scholar
Scholar
285 Views
Registered: ‎08-07-2014

@shrsmas0 ,

Although the file bd_9d5e_mac_0_rgmii_v2_0_if.vdh mentioned that 'Please modify the IODELAY_VALUE according to your design' on the idelay2 on rx_ctl and rxd, but there's no exposed interface for me to do that. 

I know. It is for this reason that in our 24 core RGMII based Eth design, we used the MAC IP core with GMII i/f but wrote our own GMII<-->RGMII i/f.

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

0 Kudos
nanz
Moderator
Moderator
195 Views
Registered: ‎08-25-2009

HI @shrsmas0 ,

Have you solved the issue or made any progress?

Please update the thread with the "accepted solution" when you have the chance, so it will also benefit other forum users. Thank you!


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
jxiris
Observer
Observer
174 Views
Registered: ‎04-25-2009

Hi @nanz ,

We are having exactly the same problem as @shrsmas0 .  If I am reading this thread correctly, the AXI 1G/2.5G Ethernet Subsystem core example works without timing violations because it can pick IOB assignments to satisfy its virtual clock constraints.  @shrsmas0 has also shown that the example design has the critical timing issues if location IOB constraints are created.

We have specific IOB constraints based on our PCB layout.  The RGMII rxc clock in our case is assigned to a SRCC pin.  The remaining RGMII rx ports are all in the same I/O bank.  Adjusting the timing constraints has no effect.

It seems like we need a way to adjust the IODELAY_VALUE on the rxctrl and rxd ports associated with the rxc clock.  We are using a block design in Vivado and there is no exposed interface to make these changes.

How do we resolve these critical warnings?

Thanks for your assistance.

 

 

0 Kudos
tom.hilgerdenaar
Observer
Observer
118 Views
Registered: ‎10-19-2017

Hello,

Could you please respond to jxiris?  I am the FAE covering his account and this is an important issue for him to resolve.

Thank you,

Tom Hilgerdenaar

Xilinx DFAE

Avnet

0 Kudos
nanz
Moderator
Moderator
88 Views
Registered: ‎08-25-2009

Hi @jxiris , 

Could you please post your question with a new thread and upload your xci and modified constraints and the exact critical warnings? 

Good practice on the forum is to freshly start a new topic but not follow up on a no solution accepted thread. You will have a higher chance for your issues to be seen and helped in this way. 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos