What Happens When You Rewrite a PCB Autorouter From Scratch?

To me, AutoRouting felt like a simple enough task: use A* or Dijkstra like I learned in my college time, and just add a few obstacles, and voilà, you have a trace that looks good and has no violations, but a PCB designer would reject those traces instantly.

Then I started learning about PCB routing, how an engineer goes about planning the routing strategy. For me, understanding the intent the engineer probably had a rough idea of during placement was the hardest part.

And of course, differential. Differential was a big problem for me back in the day—understanding and designing an algorithm aware of length matching, constant spacing, and impedance requirements.

Earlier on, we were more placement-focused, but one time Manav showed me the initial draft of an autorouter with built-in constraints and a pass-based algorithm. It seemed good at first, and we kept improving that algorithm until I realized the code was fundamentally inefficient and unable to handle complex routing decisions and techniques.

Fixing that felt like a huge task, much like how game engines work. With a new generation of games and demand for more capable physics rendering, a better engine is needed, and sometimes patching that engine creates conflicts that are hard to fix without breaking something else.

Then we decided to scratch that router and work on a cleaner fundamental algorithm that is designed to treat more real-world routing constraints as first-class inputs. Since then, we have been constantly evolving the algorithm to fit our needs, making it more flexible for different cases. I hope we do not have to do it again, I was exhausted by the giant task of making something this big and complicated.

When we first realized the older router was not going to work, I had a pretty good idea about what we wanted and was aware of the problems a generic point A to point B algorithm wouldn’t be able to solve.

Having those clear requirements with us, we had to start leaving more room for things like power pours, length-matching signals, and differential pairs. A much-needed complex cost function that judges the route not only on how short the connection is, but also on what it leaves behind, essentially measuring the impact of that trace on future traces.

The new algorithm was definitely slower. That was a downside to it, but it showed its worth in the outputs. The routing drawn by the new algorithm was cleaner, to the point that sometimes we get confused about whether it was the manual or the autoroute sample. Totally not flexing our product here.

Oh no, there is still a long way to go, and I don’t mean that in regard to the capability of the autorouter. Agreed, the router is still maturing, but it will reach good enough performance in the near future. The downside is that a router cannot adapt to what every customer wants. Some people would prefer a strict 45-degree bend rule with no curves, a continuous ground plane, or no via-in-pad design. Some would want a high-density design with more layers, while some would prefer compact and tight spacing.

With our router, the entire control of what an engineer wants or does not want is in their hands. Sure, we have already picked out what we think are the best, generally acceptable constants, but an engineer or a company might have their own set of policies that can directly be managed in the router itself, so a person can fine-tune the engine to their needs. I think this is one of our strongest features—giving full control so you can derive what’s best for you.

It is a constant evolution of ideas. Like, I have a hypothesis, and before implementing anything, we have an adversarial discussion where we discuss why something might not work. LLMs are great at gaslighting, pitching you solutions that, in theory, sound good but don’t end up working.

One great thing I like about AutoCuro is that each idea is heard, and we like to spend some time coding them up if we truly believe they might work. But we also have a rollback to prevent us from endlessly investing in one idea. If something feels like a dead end, we stop, record our observations, and hop onto another experiment.

It can get frustrating at times, but it is incredibly rewarding when some hypothesis ends up working.

As the router generates routing reports, if you go through them, you would clearly get an idea of where the router failed to produce a solution. There are separate DFM reports that also indicate where the routing violated constraints, when the router was not able to cleanly break out a fine-pitch BGA, or failed to route a differential pair.

While we aim to minimize the failures, we are pretty open about what we can and can’t do. When someone runs the autorouter, they can have an exact idea of what to fix instead of going through the whole design, and we aim to minimize that effort for a truly autonomous zero-shot system one day.

This, along with an algorithm that goes back and forth between the engineer and our system for multiple iterations if needed, is the thing I am most proud of.

Can we ask meta to summarize our conversation? just kidding. I think the crux of my work building an autorouter is that it is an iterative problem with a global goal, Working on the router has given me knowledge on hardware design that I did not have being an IT graduate, Building something that does not require a data centre to process and can run on a Core 2 Duo with 4GB of RAM is pretty amazing if you ask me. Try out our tool at autocuro.com/app