We do many tricks to reduce the impact of ordering, such as building congestion maps and using rip’n’replace, but at the end of the day there are just too many possible orderings, for a simple board with 50 traces, there are 30,414,093,201,713,378,043,612,608,166,064,768,844,377,641,568,960,512,000,000,000,000 possible ways to order the traces. You’re not going to enumerate that!

So what can we do? Enter the Unravel Algorithm.

Unraveling a HyperGraph

The unraveling algorithm takes an existing hypergraph, or a section of an existing hypergraph, and asks “what would happen if I swapped the assignment of ports at the boundary between regions?” This swap is a “mutation”, and our goal with the unravel algorithm is to improve small sections by finding small sets of mutations that reduce the number of via-causing intersections.

Unravelling uses A* and tracks a “path” of mutations. If a mutation path is winning, it continues to follow it. If a mutation path gets long or isn’t yielding wins, then it is pushed to the back of the queue.

Because unraveling can work on sections of a HyperGraph, it can execute in parallel and even has the possibility of recalling cached graphs. We’re able to correct all the “criss-crossing” that would have made for a messy, via-heavy high density route.

Because there is often a port at each layer of the PCB on each point, layer swapping is built in. Where it’s possible to swap to a different layer to avoid vias way later in our path, our mutation will apply it.

Our routes are now ready for high-density routing with the lowest number of vias.

Conclusion

The Unravel algorithm enables adjustments to global pathing to minimize the complexity of high density routing and reduce the impact of trace ordering on global pathing. It’s a highly parallelizable algorithm that can do no harm because it only accepts beneficial mutations.

If you’re interested in contributing to our autorouter or attempting some difficult algorithms, join the tscircuit discord or yell at me on twitter.

How does automatic placement fare? If you use a regular packing algorithm that minimizes the space usage, you will create a board that is nearly impossible to route. If you use a force-directed packing, where the netlist forms springs that pull chips close together based on their connections, you’ll get an unusual shape and suffer local minimums (it’s also wildly unpredictable)

When we’re thinking about packing algorithms, the first concern should be capturing human design requirements. The algorithm should, as closely as possible, understand statements like:

• The USB port must be 2mm from the left edge on the top side

• The decoupling capacitors must be near the power pins on the microcontroller

• The left and right headers must be spaced 20mm apart, and aligned

• Copy the placement from the datasheet EXACTLY for this subcircuit

How do we capture these requirements? In tscircuit, they are captured through <group>/<subcircuit> tags with different layoutMode properties, also coordinate specifications like pcbLeftEdgeX=calc(board.minx + 2mm). In some cases, the entire layout can be resolved by ordering the computations properly, but more often than not, this way of specification is arduous for the user and inflexible as a design grows.

For underspecified placements, Sequential Optimal Packing is a fast, deterministic and legible solution for packing. It allows us to capture “flexible” design constraints in a predictable way.

Sequential Optimal Packing

Sequential Optimal packing sequentially packs chips in the Pack Order. Each time it packs a new chip, it selects the Optimal position based on the Cost Function. The Cost Function is established from the design intent for that specific chip.

Here’s the algorithm in a nutshell:

• Order your chips in the Pack Order

• If there are no preplaced chips, pack the first chip in the center

• Main Loop:

  • Pick the next chip

  • Find the optimal placement and rotation for that chip and place

  • Repeat until all chips are packed

Simple!

This algorithm can be made fast because you can quickly compute a boundary along our existing packed chips and pads, then find the Cost Function minimum along each segment of the boundary.

In the animation below, you can see the algorithm in action. The lines from pin to pad help show what the components of the Cost Function are. You can think of the Cost Function as “summing” the lengths of all the lines or taking the minimum of all the line lengths as the cost.

Sequential Optimal Packing is great

Sequential optimal packing is easy to understand and visualize. You can easily watch each component pack one by one and vary the pack order or optimal packing function to achieve a desired outcome. Every individual packing decision is easy to understand.

If you are using tscircuit, you can debug the packing algorithm using the “Solvers” tab.

Sequential optimal packing is also extremely compatible with other layout mechanisms, like when you want to have a group of components that are in a reference configuration (from a datasheet) but should be packed together. You can also layout pre-computed positions before you begin packing- it’s compatible with partially packed existing layouts.

Downsides

Sequential optimal packing is flawed in two major ways:

• The best pack order is not initially obvious, early chips can be placed such that later chips don’t pack well

• Sometimes the global optimal placement is impossible, because it requires two chips to be packed in locally sub-optimal positions

Both of these issues can be mitigated by treating sequential optimal placements as an initial approximation, then refining by “hardening” constraints. e.g. if you know you want a decoupling capacitor in an exact position relative to a chip, encode that such that the chip and decoupling capacitor are packed together. LLM loops can easily adapt the design intent representation to do this!

Conclusion

Sequential Optimal Packing is one of the key algorithms that should be included in the standard constraint algorithms for PCB design. It is highly debuggable, easy to understand, and can be tweaked in a feedback loop until you reach a global optimal placement. It should be a fundamental algorithm, similar to flexbox or CSS Grid, baked into every PCB engine.

If you’re interested in algorithm development, join our discord or follow me on twitter.

