Why doesn't an ordinary set_timing_derate percentage automatically scale AOCV or POCV sigma values, and what option turns that behavior on?

Short Answer

By default, set_timing_derate (PT) affects only ordinary, flat cell and net delays — it does not touch the separate statistical models AOCV and POCV use, because those models already carry their own, more detailed variation data and blending in a flat percentage on top would double up two different representations of the same physical variation. The -aocvm_guardband, -pocvm_guardband, and -pocvm_coefficient_scale_factor options exist specifically to adjust the AOCV or POCV models themselves, separately from the ordinary derate command's default scope.

Technical Explanation

• set_timing_derate [factor] [-early|-late] [-cell_delay|-net_delay|-cell_check] (PT) is the ordinary flat-derate command, scaling delay values or check constraints by the given factor on the objects named.
• By default this command's effect stops at ordinary delay and check derating — it does not reach into AOCV table-based derates or POCV per-arc sigma values, which are computed through their own, separate statistical mechanism from their own library or side-file data.
• -aocvm_guardband applies an additional margin specifically to the AOCV model's table-based derate, layered on top of what the AOCV tables already compute, rather than replacing them.
• -pocvm_guardband and -pocvm_coefficient_scale_factor do the equivalent for POCV, adjusting the statistical sigma-based model with an additional guardband or a scale factor on its coefficients, again on top of the library's own characterized variation data.
• Keeping these paths separate is deliberate: an ordinary flat derate is a coarse, one-size-fits-all margin, while AOCV/POCV models are meant to already capture distance- and arc-specific variation in detail — automatically applying the flat number to the detailed model would flatten out the very granularity AOCV/POCV exists to provide.
• report_timing_derate (PT) reports both kinds of setting together, but reading which mechanism is providing which number is important, because a flat derate change and a guardband change can look similar in a slack report while representing very different underlying adjustments.
• What breaks: a team that wants to add signoff margin specifically to the AOCV/POCV model, but only issues an ordinary set_timing_derate command, sees no change to the AOCV/POCV-driven slack at all, because the command never reached the model it was meant to adjust.

Follow-up Question & Model Response

"If I need extra POCV margin for one late-stage signoff pass, is -pocvm_guardband or -pocvm_coefficient_scale_factor the right choice?"

Candidate Model Response: -pocvm_guardband adds a fixed additional margin on top of the model's computed sigma-based derate, which is the more predictable choice when the goal is a known, bounded amount of extra conservatism for a specific signoff pass. -pocvm_coefficient_scale_factor instead scales the underlying coefficients the model uses, which changes the derate proportionally rather than by a fixed amount, and is better suited to a broader statement like "treat this library's characterized variation as less certain than assumed," rather than a one-time signoff guardband. For a single late-stage margin add with a known target number, the fixed guardband option is easier to reason about and to remove cleanly once its purpose has been served.