> To me innovation in autorouting means being able to 'have a conversation' with it: being able to easily adjust things and see the results and map out the tradeoffs would be very useful

author here: This is basically our philosophy. LLMs can churn out constraints/code very quickly to pull out the specific requirements for a design or the chips you're using. When people use tscircuit (or any electronics-as-code framework) they can talk to an LLM and just keep yelling at it in the same way you yell at an LLM to fix a web page. The success of web pages and LLMs is built from small constraint algorithms like flexbox and CSS grid, this article is just one constraint algorithm that can help LLMs approximate a solution without specifying a bunch of XY coordinates that would challenge its spatial understanding

author here: I think synthetic data, generated by ~brute force iteration with LLMs, with every DRC analysis imaginable and more, will yield a more consistent/usable/larger dataset than any existing dataset. It's a mistake to put too much weight in anyone's existing data. This is why we work hard to make algorithms that LLMs can use, because they have emerging spatial capabilities that excel when coupled with detailed analysis.

Author here. Happy to hear thoughts on this article! Our goal is to make a "realtime PCB autorouter", which means every millisecond matters!

Hello everyone, just wrote this article to hopefully save someone a year of time while building an PCB autorouter. Enjoy! Here for questions.

Despite what electrical engineers would claim, I think it's very under-studied under a modern lens. When people ask for good places to get started I usually tell them to just look at what game developers are doing for pathfinding. Autorouting sort of a form of multi-agent pathfinding, so there are a lot of relevant concepts from that area.

The tension in autorouting IMO is people generally want something ideal that passes all design rule checks. My thinking (and IMO the more modern way of thinking) is that fast algorithms, fast feedback loops and AI participation are more important.

There are also a lot of relevant algorithms in VLSI/chip design, the folks at OpenROAD seem to have good stuff although I'm not intimately familiar.

> I usually tell them to just look at what game developers are doing for pathfinding.

The example in the article doesn't quite apply, as baking pathfinding given a mesh (like baking lighting) isn't really the same thing as what A* pathfinding is (just how it's not the same thing as, e.g., raytracing). So I'm not sure if I fully agree with the logical inference there. In my defense, I know nothing about etching PCBs, so I'm likely missing something.

Game developers do bake navmeshes that's true, but it's not the only technique, for example they've also come up with Polyana or "any-angle pathfinding" https://github.com/vleue/polyanya

I also have on my desk "Algorithms for VLSI Physical Design Automation Third Edition" which I really like, but it's ~20 years old and has a lot of nomenclature that can be helpful, but I'm not a big believer in how the problems are broken down, which is IMO more oriented towards "designs with repeated patterns" rather than PCBs that don't usually repeat patterns (unless you're doing an LED matrix)

This is sort of the premise of all of us electronics-as-code startups. We think that a text-based medium for the representation of circuits is a necessity for AI to be able to create electronics. You can't skip this step and generate schematic images or something. You have to have a human-readable (which also means AI-compatible) text medium. Another confusion: KiCad files are represented in text, so shouldn't AI be able to generate them? No- AI has similar levels of spatial understanding to a human reading these text files. You can't have a ton of XY coordinates or other non-human-friendly components of the text files. Everything will be text-based and human-readable, at least at the first layer of AI-generation for serious applications

Isn’t this just Apache 2-style permissive licensing?

lol no they both read as permissive on the surface. apache 2 doesn't include a termination clause that broadly protects an entity against any litigation. this is incredibly broad and not community safe.

Strongly disagree with the article. Enums make gradual migrations impossible in both databases and API design with third party consumers. Even in the example they gave where they recommended a user “role” instead of an is_admin boolean they are creating huge problems. Am I supposed to tell all my downstream API consumers that they need to refactor their code because we’re introducing a new value to “role” that covers “billing_manager”? There are literally zero downstream issues with adding is_billing_manager, and you get the additional representation benefit that the booleans can _both be true_, so I am not trapped into an exclusive role paradigm.

> tell all my downstream API consumers that they need to refactor their code because we’re introducing a new value to “role” that covers “billing_manager”?

With non-exhaustive enums you don't need to do that? But also, you can match on a single variant ignoring others for the admin role check?

There's a lot of potential for desktop rapid-prototyping with electronics. I think one of the things that is killing us is the tooling. One of the reasons I started building an autorouter was because I wanted to be able to have different "build targets"- e.g. a build target that is a PCB with no vias and only 0 ohm resistors (jumpers). If our EDA tooling supported different build outputs, then we could have earlier prototypes built with less-than-ideal equipment (e.g. conductive 3D printed filament, as the article suggests)