This is the situation we’re in with autorouting. We have a many similar solutions, but we don’t yet have a mechanism to retrieve those solutions and apply them to similar problems. More importantly, we don’t know how many of these solutions we would need to store to have something effective.

If you naively “cache” the exact coordinates of every pad, every hole and every required trace, you will find that you’ve stored terabytes of useless data- after all, every circuit board is unique and any slight change breaks the cache. If you store circuits lossy however, say by only storing the netlist and footprints, you’re likely to have a solution that is unusable as components are moved around.

So what do you store? How do you look up what you’ve stored? How do you apply it to a unique dataset?

Our Case Study: Zero-Obstacle Autorouting

We’re going to study an approach to caching algorithms through the lens of the “zero-obstacle autorouting” problem, which is the most pure form of “the autorouting problem”. For the tscircuit autorouter, this is also the slowest phase of our autorouter and runs just after HyperGraph Autorouting. It is the algorithm that runs on “open space” in a PCB where there are no pads, holes or keepout obstacles.

Thinking of problems as vectors

The first, most important problem to solve is the representation of the problem. Our problem representation gives us a clear insight into the “problem space”. The problem space is basically the number of unique problems that exist. In general, if you need more numbers or more data, the problem space is really big.

So let’s start by breaking down the problem into a vector, using as little data as possible. Sometimes to reduce the data representing a problem, you can “project” into a problem space that is more constrained. For example, instead of storing X and Y for each coordinate, we can just store the angle relative to the origin and the overall size of the problem. This great simplifies our representation of the problem, we now can represent each point of our problem with (angle, z) instead of (x,y,z)

Trying to find ways to compress the problem space is a great exercise in exploring “what is actually important” for your problem. When we convert this problem into angles, we constrain the problem space. We can no longer handle points that have the same angle but are different distances from the origin- however, we never needed that problem space to begin with! We always organize points on the edge of a rect, so this is a GOOD constraint. If you can reduce the problem space to avoid invalid representations being possible, that is worth exploring!!

Vector Distance and Canonicalization

Now that we can think of our problems as vectors, it becomes possible to compute a “vector distance” between two problems. But before we get excited, we need to consider the type of similarity we’re interested in. We’re interested in a special kind of similarity, where two problems are similar only if they can share the same solution with some “tweaking”. We can’t just naively take the difference between each number in the vector and add up the differences, we have to find a more complex vector difference function that is tuned to return low distances for problems that can share a solution.

The “gotcha” of similarity functions in geometric spaces is you don’t really know if you’re comparing “apples to apples” when you’re comparing two parts of the vector. For our case-study, if we compare the two numbers in the array, we don’t know which two points we’re comparing. We might could have the exact same problem but with a totally different point order. The problems would appear to be very distant when we take the vector difference even though they share the exact same solution!

This is where the notion of “Geometric Canonicalization” comes in. This is where we sort or rearrange our vectors in a way that ensures we’re always comparing “apples to apples”. In our case, we can simple sort points by making the “lowest z, then lowest angles come first” Canonicalization can often create issues. For example in our case two angles may be very close together but sort such that they’re very far apart- like 0° and 359°. These issues can be mitigated elsewhere or absorbed into the size of the cache.

Ultimately, techniques like canonicalization and complex vector distance functions trade runtime for cache size. In our case, I knew we could reasonably handle 1 million entries in our cache, so we tuned our similarity functions and tweaking functions (which we’ll discuss below) until we had the runtime and cache-space tradeoff best for the autorouter.

Putting square pegs in square-ish holes (the “adapt” function)

When you have a “lossy” cache, you need to be able to pull a solution that may not be perfect and adapt it to the current problem. You can think of this as the “reverse cache transform” or the “adapt function”

The reverse cache transform should execute quickly, because it is a runtime penalty. It should check and fail if it’s unable to adapt a solution, because this signals that a different cache entry should be used or generated. Later, we’ll use the adapt function to avoid populating our cache with entries that don’t improve the overall system accuracy.

Below, our “force-directed” adaption increases the “reusability” of cached entries by allowing them to tolerate shifting of problem points without DRC checks. This is a very simple and fast way to adapt a solution to a new problem.

Synthetic problem generation → Optimal Cache

For the zero-obstacle routing problem, we were able to generate a cache with 4,000 entries that can solve 99.9% of 4-trace problems. But to do this, we had to generate over 1 million synthetic problems to test on.

Because we don’t completely understand the underlying algorithm and what “hidden” solution topologies exist, we have to keep throwing random solutions at the cache to see what is solvable and what needs a new cache entry. After doing this for hours, we eventually start to see less and less DRC (design rule check) failures on our cache-adapted samples.

This is why synthetic datasets are so valuable. If solving a problem as simple as a 10x10mm square with 4 traces takes a million samples, then there isn’t enough human data in the world to tune an autorouting algorithm on a full board!

K-Nearest Neighbor, Shrink the cache for a slower runtime

The “Nearest Neighbor” is a super simple algorithm where you say “What data point is closest to the data point I’ve been presented with?” and return it. That is essentially what we’re doing- we measure what is “closest” with vector distance, and return the nearest solution. A well-known adaption to nearest neighbor is to take the K nearest neighbors instead of just the nearest neighbor. Each of these neighbors also “looks similar” to the problem at hand and is worth trying.

