Claude Code for pcb design?

[nctnico]

Hmm, you seem to have much, much better luck with getting routing done than me    . Did Fable create a tool to do the routing or did it the routing by itself? I'm using Opus 5 BTW. IIRC you are using Eagle for PCB design which allows for an XML driven workflow???

I second your experience with Claude doing schematic reviews. I'll let it do a PCB review soon.

[KE5FX]

Hmm, you seem to have much, much better luck with getting routing done than me    . Did Fable create a tool to do the routing or did it the routing by itself? I'm using Opus 5 BTW. IIRC you are using Eagle???

EAGLE's use of documented XML files for the board and schematic has suddenly become a Very Big Deal.   

It created a Python program to do the routing by manipulating the EAGLE .brd file, but it was very slow and error-prone.  I suggested that it give up on Python and switch to C++, and that made the process go much faster.

I haven't looked at either program so I don't know how strongly it is hardwired to this particular design, though.  I didn't ask it to route the whole board, just the crossbar area.

Not sure what to expect in terms of performance with Fable vs Opus 5, but Fable really makes those XML files walk and talk.  Right now the $200/mo subscription gives me access to Fable, so I always use it by default.  I haven't been doing a lot of vibe-coding or heavy agentic work, so I haven't run into the subscription's limits so far.

[nctnico]

OK, maybe I should retry using Fable. I tried to let Claude route a particular area of a board. Far less complex than your crossbar switch. Maybe I should let Claude write it's own autorouter instead of driving the one that comes with Allegro. Part of the problems I have seem to have come from Claude not knowing how to drive the autorouter. I think component placement might be a step to far but routing should be doable. IMO placement is one of the hard parts of board design. Routing traces is just work.

[KE5FX]

Agreed, initial component placement -- and selecting the right components in the first place -- is the key to the whole process.  But there is so much grunt work as well, including not just routing but (in this case) duplicating and placing 32 subcircuit copies, which is something EAGLE has never been any good at.  A lot of things that required custom scripts in the past are now just a matter of asking: 

I've now added two more layers, for a total of 8.  For all traces currently on layer 2, please change those traces to layer 4 (currently a solid copper plane except for via holes).  The idea is to make layer 2 the solid ground plane for the top layer.  Likewise, every trace currently on layer 15 should be changed to layer 13, allowing layer 15 to act as the bottom ground plane.

It was able to swap the traces around in-context without writing a separate program.  After some further routing prompts, it did make a couple of small mistakes:

Looks good.  There are quite a few traces, however, where vias were left in place at points where no other traces connect.  Examples are the vias at 172.974,244.094 mm and 174.244,243.586 mm.  Please go through the .brd file (which has been updated, so please reload it) and remove all of these unneeded vias.

It fixed the cable vias.

Verify that the MPU pins on U18 that are connected to signals whose names begin with DUT are all GPIO-compatible

In this case, it flagged my usage of a couple of open-drain pins where CMOS outputs were required, saving some rework.

Good catch on the open-drain pins.  Do you see any other available GPIO-capable balls within convenient reach?

It correctly identified some alternatives and offered to change the routing.

Please compute the peak-to-peak differential voltage at pins 21-22 of the quadrature downconverter IC (U17), assuming the source internal to the DUT is a 3.3V CMOS gate followed by a 200-ohm series termination resistor.

This was impressive.  It referenced multiple schematic pages on its own, correctly taking the source Z and crossbar switch capacitance into account, along with impedance transformation by the LPF that followed it.  It then commented that the signal level was too low to provide much resolution at the CPU's ADC inputs, correctly guessed what I was going to do with the readings, and suggested a pair of AD8237 diffamps rather than driving the CPU ADC pins directly from the I/Q demod.

Basically it acted like an agent that had been trained not (just) by shoving every schematic and board layout they could find at it, as many people in the thread assume, but by making it read and comprehend EE textbooks.

[nctnico]

Thanks for the added info. I think Claude should be able to do the same in Allegro although it has to do through scripts. There is no direct access to make changes to the file.

Basically it acted like an agent that had been trained not (just) by shoving every schematic and board layout they could find at it, as many people in the thread assume, but by making it read and comprehend EE textbooks.

