Explain why set_aocvm_table_group / read_ocvm after a timing update triggers a full update, and the flow implication.

Short Answer

Derating factors (multipliers applied to a cell's delay to model variation) are an input to delay calculation itself, so changing which tables apply alters delays on a broad set of arcs at once. Because arrival times propagate transitively across the whole graph, the tool can't patch just a few endpoints - it forces a full recomputation. Set all variation data before the first update.

Technical Explanation

• Derating sits upstream of delay, not downstream. AOCV (advanced on-chip variation) and POCV derating factors multiply - or for POCV, statistically parameterize - the delay and sigma of every arc they cover, and those arc values are exactly what feeds arrival-time propagation across the whole timing graph.
• What triggers the full update. Changing the active table group with set_aocvm_table_group (PT), loading new tables with read_ocvm (PT), or removing a group changes the derate applied to a wide set of arcs simultaneously - not one arc, a whole swath of the design.
• Why the tool can't patch incrementally. Because arrival times propagate transitively - each stage's output feeds the next stage's input - the tool has no way to know which handful of endpoints moved as a result. The change ripples design-wide, so PrimeTime invalidates and recomputes full timing rather than attempting a targeted, incremental update.
• The flow implication. Set all variation data and grouping once, up front, before the first update_timing or report_timing (PT) call, so the full-update cost is paid exactly once.
• The anti-pattern to avoid. Interleaving read_ocvm or set_aocvm_table_group calls between reporting commands forces a repeated full update every time - the same class of mistake as running a global parasitic re-scaling in the middle of a report loop.
• If iteration is genuinely required. Tuning the derate on a reused block might mean deliberately repeating this step - if so, expect a full-update cost each time and either script around it or do the iteration in a dedicated setup phase, not mixed into signoff reporting.
• The general principle. Anything that changes derating broadly is a full-update operation by nature; plan the script so those land at deliberate checkpoints, not scattered through a report loop.

Follow-up Question & Model Response

If a script must tune the AOCV table group on one reused IP block across five different instantiation contexts, what's the least wasteful way to structure that, given that each change forces a full update?

Candidate Model Response: The least wasteful structure is to batch all five set_aocvm_table_group assignments together, one per context, before running a single update_timing and a single round of reports - rather than alternating a table-group change with a report call five separate times. If the five contexts genuinely need to be evaluated and compared one at a time, accept that each comparison costs one full update and budget the runtime accordingly, rather than trying to avoid it through incremental tricks that the tool doesn't support for this kind of change. The only real lever is reducing how many separate full updates the workflow triggers, not making any individual update itself faster.