The benefit of K-nearest neighbor is you can get away with having a smaller cache and just pay higher runtime costs, since you have to adapt K neighbors instead of 1. In our case, we set K=16 because the runtime overhead didn’t cause much of a delay and our accuracy jumped up considerably with a smaller cache, making it so users can run the autorouter on their local machine. This is another knob to play with- sometimes storage is preferable, e.g. where you have a cloud machine backed by a massive KV store.

Exploit geometric symmetry (shrink the cache by 16x!)

The zero-obstacle routing problem has a lot of symmetry you can exploit. Symmetry means that a transformed version of the problem has the same solution, transformed. For example, negating all the X coordinates (flipping over the X axis) produces a problem that has the same solution just flipped over the X axis.

Each “axis of symmetry” halves the cache space you need to represent the problem. In our case, we can exploit this to reduce the cache size by 16x- meaning we only need to store 6% as many solutions in our cache. Here are the axes we exploit:

• Rotating the problem by 90 degrees

• Flipping over the X axis

• Flipping over the Y Axis

• Inverting the Z Layers (Top becomes bottom, bottom becomes top)

There are four ways to exploit symmetry:

• Store all variants in the cache (reduce cache generation time)

• Check all variants at runtime (reduce cache size, increase lookup cost)

• Make vector distance functions understand symmetry (less conventional/supported vector lookup)

• Canonicalize to a single variant (difficult to get right!)

Conclusion

This method of speeding up algorithm runtimes is fantastic because it adapts to any algorithm complexity. The framework of canonicalization, vector distance, and adaption greatly improves the efficacy of a cache and makes it possible to model complex geometric algorithms.

Here are some examples of our cache being used against generated problems:

If you’re interested in contributing to our autorouter or attempting some difficult algorithms, join the tscircuit discord or yell at me on twitter.

Why grid-based autorouters are ineffective

Normally when people think about autorouting, they think of grids and pathfinding. This simplification is why most autorouters can only route 50-100 traces then must give up or run for days to get a solution.

A grid creates an enormous solution space size. Because traces are very thin, the cell size of your grid must be 0.05mm or 0.1mm. Each of those cells can be “assigned” to any of your nets or marked as not-connected. Then you need to replicate the grid for each layer of the circuit board. For a modest 70x50mm 4-layer board, you’re looking at 280k cells with 50 possible assignments per cell. Or 50^280_000 possible states.

Now you might argue that not all of these states are possible (e.g. they are occupied by pads, keepouts etc.), but that’s precisely why the grid is a terrible data structure for an autorouter. Great data representations only represent valid states, and as a result the algorithms that operate on them are much simpler.

Enter HyperGraphs

Wikipedia defines HyperGraphs as follows:

In mathematics, a hypergraph is a generalization of a graph in which an edge can join any number of vertices. In contrast, in an ordinary graph, an edge connects exactly two vertices.

This wide definition is more than we need, let’s focus on a subset of HyperGraphs called “2-regular HyperGraphs”. These are HyperGraphs where each vertex belongs to 2 hyperedges (regions). With a bit of effort, we can convert any PCB routing problem into a 2-regular HyperGraph where the regions represent empty space, and the vertices represent available space on the edge of regions.

We can now route through a much smaller solution space, instead of routing over a grid that takes up this entire space, we can focus on only routing over relevant “bottlenecks” that relate to obstacles likes pads. This type of pathfinding is almost instantaneous, it only takes a few iterations to get across the board!

HyperGraph A*

So HyperGraph autorouters are really fast. But they don’t work quite the same as grid autorouters. In grid autorouters, doing an “occupancy check” is O(1), you simply ask “is there anything in the cell I want to move to?”. If there’s nothing there, that means you can explore it.

In HyperGraph Autorouting, you do something completely different. You use fast vector intersection math to check if moving through a port would trigger an intersection. This is the performance tradeoff, but it’s a good one. If your topology is set up well, you’re often not checking for intersections often, and when you do there’s only 1-2 traces to run intersection math on. Considering you can easily hop over 200 grid cells in a single iteration, this is much faster.

Here’s an animation of a HyperGraph autorouter solving how to connect 3 traces through 4 jumpers.

Handling Layers and Vias

HyperGraph regions, unlike grid cells, should occupy multiple layers. This can make the “topology construction”, the step where you generate the HyperGraph from pads and obstacles, very difficult (worthy of it’s own article). Every port is duplicated for each layer it could occupy, to represent all the different ways a trace could enter a region.

Now we’re in an interesting situation. It is actually possible for routes to “intersect” within a region because a via could be placed to make the crossing possible. Instead of not allowing crossings, we instead compute a “cost” for each crossing so that A* explores routes where intersections may take place.

Handling Zero-Obstacle Crossing Routes within a Region

So let’s say we’ve solved our HyperGraph, but we have crossing routes within our region. What do we do?

This type of problem is called the “zero-obstacle routing problem”. It is a beautifully simple problem. You have a rect, and you have pairs of points which you must connect without them touching using vias. There are no obstacles, and you can use any cell size that’s convenient. You can use a conventional grid based solver on this small region, or you can use vector-based methods. You can even combine solvers together. The zero-obstacle problem on rects with <20 traces is already known to be easy. We’ve successfully broken down the problem to a point where grid-based solvers are already known to work. In fact, you can have AI vibe-code you a decent zero-obstacle grid-based autorouter in couple minutes. Relative to full board solving, it is trivial!

