AdvancedQuestion 52 of 63Source: Synopsys PrimeTime User Guide: Clock Definition Across Hierarchical Block Boundaries

How does hierarchical timing analysis handle a clock that crosses a block boundary?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A clock entering a block from the top level has to be defined consistently on both sides of the boundary -- same period, same source latency assumption, same propagation state -- or the block's internal timing and the top level's view of that same clock will silently disagree. Hierarchical flows handle this by generating the block's own clock definition from the top-level clock tree information available when the block is built, then re-verifying that definition once the real top-level clock tree exists.

Technical Reference DiagramHow does hierarchical timing analysis handle a clock that crosses a block boundary?
A clock signal entering a block boundary, shown twice: once with an early estimated 180ps latency feeding a green clean block-level signoff, and once with the real post-CTS 240ps latency revealing a hold violation on the same internal path.

Technical Explanation

A block built in isolation needs its own SDC, including a clock definition for every clock reaching its boundary pins, but the block itself usually has no visibility into the actual top-level clock source or the buffers that will eventually drive it.

  • Early in the flow, the block's clock is typically defined using an estimated latency and uncertainty budgeted from the top level, since real clock tree synthesis (CTS) hasn't happened yet.
  • Once top-level CTS exists, the actual source latency and skew the clock experiences before reaching the block boundary become known, and the block's clock definition -- or its ETM -- needs updating to reflect that real value instead of the earlier estimate.
  • If the block's internal clock definition assumes different latency or uncertainty than what the top level's clock tree actually delivers, the block's own signoff numbers no longer correspond to how the clock will really behave once integrated, even if each side's timing run is individually clean.
  • Propagated versus ideal clock modeling has to match too: a block analyzed with an ideal clock internally, then integrated under a top level that treats the same clock as propagated, can show a very different hold margin at the boundary than either side's isolated report suggested.
  • This is one reason hierarchical flows re-run a check after final integration -- a check_timing (PT) style pass confirms the block's clock assumptions and the top level's actual clock tree agree -- rather than trusting the block-level and top-level signoffs to compose correctly on their own.

Common Mistake

The Trap: signing off a block using its early-flow estimated clock latency and never re-verifying that estimate once the real top-level clock tree is built, because the block's own report already looked clean.

  • Consequence: the block's internal hold margin, calculated against an optimistic estimated latency, can evaporate once the real clock tree's actual skew is substituted in -- turning a block that reported comfortable margin into one with a genuine hold violation, discovered only at final chip-level integration.

Follow-up Question & Model Response

If the block's clock assumption and the top level's real clock tree disagree, which side's number does a designer actually trust for signoff?

Candidate Model Response: Neither report is automatically correct on its own -- the block's isolated run only reflects whatever clock assumption it was given, and the top level's flat view, if one exists, may not capture every internal detail the block's own analysis has. The designer trusts the block's internal timing only once its clock definition, or its ETM's boundary clock arc, has been refreshed with the real, post-CTS latency and skew values from the actual top-level clock tree. Practically, that means re-verifying the block after top-level CTS completes, not relying on whichever signoff ran first chronologically. Any hierarchical flow that skips this refresh step is effectively signing off the block against a clock that doesn't exist in the final chip.

Practical Example

A graphics block is floorplanned early with an estimated 180 ps clock source latency budgeted from the chip's clock plan, and its block-level signoff shows 35 ps of hold margin on its tightest internal path under that assumption. After top-level CTS, the actual clock tree delivers 240 ps of source latency to that same boundary pin, 60 ps more than estimated -- refreshing the block's clock definition with the real value turns the reported 35 ps hold margin into a 25 ps violation, caught only because the flow re-verified the block after integration instead of trusting the original estimate.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
VLSI Physical Design Planning Handbook — fourteen chaptersDesign PlanningFourteen chapters, floorplanning through timing budgets. →

Continue practising

Related STA questions

AdvancedWhat is an extracted timing model (ETM), and why use it for hierarchical blocks?BeginnerWhat is timing budgeting, and why does each block get its own slack target?BeginnerWhat is hierarchical timing analysis, and why analyze a block on its own?AdvancedA team proposes leaving clocks ideal (skipping propagated timing) post-CTS to save runtime near a deadline. How do you respond?