> Yet, it's all the most likely token and my brain hurts trying to understand how that can be.
You and everyone else. That's the great mystery of transformer architectures as applied to language.
To be clear though, they're only good at schematic capture, which is very much a textual representation. Most of the data basically boils down to netlists, which are a text based format mapping connections between abstract pins that only later map to physical copper. The actual schematic portion is for human consumption and LLMs don't need to produce those to be useful.
Where LLMs completely break down is the next step, PCB routing. That's an NP-complete research problem that's been ongoing for decades without much progress. I've had some fun playing with using LLMs to better specify DRC rules in Altium so that the "classical" algorithms are more usable, but at the end of the day their geometric intuition is nonexistent.
They actually can route just fine. I used Sol to design and route mine from start to finish. Sent it to PCBWay and had a working prototype in a few weeks.
It was a pretty simple rp2040 based thing, similar to Adadfruits USB feather.I just gave it kicad and it wrote python to route it. The board was probably larger than it had to be, and two of the silkscreens were swapped, but it worked on the first go.
FWIW - Computer vision is also NP complete, but we do that all the time now.
I'd love to see that chat log, and the final board. To be fair I've only been testing on nontrivial PCBs with 6+ layers and I haven't had the luck you have.
> FWIW - Computer vision is also NP complete, but we do that all the time now.
I have no idea what you mean by this. What's your definition of NP complete?
NP-complete means that it's easy to test if we're right, but because of that complexity we can't always find a valid solution to test within a predictable period of time. Both circuit board routing and computer vision are variations on the same fundamental problems. Once we solve we, we solve the other.
However, when I was growing up most serious computer scientists believed that CV (computer vision) was a 'hard' problem that would never be 'solved'. After all, to do it right you must first at least solve subgraph isomorphism and a bunch of other things that are also NP-complete.
What they missed was that we don't actually NEED to solve it in a fixed amount of time. Even for things like driving a car the stochastic heuristic based answer is 'good enough'. e.g. - Cars driven by computers don't have to be perfect, they just have to kill other drivers less often than humans do.
We can find AN answer in polynomial time, and that's good enough. It might not be the ideal answer, but that doesn't matter in the real world.
People use NP complete as shorthand for 'impossible to do with a computer', but we now 'solve' (bypass?) NP complete problems regularly and at scale by just ignoring the fact that our answers aren't perfect.
> I'd love to see that chat log, and the final board. To be fair I've only been testing on nontrivial PCBs with 6+ layers and I haven't had the luck you have.
I wish I could share it, but it's for a commercial project that hasn't been released yet and I'm not sure if it will be open source, but a few folks have asked. I might do a blog post on it this weekend with as much detail as I can safely post.
It's only 3 layers, and less that 30 components, but the fact remains that I didn't design any of it by hand and it worked on the first go.
In your opinion, do you think ai can make eutorack modules by now? This is what I am waiting for: explain an idea to an ai, and sending the files to jlpcb to receive a complete working module (minus some THC soldering)
I'm sure that the best models can glue some basic synthesizer functions together, but I wouldn't waste a minute on anything less than Fable/Astra-class models for that kind of application, and I wouldn't expect the result to work the first time. It could get expensive.
Here's a question - are there software simulators for things like Eurorack modules? That would make the question somewhat more interesting, since you wouldn't have to build the circuit (or pay someone else to assemble it) to hear how it sounds. It strikes me that SPICE-like algorithms should be fast enough to do this kind of thing in real time now.
> at the end of the day their geometric intuition is nonexistent
This isn't true anymore.
I use LLMs for 3D CAD using OpenSCAD and they understand geometry fine. I've had more success with Sol than with Opus (Opus 5 is around 10 times slower because it does too much verification) though. I haven't tried Astra or Fable for it.
That is indeed impressive, but at least the excerpt given from the layout seems very easy to route, due to high regularity and an ample routing channel.
Even so, there remained some "dozens" of unrouted traces, which are likely to be much more difficult to route, after the easy traces have already occupied the space.
Many decades ago, I have written a PCB routing program, which would have routed the example shown at that link at least as well, while using many orders of magnitude less resources, i.e. while running on a single-core 233 MHz Pentium MMX.
Obviously that program would have had great difficulties to complete a real high-density PCB design, including many irregular parts and analog circuits with special requirements. I doubt that Fable would fare better.
You and everyone else. That's the great mystery of transformer architectures as applied to language.
To be clear though, they're only good at schematic capture, which is very much a textual representation. Most of the data basically boils down to netlists, which are a text based format mapping connections between abstract pins that only later map to physical copper. The actual schematic portion is for human consumption and LLMs don't need to produce those to be useful.
Where LLMs completely break down is the next step, PCB routing. That's an NP-complete research problem that's been ongoing for decades without much progress. I've had some fun playing with using LLMs to better specify DRC rules in Altium so that the "classical" algorithms are more usable, but at the end of the day their geometric intuition is nonexistent.