Routing Congestion in VLSI: Causes, Analysis and Fixes

A placed design can look perfect on paper, with good utilization and positive slack, and still fail at routing. The router runs for hours, leaves thousands of shorts and spacing violations, or detours critical nets so far that timing collapses. In almost every case the root cause is routing congestion: in some part of the block, the nets need more routing tracks than the metal stack can provide.

Most congestion is decided long before the router runs, in the floorplan and placement. This guide explains how routers measure congestion (GCells, capacity, demand and overflow), its types and causes, how to fix it at each stage of the flow, and how to debug it, with illustrative worked examples, a debugging flowchart, interview questions and an FAQ.

Related reading: Physical Design Flow, Floorplan, Placement and Routing.

What routing congestion is#

Each metal layer has a fixed set of routing tracks, set by its pitch and direction (see Pitch, Spacing and Offset and Metal Layers). A region is congested when the number of nets that must pass through it, its demand, is higher than the number of usable tracks, its capacity.

The router then has three choices, all bad:

• Detour nets around the hotspot, which adds wirelength, delay and coupling.
• Squeeze nets onto other layers, which adds vias and uses up higher layers meant for long, timing-critical nets.
• Give up and leave shorts or spacing violations, which then need manual work or a new placement.

Severe congestion makes a design unroutable.

How the tool measures congestion: GCells, capacity and overflow#

Detailed routing works on individual tracks, but that is too slow for planning. So the global router divides the block into a grid of tiles called global routing cells (GCells), also called GRCs, bins or tiles. Each GCell is usually a few standard-cell rows high and a similar width.

For every boundary between two neighbouring GCells, and for every layer, the tool works out:

• Capacity: how many tracks cross that boundary in the layer's preferred direction, minus the tracks taken by power/ground straps, routing blockages, macros and pre-routed nets such as clock nets with wide spacing.
• Demand: how many global routes the router has assigned through that boundary.
• Overflow: demand minus capacity, when demand is larger. Overflow of zero means the boundary is not congested.

Tools summarise this as a congestion map coloured by demand-to-capacity ratio or overflow, plus numbers such as the total overflow, the worst overflow and the percentage of GCells that overflow in the horizontal and vertical directions. Some tools also report a hotspot score, which measures the area of clustered overflow rather than single scattered GCells.

Worked example 1: capacity and overflow of one GCell edge (illustrative)#

Take a GCell 2.0 µm tall. Its right-hand boundary is crossed by horizontal tracks on three layers. Using round, made-up pitches:

The global router assigns 52 horizontal routes across this boundary. Overflow = 52 − 44 = 8 tracks, a demand-to-capacity ratio of 52 / 44 ≈ 1.18.

Two lessons from this simple sum:

• The power grid is not free. Here it takes 6 of 50 tracks (12%) on every GCell edge it crosses. A denser power-ground grid cuts routing capacity everywhere, so PG design and congestion must be planned together.
• Overflow on one isolated edge is often absorbed by small detours; the same overflow on many neighbouring edges is a hotspot the detailed router usually cannot clear.

Real numbers depend on your technology and the tool's capacity model.

Placement density versus routing congestion#

Two maps are often confused:

• Cell density (utilization) map: how much of each placement bin is filled with standard-cell area. High density means cells are packed tightly.
• Routing congestion map: how much routing demand passes through each GCell, compared with its capacity.

They are related but not the same. A half-full bin can be badly congested if its cells have many pins or many long nets pass through it, while a very full bin of simple cells may route cleanly.

A third map, pin density (pins per unit area), is often a better early warning for local congestion, because every pin must be reached from the lowest, most crowded metal layers.

Worked example 2: same utilization, different congestion (illustrative)#

Two regions of equal area are each filled to 70% utilization.

• Region A contains mostly inverters, buffers and 2-input NAND/NOR cells, averaging about 3 pins per cell.
• Region B contains many 4:1 multiplexers, complex AOI/OAI gates and multi-bit flops, averaging about 7 pins per cell, with a similar cell count.

Region B has more than twice as many pins to connect in the same area. Even though both regions report the same utilization, region B is much more likely to show local congestion and pin-access DRCs on the lower layers. This is why tools offer pin-density-aware placement and cell padding for high-pin-count cells.

Types of congestion#

Global congestion spreads over a large area, such as a whole macro channel or the entire core at very high utilization. It usually comes from the floorplan or from too much logic for the area.

Local congestion is confined to small hotspots of a few GCells. It usually comes from pin density, high-pin-count cells, clumping of cells by timing-driven placement, or a crossbar-style piece of logic.

Directional congestion appears in only the horizontal or only the vertical direction, pointing at the layer stack, a channel's shape or macro pin orientation.

Layer congestion is overflow on some layers only: lower layers crowd with pin access and short nets, upper layers with long nets, non-default-rule (NDR) clocks and power straps.

