AI-Native Circuit Design with SKiDL

[lachlanfysh]

How I got here

I'm a business architect by day — not a software engineer, but technical enough to be dangerous. I make things on the side (fysh.world) and have a few electronics projects going, mainly synthesizers.

Late last year I was hand-laying out PCBs, using an LLM to help with decisions but not the actual layout. This year I've had projects where honestly, if I have to do this by hand, it's never getting done.

So I asked Claude: what AI tools exist for PCB design? It surveyed the landscape — Flux.ai, Quilter, various copilots — and found them all to be sort of marketing over substance. But it also found SKiDL, sitting 4th on a list of options with a caveat along the lines of "doesn't support KiCad 9, will require significant uplift to support S-expression output."

I had a Claude Max subscription and figured — if the only gap between me and a working pipeline is a bunch of coding work, well, that's exactly what the LLM is good at.

Forked the repo. Claude wrote KiCad 9 schematic generation in a day (PRs #280–281, Feb 2026). Things escalated from there. Four months and ~200 commits later, I had a new PCB idea on the weekend and got to a probably 80% complete board straight from the LLM — schematic, validation, initial placement. Pretty wild honestly.

This post is about what I've built on top of SKiDL and where it's going.

---

Everything below is prototype work built on top of SKiDL. Some of it currently lives in my fork as additive packages; I'm still deciding what belongs upstream versus what should remain external.

The pipeline

SKiDL handles circuit definition (Python → netlist) and now schematic generation (the KiCad 9 work I've been contributing since February). The gap is what comes after the schematic — validation and physical layout. That's what these two packages add:

Python circuit (SKiDL)
    → schematic generation (already in SKiDL)
    → simulation ERC (new: src/skidl/sim/)
    → PCB layout (new: src/skidl/layout/)
    → .kicad_pcb ready for DRC / human review

Multi-agent docs — CLAUDE.md + AGENTS.md

I've been using a combination of Claude Code (interactive) and Codex (async review) on this project. Each tool looks for its own context file when it opens a repo — CLAUDE.md for Claude, AGENTS.md for Codex. Having both means either tool immediately knows the full pipeline without burning context on trial and error.

Right now SKiDL has no agent guidance — they waste time discovering env vars, library naming, that footprints are mandatory, pin syntax. I've added:

• CLAUDE.md (PR docs: expand CLAUDE.md with circuit design API guidance #314, already open) — for Claude Code sessions
• AGENTS.md — for Codex and other tools that read AGENTS.md by convention

Both document the same things: the API, the sim pipeline, the layout engine, conventions the placer relies on (decap naming, power net patterns), and the full workflow end-to-end.

Pretty low-cost to maintain. Useful for anyone using AI tools with SKiDL, not just me.

Simulation ERC (src/skidl/sim/)

~4600 lines. Static power-integrity analysis — catches common power design mistakes before you commit to a PCB.

Why static analysis first? SKiDL already has PySpice integration, but SPICE needs accurate models for every active component — and for the MCUs, regulators, and ICs in a typical board, those models either don't exist or aren't freely available. Static analysis (V=IR, power budgets, impedance math) catches maybe 80% of power design mistakes with zero model setup. Where models are available, you'd absolutely run both — static as the fast first pass, SPICE for deeper transient/analog verification. They're layers in the same pipeline, not competing approaches.

What it checks:

• Decoupling inventory — finds caps on power rails, flags what's missing
• Power tree analysis — traces sources through regulators to loads
• Rail sanity — static V=IR / P=VI on declared sources and loads
• PDN impedance model — frequency-domain estimate from cap values + ESR/ESL
• Unified risk report — ranked findings with provenance tracking

from skidl.sim import sim_source, sim_load, sim_assert_rail, generate_unified_report

sim_source("VCC", 5.0, provenance="USB supply")
sim_load("VCC", current=0.5, provenance="MCU datasheet max")
sim_assert_rail("3V3", nominal=3.3, tolerance=0.05)

report = generate_unified_report(default_circuit)
print(report.summary())

Every declaration carries provenance (where the assumption came from) and optional confidence. The idea is agents propose assumptions, humans review the report. No silent inference — if it doesn't know something, it says so.

There's also apply_simulation_intent() for batch declarations — validates transactionally so a bad assumption can't half-apply.

15 files, ~140 tests passing.

Layout engine (src/skidl/layout/)

~6300 lines. Auto-places components and writes .kicad_pcb directly from a SKiDL circuit. No pcbnew dependency — reads .kicad_mod footprint files and writes board S-expressions natively.

Placement is hierarchy-aware and connectivity-driven:

1. Fixed positions (human-placed ICs, connectors)
2. Decoupling caps — auto-detected by value/net pattern, placed 1.5mm from parent IC
3. Signal passives — stacked near their most-connected IC
4. Remaining — shelf-packed within subcircuit groups

The workflow is iterative. The engine generates an initial board, you open it in KiCad and drag ICs/connectors where they actually need to go, save, then re-run the placer — it reads back your positions and fills passives in around them:

from skidl.layout import (
    extract_groups, place_parts, write_kicad_pcb, validate,
    read_placed_positions, LayoutConstraints, BoardOutline,
    load_footprint_bboxes,
)

# Read back human-placed positions from KiCad
fixed = read_placed_positions("board.kicad_pcb")

# Re-run placer with those as constraints — passives fill in around them
groups = extract_groups(default_circuit)
constraints = LayoutConstraints(fixed=fixed, outline=BoardOutline(60, 40))
placed = place_parts(groups, constraints, fp_bboxes)
write_kicad_pcb(placed, default_circuit, fp_lib_dirs, "board.kicad_pcb")

You can also skip the KiCad round-trip and describe placement in conversation — "USB-C on left edge, MCU centre, power top-right" — and the LLM generates FixedPosition and EdgeAnchor constraints directly. Both paths end up in the same place.

The sim ERC's layout_feedback module bridges the two — flags when placement violates power integrity (decoupling cap too far from its IC, that sort of thing).

Also includes congestion scoring, power corridor detection, placement refinement, and a validator that loudly flags overlaps and outline violations.

Worth noting: this isn't trying to be an autorouter — but it does talk to one.

20 files. Works with KiCad 9 footprint libraries.

Routability testing (Freerouting CLI)

Good placement is what makes autorouting work. So the natural question after placement is: can this board actually be routed?

Freerouting has a headless CLI mode. The full loop is scriptable — no GUI, no X11:

layout engine → write .kicad_pcb → pcbnew ExportSpecctraDSN → Freerouting CLI → parse results

I tested this on one of my boards — a 70-part light sensor array with 20 sensors connected via I2C mux to an ESP32. The board has internal cutouts creating narrow bridges between sensor rows (the sensors sit in the 2mm gaps between cutouts). It's a nasty routing problem — 209 unrouted connections to start with.

This board has never been touched by a human. Circuit definition, schematic generation, component placement, board outline, autorouting — 100% natural language, no manual PCB editing. The only input was describing what the board should do.

The DRC JSON tells you which nets failed and where. Map failure positions to the board geometry and the bottleneck becomes obvious — sensor ICs in the inter-cutout gaps fill the routing channels. The LLM diagnoses the constraint and adjusts: widen bridges, increase fillet radius, add copper layers.

Iteration	Change	Unrouted
Baseline	2-layer, 2mm bridges	38
Adjusted	Wider bridges, 4-layer	9

Remaining unrouted are all power nets (GND/VCC) — those get copper pours, not traces.

The whole thing is an LLM feedback loop:

1. Route — export DSN, run Freerouting headlessly
2. Analyze — parse DRC JSON for failing nets and positions
3. Diagnose — map failures to physical constraints (narrow bridges, IC-blocked channels, layer count)
4. Adjust — modify outline geometry, fillet radius, layer count, placement
5. Re-route — repeat until clean

Each cycle is 2-10 minutes, and almost all of that is compute, not tokens. The pcbnew export, Freerouting passes, DRC analysis — that's all Python and Java. The LLM is only needed at two points: diagnosis ("why are these nets failing?") and strategy ("try bigger fillets, not wider bridges"). Everything in between is deterministic.

Which means: the planning and interpretation wants a capable model (spatial reasoning about board geometry, domain knowledge about routing constraints), but the execution loop — circuit definition, placement API calls, export/route/import/DRC — can be driven by a smaller model or just a Python script with the smart model filling in adjustment parameters. Expensive reasoning for the hard decisions, cheap execution for the mechanical steps.

Next steps

I'm still deciding what belongs upstream versus what should stay as an external SKiDL-consuming package. The sim/static ERC layer may make sense as a SKiDL contribution — it's lightweight and adds safety checks that benefit everyone. The layout and manufacturing workflow may be better developed separately first, with only small integration hooks proposed upstream.

Things I'd value input on:

1. Naming — sim/ feels right for a SKiDL contribution. Layout may end up as a separate package.
2. kinet2pcb — the layout engine writes .kicad_pcb directly (no pcbnew). Worth converging or keep them separate?

Where this is heading

The natural next step is closing the loop to manufacturing — BOM availability, part substitution, Gerber export. That's where this gets commercially interesting, and I'm exploring it as a separate tool that consumes SKiDL rather than extending it.

The schematic work is visible in the PRs already open (#308–314). If you're interested in the layout engine or routability work, happy to share — reach out directly.

cc @devbisme @shanemmattner — Shane, saw your LLM analysis work in #240, this is coming at the same problem from a different direction. Would value your perspective on the sim ERC approach especially.

[devbisme]

I think these additional tools are great. The question is where they should be located. My current opinion is that these should remain outside of SKiDL for the followiing reasons:

• The update cadence of these tools will be faster initially than SKiDL. Making these separate tools will let them iterate faster.
• These tools can be useful to non-SKiDL design flows, especially the placement tools and the Freerouting driver, so we shouldn't force other users to load SKiDL.

If possible, we should define an OS-level input/output interface to these tools which might be running as CLI scripts, skills, or MCPs. I think the netlist from SKiDL provides 90% of the information that would be needed and then there could be an additional file or files to provide anything that's missing. Then the tools can generate their results along with info files that SKiDL can read to update its state (if necessary). Non-SKiDL design flows are probably already creating netlists and maybe could generate whatever additional info is needed to drive these tools (especially if they're being steered by AI).

Is there a branch in your skidl repo for these new tools?