Every SoC is a bet placed early and paid for late: the partition you draw, the area you grant each block, the nanoseconds you allow each path, the milliwatts you promise the package, and the megabytes per second you guarantee each master. On NanoSoC those bets fit on a few tables — a 0.655 mm2 core in a 0.940 mm2 budget, 82.74 mW in RUN against an illustrative thermal limit, 361.4 MB/s sustained per fabric link — but the method is the same at any size. This section teaches the integrator's side of architecture: choosing boundaries for clock, power and protocol reasons, rolling numbers up from the NanoSoC specification so every total adds up, and running the budget as a contract with owners and margin until tapeout. For the ledger mechanics behind block budgets see the PPA Budget Ledger; for negotiating them between teams see Budget Negotiation.
Topic | What it covers | After it you can... |
|---|---|---|
Flat versus hierarchical design, boundary choices, feedthroughs, the NanoSoC partition rationale | Decide what is a partition and defend every boundary signal. | |
Area roll-up from the NanoSoC specification, utilisation and margin, how budgets move through the flow | Roll block areas to a die budget and rebalance an overrun. | |
Cycle and nanosecond budgets for crossing paths, I/O delay budgeting, margin allocation | Hand a block a timing budget it can close and check one it returns. | |
Dynamic and leakage roll-up per domain and state, thermal envelope, budget versus measured | Prove the chip fits its power and thermal envelope in every state. | |
Workload to bandwidth and latency needs, the link table, spotting the bottleneck link | Name the bottleneck link for any NanoSoC workload with arithmetic. | |
Contracts, margin burn-down, escalation, the budget-change process | Run the budget table with owners and call a rebalancing review. | |
What changes when the SoC splits across dies: links, partitions, known-good-die, cross-die budgets | Explain which budgets survive a die split and which must be renegotiated. |
Suggested order: partitioning first, because boundaries decide what every later budget is attached to; then area, timing, power and bandwidth, which can be read in any order once partitioning is set; then governance, which assumes you have read at least one budget topic; finally the multi-die view, which replays the whole section across two dies. Readers chasing a number can start at its budget topic directly.
Because blocks are designed in parallel against their budgets. Without an early contract each block optimises locally and the chip fails globally; measurement only confirms the bet the budget placed.