Here’s a zero-obstacle A* grid-based solver in action, I got a bit impatient (there’s so much to explore!) but you can see even though it takes a lot of iterations, they’re particularly good for zero-obstacle problems and solve quickly (in clock time)

The perfect cost function for regions?

When you’re autorouting boards you can slowly build up a dataset of “high density zero-obstacle” problems, each of these problems may have zero-obstacle routing problems you could or couldn’t solve with your zero-obstacle router.

If you are clever, you can compose a cost function that predicts whether or not a region is solvable, then cost appropriately so that your “HyperGraph stage” heavily penalizes regions that are unlikely to be solvable with your zero-obstacle high density problem solver (usually a grid solver)

Conclusion

See it all come together:

HyperGraphs are an incredible and underutilized way to solve autorouting problems. If you’re interested in developing open-source autorouting algorithms with us please get in touch with me (seveibar) via our discord or contact@tscircuit.com

Want to see the code? Check out our state-of-the-art, lightening fast MIT-open-source autorouter!

Before we get into the details, huge shout out to Johnathon Selstad who inspired and guided me through the process of creating this dataset, without him this would not have happened!

This dataset was created by running @tscircuit/high-density-a01 on 1 million randomly-created configurations of connection pairs in a 10x10mm rectangle with zero pads, keepouts or other obstacles within the rectangle.

This dataset represents the core problem of autorouting, which is generating viable trace paths that do not cross on the same layer within a dense space. Competing concerns with obstacle avoidance, DRC compliance, impedance matching etc. all are dependent on how you solve the “multi-agent pathfinding” problem at the core of autorouting.

The purpose of this dataset is to enable the development of vision models that can prove the viability of autorouting with vision models, not to build a full autorouting pipeline or production-ready printed circuit boards.

Here is an example of input and output data from the dataset:

The output of this autorouter, after parsing, can be input directly into the HighDensity phase of the tscircuit autorouter, so can be run as part of a larger autorouting pipeline.

This is far from a comprehensive autorouting dataset to cover all the edge cases and functions that are needed for a proper pipeline, but should pave the wave for researchers to determine if vision models are practical for autorouting.

Hugging Face ・Discord

- @seveibar

1. Know A* like the back of your hand, use it everywhere

If I was king for a day, I would rename A* to “Fundamental Algorithm”. It is truly one of the most adaptable and important algorithms for _any kind_ of search. It is simply the best foundation for any kind of informed search (not just for 2d grids!)

Here’s an animated version of A* versus “breadth first search” on a 2d grid:

The way A* explores nodes is a lot faster and more intuitive. The major difference between these two algorithms is BFS explores all adjacent nodes, while A* prioritizes exploring nodes that are closer to the destination. Because it considers a metric outside the graph (the distance to the destination) it’s an informed search.

You are already either using BFS or DFS (depth-first search) in your code. A recursive algorithm is a depth first search. Any loop that explores candidates/neighbors without sorting the candidates is a BFS. 99% of the time you can convert it to A* and get dramatic performance gains!

One of my favorite techniques in our autorouter is we run multiple levels of A* to discover the optimal hyperparameters for a particular problem. So we’re basically running each autorouter as a candidate, then using A* to determine which autorouters we should spend the most time on!

See all those numbers at the top? Those are each different configurations of hyper parameters. Running each autorouter fairly would be a huge waste of time- if one autorouter starts to win (it is successfully routing with good costs) allocate more iterations to it! This kind of meta-A* combines a regular cost function that penalizes distance with a cost function that penalizes iterations.

2. Implementation Language doesn’t matter

I’m controversially writing our autorouter in Javascript. This is the first thing people call out, but it’s not as unreasonable as you might expect. Consider that when optimizing an algorithm, you’re basically looking at improving two things:

1. Lowering the number of iterations required (make the algorithm smart)

2. Increasing the speed of each iteration

People focus way too much on improving the speed of each iteration. If you are doing something dumb (like converting everything to a grid for overlap testing), Javascript performance will beat you no matter what language you use!

95% of your focus should be on reducing the number of iterations. This is why language doesn’t matter. Whatever gets you to the smartest, most cacheable algorithm fastest is the best language.

3. Spatial Hash Indexing > Tree Data Structures

You can’t walk 5 feet into multi-dimensional space optimization without someone mentioning a QuadTree, this incredible data structure that makes O(N) search O(log(N)) when searching for nearby objects in 2d/3d space.

The QuadTree and every general-purpose tree data structure are insanely slow. Trees are not an informed representation of your data.

Why does Javascript use HashSets and HashMaps by default and every chance it gets? They’re super super fast. A Spatial Hash Index is the same concept as a HashMap, but instead of hashing the object we hash it’s location and store it in a Cell (or “bucket of things that are close together”)

Let’s look at how we might replace the QuadTree with a SpatialHashIndex with 20% as much code:

There are many variants of this basic data structure for different types of objects, but they all look pretty similar. We’re basically just creating “buckets” with spatial hashes and filling them with any object that is contained within the cell represented by the spatial hash.