The latter is also my experience. I'm trying to get Claude to create and simulate an AC model of a populated board for power supply analysis. It starts to look promising 

[mawyatt]

This is getting impressive with Claude!!

Not too long ago, a forum member built one of our "controversial" Square Wave AC References with a updated PCB where we had posted the gerber file. This updated PCB hadn't been built by us, but should work. Murphy stepped in and the member reported the circuit wasn't working as expected.

The member used Claude and it found the error (IC pins swapped), while we also found such (transposed the pins on the updated schematic). Quite embarrassing to be outdone by AI

Anyway, the solution was simple just swap a lead on the IC (SMD with leads) and it working as expected. The member had a new DMM7510 and it reported the results to ppm levels for the AC squarewave as expected

Best   

[paulca]

Last night I had a "VDDA and VDDB" are the same net, using VDDA.... error.

After about 10 minutes I was none the wiser, so I asked claude, which immediately went with "You copy pasta'd VDDA and rename it VDDB I think this is your problem."

The it went back to thinking for 5 minutes.  I got a cup of tea.

Came back to ... "Found it! There are TWO symbols on the power pin for IC5, looks like a copy pasta mistake.  Both VDDA and VDDB symbols are present on that Vcc pin ,but only one of them has it's value label shown"

Now...I would have found that.  But my approach was to remove ALL VDDA and VDDB pins and re add them.  It saved me that!  Good find.

[free_electron]

Last night I had a "VDDA and VDDB" are the same net, using VDDA.... error.

After about 10 minutes I was none the wiser, so I asked claude, which immediately went with "You copy pasta'd VDDA and rename it VDDB I think this is your problem."

Any good schematic tool would have flagged that. you don't need an AI for that. Shorted net rule.

[paulca]

Last night I had a "VDDA and VDDB" are the same net, using VDDA.... error.

After about 10 minutes I was none the wiser, so I asked claude, which immediately went with "You copy pasta'd VDDA and rename it VDDB I think this is your problem."

Any good schematic tool would have flagged that. you don't need an AI for that. Shorted net rule.

It did flag it.  ERC flagged it.  Even pointed me to the two closest individual nets and where they conflicted.

I could not "see" it.  Because a power pin "Up arrow" was sitting on top of another "Up arrow" and only one of them had a label which said VDDA.  The unlabled one was VDDB.  A KiCAD "selection bias" if you don't set your select mask you can select symbols and symbol references independantly leading, apparently, to nasty to find bugs.

Interestingly though.  My plan was to delete VDDA and VDDB references until I broke it in a different way.  Which give the two flags from ERC would have started with those two instances.  The moment I hit delete on the overlapped pin and it appear not to go away I would have twigged "Two co-located symbols"

and honestly... that should be an ERC item.  Two symbols sitting ontop of each other

[nctnico]

Placing and routing wasn't very succesful but with my next experiments Claude kept hitting the balls out of the park straight into space!

DC resistance analysis
Since Claude is able to extrac the layout from Allegro quite easely I thought it would be nice if Claude can do more analysis. I have been working on a rather complex design the past couple of weeks. Several BGAs, high speed interfaces etc. To give an idea: this design has over 40 power nets and over 100 differential pairs. One of the 'problems' which such designs is that several of the chips use lots of amps at low voltages so power distribution analysis becomes important. So I asked Claude if it could analyse the resistance between a source (regulator) and the balls / pins of a chip. After some back & forth in plan mode, Claude cobbled together a couple of Python scripts to do meshing and finite element analysis.

I tried this with the design for an FPGA evaluation board I made as part of the process of creating the large design. Claude quickly came up with this graph which shows the voltage drop per Ampere. Such a graph can show bottlenecks in traces / planes. Very useful. Keep in mind that the vertical scale can be exchanged with milli-Ohms directly.


Claude also produced this overview per pin. This is super useful to see if there aren't any outliers and where a high DC resistance path (which layer) may exist.


But I wanted a complete picture so I asked Claude for worst-case, average and effective. In this case effective is what is seen by the chip package with all the balls/pins in parallel.


Impressive! And it helped a lot to verify the main design.

