routing congestion

Picture the wires on a chip as cars and the metal layers as a stack of one-way streets, each street striped into a fixed number of parallel lanes called routing tracks. Routing congestion is a traffic jam: in some region of the floorplan, more nets want to pass through than there are lanes to carry them. The router can't widen the road, so the overflowing wires either take a long detour around the jam or, if there's truly no path, get left unconnected. It is the single most common reason a placement that looked fine actually can't be routed.

To measure it, the router overlays the die with a coarse grid of small tiles (global-routing cells), and on each tile boundary it compares supply, the number of tracks crossing that edge after subtracting blockages and pre-routes, against demand, the number of nets that want to cross. Wherever demand exceeds supply you get overflow, and the tool paints those tiles as a congestion hotspot. Detours then cost you real silicon: longer wires mean more resistance and capacitance, more vias, more delay, and so congestion quietly turns into timing and signal-integrity problems even when nothing is outright shorted.

The root cause is almost always upstream, in placement. Cramming cells too tightly, clustering pin-dense or high-fanout logic, or letting macros form narrow channels all concentrate wire demand into one spot. That's why congestion is estimated early, during placement via a quick trial (global) route, and only finally resolved during global and detailed routing. The usual cures work on the placement, not the wires: lower the local cell density, add cell padding or placement blockages near the hotspot, run congestion-driven placement, or restructure the offending nets, then re-route and re-check.