cancel
Showing results for
Show  only  | Search instead for
Did you mean:
Highlighted
Observer
1,280 Views
Registered: ‎05-10-2018

## Timing Failure when Total Delay less than Requirement

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

Tags (5)
1 Solution

Accepted Solutions
Highlighted
Moderator
1,114 Views
Registered: ‎07-16-2008

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.
-------------------------------------------------------------------------
7 Replies
Highlighted
Observer
1,253 Views
Registered: ‎05-10-2018

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

Highlighted
Moderator
1,186 Views
Registered: ‎03-16-2017

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.
Highlighted
Observer
1,174 Views
Registered: ‎05-10-2018

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...

Highlighted
Teacher
1,167 Views
Registered: ‎07-09-2009

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.

Highlighted
Guide
1,138 Views
Registered: ‎01-23-2009

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

Highlighted
Observer
1,130 Views
Registered: ‎05-10-2018

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?

Highlighted
Moderator
1,115 Views
Registered: ‎07-16-2008

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.
-------------------------------------------------------------------------