[nctnico]

How about AC impedance analysis?
The good results for the DC analysis got me thinking if Claude would be able to implement Python scripts for AC (impedance) analysis as well? This could not be simple! The AC analysis options for CAD packages are expensive. Can Claude cobble something together within a few hours? Time to find out!

After some tinkering, honing and clauding and installing ngspice, Claude came up with a solution where it would mesh the traces and model these into a PSpice circuit. But I wanted verification as well so this required doing some measurements.

I decided to measure two points on the board. The first point is at the capacitors right next to the DC-DC converter, the second at a ball for the FPGA. I used a DIY impedance probe with a 1 Ohm reference resistor and 1 Ohm current injection resistor to do the measurements using FRA analysis on a DSO. As R&S has been so kind to let me play with an MXO3 for a while and it can do FRA up to 50MHz, I used that.

First the test setup:


I setup the MXO3 to do the FRA and pointed Claude to the IP address the MXO3 sits at and told Claude to get FRA data using SCPI over telnet + Pyvisa. That worked just fine. It is not in the MXO3's manual but you can telnet to port 5025 and type commands. No need for extra bloat.



After doing a null-measurement (probe shorted) Claude combined the data from the MXO3 and the simulation into this graph:


Nice. But I'm not convinced yet. So I wanted to measure another point. A ball on the FPGA. Fortunately the FPGA has a 1mm pitch so soldering wires to a pad is doable.


This resulted in a graph where simulation and measurement corresponded pretty well. So the simulations are trustworthy. Keep in mind that component variations can be large where it comes to capacitors. Back to the DUT: I noticed that the impedance was a bit high in certain places. What if I ask Claude to optimise? And sure enough, it went sweeping through some options and it came back suggesting to replace two 10nf 0402 capacitors with two 1uf 0402 capacitors. It resulted in this graph:


Again the measurement matched the prediction.

But ofcourse I had more questions. Like: What does each capacitor do?


This is an interesting graph to check if all capacitors do at least some work. It also shows the division of labour across the frequency band. A good question to ask Claude is whether capacitors can be left out.

Something else that interested me is what are the other effects? Because the power plane has capacitance and inductance as well. The latter is the reason why the impedance at the DC-DC converter is different compared to the impedance at the FPGA pad. So I let Claude produce this graph:


These graphs show a complete picture of what contributes to the PDN impedance across the frequency bands. It is quite informative.

Time for some real work
I can't divulge too much into details of the big design I worked on. But it was impressive to use Claude combined with the AC and DC analysis tools to pinpoint weak points in the power distribution. But this required some work on the tooling as well. The power planes are large in a 250x250mm board and the Pspice models quickly ballooned to millions of points. Because it was late I let a simulation run overnight and the next morning it wasn't done even while loading the CPU 100%. So I had Claude do some hefty optimisations on how the models where created and optimised. In the end Claude came up with two flows: a simplified model for a quick scan and a complex model for more accuracy. And there is also an option to simulate with a regulator on or off. The whole workflow is run as Python scripts. Going for C or C++ isn't worth it as the cores used by Python for the calculations are written in C/C++ anyway.

For my complex design running 40+ nets through the simplified model took about 40 minutes. Using the complex model, my PC is working for several hours. But I have to say my PC starts to become outdated where it comes to speed. Also, these simulations need memory. With 48GB and some other programs (including a VM) I could only run two simulations in parallel. With a faster PC and more memory, the simulation time can be cut drastically.

Doing the optimisations was interesting. Some fixes required pushing in extra 0402 parts under the BGAs. Other fixes required using tantalum Polymer caps with a specific ESR (especially on power nets behind a ferrite bead; the ESR dampens the resonance with the bead). Just ask Claude how to optimise and it comes back with several options / suggestions to improve. More interestingly, in many places using a 100nf, 1uf and 10uf capacitor was the optimal solution. Some regard this as cargo cult engineering but the simulations at least show there is ground not to dismiss this. And there is also a lot to be gained from choosing the PCB stackup. For one net the solution was to put the power plane on a layer with less distance to the ground plane.

