Explain why set_aocvm_table_group / read_ocvm after a timing update triggers a full update, and the flow implication.
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
Derating factors are an input to delay calculation, so changing tables or table groups alters delays on a broad set of arcs and arrivals propagate transitively - there is nothing to patch incrementally, so a full update is forced. Set all variation data before the first update.
Complete Technical Explanation
AOCV and POCV derating factors sit upstream of delay calculation: they multiply, or for POCV parameterize, the delay and sigma of every affected arc, and those arc values feed arrival propagation across the whole timing graph. When you change the table group with set_aocvm_table_group, load new tables with read_ocvm, or remove a group, the derate on a wide set of arcs changes at once. Because arrivals propagate transitively, the tool cannot reason about which handful of endpoints moved - the change ripples design-wide - so it invalidates and recomputes full timing rather than doing an incremental update. The flow implication is straightforward: set your variation data and grouping once, up front, before the first update_timing or report_timing, so you pay the full update a single time. Interleaving read_ocvm or set_aocvm_table_group with reporting commands forces repeated full updates, the same anti-pattern as report_exceptions or a global parasitic scaling triggering full updates. Batch all variation setup, then analyze. If you genuinely must iterate on table groups - tuning the derate on a reused block, for example - expect each change to cost a full update and script accordingly, or do the iteration in a dedicated scenario setup phase. The general principle: anything that changes derating broadly is a full-update operation, so plan the flow so those land at deliberate checkpoints, not in the middle of a report loop.
In Pd / Signoff
In a signoff script you place all read_ocvm and set_aocvm_table_group calls in the constraint and variation setup section, before the first update_timing . When runtime blows up on a large design, the first thing to check is whether a derate command sits below a reporting command in the script - that single ordering error can double or triple the run.
Common Trap
Loading or regrouping OCVM data between reports, on the assumption that a derate change is a cheap local edit. It is not - each such command discards the entire timing update, so a script that tunes derates inside a reporting loop pays a full update per iteration and looks mysteriously slow.
Expect Next
Which other PrimeTime operations force a full update rather than an incremental one, and what do they have in common with a derate change?
Topic And Primetime Commands
Variation / AOCV Tables. read_ocvm, set_aocvm_table_group, update_timing, report_timing
Keep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising