cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
4,573 Views
Registered: ‎11-08-2016

intra-clock setup violation with large route delay

Jump to solution

Hi,

 

In my design the following path fails timing:

 

Even though there is nothing on the path and I defined the pblock closest to the IO pin, still it has 10.252ns (91.899%) route delay, which I don't understand where it comes from, also I can't pipeline the path because of requirements of my design.

 

Can someone help, please?

 

Constraints:

create_clock -period 5.000 -name {A1_RxClk_clk_p[0]} [get_ports {A1_RxClk_clk_p[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -min -add_delay 1.000 [get_ports {A1_RxDF_clk_n[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -max -add_delay 4.000 [get_ports {A1_RxDF_clk_n[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -min -add_delay 1.000 [get_ports {A1_RxDF_clk_p[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -max -add_delay 4.000 [get_ports {A1_RxDF_clk_p[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -min -add_delay 1.000 [get_ports {A1_RxDR_clk_n[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -max -add_delay 4.000 [get_ports {A1_RxDR_clk_n[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -min -add_delay 1.000 [get_ports {A1_RxDR_clk_p[0]}]
set_input_delay -clock [get_clocks {A1_RxClk_clk_p[0]}] -max -add_delay 4.000 [get_ports {A1_RxDR_clk_p[0]}]

 

Device View:

Device View

Schematic:

Schematic.JPG

Timing report:

Timing report 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
7,204 Views
Registered: ‎01-23-2009

The large amount of routing delay on that net is there because the tools were asked to put a large amount of routing delay on that path...

 

For any path, there is a setup requirement and a hold requirement. When the two cannot be satisfied simultaneously, the tool focuses on hold time violations - on the assumption that something that fails a setup check may still run at a lower frequency, but something that fails a hold time check won't work at any frequency.

 

So you need to look at the hold time check on this path, but it is clear that it is going to fail.

 

You are using the worst clocking structure to capture an input interface - a (presumably clock capable) I/O directly to a BUFG. When you do this, you have a huge clock insertion delay. At the slow process corner, this is 6.6ns (the destination clock arrives at the pin 5.00ns and makes it to the flip-flop around 11.6ns (it will actually be a bit worse for a hold check).

 

Your set_input_delay -min is 1ns, so the data will go away 1ns after the rising edge of the clock at the pin. But the clock at the capture flip-flop won't arrive until 6.7ns after the clock at the pin. Thus the tools must have at least 5.7ns of delay on the data signal coming from the pad to the flip-flop. Part of this is the IBUF delay, but the rest is added through immense routing between the pad and the flip-flop. Turn on the "Routing Resources" view in the die view, and you will see that this signal is routed FAR FAR away before coming back to the flip-flop doing the capture.

 

So, you need to fix your clocking structure to something much more reasonable - maybe use an MMCM or use the BUFIO/BUFR clocking.

 

But, this is VERY challenging timing. Your clock period is 5ns, but the difference between your min and max data delay is 3ns - thus the data is only valid and stable for 2ns. A 2ns valid window is very difficult to capture. Certainly the IBUFG->BUFG doesn't even come close.

 

Even with IBUFG -> MMCM -> BUFG, the required window is likely significantly larger than 2ns (you don't tell us what device or what speed grade you are using, but even in the smallest [hence fastest] Kintex-7 in a -3 speed grade the data sheet says it needs Tpsmmcm/Tphmmcm = 2.83/-0.29, which is a window of 2.6ns - much bigger than the 2ns you have available). (See the Datasheet for your device - i.e. DS182 for Kintex-7)

 

ChipSync clocking (using the BUFIO and BUFR) has a chance, with Tpscs/Tphcs = -0.36/1.36 for a required window of 1.0ns, but you will need more if you need to use the IDELAY to adjust the timing. Furthermore your board must have the clock and data in the same bank for this to work, and working with BUFR clocks can be complicated if you need to work with data from this interface throughout your design.

 

Finally, an interface like this should be captured in the IOB flip-flops, not a fabric flip-flop. If you forced the FF into the IOB you would have clearly seen the setup and hold timing without the tool mucking things up with huge routing delays.

 

Avrum

View solution in original post

2 Replies
avrumw
Guide
Guide
7,205 Views
Registered: ‎01-23-2009

The large amount of routing delay on that net is there because the tools were asked to put a large amount of routing delay on that path...

 

For any path, there is a setup requirement and a hold requirement. When the two cannot be satisfied simultaneously, the tool focuses on hold time violations - on the assumption that something that fails a setup check may still run at a lower frequency, but something that fails a hold time check won't work at any frequency.

 

So you need to look at the hold time check on this path, but it is clear that it is going to fail.

 

You are using the worst clocking structure to capture an input interface - a (presumably clock capable) I/O directly to a BUFG. When you do this, you have a huge clock insertion delay. At the slow process corner, this is 6.6ns (the destination clock arrives at the pin 5.00ns and makes it to the flip-flop around 11.6ns (it will actually be a bit worse for a hold check).

 

Your set_input_delay -min is 1ns, so the data will go away 1ns after the rising edge of the clock at the pin. But the clock at the capture flip-flop won't arrive until 6.7ns after the clock at the pin. Thus the tools must have at least 5.7ns of delay on the data signal coming from the pad to the flip-flop. Part of this is the IBUF delay, but the rest is added through immense routing between the pad and the flip-flop. Turn on the "Routing Resources" view in the die view, and you will see that this signal is routed FAR FAR away before coming back to the flip-flop doing the capture.

 

So, you need to fix your clocking structure to something much more reasonable - maybe use an MMCM or use the BUFIO/BUFR clocking.

 

But, this is VERY challenging timing. Your clock period is 5ns, but the difference between your min and max data delay is 3ns - thus the data is only valid and stable for 2ns. A 2ns valid window is very difficult to capture. Certainly the IBUFG->BUFG doesn't even come close.

 

Even with IBUFG -> MMCM -> BUFG, the required window is likely significantly larger than 2ns (you don't tell us what device or what speed grade you are using, but even in the smallest [hence fastest] Kintex-7 in a -3 speed grade the data sheet says it needs Tpsmmcm/Tphmmcm = 2.83/-0.29, which is a window of 2.6ns - much bigger than the 2ns you have available). (See the Datasheet for your device - i.e. DS182 for Kintex-7)

 

ChipSync clocking (using the BUFIO and BUFR) has a chance, with Tpscs/Tphcs = -0.36/1.36 for a required window of 1.0ns, but you will need more if you need to use the IDELAY to adjust the timing. Furthermore your board must have the clock and data in the same bank for this to work, and working with BUFR clocks can be complicated if you need to work with data from this interface throughout your design.

 

Finally, an interface like this should be captured in the IOB flip-flops, not a fabric flip-flop. If you forced the FF into the IOB you would have clearly seen the setup and hold timing without the tool mucking things up with huge routing delays.

 

Avrum

View solution in original post

4,406 Views
Registered: ‎11-08-2016

Thanks Avrum,

 

Very helpful information, my problem was another BUFG was being instantiated automatically inside the core that had the target flipflop and for some reason Vivado was not showing it on the path in schematic view, after removing that extra BUFG, everything passed.

 

But I learned a lot from your response.

0 Kudos