What TritonRoute Actually Does

Section 6.2 opens with an uncomfortable truth about the two routing steps so far: neither has drawn a single legal wire. Global routing produced a rough topology. Track assignment pinned it to specific tracks. Both are still promises, plans for where wires will go, not wires. TritonRoute is where the promises get cashed, or do not. It draws design-rule-correct metal shapes and vias, checks them against SKY130’s real rules as it goes, and is the single most common place in the whole flow where a design that sailed through every earlier stage abruptly refuses to finish.

Detailed routing’s actual job

TritonRoute, the detailed phase of run_routing, takes the track-assigned topology and, net by net and layer by layer, generates the exact wire segments and vias that realise it, enforcing every applicable design rule as it commits each piece of geometry. That is a fundamentally different problem from global routing’s. Global routing asked “is there roughly enough room?” Detailed routing asks “can I draw an actual, legal shape, right here, right now, given everything already drawn near it?” The answer is sometimes no even when the earlier answer was yes.

Why can something legal at the GCell and track level be illegal at the geometry level? Because tracks tell you where a wire can run, not everything about what is allowed to sit next to it. Two wires can each be perfectly on-track and still violate a spacing rule between them if a via sits nearby, and a via can be fine in isolation but violate an enclosure rule against the metal it lands in. Design rules operate on the drawn shapes, and only detailed routing works at that resolution.

Why this is where the surprises live

Every stage before this one works with abstractions: cell locations, GCell demand, track indices. Detailed routing is the first that has to produce something a fab could manufacture. That gap between “the abstraction says this should work” and “the exact geometry is legal” is why an experienced physical designer treats a clean detailed routing run, not a clean global routing run, as the real signal that a design is sound. Do not celebrate routability until detailed routing says so.

TritonRoute logs its own progress: an initial detailed routing pass, then a configurable number of rip-up-and-reroute iterations that try to resolve whatever violations the initial pass left. A design that reaches zero in a few passes is routing cleanly. A design that needs sixty iterations and still ends with violations is telling you, in the router’s own log, that something upstream is fighting it.

Reading a log excerpt

A representative excerpt of TritonRoute’s console output partway through a run on the UART:

[INFO] Start routing data preparation.
[INFO] Complete routing data preparation.
[INFO]  Number of nets to route: 1428
[INFO] Start initial detailed routing.
[INFO]  Iteration: 0
[INFO]    Number of violations: 214
[INFO]  Iteration: 1
[INFO]    Number of violations: 58
[INFO]  Iteration: 2
[INFO]    Number of violations: 9
[INFO]  Iteration: 3
[INFO]    Number of violations: 0
[INFO] Complete detailed routing.
[INFO]  Total wire length = 48213 um
[INFO]  Total number of vias = 3112

It took three rip-up-and-reroute iterations after the initial pass to reach zero. The count falling sharply and monotonically, 214 to 58 to 9 to 0, is the signature of a router converging normally: each pass clears most of what is left rather than shuffling it around.

A converging run beside a stuck one — Figure 1: Left, violations per iteration for the run above. Right, the pattern to worry about: the count drops once and then plateaus, which means a structural conflict that local rip-up cannot resolve.

Had the count plateaued instead, say 214 to 60 to 58 to 61, that would mean the router is stuck against a structural conflict, usually real congestion or a placement problem, that local rip-up-and-reroute cannot fix on its own. That is the situation Section 6.5 walks through.

Practice Exercise

A colleague says their design is “done routing” because the global routing report showed zero overflow. What is wrong with that claim, and what one piece of evidence would you ask for before agreeing?

Solution

Zero overflow in global routing means there was roughly enough coarse capacity everywhere. It says nothing about whether TritonRoute could draw every wire and via as legal, DRC-clean geometry. The claim is premature. Ask for the detailed routing log’s final violation count, ideally with the completion summary and its wirelength and via totals. Only a detailed pass that ends at zero violations is evidence the design is routed rather than roughly routable.

To understand why detailed routing can fail where global routing did not, you need to know what vias are and what “design-rule-correct” actually demands of every wire and via TritonRoute draws. That is the next article.