Why does an ETM hide internal timing arcs, and what risk does that create at the top level?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
An extracted timing model (ETM) keeps only enough information at each boundary pin -- arrival time, required time, and the constraints tied to it -- to reproduce the block's external timing behavior, and deliberately drops the internal gates and nets that produced those numbers. That compression is exactly what makes the model small and fast, but it also means the top level cannot see or verify any assumption baked into the block at extraction time, so a mismatch between what the block assumed and what the top level actually presents can go undetected.
Technical Explanation
Every ETM boundary arc is only valid for the input conditions -- drive strength, transition time, load -- the block assumed when extract_model (PT) built it; the model has no internal logic left to re-derive the arc if those conditions change.
- If the top-level design later connects the block's input to a driver with a different transition time than the ETM assumed, the model has no way to recompute the arc correctly -- it can only apply the boundary timing it was given, which may now be wrong in either direction.
- Because internal nets are gone, the tool cannot report which of the block's original internal paths corresponds to a given boundary arc, so a designer cannot verify from the top-level run alone whether the assumed condition still holds.
- A block's ETM is also blind to any top-level condition that would have changed its internal timing had it been visible -- a different supply voltage on a shared rail, or a different clock uncertainty at the boundary than the block assumed when its own SDC was written.
- This is why the boundary constraints an ETM was extracted with have to be documented and matched at the top level, not just assumed to be close enough because the model still returns a number either way.
- The same hiding of internal arcs is what makes debugging a top-level failure through an ETM require dropping back to the block's own full-netlist session, since the top level genuinely cannot see inside the model to explain a bad number.
Common Mistake
The Trap: connecting a block's ETM boundary pin to a top-level driver whose actual transition time is noticeably different from what the block assumed when the model was extracted, and trusting the reported arc anyway because the tool doesn't flag a mismatch.
- Consequence: the ETM silently applies its original boundary timing to the mismatched condition, so the top-level slack number is neither the true worst case nor a conservative estimate -- it can be optimistic in either direction, and nothing in the report distinguishes a trustworthy ETM arc from one whose input assumption no longer matches reality.
Follow-up Question & Model Response
Does PrimeTime warn when a top-level driver's actual transition time doesn't match what an ETM's boundary pin assumed during extraction?
Candidate Model Response: PrimeTime applies the ETM's stored arcs to whatever condition the top-level netlist presents; it does not independently re-derive or re-verify the assumption the model was extracted with, so no automatic warning fires when the two diverge. The designer has to check this manually, by comparing the transition and load values recorded at extraction time against the actual top-level connection, usually by keeping that metadata alongside the model file itself. Some flows re-extract the ETM specifically at the boundary conditions the top level will present, closing the gap by construction rather than relying on the original assumption staying valid. Skipping that re-extraction step and reusing a generic ETM across multiple top-level integration contexts is the more common shortcut, and it is exactly where this kind of silent mismatch creeps in.
Practical Example
A DSP block's ETM was extracted assuming a 60 ps input transition on its clk_in pin, matching the test harness used during block-level qualification. When integrated into the actual SoC, the real top-level clock buffer driving that pin produces a 95 ps transition instead -- 58% slower. The ETM still returns a boundary delay computed for the original 60 ps assumption, understating the real delay by roughly 20 ps on that arc, until the integration team re-extracts the model with the actual top-level driving conditions and the true, tighter margin becomes visible.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising