ExpertQuestion 7 of 69

How does AOCV (path-depth/distance-dependent derating) reduce pessimism compared to flat OCV, with a worked numeric example?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Flat OCV applies one multiplier to every cell and net delay on a path, regardless of how many stages the path has or how far it spans. Advanced on-chip variation (AOCV) instead looks up a smaller derate factor for paths with more logic stages or a shorter physical span, because random gate-to-gate variation partially cancels out over many stages, while systematic variation grows with distance. The result is a path-specific factor that is usually less pessimistic than one flat number applied everywhere.

Technical Reference DiagramHow does AOCV (path-depth/distance-dependent derating) reduce pessimism compared to flat OCV, with a worked numeric example?

Technical Explanation

  • Flat OCV treats every gate on a path as if it could simultaneously hit its worst-case corner, which is statistically unlikely once a path has many independent gates — some run slightly fast, some slightly slow, and the random components tend to average out rather than all stacking in the same direction.
  • AOCV builds derating tables keyed on two path-specific metrics: path depth (the number of logic stages the path passes through) and physical distance (how far apart the path's cells are placed on the die). A deep path gets a smaller derate factor than a shallow one; a long, spread-out path gets a larger factor than a compact one, because it is more exposed to slow, distance-correlated process gradients.
  • timing_aocvm_enable_analysis (PT) turns AOCV analysis on; the actual derating numbers come from vendor- or foundry-supplied tables loaded with read_ocvm (PT), not from a formula the tool invents on its own — AOCV is only as accurate as the characterization data behind it.
  • AOCV analysis runs in both graph-based mode, which applies the depth/distance lookup during the normal timing graph traversal, and path-based mode, which re-evaluates specific reported paths with the same tables for a tighter, path-exact number.
  • The derate factor scales down toward 1.0 as depth increases, meaning a 20-stage path might see a late derate of roughly 1.03 where a 3-stage path on the same design sees 1.15 — the exact numbers always come from the loaded tables, never from a universal ratio.
  • What breaks: applying flat OCV derate on a design where deep, high-stage-count paths dominate wastes real margin the design does not need, potentially forcing unnecessary buffer insertion or over-sizing during ECO to close a violation that AOCV tables would have shown was never really there.

Common Mistake

The Trap: assuming AOCV is always less pessimistic than flat OCV on every path.

  • A short, physically spread-out path (few stages, large distance) can actually see a larger derate under AOCV than under a moderate flat factor, because AOCV specifically penalizes low depth and large distance — it is not a one-directional relaxation.
  • Treating AOCV tables as portable across process nodes or library revisions is a mistake; the tables must be re-characterized whenever the process or library changes, since they describe that specific silicon's variation behavior, not a general rule.

Follow-up Question & Model Response

"If a specific path's AOCV-derated slack looks worse than its flat-OCV slack was, what does that tell you about the path, and is it a red flag?"

Candidate Model Response: It is not automatically a red flag — it usually just means the path has few logic stages and spans a large physical distance, which is exactly the combination AOCV tables penalize more heavily than a moderate flat factor would. I would confirm this by checking the path's reported stage count and endpoint-to-startpoint distance, and I would treat it as a sign the floorplan placed related logic far apart rather than as a tool error, since AOCV is reflecting a real, distance-correlated variation risk that flat OCV was simply not sensitive to.

Practical Example

Worked case: two paths on the same 7nm block both need a setup check. Path A has 18 logic stages within a compact 40 micron span; the AOCV table gives it a late derate of 1.04. Path B has 3 logic stages spread across a 900 micron span; the AOCV table gives it a late derate of 1.18, compared to a flat-OCV factor of 1.12 that would have been applied to both paths under a single-number policy. Path A's slack improves under AOCV relative to flat OCV, while Path B's slack actually tightens — showing AOCV redistributing pessimism to where the physical variation risk is real, rather than uniformly relaxing every path.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →

Offline PDF Bundle

Want all 1109 questions offline?

Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.

See what's inside the bundle
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff.

Continue practising

Related STA questions

ExpertHow does POCV combine per-arc sigma values, and how does that scale differently than flat derating as path length grows?ExpertWhat command applies OCV/AOCV derating, and how do -early/-late and cell_delay/-net_delay/-clock/-data qualifiers change what gets derated?ExpertWalk through a full setup check including clock reconvergence pessimism (CRPR) — why does OCV derating create artificial pessimism on shared clock paths, and how is it removed?ExpertHow does temperature inversion complicate the assumption that hold is always worst at the fast/cold corner?