What is an extracted timing model (ETM), and why use it for hierarchical blocks?

Short Answer

An extracted timing model (ETM) is a compact, black-box description of a block's input-to-output timing -- arrival times, required times, and internal delay arcs -- built once from the block's full netlist so the top-level analysis never has to re-read that netlist directly. Hierarchical designs use an ETM because loading every block's full gate-level detail at the top level makes a full-chip run too slow and too memory-heavy to iterate on, while an ETM keeps just enough timing information for the top level to check the block's boundary correctly.

Technical Explanation

The extract_model (PT) command reads a block's full timing view -- netlist, SDC, parasitics -- and produces a model that reports the same boundary delays, required times, and constraints the full block would have reported, without carrying the internal cells.

• At the top level, the ETM plugs in where the block instance used to be, so a path entering and exiting the block gets its delay and required-time contribution from the model instead of from a full re-simulation of every internal gate.
• Because the model only needs to be correct at the boundary, an ETM is typically a fraction of the size of the block's original netlist, which is what makes a full-chip run with dozens of ETM-modeled blocks tractable on a normal signoff machine.
• An ETM must be regenerated whenever the block's internal timing changes -- a resize, an ECO, a new library corner -- because the model is a snapshot, not a live view; a stale ETM reports timing that no longer matches the block it represents.
• Because the internal gates are gone, per-cell debug inside the block -- finding exactly which gate or net causes a slow arc -- is not possible from the top-level run; the designer has to go back to the block-level session for that.
• A block usually needs a separate ETM per corner and mode it will be analyzed under at the top level, since the model's delay numbers are only valid for the PVT and SPEF corner combination it was extracted at.

Follow-up Question & Model Response

If an ETM hides the block's internal gates, how does a designer debug a boundary timing failure the top-level run reports against it?

Candidate Model Response: The top-level run with the ETM can only say that a particular input-to-output path through the block is too slow or too fast -- it cannot say which internal net caused it, because those nets no longer exist in the model. The designer takes the specific boundary arrival and required times the top-level report shows for that block instance and re-creates the same input conditions in a block-level session that still has the full netlist loaded. From there, a normal report_timing (PT) run inside the block finds the actual internal critical path using the same boundary constraints the top level assumed. This two-level workflow is exactly why an ETM's boundary constraints -- input transition, drive strength, load -- have to match what the top level actually presents, or the block-level debug session won't reproduce the failure at all.