ExpertQuestion 61 of 69Source: Synopsys PrimeTime User Guide: Bottom-Up Hierarchical Timing With Budgeted Constraints

How do you budget timing across a hierarchical partition?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Budgeting means splitting a top-level path's available time among the blocks it passes through, before every block has its own final implementation, so each block team knows its own setup and hold targets. Because the total time on a path is fixed, giving one block extra margin necessarily takes margin away from another block on the same path, so budgeting is a negotiation over a shared, limited resource, not just a per-block guess.

A 2.5ns path split into block A (0.9ns budget, 1.05ns actual), an interconnect segment (0.3ns), and block B (1.3ns budget, 100ps spare), with 100ps reallocated from B to A and 50ps trimmed from the interconnect. — Technical Reference DiagramHow do you budget timing across a hierarchical partition?

Technical Explanation

A hierarchical partition splits a design into blocks that get implemented and timed somewhat independently, with a top-level wrapper that stitches their boundary timing back together.
Before a block's real implementation exists, the top-level owner allocates a budgeted constraint, an assumed arrival time and required time at each boundary pin, so the block team can run standalone timing closure against something concrete.
Because a path can cross two or three blocks plus the top level, the period available for that whole path splits across every segment, so over-budgeting one block's share directly shrinks what is left for the others on the same path.
The tool does not know the real interconnect delay for a path until integration, so a budget is always an engineering estimate, typically informed by prior floorplans or a similar previous design, not a guaranteed number.
If one block later needs more time than its budget allowed, for example because its logic ended up deeper than planned, that time has to come from somewhere else on the same path: another block, the top-level interconnect, or a margin reserve set aside up front for exactly this situation.
Because budgets are renegotiated as blocks mature, the top-level owner typically tracks each block's allocation per path group centrally, so a change in one block's ask is visible to whoever owns the rest of that path.

Common Mistake

The Trap: treating each block's timing budget as fixed and independent, and letting a block team quietly claim extra margin to close their own timing without telling the owner of the rest of the path.

A block that "solves" its own closure by silently eating into shared margin can leave the next block, or the top level, with an impossible budget nobody notices until integration.
Budgeting every block generously "to be safe" without checking the sum against the real path period produces an over-constrained partition where no combination of real block results can add up to a passing chip.

Follow-up Question & Model Response

What happens when integration timing shows the sum of every block's actual delay does not fit the path period, even though every block met its own individual budget?

Candidate Model Response: That means the budget split itself was wrong, not any one block's work, since each block met the number it was given. The fix is to go back to the shared budget and re-split the available time, usually by finding which block has the most realistic room to give something back, rather than assuming the block that is now over is at fault. This is why budgets get tracked centrally rather than negotiated block to block, because only the owner of the whole path can see whether the total still adds up once every block reports its real numbers.

Practical Example

A path with a 2.5ns period crosses block A, budgeted 0.9ns, an interconnect segment budgeted 0.3ns, and block B budgeted 1.3ns. Once block A's real implementation lands, its actual internal delay comes in at 1.05ns, 150ps over budget. Because the path total is fixed at 2.5ns, that 150ps has to come from somewhere: the top-level owner reviews block B's post-route timing, finds it closing with 100ps of spare margin, and reallocates 100ps from B to A, then works with the interconnect team to trim the remaining 50ps from routing slack on that segment, rather than asking block A to redo its floorplan. The revised budget file is reissued to both block teams so the next closure pass on either side starts from the same, agreed numbers.

Complete STA Handbook