BeginnerQuestion 80 of 95Source: IC Compiler II Implementation User Guide: Hierarchical Timing Analysis

What is hierarchical timing analysis, and why analyze a block on its own?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Hierarchical timing analysis breaks a large design into smaller blocks and times each one somewhat independently, using a simplified model for how each block connects to the rest of the chip instead of loading the entire flat netlist in one run. Analyzing a block on its own lets a team get fast timing feedback and sign it off before the whole chip's netlist even exists in one piece, and it keeps the top-level run from becoming too large to manage. This matters most on large SoCs where a single flat run across the whole design would be too slow or too large to iterate on.

A large 50,000-cell block reduced to a small boundary-timing box with 40 labeled pins feeding a much smaller top-level netlist diagram — Technical Reference DiagramWhat is hierarchical timing analysis, and why analyze a block on its own?

Technical Explanation

Hierarchical analysis trades some full-chip visibility for a large cut in runtime and memory.

A block owner analyzes their block's internal paths in detail, using the block's own SDC constraints, before it is even integrated into the full chip.
To let the top level check paths crossing into and out of a block without needing its full internal netlist, the flow uses an abstracted model of the block's boundary timing.
This abstraction typically hides internal gate-level detail and keeps only what the top level needs: input-to-output delays, and internal setup/hold checks at boundary pins.
Internal-only violations, ones never touching a chip-level boundary pin, are the block owner's responsibility to close using the full netlist, not something the top-level run can see.
The abstraction is chosen deliberately for parts of the design big or reused enough, such as a hard macro, to justify it.

Common Mistake

The Trap: assuming a block that passed its own standalone timing signoff is automatically correct once integrated at the top level.

A block's standalone boundary input/output delay assumptions are only estimates of the real top-level environment until it is actually integrated and checked against real, final constraints.
Skipping a proper top-level check of the integrated block's boundary paths can let a mismatch slip through undetected.

Follow-up Question & Model Response

If the top-level run uses an abstracted model instead of the block's real gates, how much accuracy does that abstraction actually lose?

Candidate Model Response: The abstraction preserves the timing behavior that matters at the boundary, so for paths passing through the block once, it is usually close to a full flat analysis. Accuracy loss shows up mainly where the abstraction was not designed to capture something, such as a path entering and exiting the same block through different pins, or distance-dependent variation it does not represent in detail. Flows periodically validate the hierarchical result against a full flat run on a subset of the design.

Practical Example

A memory-controller block with 50,000 internal cells is abstracted to a boundary model exposing only its 40 input and output pins and their delay relationships. The top-level run then completes in under an hour, instead of the 14 hours a full flat run including the controller's internal netlist would take.

Complete STA Handbook