What happens to slack at zero, and is it something to worry about?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
Slack is required time minus arrival time, and the sign is the only thing that decides pass or fail.
Technical Explanation
Slack is required time minus arrival time, and the sign is the only thing that decides pass or fail.
- Zero is a legal outcome. The tool defines a violation as slack below zero. A path sitting at exactly 0ps has met the check, nothing more and nothing less.
- The number already includes margin you asked for. If
set_clock_uncertainty(SDC) or derate values are active, the required time used in the slack equation is already tighter than the raw clock period — so 0ps is 0ps after your margin, not before it. - A design can be entirely made of 0ps paths and still be considered signed off, because signoff criteria check the sign of slack, not its magnitude, unless a project rule adds its own minimum margin on top.
- What breaks the comfort: on-chip variation the tool cannot fully model — voltage droop beyond the derate table, unmodeled aging, or a library corner that does not match silicon exactly — can turn a 0ps pass into a small fail in real hardware.
- Small negative numbers are the practical risk zone. A path at -2ps is technically a violation, but engineers often treat it differently from a path at -200ps, because rounding, extraction noise, or a slightly conservative corner could account for a few picoseconds either way.
- Why it matters: teams that chase every last picosecond of slack toward zero across an entire design remove any cushion for effects the model does not capture, even though every individual report is clean.
Common Mistake
The Trap: treating 0ps slack as automatically risky, without first checking how much margin the report already spent.
- A designer sees a wall of 0ps paths after optimization and assumes the design is fragile, when the setup check already includes generous
set_clock_uncertaintyand derate values. - The real question is not the slack number itself but what assumptions produced it — re-checking with looser or tighter margin can move the same path several picoseconds without any silicon changing.
Follow-up Question & Model Response
If every path in a block reports exactly 0ps after optimization, would you sign off on it as-is?
Candidate Model Response: Not without first checking what produced that uniform number. An optimizer that pushes every path to exactly 0ps is usually a sign it ran out of paths to fix and stopped right at the boundary, which is expected behavior, not a red flag by itself. I would check whether the margin values used (clock uncertainty, derate, any extra project margin) already cover known modeling gaps like voltage droop or library corner mismatch. If they do, 0ps across the board is an efficient, clean result. If the margin is thin, I would ask for a small additional guard-band before calling it final, since a flat plane of zero-slack paths leaves no room for anything the model missed.
Practical Example
A 400MHz block (2.5ns period) reports 40 paths at exactly 0ps slack after incremental placement optimization, with set_clock_uncertainty -setup 0.15 (SDC) already applied to both clocks. The team reruns report_timing (PT) with derate bumped from a nominal 5% to a stress 8% to simulate extra voltage margin, and 12 of those 40 paths go slightly negative, by 3-9ps. Rather than accept the nominal 0ps result, the team asks the physical design team to buffer the 12 paths that failed the stress check, keeping the nominal report at 0ps but adding real margin where the model showed it was thin.
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