Why do larger designs move from a single flat OCV derate to AOCV tables?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
A flat derate applies the same percentage margin to a one-stage path and a fifty-stage path alike, even though random manufacturing variation tends to partly cancel out over many stages, not stack up in full. AOCV tables give a smaller derate to longer paths and a larger derate to shorter ones, recovering slack on long paths that a flat number was over-penalizing without actually giving up real coverage.
Technical Explanation
The case for AOCV is really an argument about how independent random variations behave when you add many of them together.
- Flat OCV treats every path the same, regardless of length. A single
set_timing_derate -late 1.15(SDC) applies a 15% penalty whether the path has one logic stage or fifteen. - Random variation does not add up linearly across independent stages. If each stage's delay varies a little in either direction, independently of its neighbors, the total variation across many stages grows more slowly than simply multiplying one stage's variation by the stage count.
- A short path is genuinely more exposed to a single bad stage. With only one or two stages, there is no averaging effect to soften an unlucky variation on that one gate, so a larger derate is actually justified there.
- AOCV tables encode this stage-count or distance effect directly. The tool looks up a derate percentage based on how many stages, or how much physical distance, a path spans, giving long paths a smaller derate than short ones instead of one number for all.
- Why this matters more as designs grow: a large design has both very short local paths and very long paths crossing wide blocks, and a flat derate calibrated to be safe for the short paths ends up needlessly pessimistic on every long path in the same design.
- The payoff is recovered slack without lost coverage. Long paths that were failing under an overly conservative flat derate can pass under an AOCV table that reflects their genuinely smaller real-world risk, while short paths keep the larger margin they still need.
Common Mistake
The Trap: assuming a flat OCV derate is simply "safer" than AOCV because it uses one larger number everywhere, so switching to AOCV must be giving something up.
- A designer sees AOCV tables reducing the derate on long paths and worries that coverage is being weakened to make timing closure easier.
- The reduction on long paths reflects a more accurate model of how independent variation actually behaves over many stages, not a relaxed standard — the short paths that genuinely need the larger margin still get it.
Follow-up Question & Model Response
A block owner asks why their 20-stage critical path passes under AOCV when it failed under the previous flat-derate signoff, worried the design is now less safe. How do you explain it?
Candidate Model Response: The flat derate applied the same 15% margin to that 20-stage path as it would to a 2-stage path, which overstates the real risk, since independent random variation across 20 stages tends to partly average out rather than stack up in full. The AOCV table instead looks up a smaller derate for a path with that many stages, based on this library's characterization data. That is not a weaker standard — it is a more accurate one, and short paths in the same design still get the larger derate they need, since AOCV adjusts by path length rather than lowering the bar everywhere.
Practical Example
A 20-stage critical path fails signoff under a flat 15% late derate by 30ps. Switching to AOCV, with a table assigning roughly 6% derate to paths of that stage count, report_timing -derate (PT) shows the same path passing with 55ps of slack. A separate 2-stage path in the same block, derated at close to 18% for its short stage count, still passes tightly, confirming the short path kept its larger margin while the long path's overly conservative flat margin was corrected.
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