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