What is the critical path, and how does it differ from a timing violation?
From PDVerse STA Mentor Guide ยท pdVerse Mentor Guide
Short Answer
The critical path is the path with the least slack in the whole design, whether that slack is positive or negative. It is not automatically a timing violation โ a design with a healthy, all-positive-slack timing report still has a critical path, it is just the one closest to failing.
Technical Explanation
Engineers often say "critical" to mean "broken," but the tool uses a narrower definition.
- What the tool actually ranks: for every check it runs, the tool computes slack โ required time minus arrival time โ for every path, then sorts them. The path at the bottom of that sorted list is the critical path for that check.
- Positive slack still has a critical path: if every path passes with some margin, the one with the smallest margin is still called critical, even though nothing is violating.
- A violation is a slack value below zero, on any path, critical or not. A design can have a critical path at +40ps and no violation at all.
- The critical path can move between runs: a small change to one net's delay can shift the ranking, so the path a report calls critical after placement may not be the same physical path that was critical after synthesis.
- Setup and hold each have their own critical path: the setup check (max delay analysis,
report_timing(PT)) and the hold check (min delay analysis) usually name two different physical paths as critical. - Why it matters: chasing only "the critical path" does not clear the design โ another path takes over the bottom of the ranking as soon as the first one improves.
Common Mistake
The Trap: treating "critical path" and "the path that is failing" as the same thing.
- A designer sees the critical path called out in a report and assumes the design has a problem there, when the slack on that path is actually comfortably positive.
- This leads to spending optimization effort on a path that was never going to fail, while a different, lower-ranked-in-name-only path elsewhere quietly has negative slack on a different check.
Follow-up Question & Model Response
If I fix the current critical path, is my design now free of the worst timing risk? Candidate Model Response: Not necessarily. Fixing the critical path only removes that one path from the bottom of the ranking; the path with the next-smallest slack becomes critical, and it may already be a violation you had not looked at. Check the worst negative slack (WNS) and total negative slack (TNS) across the whole report, not just the single labelled path, since those two numbers show whether violations exist.
Practical Example
A block has 900 register-to-register paths. After synthesis, report_timing ranks path P217 as critical with +65ps slack โ nothing is violating yet. After placement, wire delay changes shift P552 to the top of the ranking at -30ps: P552 is now both critical and in violation, while P217 has settled at +110ps and dropped out of the top ten entirely.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Continue practising