Routing and Postroute Optimization in ICC2: A Mentor Guide

Part 1 — Chapter orientation

What routing accomplishes, and where it sits

Up through the end of Clock Tree Synthesis, every net in your design — every connection between a driver pin and its receiver pins — is still a straight, weightless line the tool draws for timing purposes only. Nothing has actually been built. Routing is the stage where every one of those lines becomes real, physical copper. Each line turns into a specific sequence of wire segments on specific metal layers, joined by vias. Every segment obeys the manufacturing spacing and width rules. Every one is sized and shaped well enough that the chip can actually be fabricated, and will actually behave the way timing analysis predicted.

Concretely, by the end of this chapter you will be able to do seven things. You will confirm that a design is actually ready to begin routing, not just placed. You will choose and set the routing rules a design needs before the first routing command runs. You will walk the standard routing sequence — global routing, track assignment, detail routing, search-and-repair — and know what each stage is doing physically. You will recognize when a net or group of nets needs a custom-router path instead of the standard flow, run that path correctly, and verify its result before trusting it. You will perform postroute optimization as a measured, evidence-driven process rather than blind command repetition. You will read the reports that tell you whether routing is healthy. And you will work through a full stage-exit checklist, so you can hand a clean, evidence-backed design to chip finishing and signoff.

As with every chapter in this guide, the goal is not memorizing flags. It is building the same judgment a routing engineer uses every day. Does this design's physical wiring meet its design-rule, timing, signal-integrity and power targets? If it does not, which report tells you why? And which specific action actually fixes it?

Estimated route versus physically completed route

Every stage before this one has already been giving you numbers that look like routing results — wire delay estimates, parasitic estimates, even a rough congestion map. Those are all built from an estimated route: a fast, approximate model of what the wiring will probably look like, good enough to guide placement and CTS decisions, but not physically real. Nothing has been checked against manufacturing design rules. No via has actually been chosen. No layer assignment has actually been made.

A physically completed route is different in kind, not just in accuracy. Every wire segment has a real layer, a real width, a real set of endpoints, and a real relationship to every neighboring shape on the same and adjacent layers. Every via is a real via, drawn from a real via definition, checked against enclosure and spacing rules. This is the geometry that a foundry could actually build. The difference matters for one reason. A routed net's parasitic resistance and capacitance can only be measured accurately once the route is physically real, and those parasitics set its timing, its crosstalk behavior and its power. That is why postroute optimization exists as its own disciplined step, covered in full in Part 7: the numbers change once estimation is replaced with reality, and someone has to close the gap.

Why routing is not simply “connecting every net”

A beginner's first mental model of routing is usually: draw a wire from each driver to each of its receivers. That mental model is not wrong, but it badly understates the problem. Every wire drawn has to share a small number of metal layers with tens of thousands of other wires, all competing for the same limited routing tracks. Every wire has to obey minimum width and spacing rules that exist so the chip can actually be manufactured without shorts or opens. Every wire adds resistance and capacitance, which changes the timing of the signal it carries. Every wire also couples electrically with its neighbors, in a way that can corrupt a neighboring signal's timing too. Every wire on certain layers, left connected to a transistor gate through an unfinished processing step, can accumulate enough charge during fabrication to damage that gate — the antenna effect, covered in Part 2. Routing is the stage that has to satisfy all of these constraints at once, for every net, across the whole design. Postroute optimization is the stage that proves the result is actually good, and fixes what is not.

What “route complete” means — and what it does not mean

A tool will happily report 100% routed once every net has a complete, connected physical path from driver to every receiver. That is a real and necessary milestone, and this chapter treats it as one. But route completion only means connectivity exists. It says nothing about whether that connectivity is legal, meaning design-rule clean. It says nothing about whether the result is safe to fabricate (antenna clean), fast enough (timing clean), quiet enough (crosstalk and noise clean), or affordable in power. A design can be 100% routed and still be nowhere near ready to leave this stage. Treat “route complete” as the halfway point of this chapter, not the finish line. The finish line is the Part 12 stage-exit checklist, and it checks all of the above.

Figure 1 — Routing and Postroute Optimization in the ICC2 flow

How routing relates to timing, signal integrity, power, reliability, and manufacturability

These five concerns are not separate checklists you work through one at a time — they interact, often in tension with each other, and most of this chapter's engineering judgment lives in that tension.

• Timing. Routed wire resistance and capacitance directly set signal delay. A net routed on a slow, resistive lower layer arrives later than the same net routed on a faster upper layer. Routing choices made for congestion or manufacturability reasons can quietly cost timing margin. Evidence: report_timing, report_clock_qor, and setup/hold slack after parasitic extraction (Part 8).
• Signal integrity. Two wires running close together on adjacent tracks or layers couple electrically. A quiet neighbor switching at the wrong moment can add delay (crosstalk delay) or inject a glitch (noise) onto a victim net. Evidence: crosstalk delay and noise reports (Part 8).
• Power. Wire capacitance is a direct contributor to dynamic power. Wider, more heavily shielded, or more heavily buffered nets cost more power even when they help timing or signal integrity. Evidence: power reports before and after postroute optimization (Part 7, Part 8).
• Reliability. Certain routing choices — a long wire on a single unfinished-processing layer connected to a sensitive gate, or a via stack with no redundancy — create long-term or manufacturing-time reliability risk, not just a functional bug. Evidence: antenna reports, redundant-via coverage reports (Part 8).
• Manufacturability. Every shape has to obey the foundry's design rules — minimum width, minimum spacing, via enclosure — or the chip cannot reliably be built at all, independent of whether the logic would have worked. Evidence: routing DRC reports (Part 8).

A design that wins on one of these at the expense of the others is not done. A design that is DRC-clean but fails timing is not done. A design that meets timing by ignoring a crosstalk violation on a sensitive net is not done, even though its static timing report looks clean. Part 12's stage-exit checklist exists specifically so none of these five gets silently dropped while you are focused on the others.

After this chapter, you will be able to

• Verify a design is genuinely ready for routing, using a full readiness checklist rather than assuming placement completion is enough.
• Choose routing layers, rules, and strategy based on the specific timing, congestion, and signal-integrity risk profile of a design.
• Run the standard routing sequence — global routing, track assignment, detail routing, search-and-repair — and correctly interpret each stage's evidence.
• Recognize when a net or net group needs the custom-router path, run it correctly, and verify its output before accepting it into the flow.
• Perform postroute optimization as a targeted, report-driven repair process for setup, hold, transition, capacitance, and crosstalk problems.
• Read the reports that describe routed geometry, congestion, timing, signal integrity, and power, and know which fields to check first.
• Diagnose common routing and postroute failures using decision trees instead of guessing.
• Work through a full stage-exit checklist and decide, with report evidence, whether a design is ready for chip finishing and signoff.

Part 2 — Beginner foundations

The mental model, before any commands

Before touching a single routing command, build the picture in your head. A chip's metal stack is a small number of layers — typically ten to fifteen in a modern process — stacked directly above the transistors, each layer reserved almost entirely for wiring in one preferred direction. Routing is the process of deciding, for every single net, exactly which layers, which tracks and which vias it will use to get from its driver to every one of its receivers. It has to do that without breaking a manufacturing rule, and without an unacceptable electrical side effect.

Routing layers and preferred direction

A routing layer is one metal layer of the process stack available for wiring. Each routing layer has a preferred routing direction — horizontal or vertical — alternating from one layer to the next. This exists because a via connecting two layers is smallest and most reliable when the two wires it joins run perpendicular to each other. Alternating direction by layer lets almost every via connect a horizontal segment to a vertical one cleanly. Lower layers (closer to the transistors) are typically thinner, more resistive, and more tightly spaced, used for short local connections and standard-cell pin access. Upper layers are thicker, faster, more expensive in area, and reserved for long nets, clock nets, and power distribution.

