A utilisation number is only useful if it leads to a decision. At 69.7% NanoSoC looks comfortable, but comfort depends on what the remaining 30% must absorb: a late memory increase, a wider fabric, a second DMA, and the routing congestion none of the block rows price. Utilisation is not a score; it is the margin expressed upside down.
A common planning guideline for a small placed design is about 70% core utilisation: dense enough to be economical, open enough to route and to absorb growth. The headroom is typically consumed in this order. Routing and buffering take the first share, because the overhead line is only an estimate until the design is routed. Engineering change orders take the second share: a metal fix needs spare sites near the fault. Planned growth takes the third. NanoSoC has reserved peripheral slots (hole H3, slots 7 to 15) that claim a little area before they exist. To make the growth share concrete the lesson prices one hypothetical addition that is not in the NanoSoC map: a 128 KB RAM block, which today would have no address (everything from 0x2002_0000 up is hole H2 and answers DECERR). A design at 90% has spent all three shares in advance; a design at 50% is paying for silicon it does not use.
# not-run: NanoSoC utilisation headroom, NanoSoC teaching values
Core 0.655 mm2 in budget 0.940 mm2: headroom 0.285 mm2 (30.3%).
Hypothetical 128 KB RAM (not in the NanoSoC map). At the NanoSoC SRAM
density, 64 KB = 0.100 mm2, so 128 KB = 0.200 mm2 of blocks; with the 12%
overhead that is 0.224 mm2.
Hypothetical second DMA plus slot logic: about 0.020 mm2 of blocks, 0.0224 mm2
with overhead.
Remaining: 0.285 - 0.224 - 0.0224 = 0.0386 mm2, about 4% of the die budget.
Verdict: 69.7% is comfortable but not generous; one growth step fits, a
third item does not.Area has a second floor that no budget table shows: the pads. If the pad ring with its drivers needs more perimeter than the core needs area, the die is pad-limited and the core utilisation number is decorative — shrinking logic no longer shrinks the die. NanoSoC with its modest pin count is core-limited, so the 69.7% is the binding constraint. The review question to ask on every project is which limit binds: quote both the core utilisation and the pad-ring perimeter check, and manage the binding one.
budget, core = 0.940, 0.655
util = core / budget
assert abs(util - 0.697) < 0.002
headroom = budget - core
assert abs(headroom - 0.285) < 0.001
# Hypothetical growth priced on the headroom, with the 12% overhead (NanoSoC teaching values).
overhead = 1.12
ram_128k = 2 * 0.100 * overhead # 128 KB = two 64 KB blocks at specification density
dma2 = 0.020 * overhead
assert abs(ram_128k - 0.224) < 0.0005, ram_128k
remaining = headroom - ram_128k - dma2
assert abs(remaining - 0.0386) < 0.001, remaining
floor = 0.03 * budget # illustrative floor kept for routing slack and ECOs
assert remaining >= floor, (remaining, floor)
# The check can fail: one more 0.020 mm2 item breaks the floor.
assert remaining - 0.020 * overhead < floor
# Pad-limited check (illustrative pad ring): die side vs the side the pads need.
import math
die_side = math.sqrt(budget) # square-die illustration, 0.970 mm
pad_side_needed = 0.700 # illustrative: pads need 0.700 mm of edge per side
limited = "pad-limited" if pad_side_needed > die_side else "core-limited"
assert limited == "core-limited"
assert (1.2 > die_side) # a ring needing 1.2 mm per side would flip the verdict
print(f"PASS: util {util*100:.1f}%, headroom {headroom:.3f}, growth leaves {remaining:.3f} (floor {floor:.3f}); {limited}")A utilisation target written down before layout, with the headroom shares named: routing, ECO, growth.
Planned growth priced against the headroom with the 12% overhead included, not assumed free.
The pad-limited check quoted beside the utilisation, with the binding limit circled.
Track utilisation weekly once synthesis starts: estimated gate area plus macro area against the same 0.940 budget. A jump of more than two points in a week means a block estimate changed, not that the tools drifted — ask which one. If utilisation crosses 80% before routing, call the rebalancing review early; the governance topic runs that meeting.
Run the pad-limited check as its own small budget: sum signal, power and analogue pads, divide by the four sides, and compare against the die side (the square root of the 0.940 mm2 die budget is about 0.97 mm, before the ring width). If the pad side wins, the project manages pad count and bump pitch instead of gate area — multiplexing functions, sharing supplies, cutting test pins. NanoSoC never reaches that regime, but the check belongs in every review pack beside utilisation, because the binding limit decides which budget the team meets weekly.
Because even modest growth — a hypothetical 128 KB RAM and a second DMA, 0.224 plus 0.0224 mm2 with overhead — claims most of the 0.285 mm2 headroom, leaving about 0.039 mm2 (4% of the die budget) for routing slack and fixes. One growth step fits; a third item needs a bigger budget.