mi-go · gpu-native fpga router · the real bottleneck

Compute was never the problem. Coordination is.

For three decades, FPGA routing carried a verdict: it cannot be parallelized on a GPU. The reason is not a shortage of cores. Routing is bound by coordination and latency, not arithmetic, and throwing more cores at a coordination-bound problem does not move it. That is the wall mi-go was built to get past.

The instinct, and what actually happens

the instinct: more cores, more speed naive parallel: the herd waits in lockstep coordinated: progress

cores on the problem coordinate the negotiation

Cell headroom

utilizedwide open

The silicon is far from its ceiling. Reaching legal barely leans on the machine, so the room above today's result is large by design.

Compute-bound vs coordination-bound

A compute-bound job gets faster as you add cores. A coordination-bound one does not: the cores spend their time waiting on each other and on memory, not computing. Routing is the second kind.

Why the field said no

Route every net at once and they all chase the same scarce wires, then back off together. The parallelism turns into a herd that moves in lockstep. More lanes just makes a bigger herd, not a faster route. So the field concluded the GPU was the wrong machine.

What mi-go changes

mi-go was built for the coordination, not the arithmetic. It negotiates the contention in parallel so the lanes make progress instead of waiting in place. That is the crux the field missed, and it is why the GPU turns out to be the right machine after all.

Conceptual illustration of a latency- and coordination-bound workload, not a measured trace. The "herd" behavior, naive fully-parallel routing failing to converge while a coordinated negotiation drives it to a legal result, is the empirical finding mi-go is built on. Legal First. Optimal Next.