Why can a block that passes clean standalone still fail once its ETM is integrated at the top level?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
A block's standalone signoff only checks timing against the boundary assumptions used to build its extracted timing model (ETM, a compact stand-in for the block's internal timing used at the top level), not against the real conditions the top level ends up creating. If the top level's actual clock arrival, skew, or loading at the block's boundary differs from what the standalone run assumed, the same block that passed on its own can produce a failing path once its ETM is stitched into the full-chip analysis.
Technical Explanation
- Standalone block signoff times the block using boundary constraints set by the block team, usually a budgeted or estimated version of what the top level is expected to look like.
- An ETM captures the block's internal arrival and required times at its boundary pins as a compact model, so the top level can time paths through the block without needing its full netlist.
- Because the ETM only stores results computed under the standalone boundary assumptions, any top-level condition that was not part of those assumptions is simply missing from the model, not wrong exactly, just absent.
- When the top level integrates the ETM, it applies the block's compact boundary timing to its own real clock network, real loading, and real neighboring logic, which can differ from the standalone assumptions in ways the ETM cannot correct for on its own.
- A path that crosses two blocks' ETMs plus top-level logic combines each block's boundary numbers with the real top-level interconnect between them, so a small mismatch at each boundary can compound into a larger integrated failure.
- This means "the block passed standalone" answers a narrower question than it sounds like: it confirms the block met its own assumed constraints, not that those constraints matched what the finished chip actually delivers.
- Because regenerating an ETM from scratch is expensive, most flows do not regenerate it for every top-level change; instead they compare the top level's real boundary conditions against the ones the ETM assumed and only regenerate when the gap is large enough to matter.
- This is the same staleness question a HyperScale block context refresh answers, applied specifically to the boundary timing numbers baked into an ETM rather than the whole block model.
Common Mistake
The Trap: reporting a block as timing-clean based on standalone ETM generation, and treating that as equivalent to a top-level signoff pass.
- Standalone-clean is a necessary check, not a sufficient one; skipping the integrated, full-chip check after ETM stitching can let a real failure reach signoff undetected.
- Assuming the ETM "knows" the real top-level environment overstates what the model actually captures, since it only reflects the boundary assumptions used when it was built.
Follow-up Question & Model Response
If ETM integration always needs a top-level check anyway, what does building the ETM actually save you?
Candidate Model Response: It saves the cost of re-analyzing the block's full internal netlist every time the top level changes something unrelated to that block, since the top-level run only needs the compact boundary model, not millions of internal gates. The top-level check after integration is still needed, but it is far cheaper than a full flat run across every block's real netlist, because most of the design's internal timing detail is already summarized. The savings come from runtime and turnaround time on the top-level side, not from skipping verification of the boundary assumptions themselves.
Practical Example
A DSP block's ETM is built assuming its clock input arrives with 30ps of skew relative to its data source block, based on an early floorplan. After the top-level clock tree is finalized, the real skew at that same boundary is 85ps, because the two blocks ended up farther apart than the early floorplan assumed. The block's standalone signoff, run against the 30ps assumption, showed 25ps of hold margin at that boundary; once the ETM is integrated into the top-level run with the real 85ps skew, the same path shows a 30ps hold violation, one that never existed in the block's own standalone report. Because the block's internal logic was never the problem, the fix is a top-level clock tree adjustment near that boundary rather than any change inside the DSP block itself.
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