How do you reconcile a bottom-up block's budgeted constraints against the top level's flat timing run?

Short Answer

A block closed bottom-up against budgeted constraints, assumed boundary timing rather than real top-level values, needs to be checked against a flat, full-chip run once the top level exists, because the budget was always an estimate. Reconciliation compares the block's assumed boundary arrival and required times to what the flat run actually computes at those same pins, and treats any gap as a signal that the budget, the block, or both need another pass.

Technical Explanation

• Bottom-up closure lets a block team start timing work before the full top-level netlist exists, by sourcing a budgeted-constraints file that stands in for the real top-level environment.
• A flat timing run analyzes the entire chip's netlist together, computing real boundary arrival and required times instead of the assumed ones the budget used.
• Reconciliation compares the two side by side at every block boundary pin: if the flat run's real arrival time is later than the budget assumed, the block effectively has less time than it thought it did, and vice versa.
• Because the budget was set before layout details were final, some mismatch is expected; the practical question is whether the mismatch is small enough to absorb in margin or large enough to require re-closing part of the block.
• The tool does not automatically know which number to trust; the flat run is the ground truth once it exists, so a mismatch is resolved by updating the block's constraints to match reality, not by editing the flat run's numbers to match the budget.
• Because rerunning the full block flow for every small mismatch is expensive, teams usually set a threshold, similar to context refresh for HyperScale, past which a mismatch triggers real rework rather than being absorbed into existing margin.
• Reconciliation is usually easiest to run pin by pin at the block boundary, since a mismatch buried inside an aggregate slack summary is much harder to trace back to which specific budget assumption was wrong.
• Once reconciliation is done for a milestone, the corrected numbers typically replace the original budget file for that block, so the next design pass starts from the reconciled values instead of repeating the same comparison against the original guess.

Follow-up Question & Model Response

If the flat run shows a large mismatch on one boundary pin, do you always have to re-implement the block?

Candidate Model Response: Not always; the first step is checking whether the block has spare margin elsewhere on the affected path that can absorb the difference, similar to reallocating budget between blocks. If the block genuinely has no slack to give, then part of the block, usually just the logic near that boundary pin, needs another implementation pass with the corrected constraint. Treating every mismatch as an automatic re-implementation wastes schedule on cases the existing margin could have covered, so reconciliation always starts with a slack check before deciding whether real rework is needed.