IntermediateQuestion 75 of 112Source: Synopsys PrimeTime User Guide: Variation

How do you apply a named AOCV table group to one hierarchical block?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

set_aocvm_table_group core_tables [get_cells H1] (PT) assigns a specific, named AOCV derate table to the cells inside one hierarchical block, instead of the whole design sharing one default table. This lets a block built in a different library corner, or characterized separately, use derate data that actually matches its own construction.

Technical Reference DiagramHow do you apply a named AOCV table group to one hierarchical block?
A chip floorplan with a top-level AOCV table applied everywhere except one hard-macro block outlined separately, labeled with its own named AOCV table group assignment.

Technical Explanation

A single design often contains blocks built or characterized differently, and a named AOCV table group lets each one use the right derate data.

  • The default is one table for the whole design. Without any grouping, every cell in the design derates from the same AOCV table, read in through read_ocvm (PT) once at the start of the flow.
  • set_aocvm_table_group assigns a different table to part of the design. set_aocvm_table_group core_tables [get_cells H1] (PT) tells the tool that every cell inside hierarchical instance H1 should use the core_tables group instead of whatever table applies elsewhere.
  • Why a block would need its own table: a hard macro characterized separately, an IP block from a different vendor, or a sub-block built with a distinct set of library cells may have its own AOCV characterization data that does not match the top-level table.
  • The assignment is by hierarchical cell instance, not by net or pin. You target the block itself with get_cells, and every cell inside that hierarchy inherits the named group.
  • reset_aocvm_table_group (PT) removes the assignment, returning that block's cells to whatever table would otherwise apply, which is useful when re-testing a block against the design-wide default.
  • Order and overlap matter, as with other per-object settings. If two commands could apply to the same cells, the tool resolves it the same way it resolves other conflicting object-level assignments, so keeping the hierarchy boundaries for each table group non-overlapping avoids ambiguity.

Common Mistake

The Trap: applying the top-level AOCV table to an integrated hard macro without checking whether the macro was characterized with its own, different derate data.

  • A designer assumes one AOCV table group is fine for the whole design, since that is the simpler setup to maintain.
  • If a hard macro's actual construction and process corner differ from the rest of the design, using the wrong table either over- or under-margins every path inside it, without any error message pointing to the mismatch.

Follow-up Question & Model Response

You integrate a third-party hard macro that comes with its own AOCV characterization data, separate from your top-level tables. How would you make sure the macro's cells use its own data instead of your default?

Candidate Model Response: I would read in the macro's own AOCV table data alongside the top-level tables using read_ocvm (PT), giving it a distinct group name, then apply set_aocvm_table_group serdes_tables [get_cells U_SERDES] (PT) targeting the macro's hierarchical instance specifically. That assignment overrides whatever table would otherwise apply to those cells, without touching the rest of the design's default grouping. I would confirm the assignment took effect by checking a sample path fully inside the macro with report_timing -derate (PT) and verifying its derate values match the macro vendor's own characterization rather than the top-level default.

Practical Example

A design integrates a third-party SerDes hard macro, U_SERDES, characterized with its own AOCV data at a different process corner than the rest of the chip. The team runs read_ocvm serdes_tables.ocv (PT) to load the vendor's tables under the group name serdes_tables, then applies set_aocvm_table_group serdes_tables [get_cells U_SERDES] (PT). report_timing -derate on a path fully inside U_SERDES then shows derate values matching the vendor's data sheet, while a path in the surrounding top-level logic continues to use the chip's own default AOCV table unaffected by the macro's assignment.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →

Continue practising

Related STA questions

AdvancedExplain why set_aocvm_table_group / read_ocvm after a timing update triggers a full update, and the flow implication.IntermediateWhy do larger designs move from a single flat OCV derate to AOCV tables?AdvancedWhat is an extracted timing model (ETM), and why use it for hierarchical blocks?IntermediateReconstruct the AOCV incremental derating: cell u1/u252 has late derate 1.082, early 0.924; you apply -increment -late 0.03 and -increment -early -0.03.