How do you estimate whether a macro channel is wide enough?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Start from usable routing layers and their track pitches — that's your raw supply of routing resource through the channel, per layer, per direction. Then subtract everything that eats into that raw supply before any signal net gets to use it: power/ground strap width and spacing, placement/routing blockages, via keepout margins around those straps, and any shielding requirements on sensitive nets.
Technical Explanation
- What's left after those subtractions is your usable directional capacity — and that's the number you actually compare against demand, not the raw channel width. A channel that "looks wide" on the floorplan can still be resource-starved once PG straps and keepouts are accounted for.
- Demand-side, don't forget facing-pin density (how many pins on the two macro edges actually need to route through this channel), parallel buses or wide interfaces, clock/reset routing needs, space reserved for repeater/buffer insertion on long nets, and macro-corner access (corners are congestion hot spots because routing detours around blocked macro edges).
- One subtlety that catches people out: space you've physically reserved for wires in the channel is not automatically usable for standard cells if you need to place logic there instead — routing-reserved space and cell-placeable space are not interchangeable, so budget them separately.
Formula Or Decision Rule
Approximate usable tracks = floor(usable channel width / relevant pitch), before detailed rule reductions.
What To Check
- Warning sign: The geometric track count looks adequate but vias and PG shapes remove access.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Build a channel congestion map, inspect layers and pin walls, then adjust geometry or resource allocation.
Command Checks & Actions
- create_channel_congestion_map -channel_width_threshold <width>: estimates congestion in channel regions
report_congestion-mode summary: reports routing demand, capacity, overflow, or hot spots
Run only the commands needed for this question. Save the report with the floorplan version and analysis context.
Healthy, Suspicious & Hard-stop Results
- Healthy: Start with usable routing layers and track pitches, subtract PG straps, blockages, via keepouts, shielding, and edge rules, then compare remaining directional capacity with signal and pin demand.
- Hard stop: required legality or physical feasibility is missing or unexplained.
Common Mistake
The Trap: Do not hide the symptom with an arbitrary utilisation, halo, channel, blockage, pin move, or die-size change.
What The Interviewer Is Testing
” to measurable physical evidence and an owned correction.
Follow-up Question & Model Response
"* Candidate Model Response: Model response: “I would change it if the same controlled rerun shows that the geometric track count looks adequate but vias and PG shapes remove access. ”
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.

Continue practising