IntermediateQuestion 24 of 112

Why must you query .mean/.std_dev on POCV attributes instead of the bare attribute?

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

Under POCV (parametric on-chip variation), a slack or arrival value isn't one number, it's a statistical distribution, so there is no single scalar the bare attribute could return. .mean gives the average of that distribution and .std_dev gives its sigma, the spread.

POCV slack shown as a bell-curve distribution with mean and std_dev sub-attributes labeled, versus a single deterministic slack scalar — Technical Reference DiagramWhy must you query .mean/.std_dev on POCV attributes instead of the bare attribute?

Technical Reference DiagramWhy must you query .mean/.std_dev on POCV attributes instead of the bare attribute?

Technical Explanation

In an ordinary, deterministic timing run, an arrival or slack value is one number, so asking for the attribute directly makes sense.

What changes under POCV: the tool now represents that same quantity as a distribution — a mean plus a spread (sigma) — because POCV models cell delay as varying randomly around a center value, not as one fixed number.
Why the bare attribute comes back empty: there's no single number to hand back for a distribution, so querying it directly returns an empty list, {}. People often misread that as "the attribute doesn't exist" or "POCV isn't actually enabled" — it does exist, you just have to ask for one specific statistic of it.
.mean and .std_dev: .mean returns the average of the distribution; .std_dev returns its standard deviation, the sigma that describes how much it typically varies.
Where this convention shows up: the same pattern applies to the whole POCV attribute family — pin-level min_rise_variation_arrival, max_fall_variation_slack, and the path- and timing-point-level variation_arrival and variation_slack.
What it means for scripting: any Tcl script doing sorting, thresholding, or margin arithmetic on POCV results has to be explicit about which statistic it wants. A script written for deterministic slack that's simply pointed at a POCV run won't error, it'll just silently return empty results instead of wrong ones.

Common Mistake

The Trap: reusing a deterministic-mode Tcl script unchanged against a POCV run and trusting an empty result as "clean, no violations."

The script queries the bare slack attribute, gets {} on every path, and treats that as zero violations rather than a query error.
The real slack numbers were sitting there the whole time under .mean/.std_dev; the script simply never asked for them, so a genuinely violating design can pass a broken check silently.

Follow-up Question & Model Response

If .mean and .std_dev are separate queries, how would you build a single "effective slack" number for ranking paths under POCV?

Candidate Model Response: A common approach is to combine the two statistics into one pessimism-adjusted number, for example mean slack minus some multiple of sigma, such as three sigma, to represent a conservative, low-probability-of-failure value. That means querying both .mean and .std_dev in the same script and doing the arithmetic yourself in Tcl, since the tool doesn't hand back a single blended figure. Which multiple of sigma to use is a signoff-policy choice, not a fixed PrimeTime default, so it should match whatever margin convention the project already uses for statistical timing.

Practical Example

A POCV-enabled run on a 200 MHz core reports get_attribute [get_timing_paths -to reg_out/D] slack (PT) as an empty list. Switching the query to get_attribute [get_timing_paths -to reg_out/D] slack.mean returns 45 (ps), and slack.std_dev returns 6 (ps). A signoff script computing mean minus three sigma gets 45 − 18 = 27 ps of pessimism-adjusted slack, still positive, so the path passes even under the conservative statistical margin.

Complete STA Handbook