The reason spatial hashes aren’t as popular is you need to be careful about selecting your cell size- this is what makes it an informed algorithm. If your cell size isn’t calibrated well, you’ll end up paying high fixed costs per retrieval. In practice, it’s not that difficult to pick a reasonable cell size.

4. Effective Spatial Partitioning + Caching is 1000x more important than algorithm performance

A circuit board like the one inside an IPhone probably has somewhere between 10,000 and 20,000 traces and take a team several months to route with the best EDA tools in world. It can seem daunting to try to optimize such an incredibly complex task- but the truth is the entire industry is neglecting a very simple idea: everything that has been routed has been routed before.

Game developers “pre-bake” navigation meshes into many gigabytes for their games. LLMs compress the entire internet into weights for search. The next generation of autorouters will spatially partition their problems, then call upon a massive cache for pre-solved solutions. The speed of the algorithm doesn’t matter when you have a massive cache with 99% of the autorouting problem pre-solved.

Most algorithms today do not focus on the effective cache-reusability or effective spatial partitioning, but a critical component of future autorouters will be caching inputs and outputs from each stage in a spatially partitioned way.

Moreover, the size of storage and caching seems to go down faster than the speed of computation goes up. It’s not a big deal to have a gigabyte cache to make your autorouter 50% faster.

5. If you do not have a visualization for a problem, you will never solve it

If there is one thing I could have printed on a poster, it would be VISUALIZE THE PROBLEM. You can’t debug problems by staring at numbers.

For every tiny problem we solve, we have a visualization. We will often start with the visualization. Time and time again this enables us to debug and solve problems 10x faster than we could otherwise. Here’s a visualization we made of a subalgorithm for finding 45 degree paths, we use this in our “Path Simplification Phase”, an ~final phase of the autorouter.

6. Javascript Profiling Is Amazing- Use it!

Javascript profiling tools are incredibe, you can easily see the exact total time in ms spend on each line of code. You don’t need to use any performance framework, just execute your javascript in the browser and pull up the performance tab. There are also awesome features like flame charts and stuff for memory usage.

Here’s a little youtube short I made about it

7. Never use recursive functions

Recursive functions are bad for multiple reasons:

• They are almost always synchronous (can’t be broken out for animation)

• They are inherently a Depth-First Search, and can’t be easily morphed to A*

• You can’t easily track iterations

• Mutability is often unnatural in recursive functions but critical to performance

Here’s an example of an “obviously recursive” function converted to a non-recursive function:

The iteration-based implementation is much faster because it keeps a set of visitedNodes and checks nodes prior to exploration. You can do this with recursive functions, but you have to pass around a mutable object and do other unnatural things. It’s just best to avoid recursive functions when writing performant code.

8. Monte Carlo algorithms are hacks. AVOID

Monte Carlo algorithms use randomness to iterate towards a solution. They are bad because:

• They lead to non-deterministic, hard-to-debug algorithms

• They are basically never optimal relative to a heuristic

I sometimes use Monte Carlo-style algorithms when I don’t yet know how the algorithm should get to the solution, but I know how to score a candidate. They can help give some basic intuition about how to solve a problem. Once you have something approximating a cost function, do something smarter than Monte Carlo or any other random technique like Simulated Annealing. If your algorithm is sensitive to local minimums, consider using hyper parameters or more complex cost functions. Almost any local minimum your human eye can see can be made into a component of a cost function.

Another way to think about it: How many PCB Designers randomly draw lines on their circuit board? None. Nobody does that. It’s just not a good technique for this domain. You’ll always be able to find a better heuristic.

9. Keep intermediate algorithms grounded

Our autorouter is currently a pipeline with 13 stages and something like 20 sub-algorithms that we measure the iteration count of for various things like determining spatial partitions or simplifying paths at the boundaries independently autorouted sections.

Being able to overlay different inputs/output visualizations of each stage of the algorithm helps you understand the context surrounding the problem you’re solving. I often ran into issues at downstream stages (often our “high density routing” stage) that could be solved by improving the output of previous stages.

The temptation when building sub-algorithms is to isolate the algorithm to its simplest form, maybe even normalizing around (0, 0). The danger with normalization or any complex transformation is it might impact the ability to quickly see consequences from early stages of the algorithm to later stages of the algorithm. To prevent this, just keep your coordinate space consistent throughout the lifecycle of the algorithm.

Here’s each stage of our algorithm one after another. We often zoom in on this to see what stage is the most guilty culprit for a failed Design Rule Check.

10. Animate your iterations to catch stupid behavior

Remember how it’s super important to lower your iteration count?

Animating the iterations of your algorithm will show you how “dumb” it’s being by giving you an intuition for how many iterations are wasted exploring paths that don’t matter. This is particularly helpful when adjusting the greedy multiplier (discussed in 12)

This video is an animation of a simple trace failing to solve, but instead of failing outright attempting to solve endlessly outward. Without the animation, it would have been hard to tell what was going on!

11. Intersection math is fast, do you really need a grid?

Consider two ways to determine if a trace A overlaps another trace B:

1. Consider each segment of A and B, and check for intersections1

2. Create a binary grid that marks each square where trace B is present, then check all the squares where trace A is present to see if B is there

