Reviewing Timing Slack - 2021.2 English

Several factors can impact the setup and hold slacks. You can easily identify each factor by reviewing the setup and hold slack equations when written in the following simplified form:

Slack (setup/recovery) = setup path requirement

- datapath delay (max)

+ clock skew

- clock uncertainty

- setup/recovery time

Slack (hold/removal) = hold path requirement

+ datapath delay (min)

- clock skew

- clock uncertainty

- hold/removal time

For timing analysis, clock skew is always calculated as follows:

• Clock Skew = destination clock delay - source clock delay (after the common node if any)

During the analysis of the violating timing paths, you must review the relative impact of each variable to determine which variable contributes the most to the violation. Then you can start analyzing the main contributor to understand what characteristic of the path influences its value the most and try to identify a design or constraint change to reduce its impact. If a design or constraint change is not practical, you must do the same analysis with all other contributors starting with the worst one. The following list shows the typical contributor order from worst to least.

For setup/recovery:

Datapath delay

Subtract the timing path requirement from the datapath delay. If the difference is comparable to the (negative) slack value, then either the path requirement is too tight or the datapath delay is too large.

Datapath delay + setup/recovery time

Subtract the timing path requirement from the datapath delay plus the setup/recovery time. If the difference is comparable to the (negative) slack value, then either the path requirement is too tight or the setup/recovery time is larger than usual and noticeably contributes to the violation.

Clock skew

If the clock skew and the slack have similar negative values and the skew absolute value is over a few 100 ps, then the skew is a major contributor and you must review the clock topology.

Clock uncertainty

If the clock uncertainty is over 100 ps, then you must review the clock topology and jitter numbers to understand why the uncertainty is so high.

For hold/removal:

Clock skew

If the clock skew is over 300 ps, you must review the clock topology.

Clock uncertainty

If the clock uncertainty is over 200 ps, then you must review the clock topology and jitter numbers to understand why the uncertainty is so high.

Hold/removal time

If the hold/removal time is over a few 100 ps, you can review the primitive data sheet to validate that this is expected.

Hold path requirement

The requirement is usually zero. If not, you must verify that your timing constraints are correct.

Assuming all timing constraints are accurate and reasonable, the most common contributors to timing violations are usually the datapath delay for setup/recovery timing paths, and skew for hold/removal timing paths. At the early stage of a design cycle, you can fix most timing problems by analyzing these two contributors. However, after improving and refining design and constraints, the remaining violations are caused by a combination of factors, and you must review all factors in parallel to identify which to improve.

See this link for more information on timing analysis concepts, and see this link for more information on timing reports (report_timing_summary/report_timing) in the Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).