tscircuit! An open source framework for building circuits, we have a lightening fast autorouter so i spend lots of time debugging complex PCB routing problems
We work on this a lot at tscircuit, and we've used cassowary (i.e. flexbox-style) constraint solvers. The issue with cassowary/flexbox is PCBs are not as uniform as webpages w.r.t. alignment, and often have a much less nested structure (3 layers) vs web pages which have many many nested layers.
CSS grid-style constraints are a much better fit IMO, but we eventually settled on sequential optimal packing[1] for "seeding" a placement so that AI can get initial positions before working in a feedback loop. I like sequential optimal packing because it's very very deterministic and the constraints are specified pretty close to how a human would specify them
> 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.
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)
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.
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
The problem with most CAD tools is they don't represent "design intent" or high-level components well, and I believe this is mostly due to the language's not being sophisticated enough
e.g. a human says "these holes need to be separated by 2mm", but when we program in OpenSCAD and other CAD languages we usually specify x={-1} for one component and x={1} for the other (just an example of how design intent is being lost)
When we can represent design intent well, we'll have something that LLMs can really grab hold of and build higher level components
You might like the PCB constraint system we're building at tscircuit for laying out boards, the biggest issue with most systems imo is that you can't cleanly specify constraints. In tscircuit you can just use a <constraint /> component to lay out PCB elements
For people interested in coding CAD in React, my team built a react fiber layer over jscad and are investing heavily into building an MIT-licensed 3d electronics library: https://github.com/tscircuit/jscad-fiber
I don't think you need a custom language to declare CAD, typescript/python have heavily invested in type systems so I hope the world moves more toward using existing languages.
The biggest limitation with code-CAD today is the lack of a constraint system (e.g. a clean way to say "these edges are 3mm apart") without X/Y coordinates everywhere. We're slowly building higher-level components that allow you to specify constraints so that you can write CAD in a way that more closely mimics the design intent, rather than a bunch of calculations.
OpenSCAD started it all so we're very grateful, but it's also time for some innovation to bring the language closer to design intent
podcast host electronics.dev
Check out my twitter https://twitter.com/seveibar
Also my open source: https://github.com/seveibar https://github.com/tscircuit/tscircuit
hnchat:WFbIqC1Jd2E3LAqCJXYQ
8382136636fb57290a97340bddea5c27fd07faa946845df70bdb1e2f1b145a5f