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: 
Observer dpikul
Observer
635 Views
Registered: ‎05-10-2018

Timing Failure when Total Delay less than Requirement

Jump to solution

I have a confusion with timing that I need some light shed on.

MANY of my intra clock paths are failing timing despite the total delay being well within the requirement.

This occurs on many paths interacting with built in FIFO IP, in this case a built in synchronous FIFO, but only occasionally on builds, most of the time there are no timing issues whatsoever.

In the images, you can see it being computed as 4.959ns for the required time. I guess I'm just confused as to why the required time for this path is larger than the clock period of 3.2ns, and if the total delay is well under the clock period, why is it still failing? How can I resolve this permanantly so I dont waste build times, since this only happens about 25% of the time?

If I'm fundamentally misunderstanding something, I really appreciate the help!

Thanks

timing failure.PNG
slack.PNG
paths.PNG
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
469 Views
Registered: ‎07-16-2008

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

2.900 = 0.114 + Source Clock Path accumulate delay (which is omitted in your figure)

Here, the setup slack equation is:

Data Required Time (setup) = capture edge time
                                             + destination clock path delay
                                              - clock uncertainty
                                              - setup time


Data Arrival Time (setup) = launch edge time
                                         + source clock path delay
                                         + datapath delay


Slack (setup) = Data Required Time - Data Arrival Time

 

As the equation shows, a positive setup slack occurs when the data arrives before the required time.

 

The Total Delay column in the timing summary report refers to data path delay. The value is then further divided into Logic Delay and Net Delay. It allows you to quickly isolate which characteristics are introducing the timing violation, high logic delay or high net delay.

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

View solution in original post

7 Replies
Observer dpikul
Observer
608 Views
Registered: ‎05-10-2018

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

I should add on, despite having these errors on over 1000 endpoints the hardware is consistently working just fine with no issues.

0 Kudos
Moderator
Moderator
541 Views
Registered: ‎03-16-2017

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

Hi @dpikul ,

>>I'm just confused as to why the required time for this path is larger than the clock period of 3.2ns,

Calculation for Data Required time for setup path is ,  Data Required Time (setup) = capture edge time+ destination clock path delay- clock uncertainty - setup time

Calculion for Data Arrival time for setup path is ,  Data Arrival Time (setup) = launch edge time+ source clock path delay + datapath delay

 

>>How can I resolve this permanantly so I dont waste build times. 

Check UG 1292, that how to resolve setup and hold violations by on your own by following the flow charts mentioned in it. You can start from page 3 since you are facing setup violation. 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_3/ug1292-ultrafast-timing-closure-quick-reference.pdf

 

>>despite having these errors on over 1000 endpoints the hardware is consistently working just fine with no issues.

Are you facing setup violations on input ports? If yes, then from your snapshot i did not see that you have set input delay constraints. If you do check_timing report in Vivado GUI you will see that you are facing high severity warnings for missing input delay constraints 

Please provide the full timing reports to evlauate further. You may run report_timing_summary 

 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
Observer dpikul
Observer
529 Views
Registered: ‎05-10-2018

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

Thanks for the response hemangd.

Sorry for the misunderstanding here, but I understand the concepts behind solving setup violations. What I'm trying to understand is why the path is failing when the total delay is significanly lower than the requirement, and this usually occurs with signals that interact with Xilinx FIFO IP about 25% of builds. Some of these paths only have a few logic levels...

For example, builds 1, 2 and 3 will pass timing, and build 4 will fail with a cumulative negative slack of -30ns in signal paths usually originating from FIFO IP or ending in FIFO IP. But every single path is reported as being within the requirement.

None of these paths are IO ports, design IO is GTH only. These violations are all occuring register to register.

All of the examples I see in that resource show a failure due to the total delay being larger than the requirement. I need to understand how to solve the issue when the requirement is lower than the delay. For example, Path 361 lists a total delay of 2.275ns, has a requirement of 3.2ns, yet has a slack of -.123ns. The design also experiences zero issues in hardware, which seems unlikely with so many paths failing...

0 Kudos
Scholar drjohnsmith
Scholar
522 Views
Registered: ‎07-09-2009

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

I have no answer, but I'll ask on a thing I have seen in the past.

do not believe that the design works in hardware is a meaning its ok,

Many times I have seen this, and sooner or later the company is caught out on a batch of chips being well within spec but not working. This could be the FPGA chips , or the power supply chips, or even the cooling changing.

if its failing timing, its failing.

having said that, it could be that your timing is needing tweaking, again I have seen people getting this wrong,

but @hemangd will get you working.

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Historian
Historian
493 Views
Registered: ‎01-23-2009

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

What I'm trying to understand is why the path is failing when the total delay is significanly lower than the requirement

The answer appears to be a combination of the clock skew (0.134ns), the clock uncertainty (0.035ns) and the setup requirement of the RAM (0.857). The setup check includes all of these. In order to pass, the following must be true

datapath_delay + clock_skew + clock_uncertainty + destination_setup_requirement <= requirement

so simply looking at the requirement and the datapath_delay is not looking at the complete picture.

Avrum

Observer dpikul
Observer
485 Views
Registered: ‎05-10-2018

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

Thanks avrum, 

The timing values in the individual path reports make much more sense, but that leads to another question.

Why does the tool (2018.2) display the Total Delay, Logic Delay, Net Delay, and Requirement columns in the Timing Summary Report? Aren't they essentially meaningless compared to the values in "View Path Report"?

Also, why is the 'Total Delay' value displayed equal to (Arrival Time)+FDRE{incr}-FDRE{Path}? I understand that the 0.114 is the path through the flip flop, but where did the 2.900 come from?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
470 Views
Registered: ‎07-16-2008

Re: Timing Failure when Total Delay less than Requirement

Jump to solution

2.900 = 0.114 + Source Clock Path accumulate delay (which is omitted in your figure)

Here, the setup slack equation is:

Data Required Time (setup) = capture edge time
                                             + destination clock path delay
                                              - clock uncertainty
                                              - setup time


Data Arrival Time (setup) = launch edge time
                                         + source clock path delay
                                         + datapath delay


Slack (setup) = Data Required Time - Data Arrival Time

 

As the equation shows, a positive setup slack occurs when the data arrives before the required time.

 

The Total Delay column in the timing summary report refers to data path delay. The value is then further divided into Logic Delay and Net Delay. It allows you to quickly isolate which characteristics are introducing the timing violation, high logic delay or high net delay.

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

View solution in original post