A chip is too large to analyse flat every day, so blocks are analysed on their own against abstracted models of their neighbours, and the full chip is analysed flat at milestones. Both directions are needed because each proves something the other cannot.
Hierarchical (block-level) | Flat (chip-level) | |
|---|---|---|
Scope | One block with abstracted models at its boundary | The whole design with real connectivity |
Speed | Fast; runs on every block change | Slow; reserved for milestones |
Proves | The block is clean under its stated boundary assumptions | Boundary assumptions actually hold between real blocks |
Cannot prove | Anything about the neighbour's real behaviour | Which block owns a boundary finding without block context |
Typical miss | A clean block integrated against a changed neighbour | Owner ambiguity: every team waits for another to fix it |
The boundary is where hierarchical signoff fails. The recurring risks are worth naming because each has a cheap guard.
A crossing with the synchroniser on the wrong side of the boundary: each block assumes the other synchronises, and neither does. Guard: the integration checklist names the owning side of every boundary crossing.
A block model that hides crossings: an over-abstracted model presents clean pins while the internals cross freely. Guard: models are generated from the analysed block, never hand-written, and regenerated on every block change.
Version skew: the top level integrates a newer block than the one that was signed off. Guard: the dashboard records which block revision each run used, and a revision change re-opens the boundary findings.
Constraint mismatch: the block was signed off under boundary timing exceptions the top level does not apply. Guard: boundary constraints travel with the block and are reviewed at integration.
The practical rule: sign off every block hierarchically so developers get fast answers, then prove the integration flat before each milestone so assumptions get checked against reality. A flat run that only repeats block results is not wasted; it is the evidence the boundaries hold.
A boundary assumption failed: the synchroniser each block assumed on the other side is missing, a model hid the crossing, or the integrated revisions differ from the signed-off ones. The fix is at the boundary, with an explicit owner.
Because block runs prove cleanliness only under boundary assumptions. Only the flat run checks those assumptions against the real neighbours.