AdvancedQuestion 40 of 63Source: Synopsys PrimeTime User Guide: Parametric On-Chip Variation (POCV)

How do you enable POCV analysis in PrimeTime, and what happens when a cell has no variation data?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

POCV analysis turns on with a single application variable, set_app_var timing_pocvm_enable_analysis true (PT), after which PrimeTime performs graph-based POCV timing updates automatically as part of every update_timing (PT) run; a POCV side file, if one is used instead of or alongside library-based data, is loaded separately with read_ocvm (PT). A cell with no variation data anywhere - no Liberty sigma tables and no side-file entry - simply gets no statistical derate on that arc, which is exactly what the diagnostic report_ocvm -list_not_annotated (PT) command is built to surface.

A design floorplan with millions of standard cells shown fully annotated with POCV sigma data in one color, and one hard macro block highlighted in a different color labeled 340 unannotated arcs, next to a report_ocvm -list_not_annotated output listing that macro's pins — Technical Reference DiagramHow do you enable POCV analysis in PrimeTime, and what happens when a cell has no variation data?

Technical Explanation

One application variable turns POCV on for the whole analysis. set_app_var timing_pocvm_enable_analysis true (PT) is the single switch; once set, graph-based POCV updates happen automatically inside update_timing (PT), with no separate command needed to trigger them.
Library-based POCV data (LVF sigma tables) does not need a separate loading step. If the cell libraries already contain ocv_sigma_cell_rise-style tables, enabling the analysis variable is enough for PrimeTime to use them.
A POCV side file is a distinct, optional data source, loaded explicitly. read_ocvm pocv_side_file_name (PT) reads variation coefficients from a side file for cells whose libraries were not characterized with LVF data.
A cell missing variation data from both sources contributes no statistical spread on that arc. There is no automatic fallback to a flat derate or an assumed sigma - the arc is simply analyzed as if it has zero variation, unless a flat, non-POCV derate is separately applied with set_timing_derate (PT).
report_ocvm -type pocvm -cell_delay -list_not_annotated (PT) is the diagnostic built specifically for this gap. It enumerates every cell delay arc that has neither Liberty sigma data nor a side-file entry, so the missing coverage does not go unnoticed.
The K sigma corner multiplier is a separate, optional refinement, not part of enabling the analysis itself. set_app_var timing_pocvm_corner_sigma K_value (PT) only changes how conservatively the already-loaded sigma data is interpreted; it has nothing to load or enable on its own.

Common Mistake

Assuming that turning on timing_pocvm_enable_analysis (PT) means every cell in the design now gets a statistically-derived margin.
A cell with no POCV data from either the library's LVF tables or a loaded side file gets no statistical derate at all on the affected arcs - the enable variable turns the mechanism on, it does not manufacture missing variation data.
Cost: a mixed-vintage design, where some libraries were characterized with LVF and others were not, ends up with POCV-derated margins on some cells and completely un-derated nominal delays on others, with nothing in the setup/hold summary distinguishing the two.

Follow-up Question & Model Response

If report_ocvm -list_not_annotated (PT) shows a hard macro's I/O timing arcs with no POCV coverage, but the rest of the design's standard cells are fully annotated, what would you check before deciding whether that gap actually matters?

Candidate Model Response: I would first check whether that hard macro's library was characterized before POCV/LVF data became part of the standard library flow, since older or third-party hard macros are a common source of this exact gap. I would then estimate how much of the design's critical timing actually routes through that macro's boundary, because a gap on a rarely-critical macro is a very different risk than one sitting on the chip's tightest path. If the macro is timing-critical, I would look for a flat set_timing_derate (PT) margin as an interim substitute for real POCV data on just those arcs, rather than leaving them completely un-derated while every surrounding standard cell gets statistical margin.

Practical Example

A 7nm SoC design enables POCV with set_app_var timing_pocvm_enable_analysis true (PT) and relies entirely on its standard-cell library's built-in LVF sigma tables, with no side file. report_ocvm -type pocvm -cell_delay -list_not_annotated (PT) afterward lists 340 arcs, all belonging to one older analog PLL hard macro whose library was delivered without LVF characterization. Every one of the design's roughly 2.1 million standard-cell arcs is fully annotated and getting a statistical derate; only the PLL macro's 340 arcs get none, until the team either requests an updated, LVF-characterized macro library or adds a conservative flat derate on just those arcs as a stand-in.

Complete STA Handbook