BeginnerQuestion 82 of 95Source: IC Compiler II Implementation User Guide: Hierarchical Timing Budgeting

What is timing budgeting, and why does each block get its own slack target?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Timing budgeting takes the total time available for a path crossing multiple blocks, one clock period, and divides it into smaller allowances for each block and each piece of interconnect the path passes through. Each block gets its own slack target because block teams typically work somewhat independently and in parallel, and giving each one a clear number to hit lets them close timing without needing the full top-level netlist available yet. Without budgeting, a multi-block path has no way to tell an individual block team whether their piece is the one using too much of the shared time.

A timeline bar split into DSP block, interconnect, and memory-controller segments totaling 2.0ns, with the interconnect segment growing and the DSP segment shrinking after renegotiation — Technical Reference DiagramWhat is timing budgeting, and why does each block get its own slack target?

Technical Explanation

The total time for a cross-block path is fixed, so budgeting is really about dividing a shared resource fairly.

A path starting in block A, crossing interconnect, and ending in block B has one total time budget, the clock period minus margin, split between A, the interconnect, and B.
The split is usually based on an early estimate of each piece's relative complexity, giving a block with more logic stages a larger share.
Each block team treats their share as a local constraint, typically an input or output delay in their own SDC, giving local closure a concrete target.
If a budget turns out wrong, say interconnect needs more time than estimated, the excess has to come from elsewhere on the same path, usually renegotiated with a block that has spare margin.
Because budgets are estimates made before full layout exists, most flows revisit and adjust them once real placement and routing data becomes available.

Common Mistake

The Trap: giving one block a generous budget "to be safe" without checking whether that starves another block on the same path.

Because the total available time for a path is fixed, over-budgeting one block always under-budgets some other piece of the same path.
A team that only tracks its own block's budget, without checking the full split adds up correctly, can end up with every block individually clean while the real cross-block path still violates.

Follow-up Question & Model Response

When an early budget estimate turns out to be significantly wrong, what's the actual process for renegotiating it between block teams?

Candidate Model Response: Renegotiating starts with the top-level team identifying, from an early hierarchical run, which cross-block path is short on time and by how much. The block with spare slack gives up some margin as a tighter local constraint, the short block gets a larger share, and both re-run local closure against the new numbers. This is easiest early in the schedule, which is why budgets are reviewed at defined milestones rather than only during a crisis.

Practical Example

A path from a DSP block through 400um of interconnect into a memory-controller block has a 2.0ns budget at 500MHz. The DSP gets 1.1ns, the interconnect 0.3ns, and the controller 0.6ns; after routing shows the interconnect needs 0.45ns, the DSP's budget is renegotiated to 0.95ns since its closure had 150ps of spare margin to give up.

Complete STA Handbook