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
  • 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
    • The Whiteboard Framework
    • Design a SoC on a Whiteboard
    • Integration Storm and Budget War Scenarios
      • The Integration Storm
      • The Budget War
      • Strong Answers, Weak Answers and Lessons
    • Rapid-Fire Questions by Section
    • Numeric Drills
  • Capstone: Integrate NanoSoC14
Loading lesson

←Integration Storm and Budget War Scenarios
  1. Topics
  2. SoC Design
  3. SoC Interview Prep
  4. Integration Storm and Budget War Scenarios
  5. The Budget War
On this page

    Part 13 of 14, lesson 8 of 16Part 13 of 14/Interview Prep/Lesson 8 of 16All levels

    The Budget War

    Area, power, timing and bandwidth collide across owners: a ledger, a timeline, and the decision that ends each fight.

    Why it matters

    Budgets collide because every owner spends margin locally and discovers globally: the DMA owner widens a FIFO, the CPU owner adds a feature, the power owner inherits the sum. The interview question hands you four owners and one overdrawn ledger and asks who gives up what. The answer is never an opinion about whose block matters most; it is arithmetic, a burn-down, and a decision rule written before the fight. This lesson runs the war as a timeline with NanoSoC numbers.

    The core idea

    The ledger opens the war. Area: blocks sum to 0.585 mm², routing and fill add 0.070, the core is 0.655 against a 0.940 budget, utilisation 69.7 percent, with 0.285 mm² of headroom. Power: RUN totals 82.74 mW against an illustrative 80 mW envelope, overdrawn by 2.74; the CPU core alone is 39.20, nearly half. Timing: the CPU word read costs 93.75 ns against an illustrative 90 ns target, over by 3.75 ns, which is less than one system clock (10.417 ns). Bandwidth: two streams sharing one bank deliver 180.7 MB/s each against an illustrative 250 MB/s demand. Four owners, four deficits, one meeting.

    The timeline runs the decisions. First, power: the overdraw is in RUN, so IDLE gating (16.89 mW total) cannot close it, and the PLL cannot be switched off while the CPU runs. The ledger shows the CPU core is 47.4 percent of RUN, and its dynamic power is 38.00 mW, so closing 2.74 mW means taking 7.2 percent out of the CPU's switching activity, for example finer clock gating or operand isolation, at no cost in frequency. Strong answer: price that single lever, name its owner and keep the clocks, because lowering clk_cpu would also lengthen the read path that is already over its target. Weak answer: demand every block cut 10 percent, which taxes the 0.10 mW DMA leakage while the CPU burns 38.

    Second, timing: the read path misses its illustrative 90 ns target by 3.75 ns, and the DMA owner offers a registered select that adds a system clock to every access to ease the critical path. That moves the wrong way: 93.75 ns becomes 104.17 ns. Strong answer: first ask whether the target is a requirement; if it is, only a whole system clock can be saved (for example one cycle of memory read latency, giving 83.33 ns), priced against the macro timing, and the registered select is refused because it is a global tax on every window. Weak answer: accept the slice everywhere and re-open the bandwidth budget, since every access just gained 10.417 ns. Third, bandwidth versus area: the second-DMA variation from the design topic reappears as a demand, and the ledger answers it: split banks already deliver 722.8 total, so placement fixes the 250 MB/s demand at zero area, and new hardware is refused with the allocator check as evidence. The war ends with the decision log: each deficit, the option priced, the owner, the date. Opinions fade; the log is what the next war reads.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    # The war as a ledger: every deficit priced from the NanoSoC tables.
    area_core, area_budget = 0.655, 0.940
    assert abs(area_core / area_budget - 0.697) < 0.002, area_core / area_budget
    run_mw, run_budget = 82.74, 80.0  # budget is an illustrative teaching value
    assert run_mw > run_budget
    cpu_share = 39.20 / run_mw
    assert abs(cpu_share - 0.474) < 0.002, cpu_share
    read_ns, read_target = 93.75, 90.0  # target is an illustrative teaching value
    assert read_ns > read_target
    T_SYS = 1e3 / 96  # ns
    assert read_ns - T_SYS < read_target < read_ns  # only a whole system clock can be saved
    assert read_ns + T_SYS > read_ns  # the registered select moves the wrong way
    cpu_dyn_cut = (run_mw - run_budget) / 38.00
    assert abs(cpu_dyn_cut - 0.072) < 0.001, cpu_dyn_cut
    shared_each, bw_demand = 180.7, 250.0  # demand is an illustrative teaching value
    assert shared_each < bw_demand
    split_each = 361.4
    assert split_each > bw_demand  # placement, not hardware, wins the bandwidth fight
    print(f"area headroom {area_budget - area_core:.3f} mm2; power over by {run_mw - run_budget:.2f} mW")
    print(f"CPU share {cpu_share * 100:.1f}%; CPU switching cut needed {cpu_dyn_cut * 100:.1f}%; read over by {read_ns - read_target:.2f} ns")
    print(f"shared {shared_each:.1f} < demand; split {split_each:.1f} > demand: placement wins")
    print("PASS: four deficits priced; bandwidth settled without new hardware")

    What the review looks for

    • The ledger precedes the negotiation: every deficit is a subtraction with named inputs, not an adjective.

    • Each decision names what was refused and why: the global pipeline tax, the PLL cut, the second DMA hardware.

    • The decision log records deficit, priced option, owner and date; the next war starts from the log.

    Verify and debug

    Recompute the ledger from the the NanoSoC tables by hand: area from section 10.1 plus 12 percent, power by state with the idle factors, the read from the latency table, the sharing from the per-link table. If any subtraction needs a number the NanoSoC tables do not contain, label it illustrative before quoting it, and say who owns confirming it. A budget war fought with unsourced numbers is two opinions shouting; sourced numbers end the meeting.

    QoS starvation: a bulk master with fixed higher priority starves a latency-critical one, and the symptom appears only with all masters active. Budget wars that allocate only averages, never worst-case shares, rediscover this in silicon.

    Ask who owns the margin before discussing any number. The owner decides; the ledger advises. Candidates who price options without asking ownership get the arithmetic right and the politics wrong.

    Check yourself The CPU owner offers to cut the I-cache to fund the DMA FIFO. What is the priced response?

    The I-cache is 0.025 mm² and 4.30 mW of the budget; a line fill is 125 ns against 93.75 for a word, so shrinking it trades a small area for misses that cost the fabric far more. Price both sides: area saved versus expected miss penalty times the workload, and refuse unless the workload is named.

    Related topics

    • The Integration Storm

    • Next: Strong Answers, Weak Answers and Lessons

    • SoC: Margin Burn-Down

    Previous

    257 / 289

    Next: Strong Answers, Weak Answers and Lessons

    Up next

    Up nextStrong Answers, Weak Answers and Lessons

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error