# DeepRoute: An autorouter built for the AI era

> Source: <https://www.zeroasic.com/blog/deeproute-tournament>
> Published: 2026-10-08 17:26:18+00:00

Taylor Hogan ·

## DeepRoute: An autorouter built for the AI era

In June we [announced PackageCompiler](https://www.zeroasic.com/blog/packagecompiler_launch), a tool that turns a description of a package into manufacturable artwork. That announcement said what it does. This article and the two that follow are about how it does it: the parts that look like magic from the outside. We start with the router.

Every router you have used routes the design once, with parameters a person or a script picked in advance, and hands you the opens. Then you reorder, retune, re-run, and repeat until Friday. DeepRoute, the router inside PackageCompiler, does not route once. It runs a tournament: many complete routings at the same time, each a different strategy, and keeps the one that scores best.

**Idea one: a tournament, not a pass.** Start with the unit of work. A routing trial is one complete routing of every connection under one configuration: a net order, a set of cost weights, a layer assignment for each net. A conventional router runs one trial, ripping up and retrying inside it. That is a sequential paradigm, and it can only ever explore one answer at a time. DeepRoute runs a tree of trials.

A tournament only works if every game is fast. The inner loop, the global router that turns one configuration into a complete routing, runs dozens of times in every compile, so it has to finish in seconds, not hours. We built it to be fast from the first line of code, because we decided early that nothing judges a configuration as faithfully as the route itself. Estimates and heuristics guess how good a plan is. Routing it tells you.

From the root, several strategies race at once: escape strategies that fan bumps out to balls, die-to-die strategies for parallel buses, redistribution strategies for interposer layers. Each strategy spawns child configurations, duplicates are collapsed, and every level of the tree routes as one parallel batch across all the compute available. The tree grows as wide and as deep as the hardware you give it. And it is deterministic: same design, same tree, same answer.

*Illustration: one compile as a tournament. Each dot is a complete routing; the highlighted path goes from 114 opens to zero.*

**The score is the interesting part.** A routing result is not one number. Every trial is measured in many dimensions at once: opens, routing efficiency, congestion, signal integrity, and the other measures that have proven to predict a design that closes. The winner is not the trial that is best on any single metric. It is the one that is strongest across all of them together. A chess engine does not play the first legal move it finds. It looks ahead over many candidate lines and plays the one that scores best. DeepRoute does the same with routing strategies.

Power and signals are one design, not two. They compete for the same layers and the same space, so the strategies in the tree plan both domains together, instead of routing the signals and pouring power into whatever is left.

**Idea two: signal integrity built in.** Three levels of electromagnetic analysis are available on every compile: closed-form formulas in microseconds, a 2D boundary-element solve in seconds, and a full 3D full-wave solve in minutes. All three read the same geometry the router wrote. It is one database shared in memory, with no export and no translation step. You do not enter trace widths. You give the target impedance, the stackup and the operating frequency. The trace widths follow from the impedance.

*A crowded corner of a BGA, straight from a compile. The escape pattern threads every signal out between the bumps, and once each trace is clear of the bump field it widens automatically to the width its target impedance calls for. Nobody drew these widths: the router computed them from the impedance and the stackup. VSS is poured into the space left between the signal traces, and stitching vias (the lighter dots in the copper) are dropped into it in a pattern driven by the operating frequency, spaced at a fraction of a wavelength so every trace keeps a return path close by.*

The planes are poured and stitched with vias whose spacing is set by the frequency, a fraction of a wavelength, so the return path holds at the speeds you care about. Every compile ends with a detailed report, which matters as much as the pretty picture.

*VSS on E6, one of the public examples on our website, straight from a compile: the ground planes, the stitching vias that tie them together (red), and the columns down to the balls (blue). The colour on each plane is a heatmap of how near the stitching vias are to the traces they protect: magenta means not enough stitching. The lower plane was deliberately under-stitched for this run, to check that the heatmap catches it.*

**Idea three: parameters are searched, not set.** Every router has knobs: how hard to push toward the target, how much to penalise congestion, how much to remember earlier failures, when to give up on a channel. In a conventional flow an expert sets them, by experience, design by design, and the next design starts from whatever worked last time. When the result is poor, nobody knows whether the design was hard or the knobs were wrong. In DeepRoute, the knobs are managed by the tournament. Settings compete like any other branch of the tree, and the combinations that win emerge as new strategies.

**The payoff: thirty minutes, not a season.** What this means for the person driving it. A package that used to take weeks of back-and-forth now comes back in minutes with the electrical evidence attached, and the human time goes into deciding, not waiting. Speed also changes what people are willing to try. When an iteration costs weeks, you choose the safe design and live with it. When it costs minutes, you try the options nobody had time for: two fewer layers, a tighter ball pitch, power moved to different balls, a different stackup. The cheapest package is often the one nobody had time to try.

**Built for the AI era.** The same choices that make DeepRoute fast for people make it a natural fit for AI. A complete routing comes back in seconds, so an agent can afford to loop over thousands of independent routing attempts. Results are deterministic, so every experiment is reproducible. Logical and physical data live in one database, so an agent reasons about nets and geometry together, with no translation step. Signal integrity is computed on every compile, which gives a learning loop an electrical score to optimize, not just a count of opens. And design intent goes in as text, the native interface of a language model.

**Coming next.** Two more articles finish the series. The first is about what happens when the electromagnetic engine lives inside the router instead of down the hall. A tightly coupled solver gives immediate feedback on every compile, and it can become the score the search itself learns from: the router stops asking only “did it connect” and starts asking “will it work”. The second is about the GUI, because there isn’t one. Package design is a compile problem. Want a different via shape or ball pattern? Instead of wading through a menagerie of bespoke dialog boxes, you type it in plain English: “tighten the ball pitch from 1.0 mm to 0.8 mm”, or “try this routing on four layers instead of six”. Then you compile and read the result.