Figure 2 — The routing canvas

Figure 3 — Layers, tracks and preferred directions

Wires, segments, shapes, pins, ports, terminals, and nets

A net is a single electrical connection: one driver pin and one or more receiver pins that must all be tied together. A net is not itself a piece of geometry — it is the electrical intent that routing must satisfy. A wire is one continuous run of metal on one layer connecting two points of a net. A long or bent wire is usually stored as multiple segments, each a straight run on a single layer between two coordinates. A shape is the general term for any piece of physical geometry — a wire segment, a via, a pin shape — on a layer. A pin is the physical location on a cell or macro where a net's driver or receiver connects; a port is the equivalent at the chip or block boundary. A terminal is the general term covering both. Routing's job, stated precisely, is: for every net, connect its driver terminal to every receiver terminal using a legal, connected set of wire segments and vias.

Figure 4 — Pin access and connectivity

Spacing rules, width rules, and nondefault routing rules

A spacing rule is the process technology's minimum allowed distance between two shapes on the same layer, set so the shapes can reliably be manufactured without shorting together. A width rule is the minimum (and sometimes maximum) allowed width of a shape on a given layer. Together these are the most basic routing design rules, and every wire the router draws, by default, uses the technology's standard minimum width and spacing. A nondefault routing rule (NDR) is a named, engineer-defined override of these defaults for specific nets. It typically asks for wider width, which lowers resistance and suits timing-critical or high-current nets. It can also ask for wider spacing, which lowers coupling capacitance and suits noise-sensitive nets. Many NDRs ask for both. NDRs are assigned deliberately, net by net or net-group by net-group, covered in Part 4.

Figure 5 — Default width and spacing versus a nondefault routing rule

Vias and via stacks

A via is the small vertical connection that joins a shape on one metal layer to a shape on the layer directly above or below it. A single via only connects two adjacent layers. To move a signal from, say, layer M2 to layer M5, routing must build a via stack. That is a sequence of vias through every intermediate layer (M2–M3, M3–M4, M4–M5), each with its own small connecting shape on the layers in between. Vias are one of the most common sources of resistance and reliability risk in a routed net. Each one adds resistance, and each one is a potential manufacturing defect site. That is why critical or high-current nets are often given redundant vias: two vias in parallel at the same layer transition, so that a single via defect does not break the connection.

Figure 6 — Vias: cut, enclosure, arrays and stacks

Figure 7 — One real route, top view and cross section

Net categories: signal, clock, power, special, and critical

Routing does not treat every net the same way. A signal net is an ordinary logic connection between two or more cells. A clock net was already built in Clock Tree Synthesis. Entering this stage it is either already routed, if clock_opt included route_clock, or it still needs its final detail routing pass. That pass usually runs on reserved layers with nondefault rules, to protect skew. A power net (including ground) was prerouted before placement and must not be disturbed by signal routing. Routing treats existing power geometry as a fixed obstruction. A special net is any net that needs handling outside the ordinary automatic flow — a reset tree, a scan chain, an analog-adjacent net, or anything assigned a nondefault routing rule. A critical net is any net — timing-critical, noise-sensitive, or high-current — that the engineer has deliberately flagged for special treatment, such as wider width, extra spacing, or shielding, covered later in this Part and in Part 4.

Global routing versus detail routing

Global routing divides the design into a coarse grid of rectangular regions, the global routing cells or GCells. For every net it then decides which sequence of GCells that net will pass through, and roughly which layers it will use. It does not yet draw exact wire geometry. It is a planning step: fast, approximate, and essential for predicting where routing resources will run short before committing to exact wires. Detail routing is the step that takes global routing's plan and converts it into exact, legal, design-rule-correct wire segments and vias, track by track, inside each GCell. Global routing without detail routing is only a plan. Detail routing without a global routing plan first would be far too slow. It would have to search the entire design's resources for every net, instead of working from a good starting plan.

Routing tracks and track assignment

A routing track is one of the evenly spaced lines, on a given layer, along which a wire is permitted to run in that layer's preferred direction. Track spacing is fixed by the process technology. Track assignment is the step between global and detail routing that assigns each net's global-routing path to specific tracks, resolving track-level conflicts between nets before the slower, more exact detail-routing step has to.

Route guides

A route guide is a region, on a specific layer or a range of layers, that the engineer or the tool uses to steer a net's routing. It forces the net to stay inside a given area, or to keep out of one. Route guides are most often used for critical nets that need a predictable path for timing or signal-integrity reasons, or to keep a net off a layer or region reserved for something else.

Congestion, capacity, overflow, hot spots, and detours

Routing capacity is the number of tracks actually available to route through a given region, on a given layer, after subtracting space used by blockages, pins, and already-committed geometry such as power routing. Routing demand is how many tracks the nets that need to pass through that region actually want. Congestion is the relationship between the two: a region is congested when demand approaches or exceeds capacity. Overflow is the specific, measurable amount by which demand exceeds capacity in a region — the number of nets that could not be assigned a track there. A hot spot is a region with persistent, significant overflow that resists an ordinary routing pass. A detour is the direct, physical consequence of congestion. A net that cannot get a track along its shortest path is routed the long way around. That adds wire length, resistance, capacitance and delay it would not otherwise have had.

Figure 8 — The congestion mechanism

Wire length, resistance, and capacitance

Every routed wire segment has physical resistance (which slows the signal edge and adds delay along the wire) and capacitance (both to the substrate/plane below, and to neighboring wires — coupling capacitance, covered next). Longer wires, and wires on thinner/more resistive lower layers, have more resistance and more delay per unit length. Wire length is therefore not just a cosmetic or area metric. It is a direct, physical driver of timing and power. That is why a detour forced by congestion is a real engineering cost, not just an inconvenience.

Coupling capacitance, crosstalk, crosstalk delay, and noise

Coupling capacitance is the capacitance between two physically adjacent wires on the same or nearby layers. It exists because any two conductors close together form a small capacitor, whether anyone wanted them to or not. Crosstalk is the general term for the electrical interaction this causes between an aggressor net (the one switching) and a victim net (the one being disturbed). It shows up two ways. The first is crosstalk delay: a victim's signal arrives earlier or later than it would in isolation, because a nearby aggressor happened to switch at the same time. The second is noise: a victim that is supposed to be electrically quiet momentarily glitches because of an aggressor's switching, and that glitch can be mistaken for a real logic transition. Both are covered as their own analysis and repair topics in Parts 7 and 8.

Shielding

Shielding is the practice of routing a dedicated grounded or power-tied wire directly alongside a sensitive net, on one or both sides. It does two things at once. It reduces coupling capacitance to real aggressors, and it gives any coupled noise a low-impedance path to a stable rail instead of into the victim's own signal. Shielding costs routing resources, because the shield wire occupies a track that could otherwise carry a signal. So it is applied selectively, to nets that are timing-critical, noise-sensitive, or both.

Figure 9 — Shielding on a real track grid, and what it costs

Layer constraints, via constraints, and blockages

A layer constraint restricts which layers a net, or a whole class of nets, is permitted to use. You might keep a clock net off the very lowest layers to protect skew, or keep a sensitive analog-adjacent net off a layer that carries a noisy digital bus. A via constraint restricts which via definitions, or how many via layers, a net may use. A high-current power-adjacent net might be required to use redundant vias, for instance. A blockage is a region marked off-limits (fully or on specific layers) to routing, typically to reserve space for macro keep-outs, future ECO headroom, or manufacturing-sensitive regions.

Antenna effects

