Back to log

Legal First. Optimal Next.

Three decades of research called FPGA routing intrinsically sequential. Here it is on one GPU: 799,403 nets, zero capacity overuse, independently verified on every run.

A depth charge detonates in dark water, its flash illuminating a submarine built from circuitry.

One sentence kept turning up in the literature, in three different papers, in almost the same words: the standard FPGA routing algorithm is intrinsically sequential. Three research groups, three decades of tooling, one verdict, routing on a GPU cannot be done. I disagreed, and I built the engine that settles it.

Routing is the dominant stage of FPGA compilation, and the reason it resists parallelism is almost elegant. Route every net at once against a frozen picture of the chip and they all see the same congestion, so they all flee to the same alternatives at the same time and pile up there instead. Next round, they flee together again. The literature never named it, so I did: herding. On a real design the herd flatlines in the tens of thousands of violations while a sequential router walks the identical problem to zero, same netlist, same chip, opposite outcome. Closing that gap in parallel, on a GPU, is the whole problem.

The receipts

mi-go floods every net at once, drives the pileup down, and finishes the last conflicts. Then a separate program re-derives the result from the emitted routes and confirms it. The router never grades its own homework, and that independent check is what signing off a chip actually demands.

Four real designs, each verified from its own output:

  • picosoc, 4,055 nets: legal in about half a second (2.4x faster than the 30-year-old reference router).
  • neuron, 50,835 nets: legal in about twelve seconds.
  • sparcT2, 182,090 nets, a real Titan benchmark: legal, three runs out of three.
  • bitcoin_miner, 799,403 nets, a routing graph of 13.7 million nodes: legal in about 259 seconds on the single 96 GB card under my desk, five runs out of five. Every connection present, zero capacity overuse.

No GPU router of any design had driven overuse to zero at even a tenth of this scale. That is the part with no precedent.

Why I trust it, and why you can

Parallel routing is chaotic enough that opinions about what helps are close to worthless. Two disciplines made the result trustworthy instead of lucky.

Controls, not vibes. Same engine, same design, one variable changed: with the key idea off, the route does not close; with it on, it closes, and fast. Two outcomes, far apart, from a single switch. I can only gesture at the idea itself, because it is claimed in a filed patent application, but the control is the part that earns trust: if you cannot switch your idea off and watch the system fail, you do not actually know it is the reason it succeeds.

Interrogate the instance, not just the solver. One fifty-thousand-net design stalled just short of legal for weeks. The solver was not the problem. The instance had been generated at the exact minimum channel width where routing it is possible at all, zero slack. Regenerate the chip model with modest slack, run the same router unchanged, and it closes cleanly in about twelve seconds. A solver is not broken when the problem it was handed is impossible.

Honest about where it stands

VPR, the open-source reference router, is faster than mine on the largest designs, and I put its numbers next to my own because it earned them: three decades of tuning by many teams. mi-go is generation one, built by one person, aimed at a single target, the property the field said could not be had at all, legal routing on a GPU with the parallelism doing the work instead of fighting it. Legal first, optimal next. Optimizing a router that does not finish is a wasted afternoon; making a router that already finishes, every run, go faster is a roadmap. That is a far better place to build from.

See it for yourself

You do not have to take my word for any of it. Two interactive views, the what and never the how:

  • Watch a design route. Pick a real design and watch the over-capacity count collapse to zero on one GPU, then a separate pass confirm every net actually connects.
  • Why routing resists the GPU. Why more cores alone do not fix it: routing is coordination and latency bound, not compute bound. That is the wall the field called impossible, and the one mi-go was built to get past.

The full technical brief, with the tabulated results, test conditions, and the honest width standing against VPR, is at voxell.ai/mi-go. The mechanism is protected in U.S. Patent Application No. 19/731,882. The reproduction kit, one binary, the designs, and the verifier, is available on request from that same page: run it yourself, or send a netlist and a placement to [email protected] and get back a legal route you can check.

The GPU Was Always the Right Weapon

For roughly thirty years, FPGA routing carried a verdict: intrinsically sequential, and therefore beyond the reach of a GPU. Routing is 73 to 91 percent of compile time on large designs, so the verdict was never academic. It set the ceiling on how fast anyone could turn a design into working silicon.

The verdict was wrong, and not wrong in the easy way. The contention storms are real. The stubborn knots, where nets deadlock over the same scarce wires, are real. But once you handle both the algorithm and the physics of the machine it runs on, the conclusion is inescapable: the GPU is the right weapon for FPGA place and route.

The mi-go router is a parallel negotiated collapse: every net negotiates at once against a shared snapshot of the fabric, the opposite of the serial negotiation the field settled for. On a single GPU, it reaches fully legal routes across four public benchmark designs, up to 799,403 nets, the bitcoin_miner Titan benchmark, in about 259 seconds. Legal. Not partial, not approximate, and independently verified on every run.

VPR, the open-source reference router, is still faster than mi-go at the largest scale, and we say so plainly. This is not a speed claim, and it does not need to be. It is a legality claim, and legality is the thing the field said this hardware could never reach.

The barrier and the rest

Here is why this matters more than one benchmark. Reaching legal was the load-bearing barrier. What remains, performance, channel width, timing closure, is not a new architecture waiting to be invented. It is the same class of problem: many constraints negotiated in parallel against a shared picture of the fabric. Legalization is simply the version with the hardest constraint, everything sharing scarce wires at once with no overuse allowed. Timing and wirelength do not change the machine; they add cost terms to a negotiation that already runs. mi-go was designed for the whole journey, legal first, then performant, then width and timing, not as a one-off trick to clear a single bar.

There is real work ahead, and we will not pretend otherwise. But its shape is the same class of problem the machine already broke, not a second one waiting to be invented. After three decades, the right tool for the job is finally on the desk.

A word on scope. We have, with this effort, demonstrated a genuine leg up, not a drop-in tool. We do not claim, and do not expect, that an engineer reading this will take mi-go into their production flow. The claim is bigger and simpler: after three decades of an assumption that held the field still, the right machine for FPGA place and route is finally here. mi-go proves fully legal routes today, independently verified run after run. Timing and wirelength quality are the declared roadmap, not today’s result.

The field said intrinsically sequential. The card under my desk says 259 seconds.

One of us has receipts.


Jonathan Corners · Founder, Voxell Inc. voxell.ai · sentimark.ai

Something in this log entry sparking an argument, partnership idea, or infrastructure war story?

Open a channel