How do you analyze and debug placement routing congestion heatmaps?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Last updated:
Short Answer
Congestion debugging starts with a fast global-routing trial over a grid of G-cells (think of it as running a rough traffic simulation before building real roads) to estimate routing demand versus available capacity. The core metric is overflow: Overflow = Demand − Supply per G-cell, where supply is how many tracks that tile actually has (layers × tile height ÷ (width+spacing)) and demand is how many nets need to cross it.
Technical Explanation
- Congestion debugging starts with a fast global-routing trial over a grid of G-cells (think of it as running a rough traffic simulation before building real roads) to estimate routing demand versus available capacity.
- The core metric is overflow:
Overflow = Demand − Supplyper G-cell, where supply is how many tracks that tile actually has (layers × tile height ÷ (width+spacing)) and demand is how many nets need to cross it. - There are real pass/fail thresholds, not just "looks red on the map": max G-cell overflow should stay ≤2–3 tracks, and total overflow across the whole chip should be under 0.5% of total routing resources — beyond that, expect real detail-routing DRC failures.
- Once you see overflow, triage by pattern rather than just re-running placement blindly: overflow that's heavily vertical (V-overflow) usually points to a narrow macro corridor or a missing horizontal routing layer in that area.
- Overflow sitting directly on top of complex cells (AOI gates, wide MUXes) is a pin-density hotspot — these cells have many pins crammed into a small footprint, and the fix is often cell padding (spreading the cells out) rather than a floorplan change.
- An "X"-shaped overflow pattern is a strong tell for criss-crossing dataflow — usually caused by macros oriented so their pins face away from each other, forcing every connecting net to detour across the die; reorienting or repositioning the macros is the real fix, not just adding routing layers.
Common Mistake
The Trap: Proceeding to CTS when G-cell overflow exceeds 5 to 10 tracks. The detailed router will fail to connect pins, creating thousands of unresolvable open nets and DRC shorts.
Follow-up Question & Model Response
"What is the difference between Global Routing Cell (GRC) congestion and trial route congestion?"
Candidate Model Response: GRC congestion evaluates statistical track demand across coarse grid boundaries. Trial route performs fast planar pathfinding to identify specific layer bottlenecks.
Practical Example
Reporting Routing Congestion:
# Synopsys ICC2: Report detailed global route congestion metrics
report_congestion -grc_based -by_layer
# Cadence Innovus: Check congestion map
checkCongestion -detailedPnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
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