All in all I'm super happy with this. Earlier I was considering upgrading / expanding Orcad with power analysis but spending a day with Claude and doing measurements gave me the tooling for a fraction of the costs and with way more flexibility. Claude just adds features on the go.

Also worth mentioning is that I also fed the BOM into Claude which lead Claude to find the exact models for the parts and extract data needed for accurate modelling. Unfortunately some of this information is not reachable for AI so I had to add that manually. For unknown MLCC caps, the model uses an approximation for the DC bias effects (reduced capacity at increasing voltage).

And there is more!
Dutch people are never satisfied and I'm no exception.  What else to do with the extracted data? Well, let Claude do an analysis of the PCB. Any lose tracks? Via placements to be optimised? Are there high speed return current vias in the right places? Remember; the design I'm working on has 100+ diff pairs so there are quite a few places where the pairs have to go to another layer which requires a return current via in place. Again, the tooling Claude made and drove worked like a charm. It came up with a list of useless vias going nowhere (as I ripped part of the design from another design, some parts became messy), overlapping vias, traces going nowhere, traces being close to diff pairs or sensitive traces, analysis of annular rings, etc. All in all very useful info which you don't get from a DRC analysis. And if there are more questions, Claude easely adds more analysis options.

Still not satisfied though.... A circuit board needs a casing. So I let Claude analyse the design to identify the connectors going to the outside world and create a technical drawing with the connector locations and mounting holes. That worked like a charm after some guidance on the layout of the drawing. But it still meant I would need to muck around with drawing a casing. So I asked to design the front and rear panels and pointed Claude to the directory with the datasheets for the connectors. For some reason Claude picked up a initial casing design I made with Protocase designer and offered to modify the design with the required opening. That process didn't go super smooth as Claude had to figure out the YAML format used by Protocase designer but after some guidance and placing some library cut-outs myself, Claude managed to get the cutouts right:

A casing designed (mostly) by AI from a PCB layout and BOM:


I specifically let Claude keep the definitions for the locations of the holes in a seperate file so what the tooling does is ingest a casing template and add the cutouts where needed.

Sharing is caring

I like to think these tools (DC, AC, PCB check, case design) can be very handy to others. So I made them available through Github (under MIT license):

https://github.com/nctnico/Claude-PDN-tools

There is a template in the project directory where the analysis results end up. The vendor directory has some models in it.

Right now the backend is for Allegro (running on Linux) but I'm sure Claude is able to find ways to extract the data needed from other PCBs package. It might even work from Gerbers and a pick & place file. I'm aware that Claude costs money. Perhaps a free AI can lead to similar results. Most of the heavy lifting where it comes to writing the analysis tools has been done already.

[mawyatt]

Those are nice informative results, Claude is indeed impressive!!

Best

[Someone]

I'm aware that Claude costs money. Perhaps a free AI can lead to similar results.

This is perhaps more interesting to the wider community. But tying all the tools together seems to be the undocumented step (here and elsewhere).

With 48GB and some other programs (including a VM) I could only run two simulations in parallel.

So the AI was in the cloud and you ran all the other tools locally?
https://github.com/nicedreamzapp/claude-code-local
Which AI model?

[nctnico]

With 48GB and some other programs (including a VM) I could only run two simulations in parallel.

So the AI was in the cloud and you ran all the other tools locally?
https://github.com/nicedreamzapp/claude-code-local
Which AI model?

I used Claude's Fable just for kicks. But Opus 5 would have done fine as well; that is what I used for board analysis and throwing the casing together. I'm using Claude's cloud service with their local application. The local application is basically the interface for the AI to do stuff on your computer. Typically the workflow is that Claude solves a problem by writing software for it if the problem isn't writing software.

[AndyC_772]

Wow.

I'm going to take a while to digest all of this. I knew my job description was going to change at some point thanks to AI.

[free_electron]