During fabrication, a long metal wire that is connected to a transistor gate but not yet connected to its final protective diode or driver can act like an antenna, collecting stray charge from plasma-based manufacturing processes. If enough charge accumulates on a wire connected only to a gate, it can discharge through that thin gate oxide. It permanently damages the transistor, long before the chip is ever powered on for real use. This is the antenna effect. It is purely a function of routed wire area and layer, not of the design's logic, which is why it is checked and fixed as part of routing rather than in earlier, less-physical stages.

Figure 10 — The antenna effect and its two standard fixes

Design-rule violations, opens, shorts, and connectivity errors

A design-rule violation (DRV), in the routing context, is any piece of geometry that breaks a manufacturing rule — too close to its neighbor, too narrow, an illegal via enclosure. An open is a net that is supposed to be one electrically connected piece of copper but, due to a routing or extraction problem, is actually broken into two or more disconnected pieces. A short is the opposite failure: two different nets that are supposed to be electrically separate are, due to a routing error, physically touching or overlapping. Both opens and shorts are connectivity errors and are always unacceptable — unlike some DRC or antenna items, there is no such thing as an acceptable, dispositioned open or short.

Parasitic extraction, estimated versus routed timing, and ECOs

Parasitic extraction is the process of measuring the actual resistance and capacitance of every routed shape, from the real physical geometry, rather than estimating it. Timing computed from extracted, routed parasitics is simply more trustworthy than timing computed from any earlier estimate, because it reflects what was actually built rather than a prediction. An engineering change order (ECO) is any small, targeted, after-the-fact change to a design that is already mostly finished. A cell resize, a buffer insertion or a local reroute all count. What makes it an ECO is that the change is made surgically, instead of by rerunning the whole flow. A route ECO is specifically a targeted rerouting of one net or a small group of nets. It is most often used to clean up the local consequences of a postroute optimization change (Part 7) or a custom-router import (Part 6).

Postroute optimization, in one sentence

Postroute optimization is the process of using the real, routed, extracted parasitics to find and fix problems. Those are the timing, transition, capacitance, crosstalk and power problems that only became visible once the route was physically real. Part 7 covers it in full. It exists because no estimate, however good, is a substitute for measuring the real thing.

Beginner vocabulary quick reference

GCell (global routing cell)

A coarse rectangular region used by global routing to plan net paths before exact geometry is drawn.

Preferred direction

The horizontal or vertical direction a given routing layer is optimized for; alternates layer to layer.

Track

One of a layer's evenly spaced, technology-fixed lines a wire may run along in the preferred direction.

Via

A vertical connection between two adjacent metal layers.

Via stack

A sequence of vias connecting non-adjacent layers through every layer in between.

Redundant via

A second, parallel via at the same layer transition, added for reliability.

Overflow

The measurable amount by which routing demand exceeds capacity in a region.

Detour

Extra wire length a net accumulates when it cannot use its shortest path due to congestion or blockages.

Coupling capacitance

Capacitance between two physically adjacent wires, the physical basis of crosstalk.

Aggressor / victim

The switching net causing crosstalk (aggressor) and the net being disturbed by it (victim).

Nondefault routing rule (NDR)

An engineer-defined override of default width and/or spacing for specific nets.

Antenna effect

Fabrication-time gate damage risk from charge accumulated on a long wire connected only to a gate.

DRV

Design-rule violation: any geometry that breaks a manufacturing spacing, width, or via rule.

Parasitic extraction

Measuring the real resistance and capacitance of routed geometry, as opposed to estimating it.

Route ECO

A small, targeted reroute of one net or a small net group, done without rerunning the full flow.

Part 3 — Prerequisites and readiness

Is this design actually ready to route?

Routing is expensive to redo. A design that starts routing before it is genuinely ready wastes runtime. Worse, it can bury a real problem — illegal placement, unresolved congestion, a missing scenario — under a mountain of routed geometry that then has to be unwound. This Part is a disciplined readiness review, item by item, each ending in a PASS, REVIEW, or BLOCKER classification. Do not begin routing in the worked example (Part 10) until every item below has an explicit classification.

Picture the design exactly as it sits right now. Cells are legalized on their rows, a clock tree is already built and propagated, and not one signal wire has been drawn. This Part is the walk-around you do before that first wire goes down, the way you would walk a building site before anyone pours concrete.

Command verification noteThe names check_legality, check_pg_connectivity, check_mv_design, check_routability and get_scenarios are used in this Part's readiness checks, and all five are independently verified against the real Synopsys ICC2 Tcl Command Reference. Three others remain this chapter's illustrative pseudocode: check_pin_access, check_connectivity and report_layer_usage. No command by those names was found in that reference. See qa/command-verification.csv for the full, per-command status.