Believe it or not, most people would choose to use Option 2 with a binary grid check, even though this can easily be 1000x slower. People do this because math is hard 🤦

Luckily LLMs make this kind of intersection math trivial. Use fast vector math!! Checking a SINGLE grid square (memory access!) can literally be slower than doing a dot product to determine if two segments intersect!

12. Measure spatial probability of failure at each stage, prioritize solvability

When doing spatial partitioning of the problem, you can measure the probability of solve failure of each stage with some leading indicators. For example, in the Unravel Autorouter we track the probability of failure for each “Capacity Node” at each major pipeline stage. Each stage focuses on reconfiguring adjacent nodes or rerouting to reduce the probability of failure.

The great thing about probability of failure as a metric is you can literally measure it and improve your prediction as your algorithm changes. Each stage can then do it’s best to minimize the chance of future stages failing.

I think generally prioritizing solvability is better than trying to incorporate too many constraints. Once a board is solved, it’s often easier to “work with that solution” than to generate optimal solution from scratch.

13. The “Greedy Multiplier”, the secret hack to 100x A* performance at the cost of optimality

Ok it’s not exactly a secret, maybe a “well-known secret”, but if you don’t know about it, you’re not using A* properly.

By default, A* is guaranteed to give you the optimal solution, but what if you care more about speed than about optimality? Make one tiny change to your f(n)and you have Weighted A*, a variant of A* that solves more greedily, and generally much, much faster!

You can read more about weighted A* and other A* variants here.

Game developers have a lot of the same problems as autorouting developers, so it’s not a bad idea to look for game development papers if you’re searching for related work!

We’re making an autorouter.

If this was interesting to you, I’d love to show you our autorouter as it gets closer to release. I believe that solving autorouting will be a massive unlock for physical-world innovation and is a key piece to enable the “vibe-building” of electronics. All of our work is MIT-licensed open-source. You can also follow me on twitter.

There are a lot of benefits to using intersection calculations vs grids for fast autorouters, Grids take up a lot of memory and cause the algorithm to go slower as it routes across more real distance (I discuss this a bit in the intersection-jumping algorithm article). This means that grid-based autorouting algorithms are not scale-invarant, a problem over 100mm will take 10x more compute than a problem over 10mm.

I was trying to think of ways to create an autorouting input/output data format that would be optimal for training machine learning algorithms when I realized that patterns are an incredibly useful way to represent scale-invariant autorouting results. What I mean is that if you could build a classifier that outputs a set of probabilities for a set of predefined routes. This is much easier to “learn” than outputting images or coordinate paths.

There are a lot of benefits to having a constrained output space. The less options to choose from, the less ways to be wrong! I also realized I could now create a very simple algorithm that recursively attempts patterns for any region with a collision.

To do this, we just write an algorithm that says “whenever there is an intersection with an obstacle, take the segment that ran into the obstacle and try to replace it with any of the predefined patterns”

Check it out in the short video below!

Can you see what patterns were recursively applied above? There are only 4!

This algorithm scales nearly perfectly with the complexity of the autorouting problem (the gray obstacles) so it’s a great choice for sparse problems! I also like how the depth of the recursion is a nice natural measurement for complexity.

It’s also kind of crazy to me that these patterns can actually allow the pathfinder to go backwards

You can play with the algorithm and customize the patterns online in this sandbox

The State of Autorouting in 2024

In 2024 here’s where we’re at:

• There are very few people working in the public on autorouting algorithms, a notable exception being a single maintainer at freerouting

• There is virtually no published work on building autorouters using modern AI techniques

• There are very few, if any, large datasets of circuit boards with a corresponding fully-routed solution that can be used for training or tuning a modern algorithm

Why aren’t people working on autorouting?

• Hardware expertise and machine-learning/AI expertise is uncommon

• It currently takes hardware expertise just to understand the formats (such as Specctra DSN)

• It is difficult to find a large repository of routed circuit boards for training

How we’re doing it

We want to seed the ecosystem with large datasets that can be used to solve autorouting, as well as utilities to make it easy to parse and work with autorouting data, so that machine learning experts can jump in without needing to have hardware expertise.

More specifically:

• Develop datasets that can be used for evaluation and training of autorouters

• Develops standards for benchmarking autorouters for comparison

• Fund the development of open-source autorouting solutions

• Showcase both closed and open-source autorouters

• Develop open-source tooling and formats to make it easier to work with autorouters

Get Involved

Please reach out to autorouting@tscircuit.com or join our discord if you’re interested in working with us. We need help building datasets, utilities and autorouters themselves!

If you are someone who would be interested in purchasing an autorouting API, please reach out so we can connect you to great companies working on deploying autorouting solutions!

If you are an autorouting developer, we would love to benchmark or list your autorouter on autorouting.com, please reach out!

These are the first critical steps for getting started. In a future tutorial we’ll show how to do this in other languages like Python.

Get started with this repo: https://github.com/tscircuit/autorouting

Why I was mad at grid-based autorouters

In Part 1 we built a grid-based autorouter and used the popular pathfinding.js library, but the simple-grid was extremely slow for the “distant-single-trace” dataset, which is basically just where there’s a ton of empty space. The reason it’s so slow is it’s doing a bazillion checks in wide-open space.

