Chatting with Schematic: Evaluation of LLMs' Know-How in Electronics

This article evaluates the proficiency of 11 contemporary Large Language Models (LLMs) in performing electronic circuit analysis.

Utilizing OpenCode, an open-source agentic framework, the LLMs are tasked with analyzing a clock generator’s resistor-capacitor (RC) network defined in a KiCad 9.0 schematic. To facilitate LLMs’ comprehension, an efficient preprocessing methodology is introduced to convert schematic data into structured CSV formats. The evaluation requires the models to parse circuit netlists, retrieve specifications from component datasheets available in the workspace, and calculate the critical circuit parameters, specifically the common-mode voltage and differential swing of the clock output.

To validate the LLMs’ predictive accuracy, their results are compared against a ground truth established through LTspice simulation and empirical measurements from a physical PCB implementation.

table { border-collapse: collapse; } th, td { border: 1px solid #777; padding: 0.4rem 0.6rem; }

What is an Agentic AI

Large Language Models (LLMs) versus AI Agents are like calculators versus computers. A calculator – analogous to an LLM – accepts a single formula (= a prompt) and calculates an answer. Then the user might type in a follow-up formula and so on. A computer – analogous to an AI Agent – implicitly contains a calculator (the LLM) but with new features: looping, branching (if-then-else), and file storage or network access. A single question to an AI Agent might run dozens of LLM loops to iteratively break down the question into a todo list and work through it systematically.

The picture below describes how a typical Agentic AI ecosystem works: (AI-generated illustration, details approximate.)

At the center of the Agentic AI ecosystem there is the AI AGENT ORCHESTRATOR (also called ‘harness’). This is a piece of software that runs locally on user PC and communicates with the user through a text and graphical interface. The most common examples today are: Github Copilot CLI, Claude Code, OpenCode (Desktop), or Github Copilot plugin in VSCode. The AGENT ORCHESTRATOR is connected over the network to LLM INFERENCE SERVER which is where the LLM AI models are hosted. The inference server is typically located in large and power-hungry AI datacenters with thousands of GPUs.

The crucial feature of an AGENT ORCHESTRATOR, compared to old browser-based chat-gpt, is its default access to local files on the user PC. This enables the LLM to automatically find, read and write files in the project workspace. The ORCHESTRATOR automatically configures the LLM for a given project via special files like AGENTS.md, SKILLs, and others, that are prepared and persistent in the workspace.

Finally, so-called MCP SERVERS are basically plugins for the ORCHESTRATOR that provide additional software-defined features for LLM Agents to enable or improve their work. Although they are called ‘servers’ these are typically small pieces of software running on the local PC alongside the ORCHESTRATOR. MCP SERVERs can provide features such as access to command line (dangerous!), indexed searching through project documentation, fetching data from specialized company servers and so on.

OpenCode Desktop Beta

The picture below is an annotated screenshot of OpenCode Desktop Beta, www.opencode.ai, an open-source coding agent (the orchestrator). OpenCode is available with two front-ends: standard textual working from the command line, and the graphical desktop shown below. Both perform identically in terms of agentic work, but I find the graphical version more convenient for non-coding tasks. You can connect many different providers of LLM to this agent, including Github Copilot, Anthropic Claude models, and open-weight models.

The example below shows an output by Gemini 3 Pro. This model outputs the math in Markdown/LaTeX format which renders beautifully in the OpenCode Desktop app (click to enlarge):

The Electronic Task for LLM

This section describes the electronic analysis task which will be prompted for the evaluation of the AI Agents. It might seem long and out of place for an article about AI, but the purpose here is to appreciate the complexity of the task that the AI will have to solve.

I am building a test-PCB for a future board with Agilex 3 FPGA. The picture below shows a block diagram of the test PCB and a 3D render:

An important testing part of this board is the Clock Generator. The Clock Generator must create (among other outputs) a 100MHz differential clock for future LP4 interface in FPGA. We already discussed the interface in previous articles. To recap shortly, the input buffers in FPGA must be configured in Altera’s True Differential Signalling 1.1V:

As highlighted above, the input clock signal must have these main parameters:

• Differential amplitude VID between 100mV and 454mV (the peak-to-peak swing which we typically measure on an oscilloscope is double that, i.e. 200mV to 908mV).

• Common mode voltage VICM(DC) between 0.8V to 0.95V.

The critical part of the schematic is shown below. On the left a clock distributor U1002 - SY75604BTWL generates LP-HCSL differential signal. The necessary target voltage levels are generated by R-C termination network in the middle. The FPGA, which is not included in this test-board, will provide internal 100 ohm termination - this is emulated by R1036 in the test schematic. The SMA connectors on the right are really just test-points for high-impedance active probes:

With the LPHCSL, each output pin of U1002 (OUT0_P and OUT0_N - the red and blue traces in the simulation plot below) switches between 0V and 0.75V single-ended (N is inverted P). Therefore, the LPHCSL time-averaged common mode voltage of each output (P and N) is 0.75/2 = 0.375V (typical value). The LPHCSL differential amplitude (VOD) is 0.75V and the total peak-to-peak diff swing is 2*0.75 = 1.5V.

The LPHCSL common mode voltage (0.375V) is blocked by coupling capacitors C1006 and C1007 and a new output common mode voltage is established by the resistor divider network R1028/R1029 and R1032/R1033. The divider is identical for P and N, so we can calculate it just once: Vcc / (R1028 + R1029) * R1029 = 1.1 / (49+190) * 190 = 0.875V. This is the final output common mode voltage and it lands exactly in the middle of the requirement range 0.8V to 0.95V of the True Differential Signalling 1.1V. Calculation of the common mode voltage is relatively easy.

To calculate the final output differential amplitude we must consider the whole loading on the nets starting with the output internal resistance in U1002 SY75604BTWL. Here the suffix -B is very important because it specifies a variant of SY75604 that is matched to 100 Ohm transmission line - i.e. the 50 Ohm series source termination resistors are included inside the IC (and not shown in Kicad schematic!):

The schematic below, drawn in LTspice, shows the complete differential signal path through the RC network. It is identical to the Kicad schematic. The 50 Ohm source termination at the voltage sources on the left is made explicit by resistors R8 and R9. The V1+R8 and V2+R9 represent OUT0_P and OUT0_N of U1002, respectively.

We could simulate this schematic to obtain the output voltages, but let’s first analyze it manually:

For 100 MHz clock signal the 10nF capacitors C1, C2 (in Kicad: C1006, C1007) are shorts: Z = 1 / (2*pi*f*C) = 1 / (2*pi*100e6*10e-9) = 0.159 Ohm, and could be ignored.

For AC signals the resistors R2|R3 (50 Ohm and 190 Ohm) and R4|R5 are in parallel because they are terminated in the low-impedance nets GND and +1.1V, respectively. The parallel combination of 50 Ohm and 190 Ohm is 39.58 Ohm. Finally, the 100 Ohm resistor across P and N is equivalent to two 50 Ohms in series and with GND in the middle, because signals are symmetrical (in AC analysis: when V1=+0.375V then V2=-0.375V).

The AC simplified schematic is shown here (note signal sources swing between +0.375V and -0.375V):

It is now relatively easy to calculate the voltages with the AC-simplified schematic. The R3 (39.58 ohm) and R1 (50 Ohm) are in parallel and have the combined resistance R1|R3=22.09 Ohm. When V1=+0.375V then the instantaneous single-ended peak voltage TD_P (across R1|R3) is 0.375/(100+22.09)*22.09 = 0.068 V. At the same time, since the V2 is AC-symmetrical, V2=-0.375V, the instantaneous single-ended peak voltage TD_N (across R2|R5) is -0.068V. The instantaneous differential voltage (TD_P - TD_N) at this peak is 0.068-(-0.068)=+0.136V. This zero-to-peak instantaneous diff. voltage is the differential amplitude (0.136V). The minus-peak-to-plus-peak swing between TD_P - TD_N is double the amplitude for symmetrical signals, i.e. 0.272V - this is the signal “height” on scope and it is just double the amplitude.

The graph below is from LTspice simulation of the full circuit (not the AC simplified one above). The red and blue traces are the single-ended _P and _N signals; the mean value (= common mode) around 0.875V is visible. The green trace is the difference P-N; the differential amplitude is around 0.140V (the peak-to-peak swing is 0.280V).

Simulation results equal our calculation.

The circuit was built on the test-board:

And measured: the red and blue traces are the positive and negative outputs measured with active single-ended probes. The brown trace is math difference.

The scope measured the common mode voltage 0.871V, and the differential swing 0.257V (this is labeled “Amplitude” in the lower window, but it is really the swing between High and Low values).

The hand calculation (0.272V), simulation (0.280V), and measurement (0.257V) are all within expected tolerances.

Electronic Circuit Comprehension by an Agentic AI

This is the prompted question for AI Agents:

In circuit testpcb-nofpga, on the sheet Clock generator, we need to calculate the final clock differential signal levels on the signals LP4_CLK_P/N, generated from OUT0_P/N of U1002. The circuit is a test for future board with FPGA; the FPGA is not included here; SMA will be connected to high-impedance active probes. Generate analysis plan.

The prompt leads to a todo list for agents with roughly these items:

1. locate the correct schematic files in workspace (= where is “circuit testpcb-nofpga”?)

2. read the schematic files (= which format are the schematic files? Can I understand it?)

3. find sheet Clock generator, find signals LP4_CLK_P/N, OUT0_P/N of U1002

4. what is U1002, where is a datasheet?

5. calculate the parameters

AGENTS.md = Onboarding Your AI Colleague

Agent Orchestrators work from a specified project directory, a workspace. If you use VScode, for example, this is the top folder in the ’explorer’ tab on the left. The agent workspace is configured by special files (all optional) that inform the AI about the project (AGENTS.md) and extend it with skills (recipes) and tools (MCP servers).

The AGENTS.md is a README for AI. It is recommended to keep it simple, short, and focused on just the most important items, since this file is always preloaded into the finite-sized LLM context. The file is written in plain language (e.g. English).

In case of the project discussed here the whole AGENTS.md is about 115 lines. In the beginning the project folder structure is described:

## Repository Layout

agila-pcb.git/agila-pcie-card/   # KiCad 9 main PCB project (13 schematic sheets)
agila-pcb.git/Library/           # Custom KiCad symbol + footprint libraries
agila-pcb.git/testpcb-nofpga/    # PSU validation test PCB (no FPGA)
tools/kicad-net-to-csv/          # kicad-net2csv.py — netlist → CSV converter
tools/import_pad_to_die/         # import_pad_to_die_fab.py — BGA bond-wire importer
tools/pdf/pdf_converter_pymupdf4llm.py  # conversion tool PDF -> Markdown
Agila-m2-notes/                  # Obsidian markdown design notes (read-only reference)
Simulations/                     # LTspice analog simulation files (.asc)
Datasheets/                      # Component datasheets (organised by category)
thinking/                        # Put temporary agent generated files here.

How the LLM “sees” a Schematic

An LLM can understand circuit netlist files in textual form. According to my experiments (and conversations with the AI), the more straightforward the format, the better. In the end I settled on a format using three simple CSV files:

• all-sheets.csv

  • CSV columns: sht_ref,sht_name,sht_title,sht_source

• all-components.csv

  • CSV columns: designator,category,value,stuff,footprint,datasheet,sheet_refs

• all-pins-nets.csv

  • CSV columns: designator,pin,net_name,func,type

The all-sheets.csv lists all the schematic sheets in the project. It contains sheet names in the field sht_name which the user can reference:

sht_ref,sht_name,sht_title,sht_source
001,/,AGILA,testpcb-nofpga.kicad_sch
002,/FPGA SDM/,AGILA,fpga-sdm.kicad_sch
003,"/FPGA HPS (nc), GND/",AGILA,fpga-hps.kicad_sch
004,/FPGA HSIO 2A + LP4/,AGILA,fpga-hsio-2a.kicad_sch
005,/FPGA HSIO 3A/,AGILA,fpga-hsio-3a.kicad_sch
006,/FPGA HVIO/,AGILA,fpga-hvio.kicad_sch
007,"/FPGA GTS, PCIe/",AGILA,fpga-gts-pcie.kicad_sch
008,/FPGA SDM/FTDI USB-JTAG/,AGILA,ftdi-jtag.kicad_sch
009,/FPGA Power/,AGILA,fpga-power1.kicad_sch
010,/Clock Generator/,AGILA,clocking.kicad_sch
011,/PSU top-level/,AGILA,psu1.kicad_sch
012,/PSU top-level/PSU PoL Group 1/,AGILA,psu-gr1.kicad_sch
013,"/PSU top-level/PSU PoL Group 2A, 2B/",AGILA,psu-gr2.kicad_sch

The file all-components.csv lists all components in the schematic project. It ties component designator (reference) to the category, value, footprint and sheet reference:

designator,category,value,stuff,footprint,datasheet,sheet_refs
C201,capacitor,100n/50V/0402,yes,Capacitor_SMD:C_0402_1005Metric_Pad0.74x0.62mm_HandSolder,~,002
C202,capacitor,1n/50V/0402,yes,Capacitor_SMD:C_0402_1005Metric_Pad0.74x0.62mm_HandSolder,~,002
C203,capacitor,100n/50V/0402,yes,Capacitor_SMD:C_0402_1005Metric_Pad0.74x0.62mm_HandSolder,~,002
C204,capacitor,100n/50V/0402,yes,Capacitor_SMD:C_0402_1005Metric_Pad0.74x0.62mm_HandSolder,~,002
D201,diode,BAT54J,yes,Diode_SMD:D_SOD-323F,https://assets.nexperia.com/documents/data-sheet/BAT54J.pdf,002
D202,diode,BAT54J,yes,Diode_SMD:D_SOD-323F,https://assets.nexperia.com/documents/data-sheet/BAT54J.pdf,002
D203,diode,BAT54J,yes,Diode_SMD:D_SOD-323F,https://assets.nexperia.com/documents/data-sheet/BAT54J.pdf,002
D204,diode,BAT54J,yes,Diode_SMD:D_SOD-323F,https://assets.nexperia.com/documents/data-sheet/BAT54J.pdf,002
...

Finally, the most important file is all-pins-nets.csv which ties component-pins to nets, as shown below. I settled on a normalized form of the table, which means that there is one row per component pin. For example, the resistor R1028 has two pins (1, 2) and so appears twice in the netlist table:

designator,pin,net_name,func,type
C1207,1,+1V0,,passive
C1209,1,+1V0,,passive
J602,17,+1V0,Pin_17,passive
R1028,1,+1V1,,passive
C1006,2,/Clock Generator/TD0_P,,passive
J1001,1,/Clock Generator/TD0_P,In,passive
R1028,2,/Clock Generator/TD0_P,,passive
R1029,1,/Clock Generator/TD0_P,,passive
R1036,1,/Clock Generator/TD0_P,,passive
...

I have a Python 3 script that converts Kicad 9 netlist files, which use a rather verbose nested S-expression format, into these flat CSV files. First I wrote a Readme describing the not yet existing tool and then I let a coding agent generate the implementation to the spec. The tool and the Readme are referenced, along with additional instructions, in the top-level AGENTS.md so the AI will “understand” the schematic file structure:

To read schematic follow this procedure:
1. Convert schematic into netlist file (might already exist, check timestamps):
    $ kicad-cli sch export netlist --format kicadsexpr myschematic-example.kicad_sch
2. Convert netlist, which is still a big file, into CSV files:
    $ tools/kicad-net-to-csv/kicad-net2csv.py myschematic-example.net myschematic-outdir/
3. Use the CSV files generated in step 2 for your analysis.
    Readme incl. the CSV structure is in `tools/kicad-net-to-csv/README-kicad-net2csv.md`.

The AI is smart enough to figure it out from these instructions.

If you would like to see the complete AGENTS.md for the project, click to unfold the detail below. The file is about 115 lines long, and I would say today that it contains some unnecessary information. It is presented here for completeness.

# AGENTS.md — AgilaM2FPGA Project

This file provides guidance for AI coding agents working in this repository.

## Project Overview

**AgilaM2FPGA** is an open-hardware PCB design project for an FPGA-based low-profile PCIe x4 card.


## Repository Layout

“`
agila-pcb.git/agila-pcie-card/ # KiCad 9 main PCB project (13 schematic sheets)
agila-pcb.git/Library/ # Custom KiCad symbol + footprint libraries
agila-pcb.git/testpcb-nofpga/ # PSU validation test PCB (no FPGA)
tools/kicad-net-to-csv/ # kicad-net2csv.py — netlist → CSV converter
tools/import_pad_to_die/ # import_pad_to_die_fab.py — BGA bond-wire importer
tools/pdf/pdf_converter_pymupdf4llm.py # conversion tool PDF -> Markdown
Agila-m2-notes/ # Obsidian markdown design notes (read-only reference)
Simulations/ # LTspice analog simulation files (.asc)
Datasheets/ # Component datasheets (organised by category)
thinking/ # Put temporary agent generated files here.
“`

—

## Install dependencies

“`bash
pip install openpyxl schemdraw sexpdata pandas pymupdf4llm
# pcbnew is part of KiCad’s bundled Python — not pip-installable normally
# On Windows use py.exe to invoke python; on linux use python3.
“`

## Run the tools

“`bash
# Convert a KiCad netlist to CSV files
python3 tools/kicad-net-to-csv/kicad-net2csv.py <file.net> <output_dir>

# Convert PDF to markdown
python3 tools/pdf/pdf_converter_pymupdf4llm.py <document.pdf> <output.md>
“`

## IMPORTANT: Analysis of KiCad schematic and files

IMPORTANT: Do not hand-edit `.kicad_sch`, `.kicad_pcb`, or `.kicad_mod` files unless you are absolutely certain of the syntax — a parse error silently corrupts the project!

IMPORTANT: Although KiCad schematic and PCB files are **S-expression text files** and could be read
directly, BY DEFAULT DO NOT DO IT because it wastes lot of LLM tokens!
Instead follow this procedure:
1. Convert schematic into netlist file (might already exist, check timestamps):
$ kicad-cli sch export netlist –format kicadsexpr myschematic-example.kicad_sch
2. Convert netlist, which is still big file, into CSV files:
$ tools/kicad-net-to-csv/kicad-net2csv.py myschematic-example.net myschematic-outdir/
3. Use the CSV files generated in step 2 for your analysis.
Readme incl. the CSV structure is in `tools/kicad-net-to-csv/README-kicad-net2csv.md`.

Always check timestamps if files need regeneration.


## Pinouts

Pinout is a pin-number to function mapping. For a given part type it could be different in various packages.
Therefore, always check footprint or package types in datasheet; if unsure which package is used, ask the user.
For simple components like resistors, capacitors, diodes, transistors the pinout MAY be obvious.
For connectors (!!) and integrated circuits, NEVER assume you know the pinout from model knowledge, but read
the correct datasheet. You should find the datasheet in the project folder, or else ask the user to provide it!


## Datasheets

For all relevant components the datasheets SHOULD BE ALREADY available in the project (generally in `Datasheets/`); if not, ask the user to provide!
DO NOT search for datasheet on the internet, unless explicitly asked to.
PDF datasheets SHOULD BE ALREADY converted to text (Markdown or HTML) before use by the model. Look in folders named `HTML`. If not, use the PDF tool in `tools/pdf/pdf_converter_pymupdf4llm.py` to convert to markdown and then read.

## Graphics output

To draw electronic schematic, draw either ASCII art, or use python package schemdraw (use european resistor symbols; place resistor text slightly offset so that it is not obscured).

## Document generation

Generated documents must include:
* date;
* author: identification of the LLM model which generated the file;
* source data references.

By default generate documents in Markdown.
Use python’s openpyxl to read/write excel files.

## Design Notes (Obsidian Vault)

`Agila-m2-notes/` is an **Obsidian markdown vault** used as the project design journal.

| File | Content |
|——|———|
| `Agila Features.md` | Definitive interface and IC feature list |
| `PSU/PSU.md` | Power supply topology decisions |
| `LPDDR4/LPDDR4 in FPGA IP.md` | EMIF/LPDDR4 IP configuration |
| `GTS/PCIe.md` | PCIe impedance requirements |
| `PCB/FPGA footprint.md` | BGA pad sizing and JLCPCB DFM rules |

Read these files for context before making design decisions. Do not modify them unless the
user explicitly asks — they are the human engineer’s working notes.

—

## External Tools

| Tool | Purpose | Notes |
|——|———|——-|
| **KiCad 9** | PCB/schematic design | GUI tool; Python API via `pcbnew` module |
| **LTspice** | Analog simulation | `.asc` files in `Simulations/` |
| **Altera PTA** | Power/thermal analysis | Output saved in `Power.txt` and `pta/` |
| **Quartus Prime / Agilex tools** | FPGA compilation | Not in this repo |

If you are interested in a small deep dive, the next detail section shows part of a session generated by Gemini 3 Pro. The log was extracted from OpenCode session and contains interesting low-level details of tool calls that are normally hidden from the user.

Why not Vision?

Humans best understand circuits laid out on a 2D paper, so why not use LLM with vision input capability for the circuit input as well? The answer: it becomes very expensive very fast. The unit of computation for an LLM is a token. One textual token is on average 3/4 of a word. One visual token is typically a picture patch of 16x16 pixels in RGB, varying by model.

Let’s calculate how many tokens are needed for textual CSV netlist - the sheet 10 with the Clock Generator. I extracted the components and nets on sheet 10 using grep on the CSV files and used python tiktoken module to count the tokens: 4 232 tokens.

For a good-enough picture resolution (not to lose important details) I estimated that the sheet 10 of the schematic should be represented in the resolution at least 2000 x 1625 pixels (size A3 page). This is 125 x 102 patches (each 16x16 pixels) = 12 625 patches = tokens. (In reality the patches should slightly overlap so it will be more of them.) This is at least a factor of 3 increase going from textual tokens to visual tokens, and the LLM still has yet to do the visual recognition of components, wires and connections. The higher visual token count occupies a larger portion of the LLM context window.

Visual input is suitable for small circuits that are not available in other format. For example, a picture of an application circuit in a datasheet.

Model Evaluation

The evaluation ran in OpenCode Desktop Beta. The following 11 models were tested:

• Google / Gemini 3 Flash (via Google AI Studio)

• Google / Gemini 3 Pro (via Google AI Studio)

• Anthropic / (Claude) Haiku 4.5 (via Github Copilot)

• Anthropic / (Claude) Sonnet 4.6 (via Github Copilot)

• Anthropic / (Claude) Opus 4.6 (via Github Copilot)

• OpenAI / GPT 5.4 (via Github Copilot)

• BigPickle (OpenCode Zen)

• Mimo V2 Omni Free (OpenCode Zen)

• Mimo V2 Pro Free (OpenCode Zen)

• MiniMax M2.5 Free (OpenCode Zen)

• Nemotron 3 Super Free (OpenCode Zen)

The workspace was set up identically for each agentic session. Models were configured in the Default effort mode, and conversation started in the Plan mode first. An agent received the initial prompt (shown in previous section) and after some thinking presented an analysis plan. If there were obvious mistakes at this point I tried to question it or correct it to put LLM back on track. Then I switched the mode to Build so the agent could create an analysis report.

I collected all reports and session log files into a separate ‘results’ folder. To evaluate all the racing contenders I used another agent, which was instructed to check the analysis reports and session logs. Using an LLM as judge has known biases, but it provided a useful ranking that I manually verified. The judging was based on the correct prediction of voltages, thinking time, zero-shot results, asking follow-up questions, providing additional helpful suggestions to the user, and on the overall quality and completeness of the report. The judge was asked to rank models from best to worst. The judges were Gemini 3 Pro and GPT 5.4.

# Evaluation of LLM models (agents) in their understanding of electronic circuit

The folder evaluated_models/ contains a subfolder for each conversation with an LLM.
The file evaluated_models/AGENTS-for-evaluated-models.md was the AGENTS.md for the evaluated models in their sessions in OpenCode.
Each session (or conversation) was independent.
Each model received the same initial prompt:

In circuit testpcb-nofpga, on the sheet Clock generator, we need to calculate the final clock differential signal levels on the signals LP4_CLK_P/N, generated from OUT0_P/N of U1002. The circuit is a test for future board with FPGA; the FPGA is not included here; SMA will be connected to high-impedance active probes. Generate analysis plan.

(There might be slight variations!)

Ground truth: The electronic circuit was built and we measured the following voltages:
output common mode voltage = 0.871 V
output differential swing = 0.257 V
Therefore, the model’s calculation is basically correct when it predicts these values as the typical result.

In the conversation/ subfolders there are dumps of the session with the model.
The conversation is structured as series of `## User` prompts and `## Assistant` responses. Note that in case of @subagents the ‘User’ refers to master’s Assistant message.
The `## Assistant` line is actually formatted as: `## Assistant (<model-provider>/<model>) – <response-time> seconds`.

The outputs/ subfolders contain all file outputs from sessions.

The models should be judged by these criteria:

– correct prediction of the common mode voltage (this is an easy calculation)
– correct prediction of the differential swing (a difficult calculation)
– thinking time (lower is better)
– zero-shot prediction, or did the user have to correct or guide the model?
– asking follow-up questions (is not bad by itself):
– were the questions logically formulated?
– did the model ask for something which was already available in previous inputs?
– did the model use the answer from the user?
– providing helpful analytical suggestions to the user
– generation of the output report:
– was everything included what was specified?
– how effectively was the document created?

Results

Top Performers (Accuracy): Claude Opus 4.6, Claude Sonnet 4.6, and Gemini 3 Pro were the only models to accurately calculate both the common mode voltage (~0.875V vs 0.871V ground truth) and the difficult differential swing (~272mV vs 257mV ground truth).

Speed vs. Accuracy: Gemini 3 Pro achieved highly accurate results with significantly shorter thinking time (~284 seconds) compared to Claude Opus 4.6 (~1437s) and Claude Sonnet 4.6 (~1934s). The thinking time also includes tool execution.

Zero-Shot Champion: Claude Opus 4.6 was the best at zero-shot reasoning. It autonomously gathered all data and produced highly accurate calculations without any corrections, while additionally proactively suggesting resistor changes to improve the voltage input differential margins.

Common Mistakes: Many models incorrectly assumed the AC coupling capacitors completely blocked the DC component leading to a 0V common mode prediction. Others failed the differential calculation by modeling the driver as an ideal voltage source without accounting for the internal 50Ω impedance (specified in the clock-driver datasheet) against the external bias network.

Unexpected Loser: GPT 5.4 failed to produce numerical results and provided only general information.

Expected Losers: Gemini 3 Flash and Claude Haiku 4.5 are cheap, fast models which lack deep understanding - by design.

Example Reports

LLM wrote reports in Markdown and I converted them to PDF, with a minor loss in formatting.

Report by Opus 4.6:

Opus4-6–2026-03-20–lphcsl-clock-signal-level-analysisDownload

Report by Sonnet 4.6:

sonnet4-6–lp4_clk_signal_analysisDownload

Report by Gemini 3 Pro (it has used latex syntax in the math equations, which has rendered badly in pdf, but looks great on screen):

2026-03-16–LPHCSL-Clocking-Gemini3-1ProPreDownload

Future Work

SKILL

The instructions in AGENTS.md on how to convert a Kicad schematic into CSV files and how to read them are basically a SKILL. Skills should be specified in individual SKILL.md files rather than in the main AGENTS.md because of context waste: a particular SKILL.md is loaded into context just when it is needed (eg. when the user task requests schematic reading).

MCP Server / Plugin instead of the CSV Files

I found out that the LLM dissects the CSV netlist files with basic tools like grep. This is not efficient and it is structurally wrong. It would be better to provide the LLM with an MCP server that can efficiently parse and search through the circuit database (even if it is first converted to CSV). This method could also support richer interface with the circuit, e.g. including user comments in the page, extended component attributes on demand and so on.

Datasheets in PDF

A PDF is designed for printing and is not well suited for LLM processing. I have converted component datasheets in PDF to Markdown or HTML, and gave an instruction in AGENTS.md which tool the agent should use to do the conversion (this could be a SKILL). There are many different pdf-to-text tools, but none is quite perfect. These tools often have problems with converting complicated tables, multi-column layouts and so on.

Once a PDF is converted to text (Markdown, HTML) the LLM tends to use grep to search for guessed keywords. This is not efficient and the agent could easily overlook important details. A much better approach would be to index the text with LLM embedding (a form of index organized by meanings) and provide an MCP to search the text by semantic ideas.

Conclusion

Use Opus 4.6 for critical analysis of schematic circuits. It has good understanding and can provide valuable feedback. This model is also probably the most expensive (token cost).

For simpler tasks where you can easily check intermediate results and correct minor mistakes, the Claude Sonnet 4.6 and Gemini 3 Pro (but not the Flash variant) can provide excellent results at higher speed and reduced cost.

Ok, But Would I Believe an AI Agent for Circuit Analysis?

Short answer: Never as the only source of truth! The example presented here was done ex-post when I already had the LTspice simulation results and the actual measurement done. The problem with LLM is: it often makes a simple mistake (which might be justifiable because the input data is either huge or incomplete) and then covers up the mistake with made-up well-sounding arguments! The Agentic systems try to defend against this by nudging the LLM to question all its conclusions and re-evaluate (do–> check). Humans prefer not to do potentially wasteful work, so when something seems odd because of former error, they stop and re-evaluate. LLM, in contrast, is eager to do anything and everything it can do immediately, so it happily runs with faulty inputs no matter what.