Placement and clock readiness
Readiness item 1 Placement legality What to check check_legality reports zero illegal or overlapping placements. Why it matters Routing assumes every cell sits on a legal site row at a legal location. An illegal placement can make correct routing geometrically impossible near that cell. Evidence of a healthy result check_legality -verbose returns zero violations. Consequence if wrong Local unroutable regions, pin-access failures, and DRC violations clustered around the illegal cells. Safe recovery Return to placement legalization before proceeding; do not attempt to route around an illegal cell.	Readiness item 2 Completed clock tree synthesis and clock routing status What to check Every clock is marked propagated; if clock_opt stopped before route_clock, clock nets still need detail routing in this stage. Why it matters An ideal (unpropagated) clock gives timing analysis false confidence; routing decisions made against ideal-clock timing can be wrong once the clock is real. Evidence of a healthy result report_clock_qor shows every clock propagated, zero DRC violators, acceptable skew (see the Clock Tree Synthesis chapter's exit checklist). Consequence if wrong Timing-driven routing decisions optimize against the wrong clock model; results have to be redone once clocks are corrected. Safe recovery Return to Clock Tree Synthesis and complete propagation before beginning signal routing.
Readiness item 3 Power and ground routing What to check Power/ground straps, rings, and rails are complete and were verified with check_pg_connectivity or equivalent. Why it matters Signal routing must treat power geometry as a fixed obstruction; incomplete power routing changes the router's understanding of available resources mid-flow. Evidence of a healthy result Zero unconnected power/ground shapes; power mesh matches the intended power plan. Consequence if wrong Signal routing plans around the wrong obstruction set, requiring a full reroute once power routing changes. Safe recovery Complete and verify power routing before starting signal routing; treat it as immovable afterward.
Timing, congestion, and rule readiness
Readiness item 4 Required scenarios and corners defined What to check Every scenario (mode × corner) that must be verified at signoff is active and available now, not added later. Why it matters Routing and postroute optimization decisions made against an incomplete scenario set can look correct while quietly failing a scenario nobody checked. Evidence of a healthy result get_scenarios matches the project's signoff scenario list. Consequence if wrong A scenario added late may reveal timing or DRC problems the routed design was never optimized against. Safe recovery Add the missing scenario now, before routing, and re-baseline readiness evidence.	Readiness item 5 Timing state entering routing What to check Estimated-parasitic setup and hold slack from the end of Clock Tree Synthesis, in every active scenario. Why it matters Routing will change timing (usually for the worse before postroute optimization repairs it); starting from a healthy estimate gives the process margin to absorb that change. Evidence of a healthy result Positive WNS/TNS on the CTS exit checkpoint, with no unexplained large violations. Consequence if wrong A design that enters routing already failing timing is very unlikely to close after routing adds real parasitics. Safe recovery Return to Clock Tree Synthesis or Placement and Optimization to close timing before routing.
Readiness item 6 Congestion state What to check An early global-routing-based congestion estimate (report_congestion or GUI congestion map) shows no severe, widespread overflow. Why it matters Severe congestion detected only during detail routing is far more expensive to fix than the same congestion caught and addressed before routing starts. Evidence of a healthy result Overflow confined to small, explainable regions, not spread across the design. Consequence if wrong Excessive detours, DRC violations that never fully clear, and routing runtime that balloons chasing unroutable regions. Safe recovery Return to placement density/utilization adjustments, or add routing blockage relief, before committing to detail routing.	Readiness item 7 Design-rule constraints and layer availability What to check The routing layer set, and any layers reserved or restricted (for clock, power, or process reasons), are defined and match the technology file. Why it matters Routing that starts without an explicit layer plan may use layers that should have been reserved, creating conflicts discovered only later. Evidence of a healthy result Layer directives (preferred/restricted) match the project's routing-layer plan (Part 4). Consequence if wrong Clock or power-adjacent nets end up sharing layers they were meant to avoid; rework required. Safe recovery Set layer directives explicitly before routing; do not rely on tool defaults for a project with specific layer reservations.
Blockage, pin, and special-net readiness
Readiness item 8 Blockages, keepouts, and routing obstructions What to check All intended routing blockages (macro keep-outs, reserved ECO margin, process-sensitive regions) are placed before routing begins. Why it matters A blockage added after routing has already used that space forces a rip-up of everything routed there. Evidence of a healthy result Blockage layer matches the floorplan and macro-interface specification. Consequence if wrong Routed geometry has to be removed and rerouted once the blockage is added correctly. Safe recovery Confirm blockages against the floorplan chapter's macro halo and keep-out definitions before routing.	Readiness item 9 Pin accessibility and macro interfaces What to check Macro and standard-cell pins are reachable from at least one adjacent routing track, not buried behind blockages or other macros. Why it matters An unreachable pin cannot be routed at all, regardless of how much routing resource exists elsewhere. Evidence of a healthy result check_pin_access (or equivalent pin-access analysis) reports zero unreachable pins. Consequence if wrong Unrouted nets at that pin, often requiring a placement adjustment to fix, not just a routing setting. Safe recovery Adjust macro orientation, placement halo, or local cell placement to restore access before routing.
Readiness item 10 High-fanout nets and their routing plan What to check Non-clock high-fanout nets (scan enable, reset) are already buffered and their routing intent (layer, NDR) is decided. Why it matters An unplanned high-fanout net can create a sudden, unexpected demand spike in one region during routing. Evidence of a healthy result High-fanout nets have a defined buffering and routing strategy carried in from Placement and Optimization. Consequence if wrong Localized congestion and DRC violations concentrated around the high-fanout net's source. Safe recovery Confirm high-fanout buffering carried forward correctly; add routing guides if a specific path is required.	Readiness item 11 Routing-rule assignments and special-net status What to check Every net intended to receive a nondefault routing rule, shielding, or a route guide has that assignment made before routing starts. Why it matters Rule assignment made after routing requires the affected nets to be ripped up and rerouted under the new rule. Evidence of a healthy result NDR and shielding assignments match the routing-strategy decisions from Part 4. Consequence if wrong Critical or noise-sensitive nets route under default rules, discovered only during postroute crosstalk or timing analysis. Safe recovery Assign rules before the routing run; if discovered late, plan a targeted route ECO rather than a full reroute.
Readiness item 12 Multivoltage considerations, where applicable What to check Level-shifter placement, voltage-domain boundaries, and isolation cells are final before routing crosses a domain boundary. Why it matters Routing across a voltage domain boundary without the right shifting/isolation cells in place creates a route that cannot be made electrically legal. Evidence of a healthy result Voltage-domain and power-intent checks (check_mv_design or equivalent) report clean. Consequence if wrong Illegal cross-domain routes, requiring rework once the correct cells are placed. Safe recovery Resolve multivoltage structure and placement before routing; not applicable if the design is single-voltage.	Readiness item 13 Saved checkpoint and recovery point What to check A checkpoint of the design exists, saved immediately before routing begins. Why it matters Routing is a large, sometimes slow operation; without a pre-route checkpoint, a bad routing attempt can only be undone by rerunning everything before it. Evidence of a healthy result A named checkpoint exists and has been confirmed to reopen cleanly. Consequence if wrong Recovery from a bad routing run costs far more time than saving the checkpoint would have. Safe recovery Save the checkpoint now, before proceeding, even if it feels like an extra step.
Readiness item 14 Required reports and baseline evidence What to check Baseline reports — timing, congestion, clock QoR — are collected and saved before routing, to compare against after. Why it matters Without a “before” baseline, it is impossible to tell whether routing improved, worsened, or barely changed a given metric. Evidence of a healthy result A saved baseline report set exists, timestamped, matching this checkpoint. Consequence if wrong Postroute analysis has nothing to compare against; regressions can go unnoticed. Safe recovery Generate and save the baseline set now; this is inexpensive relative to the value it provides later.

Readiness checklist summary

Part 10 walks through this exact checklist against the Nimbus‑8 project, with real evidence and a real PASS/REVIEW/BLOCKER classification on every row. This Part defines what to check and why. Part 10 shows it done.

Part 4 — Routing strategy and setup

Choosing a routing strategy before you route

Every routing setting below exists to solve a specific engineering problem — not as an item on an alphabetical options list. This Part is organized by the problem each group of settings addresses, so you can reason from “what am I worried about in this design” to “which setting addresses that,” the way an engineer actually works.

Think of this Part as setting the rules of the road before any traffic moves. Nothing here draws metal. Every setting you make now decides how the router behaves later, when there are tens of thousands of wires and no time to supervise any one of them.

Problem: which layers should carry which kind of net

Problem: critical-net and clock-net treatment

Problem: via reliability on critical or high-current paths

Problem: congestion risk known ahead of routing

Problem: timing-critical paths need routing-aware protection

Problem: signal integrity risk on dense or high-fanout regions

Problem: antenna risk from long wires on early layers

Problem: power-aware routing decisions

Problem: runtime versus quality, scenario selection, and incremental strategy

Checkpoint strategy

Save a named checkpoint after every major stage in Part 5's sequence — after global routing, after detail routing, after search-and-repair convergence, and after postroute optimization. Each checkpoint is a safe rollback point if a later step goes wrong, and each is also a source of the “before” evidence Part 8's analysis depends on. This habit costs disk space and a few minutes per save; it saves far more time the first time something needs to be re-diagnosed from a known-good point instead of from scratch.

Figure 11 — Choosing routing rules by risk profile

Part 5 — Standard routing flow

The standard routing sequence, stage by stage

This is the normal path almost every net in almost every design takes. Part 6 covers the alternative path — the custom router — for the specific nets that need it; everything in this Part is the baseline every design starts from and returns to.

Picture the sequence as four passes over the same piece of the design, each one more committed than the last. First a plan of which regions each net crosses. Then a specific track for each net. Then real copper. Then repairs. Figures 12a and 12b show one identical region at each of those points, so you can watch the plan turn into metal.

Figure 12a — One region, three stages: from plan to real metal

Stage 1 of 9 — Pre-route checking Stage 1 of 9, continued Stage 2 of 9 — Global-route planning and global routing Stage 2 of 9, continued Stage 3 of 9 — Congestion estimation review Stage 3 of 9, continued Stage 4 of 9 — Track assignment Stage 4 of 9, continued Stage 5 of 9 — Detail routing and via insertion Stage 5 of 9, continued Stage 6 of 9 — Search-and-repair Stage 6 of 9, continued

Figure 12b — The same region, the last two stages

Stage 7 of 9 — Antenna handling and connectivity checking Stage 7 of 9, continued Stage 8 of 9 — Timing update after routing Stage 8 of 9, continued Stage 9 of 9 — Checkpointing and the decision to continue or return Stage 9 of 9, continued

Figure 13 — The standard routing flow and its feedback loops

Part 6 — Routing Using Custom Router

When the standard flow is not the right tool

Everything in Part 5 assumes the standard, automatic routing flow is the right tool for every net. Most of the time it is. This Part covers the case where it is not. Here a net, or a small group of nets, needs routing built with a separate, specialized custom router. That geometry is then brought into the same design the standard flow just finished routing. This is not a footnote. A custom-routed net still has to pass every verification this chapter requires, and the design still has to return to one unified postroute optimization flow afterward. Treat this Part as a detour with a clearly marked on-ramp and a clearly marked off-ramp back to Part 7, not a separate chapter.

Imagine one bus on the chip that has to be built to a tolerance the automatic router cannot promise. Everything else on the die is still routed normally, around it. That is the whole shape of this Part: a short, well-marked detour off the standard flow, and a clearly marked way back onto it.

What routing with a custom router means

In the standard flow, ICC2's own router makes every decision: which GCells a net passes through, which tracks it uses, which layers, which vias. Routing with a custom router means that, for a specific net or net group, those decisions are made outside that automatic flow. They are made by a separate routing engine, by a specialized methodology, or in some cases by careful manual construction. The resulting geometry is then imported into the design as if it had been routed normally. The rest of the design, and the rest of this chapter's flow, is completely unaffected. Standard-router nets are still routed by Part 5's sequence. The custom-routed nets simply arrive by a different path, then rejoin the same postroute optimization and signoff flow from Part 7 onward.

Standard path versus custom-router path, side by side

Figure 14 — Standard router path versus custom-router path

Situations in which custom routing may be appropriate

• A small group of nets needs a routing property the standard router cannot guarantee directly. That might be exact matched length within a tight tolerance, full symmetric shielding on both sides for the entire net length, or a specific fixed topology required by an analog or mixed-signal interface.
• A hard macro or IP block ships with its own required routing methodology for its interface nets, as a condition of using that IP.
• A structure (a memory-compiler bus, a differential pair set) is repeated identically many times, and a specialized generator produces more consistent, verifiable geometry than per-instance automatic routing would.
• An SI-critical net group needs an iterative, engineer-in-the-loop routing process beyond what a fully automatic SI-driven strategy (Part 4) can practically achieve.

Required prerequisites before using a custom router

Every readiness item from Part 3 still applies to the design as a whole. Three things are needed in addition. First, the net group intended for custom routing must be explicitly identified and excluded from the standard route_detail pass. It can instead be routed standard-first as a placeholder, then deliberately ripped up. Second, the routing rules that group must obey — layer, width, spacing, via and blockage — must be documented and exportable in a form the custom router understands. Third, a rollback checkpoint must exist from immediately before the export, independent of the general pre-route checkpoint. A custom-router import that goes wrong needs its own clean return point.

Data and constraints passed to the custom router

Figure 15 — Custom-router input/output handoff

At minimum, the export must carry six things. It must carry exact pin locations and net connectivity for every net in the group, with nothing left to be inferred. It must carry the layer set the group is restricted to. It must carry the nondefault routing rule, width and spacing, that each net must obey. It must carry via constraints, including any redundant-via requirement. It must carry every blockage and keepout the group's region must respect. And for clock, critical or special nets in the group, it must carry the specific intent behind their assignment. That intent may be a matched-length tolerance, a shielding requirement or a topology constraint. Whatever it is, state it as an explicit, checkable number rather than leaving it implicit. A constraint left implicit is a constraint the custom router has no way to honor.

How clock nets, critical nets, and special nets are treated

A clock net routed by a custom router still has to meet the same skew and latency intent Clock Tree Synthesis established. The custom router's export must therefore carry the relevant balance-group or matched-length requirement explicitly. The post-import verification must then re-run report_clock_qor on the affected clocks. Do not assume the custom route preserved skew simply because it connects correctly. A critical net's NDR and shielding requirements are exported exactly as documented in Part 4 — the custom router does not get to substitute its own default width/spacing. A special net, such as a reset tree or a scan chain, carries whatever topology or fanout-order constraint made it special in the first place. If the custom router's methodology cannot express that constraint, that net is not a candidate for this path.

Running the custom-router path

Custom-router step 1 of 4 — Export Custom-router step 2 of 4 — Route externally Custom-router step 3 of 4 — Import Custom-router step 4 of 4 — Immediate sanity check

Checks required immediately after custom routing

A successful import message from read_def is not evidence the custom-routed result is correct — it only means the geometry was accepted into the database without a format error. Every item below must be checked explicitly. Never treat import success alone as acceptance.

Command verification notecheck_connectivity, report_layer_usage, extract_rc, report_crosstalk_delay, and report_route below remain this chapter's illustrative pseudocode — no command by these names was found in the real Synopsys reference; see qa/command-verification.csv. Every other command in this table (check_routes, update_timing, report_noise, report_congestion) is independently verified against it.

Figure 16 — Custom-router verification decision tree

Restrictions, limitations, and recovery strategy

A custom-router path has real limitations worth stating plainly. It only covers the net group it was explicitly given. It has no awareness of the rest of the design's congestion or timing state. That is exactly why the post-import checks re-verify against the whole design, not just the imported nets in isolation. It cannot participate in ICC2's own incremental search-and-repair. If the import introduces a DRC violation, that violation is fixed with a standard, scoped route ECO (Part 2, Part 7) on the affected shapes, not by rerunning the custom router. The custom router's own internal metrics, such as its length-matching report and its own DRC pass, use a different rule model than ICC2's. They are informative but not authoritative. ICC2's own checks, run after import, are what decide acceptance.

Suppose verification fails in a way a scoped route ECO cannot cleanly fix. The safe recovery is then to restore the rollback checkpoint saved before export, correct the constraint export or the custom router's configuration, and repeat the four-step process above. Do not attempt to patch a structurally wrong import by hand-editing geometry directly; the constraint mismatch that caused the failure will still be present the next time this net group needs to change.

How the design returns to normal postroute optimization

Once every post-import check above passes — connectivity, DRC, layer/via, timing update, signal integrity, antenna — the custom-routed net group is, from this point forward, ordinary routed geometry. It is included in the same save_block checkpoint as every standard-routed net. The same postroute optimization pass in Part 7 can touch it, resizing a buffer near its endpoints if timing requires it. The same stage-exit checklist in Part 12 applies to it, with no special exception. The only trace that a custom router was used is the documentation of why, plus the evidence that its verification passed. Both belong in the stage-exit checklist's evidence column, not in a separate, second checklist.

Evidence required before accepting a custom-routed result

Part 10's worked example fills in this exact table with real Nimbus‑8 evidence; this Part defines what has to be checked and why.

Worked example: why the Nimbus‑8 ADC-input bus needs a custom router

Nimbus‑8's 16-bit ADC-input bus, sens_adc_in[15:0], feeds an on-die analog front end. That front end demands three things of the bus. Every bit's wire length must be matched to within ±5 µm of the others. The whole run needs full symmetric grounded shielding. And the bus needs a fixed two-layer (M6/M7) topology, to keep it away from the noisier digital layers below. The standard SI-driven and timing-driven routing strategies in Part 4 can approximate matched length, and they can apply NDR-based shielding. Neither can guarantee the exact, uniform tolerance and full-length symmetric shielding this interface's specification requires across all sixteen bits at once. That is exactly the situation Part 6 describes as appropriate for a custom-router path. The full run, with real before/after numbers, is in Part 10.

Troubleshooting example: a connectivity problem in imported routing

Troubleshooting example: physically valid but electrically unacceptable

Part 7 — Postroute optimization

Closing timing, signal integrity, and power on real parasitics

Once wires are real, their resistance and capacitance are real too — and real numbers are rarely identical to the estimates every earlier stage used. Postroute optimization is the measured, evidence-driven process of finding exactly what changed for the worse and fixing it with the smallest change that works. It is not a loop of rerunning the same command hoping for a better result; every technique in this Part exists to answer a specific symptom a report has already shown you.

Picture the design at the moment you enter this Part. Every wire is real, and for the first time the timing numbers describe copper instead of a guess. Some of those numbers will have moved the wrong way. In practice this Part is about finding exactly which ones moved, and then changing as little as possible to move them back.

Command verification notereport_timing, report_constraint, and report_power cited below are independently verified against the real Synopsys ICC2 Tcl Command Reference; extract_rc remains this chapter's illustrative pseudocode — no standalone extraction command by that name was found in that reference. See qa/command-verification.csv.

Why timing changes after detailed routing

Every timing number computed before this stage — in Placement and Optimization, in Clock Tree Synthesis, even in Part 5's own initial global-routing estimate — is built from a model of what the wiring will probably look like. Real detail-routed wires almost never match that model exactly. Some nets route shorter than estimated. Some detour around congestion (Part 2) and route longer. Some get an NDR's extra width and lower resistance. And some end up with more parallel-run neighbors than the estimate assumed, so they pick up more coupling capacitance. Extraction accuracy — how precisely extract_rc measures the real geometry's resistance and capacitance — is what makes the resulting timing numbers trustworthy where the earlier estimates were only approximate. Postroute optimization exists because this is the first point in the flow where timing, transition, capacitance, crosstalk, and power are all being measured against reality instead of a prediction.

Setup repair

Hold repair

Transition and capacitance repair

Fanout-related repair and crosstalk-aware optimization

Fanout repair and crosstalk/noise-driven optimization — Part A of 2: diagnosis Fanout repair and crosstalk/noise-driven optimization — Part B of 2: verification and recovery

Cell sizing, cell movement, and route/via changes

Most of the repair techniques above resolve down to a small set of physical actions, applied in combination. Buffer insertion and resizing adds drive strength or splits load. Cell sizing chooses a stronger or weaker library cell for the same logic function. Cell movement nudges a cell slightly, where legalization rules permit, to shorten a specific critical connection. Route changes are made through a targeted route ECO. Via changes add redundancy, or promote a transition to a lower-resistance via definition. And layer promotion moves a net's run from a lower, more resistive layer to a faster upper layer, where resource allows. Detour reduction is often the highest-leverage of these. A path that fails setup because it was forced into a long detour (Part 2) is frequently better served by relieving the congestion that caused the detour, rather than by repeatedly upsizing drivers along it.

Clock-data interaction

A postroute fix that changes a data path's delay can change its relationship to the clock edges launching and capturing it. This is clock-data interaction. It is why every setup or hold fix above is followed by a recheck across all corners, not just the corner that originally failed. In rare cases, a data-path fix is better replaced by a small, deliberate clock-side adjustment rather than repeated data-path buffering. That means useful skew, applied cautiously and only when the project's methodology explicitly allows it. That decision belongs with a senior engineer, not a default first move.

Leakage, dynamic power, and area recovery

Design-rule and legality preservation, incremental optimization, and ECO routing

Every technique above must preserve two things that are easy to silently break while chasing a timing number. The first is design-rule preservation: a resized cell or a rerouted net must still be DRC-legal. The second is legality preservation: a moved cell must still sit on a legal site, and any nudge must respect the same placement legality rules Part 3 checked before routing. Postroute optimization runs in many small, targeted steps rather than one pass, so it is run incrementally, with each fix scoped to the specific path or net it addresses. ECO routing handles the physical rerouting a fix requires. Re-extraction then updates parasitics for exactly what changed, and reanalysis re-runs timing, DRC and SI checks on the updated state. Only then does the next fix begin.

Figure 17 — From symptom to technique: the postroute optimization decision map

Convergence criteria and when not to keep optimizing

Part 8 — Analyzing routed results

Reading the reports that prove routing is healthy

Every technique in Parts 5 through 7 depends on being able to read the right report, find the right field, and know what a healthy value looks like. This Part is a reference for that skill — organized by what you are trying to learn, not by command name.

Think of the reports in this Part as instruments on a dashboard rather than as commands to memorize. Each one answers a single question about the routed design. Reading them in the wrong order sends you chasing a symptom instead of a cause, which is why the order here is deliberate.

Command verification noteMost command names below have now been checked against the real Synopsys ICC2 Tcl Command Reference and are independently VERIFIED (exact syntax corrected where this chapter's earlier form differed) — including report_timing, report_congestion, report_noise, report_clock_qor, report_power, check_routes, and update_timing. The names report_route_status, report_route, report_layer_usage, report_crosstalk_delay, check_connectivity, check_pin_access, and extract_rc remain this chapter's illustrative pseudocode — no command by these names was found in that reference. See qa/command-verification.csv for the per-command sourcing, page citations, and status.

Route completion, connectivity, and physical-rule quality

Figure 18 — report_route_status anatomy

Timing, transition, and capacitance

Clock quality of result after routing

Clock latency and skew, already verified once in Clock Tree Synthesis, must be re-checked after routing — the same report_clock_qor command from that chapter, now run against routed, extracted parasitics rather than CTS-time estimates. A clock that was healthy on estimated parasitics can still shift once its real routed geometry (especially if any clock-net detail routing was deferred into this stage) is measured. Read it the same way: DRC violators at zero first, then latency and global/local skew against the project's targets. A meaningful skew regression from the CTS-time numbers is a signal worth tracing back to a specific branch before accepting the design.

Signal integrity: crosstalk delay, noise, and coupling

Power after routing

Run report_power -scenarios [all_scenarios] after routing and again after postroute optimization. Read dynamic power, leakage power and clock power as three separate lines, not one combined number. Dynamic power is most sensitive to routed capacitance, so NDR width, shielding and detours all move it. Leakage tracks total cell area and library cell choice. Clock power reflects the clock tree's own buffer count and activity. A meaningful increase in dynamic power after postroute optimization is expected if setup repair required real buffering. The question is not whether power increased during repair. It is whether the area and power recovery step in Part 7 brought it back down once timing was closed.

QoR and area changes, scenario consistency, and log review

Compare the design's overall quality-of-result summary against the Part 3 baseline and the Part 5 post-route baseline. The summary covers total cell count, total area, total wire length and via count. A large, unexplained jump in any of them after postroute optimization is worth understanding before you accept the design. Confirm that every active scenario shows consistent results, not just the primary one (Part 3, readiness item 4). A design that looks perfect in the typical corner but was never checked at a fast or slow corner is not actually verified. Finally, review the full run log for warnings and errors, not just the summary reports. A report can look clean while the log carries a warning that deserves attention, such as a degraded fallback where a search-and-repair iteration limit was reached.

Figure 19 — Report reading order after routing

GUI-based analysis

Reports tell you a number; the layout viewer shows you where and why. For any violation that a report alone does not make obvious, open the layout and use the following habits.

• What to display. Show only the layer(s) and net(s) relevant to the violation being investigated — displaying every layer at once hides the specific problem in visual noise.
• What colors or markers mean. This guide's convention marks a healthy/accepted element in teal, a flagged or violating element in orange, and a fixed structural element (a blockage, a shield) in navy outline — consistent with every figure in this chapter.
• Locating a reported violation physically. Most report commands accept a -highlight or equivalent option that selects the exact shape or net in the layout; use it instead of manually searching coordinates.
• Correlating a report entry with the layout. Cross-check the report's coordinates or net name against what is highlighted — a mismatch usually means the report is describing a different (often nearby) instance than the one visually inspected.
• Distinguishing a local symptom from a global problem. Zoom out one level after inspecting the specific violation — a single detour is local; a whole region shaded with detours is a congestion problem requiring Part 4/Part 5 treatment, not a one-net fix.
• Confirming a visual repair is numerically valid. A fix can look correct in the layout, with spacing now visibly wider or the route now visibly shorter. It must still be re-confirmed with the actual report command. Visual inspection catches gross errors, but it cannot substitute for the precise numeric check.

Part 9 — Troubleshooting and decision trees

What to do when something does not converge

Every card below follows the same shape: likely causes, what to check, what evidence confirms the cause, the corrective action, what to recheck afterward, and a safe rollback point. Work through them in this order when a symptom is unclear: physical and connectivity problems first, then design-rule problems, then timing, SI and power problems. An unresolved earlier-category problem can produce misleading symptoms in a later one.

Picture yourself at the point where a report has just told you something is wrong and you do not yet know why. In practice that is where most routing time is actually spent. So this Part is organized the way a real diagnosis runs: category first, cause second, fix last.

Command verification noteThe full statement of what was verified and what is illustrative is in Part 8. For this Part: check_routes, report_timing, report_congestion and report_noise are VERIFIED against the Synopsys reference, while report_route_status, check_connectivity and extract_rc are this chapter’s illustrative pseudocode.

Figure 20 — General troubleshooting decision tree

Part 10 — Worked example: Nimbus‑8

From a routed-clock checkpoint to a signed-off physical route

Nimbus‑8 enters this chapter exactly where the Clock Tree Synthesis chapter left it. Every clock is propagated and there are zero clock DRC violators. Global skew is 52 ps and worst local skew is 18 ps. The tree holds 700 clock buffers and inverters over 18,420 µm². This Part carries that checkpoint through readiness, routing strategy, the standard flow, the custom-router path for one sensitive bus, postroute optimization, and a final, evidence-backed PASS decision.

Notice as you read that nothing in this Part is new. It is the whole chapter run once, end to end, on one real block, with every number written down as it appears. Picture it as watching over a colleague's shoulder for a full day of work.

Scope. Nimbus‑8 as a whole is 9.90M standard cells, 72 SRAM macros and 1 DDR PHY hard macro in a 3.20 mm × 3.20 mm core (see Part 3). This worked example routes one named partition of it. That partition is u_sens_tile, the sensor-interface tile carrying the ADC input bus. It holds 46,200 standard cells and 2 SRAM macros in a 0.70 mm × 0.62 mm block at 79.6% utilization, with 48,612 signal nets. Every net count, wire length, via count and slack number below is that partition's, not the full chip's. Routing a full 9.90M-cell design is a hierarchical exercise that belongs to a later chapter; routing one partition end to end is what teaches the stage.

Command verification noteThis worked example's reported field values (latencies, slacks, violator counts) are fictional teaching data, not a real tool transcript. Most command names used below are independently verified against the real Synopsys ICC2 Tcl Command Reference. Those are check_legality, check_pg_connectivity, route_global, route_track, route_detail, check_routes, write_def, read_def, report_congestion, report_timing, update_timing, report_clock_qor, report_power, route_opt and save_block. Five others remain this chapter's illustrative pseudocode: check_pin_access, check_connectivity, extract_rc, report_crosstalk_delay and report_route. See qa/command-verification.csv for the full, per-command status.

Step 1: readiness review

Item 6's REVIEW is not left unresolved: the one hot spot sits directly against the region the ADC-input bus (sens_adc_in[15:0]) will occupy. Step 2 resolves it as part of choosing the routing strategy, and readiness item 6 is re-classified PASS once that resolution is in place.

Step 2: strategy selection, including the custom-router decision

Following Part 4, the 42 setup-critical nets (identified from the pre-route timing report's worst-slack paths) receive NDR_WIDE_2X. Redundant vias are enabled on every power-adjacent and clock net. Antenna-aware and SI-driven, timing-driven high-effort routing are enabled design-wide. For the congestion hot spot flagged in Step 1: it is caused by the standard router's attempt to route sens_adc_in[15:0] through the same region as several ordinary signal nets. Following Part 6, this bus already needs custom routing on its own merits. It needs ±5 µm matched length across all sixteen bits, full symmetric grounded shielding for its entire length, and a fixed M6/M7-only topology. The standard flow's settings cannot guarantee all three at once. Carving those sixteen nets out of the standard flow, and reserving their region for the custom-router path, also resolves the congestion flag directly. The standard router no longer contends for that space at all. Readiness item 6 is re-classified PASS on this basis, and the decision (why, and what it resolves) is recorded here as its evidence.

Step 3: global routing and congestion analysis

route_global runs against the partition's 48,596 standard-flow nets (48,612 total signal nets in u_sens_tile, less the 16 reserved for the custom-router path). A fresh report_congestion shows overflow down to 0.15% H / 0.05% V, with the previously flagged hot spot now at zero — confirming Step 2's carve-out resolved it. No further congestion relief is required before track assignment and detail routing.

Step 4: detail routing and search-and-repair

route_detail completes 100% of the standard-flow nets, 0 unrouted, 0 opens, 0 shorts, with an initial 248 DRC violations and 37 antenna violations — a normal starting point for a design this size. Search-and-repair converges cleanly:

Antenna handling fixes all 37 violations — 28 with protection diodes, 9 with layer jumpers where no diode site was reachable locally. Both check_connectivity and check_routes report clean on the standard-flow portion of the design.

Step 5: the custom-router path for sens_adc_in[15:0]

Part 6's four-step procedure runs as written. Constraints are exported with write_def -include {nets routing_rules vias blockages}, on layers M6/M7, under rule NDR_SHIELD_2X, with a matched-length tolerance of ±5 µm and shields tied to VSS. The custom router then produces the sixteen-bit bus geometry to that specification. Then read_def -include {nets routing_rules vias blockages} brings it into the Nimbus‑8 database. The scoped check_routes sanity check passes immediately. The full post-import verification table then runs:

Exactly as Part 6 warns, import success is not accepted as correctness on its own: the neighboring-region timing dip is caught by this table, not assumed away. A small route ECO on SIG_CRIT_017 and SIG_CRIT_038, freeing a track by confirming the shield spacing was slightly wider than the specification strictly required and trimming it back within spec, resolves the −0.008 ns dip. Full local re-verification afterward confirms both the two signal nets and the ADC bus are simultaneously clean. The custom-routed bus is now ordinary routed geometry, included in the same checkpoint as every other net, exactly as Part 6 describes.

Step 6: parasitic update and full-design timing analysis

extract_rc and update_timing -full across all three active scenarios (func_ss_0p72v_125c, func_ff_0p88v_m40c, test_ss_0p72v_125c) produce the expected regression from the pre-route estimate. WNS(setup) in func_ss_0p72v_125c drops to −0.062 ns, over 14 violating paths, with TNS −0.31 ns. WNS(hold) in func_ff_0p88v_m40c remains positive at +0.021 ns, and setup in test_ss_0p72v_125c holds at +0.004 ns. 11 max transition violators and 4 max capacitance violators appear, concentrated on detoured nets identified in Part 8's wire-length and congestion cross-reference. A fresh report_clock_qor shows a small, expected clock regression from real clock-net routing. Latency is 615/562/590 ps, global skew is 55 ps and worst local skew is 19 ps. Both skew numbers are still well inside the project's 100 ps global and 30 ps local targets.

report_crosstalk_delay and report_noise show 16 crosstalk delay violators and 3 noise violators, concentrated on the same detour-affected nets plus two nets running adjacent to the ADC bus's shield edge.

Step 7: postroute optimization

Following Part 7's decision map: setup repair (buffer upsizing and insertion on the 14 violating paths) brings WNS(setup) to +0.011 ns. Hold is rechecked at every corner afterward and remains positive at +0.019 ns — a small, expected decrease from +0.021 ns, still healthy with margin. Transition and capacitance repair clear all 11 and 4 violators. Crosstalk-aware optimization (targeted shielding/spacing against each named aggressor) clears all 16 crosstalk delay and 3 noise violators. A power and area recovery pass follows, but only after every violation above is confirmed clear. Dynamic power had risen to 1.94 mW during repair, from the 1.82 mW CTS-era baseline. Downsizing cells on paths with generous remaining slack brings it back to 1.87 mW. Leakage power settles at 0.097 mW. A full timing re-check after the recovery pass confirms no violation reopened.

Step 8: final verification and checkpoint

A final full pass of every report in Part 8 confirms the result. The partition is 100% routed, with 0 unrouted nets, opens and shorts, 0 DRC and 0 antenna violations. There are 0 transition and capacitance violators and 0 crosstalk delay and noise violators. WNS(setup) is +0.011 ns in func_ss_0p72v_125c and +0.015 ns in test_ss_0p72v_125c, and WNS(hold) is +0.019 ns in func_ff_0p88v_m40c. Clock skew is within target, redundant-via coverage is 100% on every flagged net, and the run log carries zero unexplained warnings or errors. The checkpoint is saved as nimbus8_sens_tile_routed_postopt_v1 and confirmed to reopen cleanly.

Before and after: the complete picture

Figure 21 — Nimbus‑8 before and after: from congested estimate to closed route

Final decision: PASS

Every item in Part 12's stage-exit checklist, evaluated against the evidence above, reaches PASS. Routing is complete and legal, and connectivity is clean. DRC and antenna are clean, and congestion is resolved. Timing and hold are positive with margin in every active scenario, and transition, capacitance, crosstalk and noise are clean. Clock QoR is within target, and power was measured and recovered. The custom-router handoff for sens_adc_in[15:0] is fully verified per Part 6, and the run log carries no unexplained warnings. Nimbus‑8's routed, postroute-optimized checkpoint is ready to hand to chip finishing, extraction, and signoff.

Part 11 — Guided lab

Repeat the flow yourself

This lab repeats Part 10's flow at a scale you can run and inspect yourself, with both the standard routing path and a custom-router comparison exercise.

Picture a much smaller version of Part 10, sized to fit on the machine in front of you. Everything has the same shape as the worked example. The difference is that you can open the block yourself, look at the geometry, and see what each command actually did.

Lab exercise 1 of 3 — Standard routing path Lab exercise 1 of 3, continued Lab exercise 2 of 3 — Postroute optimization Lab exercise 2 of 3, continued Lab exercise 3 of 3 — Custom-router comparison Lab exercise 3 of 3, continued

Overall lab completion criteria

• Standard routing path run end to end, with a saved routed checkpoint.Evidence: lab_block_routed_v1
• Postroute optimization applied and all violation categories cleared.Evidence: lab_block_postopt_v1, pre/post reports
• Custom-router comparison exercise completed on the lab bus, both variants verified.Evidence: lab_bus_standard_v1, lab_bus_custom_v1, comparison notes
• All diagnostic questions answered in your own words before checking the given answers.

The one word this lab has to end in

Classify the lab the same way this chapter classifies everything else, and write the classification down before you look at anything else. PASS: every criterion above met, with its named checkpoint saved and confirmed to reopen. REVIEW: every criterion met except one you can state precisely, with a stated action and a stated re-check — a REVIEW with no action is a BLOCKER wearing a friendlier label. BLOCKER: any unrouted net, any open, any short, or any DRC or antenna violation left without a written disposition, or any missing checkpoint. Record the verdict, the checkpoint names (lab_block_routed_v1, lab_block_postopt_v1, lab_bus_standard_v1, lab_bus_custom_v1) and the evidence file behind each one, exactly the way Dashboard 5 in Part 12 does. Ending a stage with one explicit word, and a saved artifact behind every claim, is the transferable part of this lab.

Part 12 — Stage-exit checklist

The complete routing and postroute optimization exit gate

This is the objective definition of “done” for this stage, referenced throughout the chapter. Every item needs its own evidence. An earlier Part's success is not a blanket assumption that a later item is automatically satisfied. Every item also needs a saved artifact, because the next stage inherits this design without inheriting your memory of how you checked it. The whole gate is given below as one evidence board, rather than as twenty-five separate cards. A criterion is only meaningful beside the others it is judged with. A reader deciding whether to ship a stage needs to see the whole decision at once.

Think of this Part as the gate at the end of the site, not a form to sign on the way out. Picture the next engineer opening your block a week from now with no memory of what you did. Everything they need has to already be in the evidence column.

Command verification noteThe full statement of what was verified and what is illustrative is in Part 8. For this Part: check_routes, report_timing, report_clock_qor and report_power are VERIFIED against the Synopsys reference, while report_route_status and extract_rc are this chapter’s illustrative pseudocode.

When a row is not PASS

The board above records the decision; this is how to act on one. A connectivity row that is not PASS is never dispositioned and never carried forward. That covers unrouted nets, an open and a short. Return to Part 5's detail-routing stage and Part 9's unrouted-net and connectivity cards, then re-run the gate from the top. A physical-rule row covering DRC, antenna, via quality or layer usage may be dispositioned. It may only be dispositioned with a written reason attached to the saved artifact, naming each remaining item and why it is acceptable. “A few left over” is not a disposition. A congestion row that is not PASS usually means the design was routed through a problem rather than around it, and the fix lives in Part 4's strategy decisions or, further back, in placement. A timing, signal-integrity or power row sends you to Part 7's decision map, which maps the specific symptom to the specific technique. Every repair there is followed by a re-check of the rows above it. A setup fix can open a hold violation, and a crosstalk fix can move congestion. A process row is the cheapest of all to fix and the most often skipped. That means unexplained log messages, a missing artifact or an unverified checkpoint. Fix it before the handoff, not after.

One BLOCKER anywhere makes the whole board NO-GO. The verdict is a single decision about the whole stage, not a score out of twenty-three.

Part 13 — Knowledge reinforcement

Locking in the judgment, not just the commands

Key takeaways

• Route completion is a milestone, not a finish line — it proves connectivity exists, nothing about legality, timing, signal integrity, or power.
• Congestion, timing, and signal integrity are not separate checklists — a decision made for one almost always has a measurable cost to another.
• A custom-router path is chosen when a requirement is genuinely outside what the standard flow can guarantee — never as a workaround for an unresolved setup or congestion problem.
• Import success from a custom router is never treated as correctness on its own; the same verification a standard-routed net must pass still applies, plus a neighboring-region congestion recheck.
• Postroute optimization is report-driven repair, not command repetition — every fix answers a specific symptom a report has already shown.
• Convergence has a stop condition, defined by the stage-exit checklist — not a subjective sense that the design feels finished.

Beginner questions

Interview questions with answers

Scenario questions

Troubleshooting exercises

Flashcards

Short quiz

1. Name the four stages of the standard routing sequence between global routing and antenna handling.
2. What is the difference between a spacing rule and a nondefault routing rule?
3. Why must connectivity be checked separately from DRC after a custom-router import?
4. Name two physical actions postroute optimization uses to repair a setup violation.
5. What is the objective definition of “done” for this chapter?

Answers: 1) Track assignment, detail routing, via insertion, search-and-repair. 2) A spacing rule is the technology's fixed minimum; an NDR is an engineer-defined override of the default for specific nets. 3) DRC checks geometry legality; connectivity checks that the geometry actually forms the intended electrical net — a design can be geometrically legal and still electrically wrong. 4) Buffer insertion/upsizing and cell resizing (also acceptable: route change, detour reduction). 5) Every row of the Part 12 stage-exit checklist reaching PASS or an explicitly justified, non-blocking disposition.

Quick command reference

Command verification noteEvery command in this table was checked against the genuine Synopsys IC Compiler II Tool Commands reference (Version X-2025.06-SP2). 21 of the 25 rows below are independently VERIFIED against it (exact syntax corrected where the chapter's earlier form differed); 4 remain ILLUSTRATIVE PSEUDOCODE because no command by that name exists in the reference. See qa/command-verification.csv for the full per-command sourcing, page citations, and status.