The benchmark showed that the simple-grid was extremely slow on "the “distant-single-trace” dataset, taking on average 70ms. Even the single-trace performance is a bit scary, taking 1ms for a single trace when circuit boards have thousands of traces completely dashes my dreams of having realtime-routed circuit boards.

Generating Navmeshes

Game engines will often throw out grid-based routing altogether and construct “navigation meshes” that contain all the points of interest for an autorouting problem.

I have a lot to say on navmeshes, there are so many techniques and interesting decisions, but I’m going to table that for now because there is one big problem with navmeshes- especially how they’re done in game development: they’re pre-computed. In a game, it’s totally okay to spend some time pre-computing meshes, even “baking them overnight”, but for circuit boards that are being edited in realtime AND have dynamic adjustments due to other traces being routed or adjusted, that precomputation step is just too expensive. I have a lot more to say on this, but I’ll save it for a future article!

Let’s talk about “infinite grid” autorouters

With the grid-based approach we worked on in Part 1, we iterated over each of our obstacles to compute a binary grid we would store in memory. Then you would know if there was an obstacle at a point by checking grid[x][y], but as I mentioned above, I don’t like pre-computation, so what if we defined a method isObstacleAt(x,y) that iterated over our obstacles and checked in realtime? Now we don’t have to precompute, and as a bonus we don’t need to pick a size of the grid!

Allow me to introduce the Infinite Grid Autorouter. To reduce the possibility of mistakes in the algorithm, I’m moved all the A* logic into it’s own class. To define our autorouter, we just have to tell it out to get it’s neighbors!

This algorithm has 3 basic steps:

1. Define the four directions we want to go in, left, up, right, and down. Each of these directions is represented with a vector (-1, 0), (0, 1), (1, 0) and (0, -1)

2. Filter any neighbors that are inside an obstacle

3. Compute the neighbors position by adding the direction vector to the current node

Concerned about iterating over every obstacle inside of isObstacleAt? We’ll get to how we can do this efficiently using Quadtrees in a future article. It turns out this is a lot less important than the stuff I’m talking about today!

The critical insight: Optimal Neighbors = Massive Speedup

The neighbors above are computed just by moving one GRID_STEP in all four possible directions. For a 0.1mm step, this means it would take a hundred steps to traverse a distance of 10mm. With A* exploring out in multiple directions, this can multiply and waste thousands of iterations. There’s got to be a better way!

I don’t think I’ve completely cracked the egg on optimal neighbor selection, but I did find three heuristics that generate nearly optimal points for most cases. Follow the direction for a travelDistance until one of the following happens:

1. You hit a wall

2. You cross an axis that your goal is on

3. You overcome the obstacle that the parent node ran into

Heuristic 1: Hitting a wall

This is really simple, you just project the direction outward and compute when it intersects an obstacle.

Computing where two lines intersect is really fast, and rectangle obstacles are basically just 4 lines, so this is really easy!

Heuristic 2: Crossing the Goal Axis

Often times, there is no wall! We could travel on in a distance towards Infinity! To stop this, we add a heuristic where we stop along the “goal axis”, this means we’ll never pass by the goal without adding a new neighbor

Heuristic 3: Overcoming an Obstacle

This was definitely the most difficult heuristic to figure out, but it’s absolutely essential. With the Intersection Jump Autorouter we’re constantly running into walls, we want to place a neighbor whenever we hit a wall, change direction and overcome the wall. This allows us to “follow corners”

Let’s look at an example

The autorouting-dataset repo has a lot of tools for iterating over your autorouter to help you debug. Let’s walk step by step through an autorouting problem and look at the neighbors to understand how the IJump Autorouter works.

To get debug information/graphs, we just run export DEBUG=autorouting-dataset* prior to running bun start to start the development server.

Let’s take a look at this problem, we want to connect the two squares connected by a white line.

Iteration 1: Hitting Walls on All Sides

In iteration 1, we hit walls on every side. Each neighbor is numbered by it’s position in the A* open set. 0 means your next up! Let’s see what happens.

Iteration 2: Passing the Goal Line

In this iteration, we explore to the right and left, because we’re blocked on an obstacle in the forward direction and we’re not allowed to backstep. The left neighbor goes until it overcomes the obstacle, the right neighbor goes until it crosses the goal axis.

Iteration 3: Going for Gold

The last iteration we go up until we pass the goal axis, which this time happens at the goal! We did it! Only 3 iterations!

That’s it?

Yes that’s it! Implementing this gives us a 100x+ speedup over our original grid-based autorouter, and no penalty for distant traces!

Comparing this to the simple grid-base autorouter benchmark, we have a clear winner!

Why is it so fast?

Where the simple-grid autorouter can take thousands of iterations, the ijump autorouter can take just 3-4. The main reason it’s better is it heuristics can be computed very quickly, and if the intersection is greater than 1 grid cell distance away, we’ve saved an iteration. In practice, this amounts to hundreds or thousands of iterations saved, making the cost of the intersection computation worth it.

It’s particularly good when the obstacles are sparse (like in the distant-trace dataset) but even with reasonably dense obstacles it tends to have many less iterations. The comparably low number of neighbors makes it easier for A* to select meaningfully different paths.

Where it fails

