After the OAI demo, like many others, I tried to use KiCAD through computer-use. This doesn't produce great results.
I have found the best results through a mix of Happy[0], this repo, and computer use to fill in the blanks.
It is _really_ good at the stackup and part config, but creates some absolutely terrible routes. It will snake tiny traces through some SMD pins even though there is plenty of space available outside of the component. When it hits an obstacle, instead of creating 2 45 degree turns, it does 10~30 small ones creating some sort of weird crooked arc.
I have produced a couple of boards for testing this way and they are generally functional.
I have tried KiCadRoutingTools[1] as well which does seem to create routes that make more sense.
Anyone any better experiences with these or similar tools?
Why bother with computer use at all? Did you DRC it?
I did this months before that OpenAI demo, and produced a product that many people are using without knowing it was an AI designed PCB.
It ran using kicad completely headlessly from a terminal with a bit of python and DRC'd it in a loop until it passed. I sent it to PCBWay and it worked the first go. It did take a bit, but if you just set a goal and let 'er rip the LLM gets there in the end.
Would a real EE vomit if they looked at it? Maybe. Does it work? Absolutely.
I think “it works” is a very low standard for any creative work you set out to do, professionally or as a hobby. Possibly the lowest standard. We should aim higher in all things.
We have developed something similar inhouse (a CLI tool for agents that has a few dozen utilities for manipulating KiCad files) and the results are pretty good. In terms of complexity, I would say that tasks like "replicate the layout from the datasheet of this amplifier and make me a testboard" or "look, we need an adapter that goes from <this devkit (insert PDF schematic)> to <these boards (insert KiCad file)>" are basically solved. More dense layouts are a stretch at the moment. (speaking about Opus 5.5 specifically here, other models are likely worse at these visual-coding tasks anyway)
In terms of result quality, I would say that the results are distinctly "2024/2025 LLM programming quality". The models lack a certain... taste? Good and careful prompting can help, but for example "use hierarchical sheets" can yield a single hierarchical sheet containing 3 copies of the same thing instead of three instances of a hierarchical sheet containing the same thing once. When pointed out, the model can of course do it no problem the way you want.
It's probably a case of you can't write down infinity. There is probably no general prompt that works. Even many humans can't be given a general conceptual instructions.
I’ve had really good results recently with Fable 5.1. The typical process that it uses for routing is to pin a few key traces (using the kicad python api) and then use freerouting for the others. I’ve also noticed that if I push hard for “carefully designed” routes, eg for a 38 pin connector, it will write code and make much better looking results.
I’d say that at the moment it still requires you to look at its results and point out their weaknesses and/or route a couple of traces yourself and then hand it back.
This project from a couple of weeks ago is a great example. I’m new to ST MCUs: in addition to the PCB, Claude brought up the firmware and driver. https://github.com/ckemere/hub-imu
I will give this a try! I feel like AI should be able to automate this process (Schematic and/or PCB). I made a new design 2 months ago; tried to get Claude and COdex to do the schematic in KiCad, and they were not effective. Made a mess of it for an initial build, and edits later. I didn't bother with the component placement and routing.
I did find LLMs to be very effective on answering questions about routing, part selection, and identifying problems; was using a new MCU (Atmosic) with some unusual power circuitry, and got a working board first go. LLMs also crushed getting it working with rust (Very likely I am the first person to program an Atmosic MCU in rust); found a debugger that would work (NXP MCU-Link; the St-Linkv3s I normally use won't work for this, and the official recommended part is very expensive). The LLMs wrote a probe-RS configuration for it, linking scripts etc.
The LLMs also, under close direction, wrote a minimal HAL subset for I2C, SPI, power management, clocks, and BLE. I pointed it to my STM32 HAL as an API guide, set up the basic data structures, and pointed it to the Atmosic SDK (In C). It connected the dots, and produced a working HAL with a familiar API.
Tried this for a GaN BLDC ESC using EPC GaN FETs. Didn't go well. It still made significant mistakes about the ppart. I guess if you have a common part this may work well as there's probably good examples in the training data sets. But when you get in to more unusual parts it makes mistakes with packaging selection and foot prints.
I've had good luck doing this recently with my own set of similar tools for a high altitude balloon tracker. The PCB has a transmitter module, pico, gps, barometer, accelerometer, magnetometer and extra flash plus all the power and rf filtering needs. It also needs to withstand ~ -40C temps. I also had size constraints. It did a good job of making compromises while designing a 4 layer board for prototyping.
I had Fable work on it, and it made a good board, after some trial and error. I used mixtelas previous MCP tool, and even had it do ngspice runs on the filters. One of the tricks was to run a "tournament" style system for routing and lock in good routes. It also seemed to have and idea of what a "good" board should be.
And it found all the components on jlcpcb, made sure they met specs, gave me options, etc. and it outputs everything I need to upload the boards and get them produced.
Its not exactly a complex rf monster like some 5G board, but it's not just a simple board full of connectors for other dev boards either. I have to say I was quite impressed, for a first board. And it's been easy to iterate as well.
I've tried with Opus, and Opus doesn't quite get to what I would consider a "good" board, but it will get you close.
I haven't ordered the board yet (cost plus being cautious) but looking over it, I've yet to find any issues on it. I just ordered a simple connector board all done by AI last night with a few resistors and caps on it, all to be assembled by jlcpcb. Obviously, looking over it, I thought it was good enough to spend $60 on. We shall see.
But like so much in AI, it helps if you have some domain knowledge. I'm not sure how it'd go if I just had a newbie vibe code a board. I help with FabAcademy, and I fully expect to see this done many times there, over the next year.
I don't think they have any access or scraped data. The plugin let's me configure a JLCPCB DB path and it seems like it doesn't ship with one. I have no clue how to obtain that db.
I have found the best results through a mix of Happy[0], this repo, and computer use to fill in the blanks.
It is _really_ good at the stackup and part config, but creates some absolutely terrible routes. It will snake tiny traces through some SMD pins even though there is plenty of space available outside of the component. When it hits an obstacle, instead of creating 2 45 degree turns, it does 10~30 small ones creating some sort of weird crooked arc.
I have produced a couple of boards for testing this way and they are generally functional.
I have tried KiCadRoutingTools[1] as well which does seem to create routes that make more sense.
Anyone any better experiences with these or similar tools?
[0] https://github.com/aklofas/kicad-happy [1] https://github.com/drandyhaas/KiCadRoutingTools
I did this months before that OpenAI demo, and produced a product that many people are using without knowing it was an AI designed PCB.
It ran using kicad completely headlessly from a terminal with a bit of python and DRC'd it in a loop until it passed. I sent it to PCBWay and it worked the first go. It did take a bit, but if you just set a goal and let 'er rip the LLM gets there in the end.
Would a real EE vomit if they looked at it? Maybe. Does it work? Absolutely.
In terms of result quality, I would say that the results are distinctly "2024/2025 LLM programming quality". The models lack a certain... taste? Good and careful prompting can help, but for example "use hierarchical sheets" can yield a single hierarchical sheet containing 3 copies of the same thing instead of three instances of a hierarchical sheet containing the same thing once. When pointed out, the model can of course do it no problem the way you want.
Why don't you make it a part of the system prompt then?
I’d say that at the moment it still requires you to look at its results and point out their weaknesses and/or route a couple of traces yourself and then hand it back.
This project from a couple of weeks ago is a great example. I’m new to ST MCUs: in addition to the PCB, Claude brought up the firmware and driver. https://github.com/ckemere/hub-imu
I did find LLMs to be very effective on answering questions about routing, part selection, and identifying problems; was using a new MCU (Atmosic) with some unusual power circuitry, and got a working board first go. LLMs also crushed getting it working with rust (Very likely I am the first person to program an Atmosic MCU in rust); found a debugger that would work (NXP MCU-Link; the St-Linkv3s I normally use won't work for this, and the official recommended part is very expensive). The LLMs wrote a probe-RS configuration for it, linking scripts etc.
The LLMs also, under close direction, wrote a minimal HAL subset for I2C, SPI, power management, clocks, and BLE. I pointed it to my STM32 HAL as an API guide, set up the basic data structures, and pointed it to the Atmosic SDK (In C). It connected the dots, and produced a working HAL with a familiar API.
I had Fable work on it, and it made a good board, after some trial and error. I used mixtelas previous MCP tool, and even had it do ngspice runs on the filters. One of the tricks was to run a "tournament" style system for routing and lock in good routes. It also seemed to have and idea of what a "good" board should be.
Its not exactly a complex rf monster like some 5G board, but it's not just a simple board full of connectors for other dev boards either. I have to say I was quite impressed, for a first board. And it's been easy to iterate as well.I've tried with Opus, and Opus doesn't quite get to what I would consider a "good" board, but it will get you close.
I haven't ordered the board yet (cost plus being cautious) but looking over it, I've yet to find any issues on it. I just ordered a simple connector board all done by AI last night with a few resistors and caps on it, all to be assembled by jlcpcb. Obviously, looking over it, I thought it was good enough to spend $60 on. We shall see.
But like so much in AI, it helps if you have some domain knowledge. I'm not sure how it'd go if I just had a newbie vibe code a board. I help with FabAcademy, and I fully expect to see this done many times there, over the next year.
https://kdeconnect.kde.org/
Or do you need to get an API key first?
Seems to be scraped data? and then you review it manually like it recommends in: https://github.com/mixelpixx/Konnect/blob/9488e5f09717cb508c...
It's a pity JLCPCB always wants to nudge me towards their own EDA tools.
Perhaps someone can vibe-code an LCSC interface that uses a headless browser?