i've used Claude to make a library management tool. The library is a collection of CSV files ( so they are human readable and editable. no need for complicated database management and setup) . It sets mandatory fields and you can add custom fields. It recognizes part types and you can set formatting rules per type. For example: for any resistor, build the description field as "RESISTOR",[value],[tolerance],[power],[package],[aec-q]. it does data sanitation, keeps coherent indexing using GUIDs (and verifies they are truly unique in your dataset). has built in warehouse management (you can assign where the parts physically reside) and link symbols and footprints. it can do web lookup in all your favorite suppliers ( you add your own and give the web url for their search path ). It can also consolidate boms for a project with more than one board.
Has a fully graphical UI that displays and lets you edit data in excel-style formatting (table) . it keeps backups of the last 5 saves per file and has unroll capability. it can make zip files of your project. all settings are stored as JSON files.

I didn't write a single line of code or designed any user form. purely using prompts in claude. Some of the data sanitation and formatting tools it build are very complex. i would never have been able to build that on my own.
For shits and giggles (and because i know that language best) i asked it to code it in visual basic, build a test case, trigger compilation verify the new functionality works as intended and fix if it broke something.

My dataset is now clean

the CSV files can be shoved on github for teams . to expose this as a database i use the built-in ODBC connector  for text files. Windows has this out of the box ( no need for office) . point it to a folder with CSV files , give it a name and odbc sees a database where every CSV file is a table.
So i can connect it to altium directly as my master library.

i don't need to install any database program, i'm not locked into some binary format (ascii csv) , i don't need a server or host (github will do nicely) and worst case i can edit with notepad !

[bookaboo]

I'm having great success with claude code inside my Altium Database folder. 

Among other tasks
- Populate a DB entry for a new part, all parameters, datasheet downloaded.
- Download symbol, footprint and step to a temp folder. For now symbol and footprint editing are still fully manual.
- Check existing DB suggest any matches on symbol or footprint.
- Mod a step file in situ. Today I fixed a number of TH parts where the leads were full length on the model, now they are "pre-cut" so the PCB step is realistic. I also fixed the incorrect colours that seem to be mandatory for public libraries.
- Auto supplier look up.
- Dedupe and general DB hygiene.

That's just the DB, I've also been using  Claude as an assistant for component selection, design review. If Altium's file format wasn't so obscure it could probably do a lot more.

[mzzj]

How about AC impedance analysis?

Impressive work, both You and Claude.
my experiments with Kicad are more of a mixed bag but I really haven't put much effort on that.

It seems AI has taken quite leaps in last 6 months or so. Especially visualization & "understanding" pictures is miles ahead what it was some time ago. It is also much closer to "engineering grade thinking" instead of babbling nonsense like before.
Claude fed with stupid cartoon style drawing of solar power system correctly identified +- bolted to same busbar, fuses missing, analyzed wiring sizes and inverter/charge controller cooling requirements down to noting that selected 50mm2 cable wont fit in the inverter terminals per manufacturer specification.

For example earlier trick question of "meme capacitor" 10nf+100nf+1uf usage gets IMO perfectly fine answer nowadays:

is 10nf +100nf + 1uf good decoupling for a AC series buffer ic?

Working out decoupling guidance for fast AC-series buffers.

Yes, it works, but the 10 nF isn't buying you much. With modern MLCCs, layout and placement matter more than the mix of values.

What I'd use for a 74AC buffer (e.g. AC244/AC541):

100 nF X7R, 0402 or 0603, right at the VCC pin, with its own via straight down to a solid ground plane. Keep the loop of pin → cap → via → plane as small as possible. This cap does most of the work.
1–10 µF nearby. One can be shared between a few ICs. It refills the 100 nF.
Skip the 10 nF, or replace it with a second 100 nF. A small 0402 100 nF already works well up to a few hundred MHz. Mixing values a decade apart can create an anti-resonance peak between them, where the impedance actually gets worse. Two caps of the same value don't have that problem.

The real problem with the AC family is ground bounce, not decoupling. Its outputs switch hard (edges around 2 ns, about 24 mA drive). When all 8 outputs switch at once, the IC's ground pin bounces no matter how good your caps are. Ways to reduce it:

22–33 Ω series resistors on the outputs, especially on long traces or clock lines. This also cuts ringing and EMI.
A solid, unbroken ground plane under the IC, and avoid thin ground traces.
A slower family if you don't need AC speed: 74AHC, 74HC or 74LVC are much gentler and decouple more easily. AHC is a common drop-in replacement for AC.