When It Is Actually a Placement Problem
Here is the instinct that gets new physical designers stuck. A routing run fails, so the natural next move feels like a routing fix: raise DRT_OPT_ITERS, relax a layer constraint, try a different router setting, run again. Sometimes that works. But when the failure looks like the clustered report from the previous article, several violation types crammed into one small neighbourhood with at least one net flatly Unrouted, no routing setting will fix it, because routing was never the problem. Recognising that is the most valuable skill in this module.
Why congestion traces back to placement
Think about what placement decided in Module 4: where every cell sits. If placement packs too many cells into too small a region, a high local density even when overall utilisation looks reasonable, it does not just make a tight fit for the cells. It compresses the routing channels between them, because the tracks available to route nets through that region are the same physical space the cells compete for. Global routing’s congestion estimate already hints at this. But if placement was dense enough, no amount of clever track assignment or rip-up-and-reroute can create capacity that was never there.
The router is not failing to do its job. It is correctly reporting that the job, as set up, is impossible. Asking it to try harder is asking it to solve a geometry problem with no solution at that density.
Two root causes, two fixes
Not every congested failure has the same origin, and the fix differs:
| Symptom | Likely root cause | Where to fix it |
|---|---|---|
| Congestion clustered in one interior region, rest of the design routes fine | Local placement density too high in that area | Module 4: lower PL_TARGET_DENSITY, or otherwise spread that region out with whitespace or cell padding |
| Congestion spread across the whole design, worse near the edges or along the narrow dimension | The core’s shape does not leave enough routing room in some direction | Module 3: revisit the aspect ratio or overall utilisation; a needlessly narrow or over-packed die squeezes routing everywhere |
The distinction matters because the wrong fix wastes iteration time. Lowering density everywhere when the real problem is a narrow die barely helps; the die is still narrow. Reworking the aspect ratio when the real problem is one over-dense cluster is a much bigger, slower change than the targeted density fix that region needed.
The practical habit that separates the two is to look at where the trouble concentrates. A congestion heatmap or a violation cluster isolated to one small region points at local density. The same evidence spread fairly evenly across the core, worse in whichever dimension is shortest, points at the floorplan’s shape. Iterating on routing config first, before looking at the heatmap for that region, occasionally buys a little headroom, but if the cause is a real local space shortage you are treating a symptom that resurfaces on the next revision.
Tracing the cluster to its cause
Recall the report from the previous article: violations 1, 2 and 14 clustered around x = 118000 to 142000, y = 176000 to 182000, plus parity_check unrouted with no legal path within congestion bounds. The UART’s parity logic is a small, densely interconnected cluster of combinational cells that a wirelength-minimising placer naturally pulls close together.
The most likely root cause is local placement density. A tight, heavily interconnected group like that is exactly what Module 4’s placer packs into a locally over-dense pocket even when the overall target looks reasonable, and it matches the first row of the table: trouble isolated to one region. Module 4 is where to look first, at the heatmap for that region and a PL_TARGET_DENSITY reduction or cell padding, rather than a Module 3 aspect ratio change or a routing knob.
Practice Exercise
A different UART run shows congestion and violations spread across nearly the entire core, worse along the design’s shorter vertical dimension, with no single hotspot. PL_TARGET_DENSITY is already a conservative 0.45. What does this pattern suggest, and why would lowering density further likely not help much?
Solution
Broad, roughly uniform congestion that is worse along the short dimension, with density already conservative, points at the floorplan’s aspect ratio. If the core is narrower in one dimension than the total routing demand comfortably needs, every net crossing that dimension competes for the same limited channels regardless of how sparsely cells are placed within the shape. Lowering density spreads cells out but cannot create the tracks a narrow die does not have room for. The fix that addresses this symptom is revisiting the aspect ratio or die size in Module 3.
You can now diagnose the two root causes behind a routing failure. The module’s capstone puts it into practice end to end: deliberately break the UART’s placement, watch routing fail, diagnose it with this article’s method, and fix it for real.