What does an ETM actually hide, and what timing information does it keep at the block boundary?

Short Answer

An extracted timing model (ETM) hides everything happening inside a block — its gates, its internal nets, its internal paths — and keeps only the input-to-output timing arcs a neighboring block actually needs: how long a signal takes to cross the block, and what capacitance or drive strength it presents at each boundary pin. It is built so a top-level run can time paths that pass through the block correctly, without ever loading the block's real netlist.

Technical Explanation

The whole point of an ETM is to answer exactly what a top-level analysis needs from a block and nothing more, since loading every block's full netlist is what makes flat, hierarchical analysis expensive in the first place.

• What is hidden: the internal netlist. Every gate, every internal net, and every internal timing path inside the block disappears from the model — the top level never sees them and cannot report on them.
• What is kept: input-to-output timing arcs. For each input pin that can affect an output pin's timing, the model keeps the delay (and, where relevant, delay variation across corners) of that specific path through the block, generated with the extract_model (PT) command.
• What is kept: boundary electrical behavior. Each input pin's model keeps how much capacitance it presents to whatever drives it from outside the block, and each output pin's model keeps its effective drive strength, so a top-level path's delay calculation across the block boundary stays accurate.
• Why the tradeoff is worth it: a top-level run using ETMs for its sub-blocks needs a fraction of the memory a fully flat run would, since dozens of blocks' internal netlists are replaced by compact input-to-output tables.
• What breaks: trying to debug an internal timing problem using only the ETM — with no internal paths represented, a violation traced inside the block has to be debugged against that block's own full netlist, not the top-level ETM run.

Follow-up Question & Model Response

If a block has two different internal paths that both reach the same output pin from the same input pin — one fast, one slow depending on which mode is active — how does an ETM represent that?

Candidate Model Response: It depends on how the model was generated. If extracted per mode, using extract_model's per-scenario support, each mode gets its own version of that arc, correctly reflecting whichever path is active. If generated from only a single mode, the arc reflects whichever path was active during extraction, and the other mode's real behavior goes unrepresented — which is why regenerating ETMs whenever a block's active modes change matters.