Pin-access congestion is not fully visible in the global route. The global router models tracks across GCell edges, not the exact way each pin is reached inside a cell. A global route can look clean while detailed routing still reports shorts and spacing violations around dense groups of cells. At advanced nodes, cell-edge and diffusion-break rules (see PODE vs CPODE) and multi-patterning rules (see Double Patterning) make pin access harder still.

Common causes of congestion#

Floorplan causes

• Narrow channels between macros that must carry macro pin connections plus through-nets. See Macro Placement Guidelines.
• Macro pins facing the wrong way. Pins facing a wall or another macro force every connection to travel around the macro.
• No halo or keep-out around macros. Cells placed right against macro pins compete with the macro's connections.
• Ports clustered on one edge or far from their logic, funnelling nets.
• Too-dense power grid. As shown in example 1, every strap removes tracks.

Logic and netlist causes

• High-connectivity logic. Crossbars, wide multiplexers, barrel shifters and interconnect fabrics connect many inputs to many outputs. Rent's rule describes how the number of external connections of a block grows with its size; logic with a higher Rent exponent needs more wiring per cell, and congests no matter how it is placed.
• High-pin-count cells. Complex gates and multi-bit flops save area but concentrate pins. See Multi-Bit Flip-Flops for the trade-off.

Placement and optimization causes

• High utilization, overall or local.
• Timing-driven clumping. The placer pulls cells of critical paths tightly together, creating dense islands.
• Upsizing and buffering in regions that were already full.
• Scan nets in synthesis order, which add long criss-crossing wires. Scan chain reordering removes most of that waste.

Routing resource causes

• Clock and other NDR nets with double width or double spacing, which each take two or more tracks. See Clock Tree Synthesis.
• Routing blockages, shielding, and via pillars or via ladders on many nets (see Via Pillars).
• Too few routing layers for the design's wiring needs.

When to check congestion in the flow#

Congestion should be checked repeatedly, not only at routing:

1. Floorplan. Review macro and port flylines and run a quick placement plus early global route.
2. Placement. After global placement and again after placement optimization, run an early (trial) global route and review the congestion map, cell density and pin density.
3. After CTS. Clock buffers and NDR routes usually make congestion a little worse.
4. Global and detailed routing. Compare the global route overflow with the detailed route violations. A hotspot in the global route that becomes a cluster of shorts confirms a real resource problem; shorts with a clean global route point to pin access.
5. ECOs. Late timing fixes add cells into full regions; watch local density during the ECO flow.

How to fix congestion#

The right fix depends on whether the problem is global or local, and on where in the flow you are. The usual order is to fix structural (floorplan and logic) causes first, then placement, then routing.

Floorplan fixes

• Widen channels, or remove channels completely by abutting macros whose pins face away from each other.
• Rotate or flip macros so their pins face open core area, and place macros close to the ports and logic they talk to.
• Add halos (keep-out margins) around macros, and partial (density) blockages in channels so cells cannot fill them completely. See Blockages in Physical Design.
• Move ports so nets do not funnel through one edge.
• Review the PG grid: strap pitch, width and layers. Use only the grid that IR drop and EM sign-off really need (see IR Drop Analysis).
• If the whole block is congested, reduce target utilization, which means more area.

Placement fixes

• Run congestion-driven placement with a higher congestion effort. Tools trade some wirelength and timing to spread cells out of hotspots.
• Apply cell padding to high-pin-count cells, or to a list of cell types known to cause pin-access problems.
• Add local density limits (partial blockages or density screens) on known hotspots.
• Restrict very high-pin-count cells (complex AOI, wide mux cells) in congested regions.
• Debank multi-bit flops in hotspots, if their pin density is the problem.
• Make sure scan chains are reordered and high-fanout nets are buffered sensibly.

Logic fixes

• Restructure crossbars and wide multiplexers, for example by splitting them into stages, or by pipelining.
• Ask the RTL or synthesis team to change structures that are inherently hard to route, early, when floorplan studies first show the problem.

Routing fixes

• Allow the router to use more layers for signal routing, if the design rules and IR budget allow.
• Review NDRs. Keep wide or double-spaced rules for the nets that truly need them (main clock trunks, sensitive nets) and use default rules elsewhere.
• Apply route guides or layer assignments to keep long nets on upper layers and away from hotspots.
• Extra search-and-repair iterations help only when the remaining overflow is small and scattered.

Worked example 3: a macro channel hotspot (illustrative)#

Two SRAM macros sit 10 µm apart, each with 120 pins on the edge facing the channel. Early global route shows the channel with a vertical demand-to-capacity ratio above 1.2 along most of its length, while the core around it is light. Investigation shows:

• The placer has filled the channel with cells to about 85% density.
• About 40 nets from logic on the left side of the core cross the channel to reach logic on the right.
• The macro pins are on the channel side for both macros.

Fixes, in order:

1. Flip the right-hand macro so its pins face the open core on its right. This removes half of the pin connections from the channel.
2. Add a partial placement blockage in the channel, limiting cell density to around 50%, so the remaining macro connections have space for routes and buffers.
3. Re-run placement and early global route.

The remaining overflow is a few scattered GCells near the macro corners, which detailed routing clears. The numbers are illustrative; the method is what matters: find the cause, then choose the matching fix.

