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’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.
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.
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 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.
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.
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?
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?