Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
    • Partitioning and Hierarchy
    • Area Budgets
    • Timing Budgets Across Hierarchy
    • Power Budgets
    • Bandwidth Budgets
    • Budget Governance
      • Contracts with Owners
      • Margin Burn-Down
      • Budget-Change Process
    • Multi-Die and Chiplet View
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Budget Governance
  1. Topics
  2. SoC Design
  3. Architecture and Budgets
  4. Budget Governance
  5. Budget-Change Process
On this page

    Part 2 of 14, lesson 18 of 21Part 2 of 14/Architecture and Budgets/Lesson 18 of 21All levels

    Budget-Change Process

    Escalation and the budget change: who decides, what the entry records, and how the books stay balanced.

    Why it matters

    Every project moves a number mid-flight — the fabric needs 0.008 more, the power envelope tightens, a use case adds bandwidth. Without a process each change is a quiet edit and the books drift; with one, each change is a balanced entry with a reason, a cover and a signature.

    The core idea

    Escalation runs in four steps. The owner proposes a cover first: trade, restructure or descope within their rows. If no cover fits, the integrator spends top margin and records the draw. If margin cannot cover it, the change board replans: cut scope, slip the use case, or grow the die budget as a recorded change entry that keeps the old burn-down chart and starts a new segment. If the board cannot agree, the decision escalates with the data, never with the volume — both options priced, both risks stated. Every approved change is one ledger entry: what moved, by how much, covered by what, signed by whom, on what date.

    Step

    Decides

    Example

    Owner cover

    Block owner

    Fabric takes SBR slack of 0.002

    Margin spend

    Integrator

    Draw 0.006 of area headroom (0.285 to 0.279)

    Replan

    Change board

    Grow die budget or cut the second DMA

    Escalate with data

    Project lead

    Both options priced with risks stated

    The calculator

    The script validates a change entry: the books balance (covers equal the move) and the approver matches the step.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    authority = {"owner-cover": "block-owner", "margin-spend": "integrator",
                 "replan": "change-board", "escalate": "project-lead"}
    def check(entry):
        balanced = abs(sum(entry["covers"]) - entry["move"]) < 1e-9
        return balanced and authority[entry["step"]] == entry["approver"]
    change = {"row": "xbar-area", "move": 0.008, "covers": [0.002, 0.006],
              "step": "margin-spend", "approver": "integrator"}
    assert check(change)
    # The check can fail: an unbalanced entry and a wrong approver are both rejected.
    assert not check({**change, "covers": [0.002, 0.004]})
    assert not check({**change, "approver": "block-owner"})
    # Headroom falls by the margin part only: the 0.002 trade moves between rows.
    ledger = {"headroom": 0.285}
    ledger["headroom"] = round(ledger["headroom"] - change["covers"][1], 3)
    assert abs(ledger["headroom"] - 0.279) < 0.0005
    print(f"PASS: change balanced by {change['covers']}; headroom now {ledger['headroom']}")

    What the review looks for

    • Every change entry balances: covers sum to the move, with no residual.

    • Approver matches the step; owner covers never spend top margin on their own authority.

    • The ledger version bumps on every entry, and consumers regenerate from the new version.

    Verify and debug

    Sum the covers before reading the justification: an entry that does not balance is rejected whatever its story. Then check the approver: a margin spend signed by a block owner is an escalation that skipped its step. Both checks run in the script above; run it on every entry.

    A change approved in the ledger but not in the build. The fabric entry says 0.048 mm2, headroom 0.279, yet the floorplan script still reads 0.040 and the area report passes against the old number, so two truths exist: the approved one and the built one. The entry is not closed until every consumer (floorplan, power and area scripts, the review pack) names the new ledger version. Make the version a required field in each consumer so a stale one fails.

    If handed the overrun scenario, walk the four steps in order and refuse to skip: cover, margin, replan, escalate. Skipping to replan spends authority you do not have.

    Version the ledger and regenerate from it: the header files, the decoder parameters and the verification assumptions all derive from the budget version the change entry bumps. A change recorded in the ledger but not regenerated into the consumers creates two truths — the approved numbers and the built numbers — and the next failure lands in the gap between them. The entry is only closed when every consumer names the new version.

    Check yourself The fabric needs 0.008 and the SBR offers 0.002. What is the entry?

    Move 0.008 to the fabric row, covered by a 0.002 SBR trade plus a 0.006 headroom draw (0.285 to 0.279), approved by the integrator as a margin spend, ledger version bumped.

    Related topics

    • Margin Burn-Down

    • Arch: Architecture Signoff

    • Arch: Budget Negotiation

    Previous

    35 / 289

    Next: Designing the Address Map

    Up next

    Up nextDesigning the Address Map

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Contracts with Owners