What is the correct order for fixing an early congestion hot spot?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Last updated:
Short Answer
Resist the urge to jump straight to "make the die bigger" — that's the most expensive fix and often masks (rather than solves) the actual root cause, so it should be close to your last resort, not your first move. Step 1: confirm the data itself is trustworthy — check that the netlist, constraints, and PG assumptions feeding the congestion estimate are actually current and correctly loaded; a stale or misconfigured input can produce a phantom hotspot that doesn't really exist.
Technical Explanation
- Step 2: locate exactly where demand exceeds capacity — which layer, which direction (horizontal/vertical), and which specific region. Don't treat "congestion in the block" as one problem; it's usually one specific resource in one specific area.
- Step 3: diagnose the physical cause before touching anything — is it driven by pin density at a macro edge, a high-fanout bus routing through a narrow channel, PG straps eating capacity, a placement/routing blockage, or a layer restriction limiting available direction?
- Step 4: make the smallest change that addresses that specific cause — nudge a macro, widen one channel, relax a blockage, redistribute a bus — rather than a broad, disruptive change like inflating the whole floorplan.
- Step 5: rerun the exact same congestion measurement to confirm the fix actually worked and didn't just relocate the problem somewhere else nearby.
- The discipline here is: diagnose before you cut. A quick "just make it bigger" fix without understanding root cause often just moves the hotspot, wastes area, and can even mask a real netlist or constraint issue that needed fixing anyway.
Formula Or Decision Rule
Decision rule: the fix must reduce the diagnosed demand or restore the missing capacity without moving the problem elsewhere.
What To Check
- Warning sign: Global area is increased but the same macro corner remains blocked.
- Inspect: choose one affected region, macro, row, pin, path, or net and trace the physical cause.
- Correct: Change the responsible macro, pins, channel, blockage, PG corridor, aspect ratio, or layer plan and compare before/after maps.
Command Checks & Actions
report_congestion-mode hot_spot: reports routing demand, capacity, overflow, or hot spots- create_channel_congestion_map -congestion_map_only true: estimates congestion in channel regions
Run only the commands needed for this question. Save the report with the floorplan version and analysis context.
Healthy, Suspicious & Hard-stop Results
- Healthy: Confirm data and constraints, locate demand and capacity, identify the physical cause, make the smallest causal change, then rerun the same measurement.
- 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 global area is increased but the same macro corner remains blocked. ”
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