This autorouter is brand new, and I can’t find any literature on this technique (be sure to comment or message me on twitter if you find something), so there are a couple places where it doesn’t do so well.

Want to build an autorouter?

The autorouting-dataset (github) is a massive synthetic dataset of autorouting problems and a development environment for developing and benchmarking autorouters. I’d love to discuss and build autorouters together! There’s also a channel on our discord where I’d love to help :) I’d also love to sponsor contributors to work on autorouting algorithms!

All the code for the IJump Autorouter is available on Github here, you can view it against datasets online too!

We’re just getting started in our adventures building autorouters, subscribe if you’re interested, we’ve got multi-layer autorouters, navmeshes, and new datasets coming soon!

Before you even THINK about nerd-sniping me with “actually, autorouting is a solved problem” - I know if you set up your constraints you can get decent results. The problem is even those results aren’t fast and people still can’t agree on what foundational algorithms are ideal. Once there’s an open-source solution with wide adoption and real usage we can call it a solved problem.

In this post, I’m going to show you how I quickly built the easiest of autorouters, a grid-based single layer autorouter. I’m also going to evaluate the autorouter on a new dataset of thousands of autorouting problems that you can play with or view online here.

This is Part 1 of the Building Autorouters Series where we’ll build different types of autorouters, Part 2 is about a gridless autorouting technique that uses line collisions, subscribe to stay tuned!

A quick note on terminology

For basic autorouting, you really only need to know a couple concepts

• Chips are glued (soldered) to a circuit board by placing them on “Copper Pads”

• To connect two chips together, we draw traces between their Pads

• When drawing a trace, other Pads become Obstacles

That’s basically it! We’re just drawing lines.

Grid-Based Autorouting

Before we dive into the code (don't worry, it's coming), let's talk about why I chose a grid-based approach.

Pros of Grid-based Autorouting

1. It's Stupid Simple. Pathfinding on a 2d grid is incredibly common in game design, there’s almost certainly a library in your language that does it

2. Fast for dense “maze-like” designs without a lot of area

3. Consistent Clearance: Guaranteed clearance between traces. No awkward touching

4. Layer Friendly: Multi-layer routing? Just add more grids.

Cons of Grid-Based Autorouting

1. Limited Angles/Curves: Generally limits traces at 45 or 90 degrees (many EEs prefer this anyway)

2. Resolution: Sometimes, you need more cells than the grid allows, and increasing the number of cells increasing computation time.

3. Limited for Odd Pads: Funky pad shapes (and to a lesser extent circles) have trouble fitting onto a grid perfectly.

4. Performance limited by size of grid - your memory usage is going to scale with the area of your circuit board, this can be pretty intense since you’ll typically want to have each cell less than 0.1mm x 0.1mm

Let's Get This Party Started: Implementing Our Grid-Based Autorouter

Here's how we're going to structure this beast:

1. Grid Creation: We'll create our grid(s) based on the PCB dimensions.

2. Mark Cells with Obstacles Unwalkable: We'll mark all the components as no-go zones on our grid

3. Pathfinding and Routing: We'll set up our A* pathfinder and use it to route all our connections, avoiding any traces that have already been laid

All of the code we write today takes in “Simple Route JSON” and spits out JSON “pcb_trace” objects. In PCB land these simplified JSON formats are uncommon, most formats are in the form of s-expressions, deprecated XML files and hundred-page-spec binary formats.

Want to skip ahead? Here’s the source

Making the Grid

Let's construct a 2d binary grid with 0.1mm x 0.1mm cells.

Now we’ll set the inside of each obstacle as “unwalkable” by iterating over each obstacle, then each cell inside each obstacle’s bounds.

Pathfinding and Routing: Where the Magic Happens

Alright, this is where things get spicy. We're going to set up a A* pathfinder using the pathfinding module and use it to route all our connections.

1. For each connection, look at each pair of points (A & B) that make up the connection

2. Try to create a path from A to B using A*

3. If we find a path, add it to our array of pcbTraces

And there you have it! It's finding paths, laying down traces, and respecting the personal space of components.

This is basically the hello world of autorouters. For simple connections, it gets the job done, but as designs get more complex, you’ll want to implement algorithms on top of this like “rip and replace”, which is where you remove traces that are too often “in the way”. You’ll also notice that this autorouter is very order-dependent, the first trace is much more likely to get the shortest route.

The kryptonite of grid-based autorouters

The performance of this grid solver falls apart as soon as you have traces separated by any distance. Creating a huge grid and checking for collisions all over it isn’t cheap! If you run this solver against the the distant-single-trace dataset, it suddenly becomes 94x slower, even though the complexity of the dataset in terms of pads and traces is identical to the single-trace dataset.

Running a benchmark using the npx autorouting-dataset benchmark confirms the slowness.

Conclusion- What’s Next

Grid-based autorouters definitely play their part, I think if you’re in a dense routing situation it can makes sense to whip out the grid, but we’re going to take a break from Grids in Part 2 and work on a totally different type of autorouter, one that uses line collisions and a BFS algorithm to quickly solve for autorouting paths regardless of the distance.

Can you think of what kinds of datasets stump a gridless autorouter? Want to make your own autorouter? Join the tscircuit discord, check out the Github, or subscribe to follow along!

Subscribe now