Congestion and timing#

Congestion and timing are tightly linked:

• Detours add delay the placer never assumed, a common reason timing degrades between placement and routing.
• Crosstalk gets worse. In a congested region, wires run tightly packed and in parallel for long distances, which raises coupling capacitance, delta delay and glitch noise. See Crosstalk in VLSI.
• Optimization adds cells. Fixing the timing damage adds buffers and upsizes cells in the same full regions, which makes congestion worse.

The reverse also holds: aggressive timing-driven placement can create congestion by clumping cells, so good flows review timing and congestion together.

Congestion also shows up as design rule problems. Overflowing regions produce shorts, spacing and end-of-line violations in detailed routing (see Technology DRCs), and long detoured nets can break max transition and max capacitance limits (see Design Rule Violations).

Debugging congestion step by step#

A practical checklist:

1. Look at the map before the numbers. Clustered overflow matters more than the total.
2. Find the location. Macro channel, port edge, a specific hierarchy or cell type? Highlight hotspot cells by hierarchy and type.
3. Check direction and layer. Horizontal-only or vertical-only overflow, or overflow on certain layers, points to the layer stack, PG straps, macro orientation or NDR nets.
4. Compare the maps. Overlay the cell density, pin density and congestion maps. High pin density means padding or cell restrictions; high cell density means density limits or less utilization; low density with high congestion means through-nets or high-connectivity logic.
5. Check the nets through the hotspot. Are they long nets passing through, nets of one big module, scan nets, or clock NDR nets?
6. Choose the fix that matches the cause, then re-run placement and early global route to confirm before moving on.
7. After detailed routing, review the DRC map. If violations cluster where the global route was clean, focus on pin access rather than capacity.

Interview questions and answers#

1. What is routing congestion? It is a condition where the routing demand in a region, the number of nets that must pass through it, exceeds the available routing tracks. It causes detours, extra vias, DRC violations and in severe cases an unroutable design.

2. What is a GCell and what is overflow? A GCell is a tile of the global routing grid. For each GCell boundary and layer, the tool computes capacity in tracks and demand from global routes. Overflow is demand minus capacity when demand is higher.

3. What is the difference between placement congestion and routing congestion? Placement congestion, or high cell density, is about how full the placement area is. Routing congestion is about whether there are enough tracks for the wires. They are related, but a low-density region can still be congested if it has many pins or many through-nets.

4. Why can a design have a clean global route but many shorts after detailed routing? The global router works on tracks across GCell edges and does not fully model pin access inside dense cell groups. Local pin-access problems and detailed design rules only show up during detailed routing.

5. What is cell padding? Reserving extra empty sites around certain cells during placement, so neighbouring cells do not crowd their pins. It is used for high-pin-count cells in congested regions.

6. What is a partial placement blockage? A blockage that limits the maximum cell density in an area, for example to 50%, instead of forbidding cells completely. It is often used in macro channels.

7. How does congestion affect timing? Detours increase wire delay, parallel wires increase crosstalk, and short nets pushed to upper layers take room from long critical nets. Timing usually degrades between placement and routing in congested designs.

8. How does Rent's rule relate to congestion? Rent's rule relates the number of external connections of a logic block to its size through an exponent. Logic with a higher exponent, such as crossbars, needs more wiring for the same number of cells, so it congests more easily.

FAQ#

When should I start checking congestion? At the floorplan stage, with a quick placement and early global route. The earlier a structural problem is found, the cheaper it is to fix.

Is some overflow acceptable after global route? Small, scattered overflow is often cleared by detailed routing. Clustered overflow usually is not. Agree thresholds with your team and tool flow, and always confirm with a detailed route.

Does lowering utilization always fix congestion? It helps global congestion, but not if the cause is the floorplan, pin orientation or a highly connected piece of logic. Find the cause first.

Summary#

• Routing congestion means routing demand exceeds the tracks available in a region.
• Global routers measure it per GCell edge and layer as capacity, demand and overflow, shown in a congestion map.
• Cell density, pin density and routing congestion are different maps; look at them together.
• The main causes are the floorplan (channels, macro pins, ports, PG grid), high-connectivity logic and high-pin-count cells, and placement or optimization choices.
• Fix structural causes first: floorplan and logic, then placement with padding and density limits, then routing settings.
• Congestion hurts timing through detours and crosstalk, and shows up as shorts and spacing violations in detailed routing.

References#

• A. B. Kahng, J. Lienig, I. L. Markov and J. Hu, VLSI Physical Design: From Graph Partitioning to Timing Closure, Springer, 2011 (chapters on global routing and placement).
• G.-J. Nam, C. Sze and M. Yildiz, "The ISPD Global Routing Benchmark Suite," Proc. International Symposium on Physical Design (ISPD), 2008.
• B. S. Landman and R. L. Russo, "On a Pin Versus Block Relationship for Partitions of Logic Graphs," IEEE Transactions on Computers, vol. C-20, no. 12, 1971.