AdvancedQuestion 2 of 63

Why is report_ocvm -type pocvm -cell_delay -list_not_annotated an important pre-signoff check, and what does a missing cell imply?

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

The command lists cells with no POCV (parametric on-chip variation, a statistical way of modeling how much a cell's delay can vary) coefficient or distance data - cells that quietly fall back to zero variation. Any path through one of them has under-modeled spread, so its reported corner is optimistic and can hide a real violation.

Table comparing a fully-annotated standard-cell library against a partially-annotated IP library, listing which cell types have POCV sigma coefficients and which fall back to zero variation — Technical Reference DiagramWhy is report_ocvm -type pocvm -cell_delay -list_not_annotated an important pre-signoff check, and what does a missing cell imply?

Technical Reference DiagramWhy is report_ocvm -type pocvm -cell_delay -list_not_annotated an important pre-signoff check, and what does a missing cell imply?

Technical Explanation

What the command does. report_ocvm -type pocvm -cell_delay -list_not_annotated (PT) enumerates every cell in the design that has no POCV coefficient or distance data - cells that neither the Liberty (LIB) variation tables nor a side-file annotation ever reached.
Why a missing cell is worse than a missing feature. Without POCV data, that cell falls back to zero variation, meaning the statistical model treats it as if it never varies at all. It contributes no sigma (the statistical spread term) to the path's timing, so every path through it comes out narrower - more optimistic - than reality.
Why it fails silently. The report still prints a clean-looking number. Nothing flags that the spread behind that number is too tight, so a real violation can sit hidden behind a passing slack value.
When to run it. The check needs no timing update first, so run it right after reading the library and before update_timing (PT). Catching a gap here is cheap; catching it after a full signoff run is not.
The usual causes. A library missing LVF (Liberty Variation Format) tables for some cells, a side-file object list that didn't match the actual cell names, or new cells added to the netlist after the POCV data was generated.
The fix. Get POCV coverage on every timing-relevant cell, either by completing the LVF data or by adding side-file coverage, then rerun the check until the not-annotated list is empty.

Common Mistake

Treating "no output from the check" as the only failure signal, when the real risk is cells present in the not-annotated list that nobody investigates because the overall timing report still looks clean.
Assuming a library with CCS timing data automatically carries POCV coefficients too - the two are separate table sets, and a library can have one without the other.
Cost: a signoff corner that looks converged while several cells are silently modeled with zero variation, which understates real spread on any path running through them.

Follow-up Question & Model Response

Two libraries in the same design have different LVF coverage - one complete, one partial. What happens to a path that crosses both, and how would you confirm the gap before it reaches signoff?

Candidate Model Response: The path is timed cell by cell, so the cells from the complete library get real POCV sigma values while the cells from the partial library fall back to zero variation for any arc missing coefficients. The path's overall statistical spread ends up understated, because part of it was never modeled with real variation at all. To confirm this before signoff, run report_ocvm -type pocvm -cell_delay -list_not_annotated (PT) on the full design, not just the block using the partial library, since the same partial library may be instantiated elsewhere too. Cross-check the not-annotated list against the specific cells on the path in question using report_timing (PT), and if any of them appear, treat the corner's numbers as optimistic until the library or side-file coverage is completed.

Practical Example

A 16nm design reads a standard-cell library with full LVF coverage plus a memory-compiler library whose LVF tables cover only its D flip-flops, not its multiplexers. Running report_ocvm -type pocvm -cell_delay -list_not_annotated before update_timing lists 42 multiplexer instances from that IP. A hold path launching through one of those muxes reports 18ps of slack at the ss_0p72v_125c corner - a number computed with zero POCV sigma on that mux stage. Adding a side-file entry with the vendor's supplied coefficient for that cell type drops the reported slack to 6ps, still passing, but honestly modeled instead of silently optimistic.

Complete STA Handbook