What is the difference between AOCV and POCV?

Short Answer

AOCV (advanced on-chip variation) adjusts the derate factor from a lookup table based on how many logic stages or how much distance a path covers, using fixed numbers set once for the whole library. POCV (parametric on-chip variation) instead derates each individual timing arc from a statistical spread — a mean and a sigma value — read directly from the library, so the margin can differ arc by arc instead of by table lookup alone.

Technical Explanation

Both AOCV and POCV exist to make on-chip variation margin less pessimistic than one flat number applied everywhere, but they get there in different ways.

• A flat OCV derate is the baseline both improve on. A single set_timing_derate -early/-late (SDC) factor applies the same percentage margin to every cell and every net, regardless of how long or short the path actually is.
• AOCV keys its margin off path depth or distance. The tool looks up a derate value in a table indexed by the number of stages, or the physical distance, a path covers — a short path gets a larger derate than a long one, because random variation tends to average out over more stages.
• POCV keys its margin off each arc's own statistical spread. Every cell arc in the library carries a mean delay and a sigma (standard deviation) value, and the tool combines these statistically across the path instead of reading one table entry per path length.
• Where the numbers come from differs too. AOCV tables are built once, ahead of time, from characterization data grouped by depth or distance bucket. POCV sigma values live directly in the Liberty timing arcs the tool already reads for delay.
• Why POCV is generally less pessimistic still. Combining many independent per-arc sigma values statistically produces a tighter, more accurate total margin than reading one table-based number that has to cover a whole bucket of similar paths.
• Both still assume the tool trusts propagated clock timing. Neither AOCV nor POCV derating is meaningful until the design's clock network uses real, propagated latency instead of an ideal, zero-skew clock model.

Follow-up Question & Model Response

Your library has POCV sigma data available, but a teammate suggests sticking with the existing AOCV tables since they already pass signoff. What would you check before agreeing?

Candidate Model Response: I would check whether the AOCV tables were characterized for the specific process node and library cells actually used in this design, since AOCV margin is only as accurate as the depth or distance buckets it was built from. If POCV sigma data is available and verified in the library, I would expect it to give a tighter, more accurate margin on most paths, since it derates each arc individually instead of grouping paths into buckets. I would not switch without re-running signoff on a representative block first, because a path that passed comfortably under one method's margin might land closer to the edge under the other, even if neither method is incorrect.