SPICEAssistant: LLM-Enhanced SMPS Design
- SPICEAssistant is a tool-augmented large language model framework that integrates datasheet retrieval and LTSpice simulation for iterative SMPS netlist adaptation.
- It employs retrieval-augmented generation to access controller datasheet details and a suite of simulation tools to extract quantitative feedback for design refinement.
- Benchmark results on 256 SMPS design tasks demonstrated a significant performance boost—achieving a 53% solve rate and reducing median APE to 4.2% through iterative simulation feedback.
SPICEAssistant is a tool-augmented LLM framework for schematic and netlist design of switched-mode power supplies (SMPS) on printed circuit boards. It is centered on GPT-4o and extends standalone prompting with two external capabilities: retrieval-augmented access to controller datasheets and a set of LTSpice-linked simulation tools that expose structured numerical feedback to the model. The framework is designed for multi-step SMPS design tasks in which a typical application circuit from a datasheet must be modified until output voltage, ripple, switching frequency, startup behavior, or controller mode satisfies a target specification. In benchmarking, SPICEAssistant was evaluated on 256 SMPS design questions and was reported to outperform standalone GPT-4o by approximately 38%, with simulation feedback identified as the main source of improvement (Nau et al., 14 Jul 2025).
1. Definition and problem setting
SPICEAssistant addresses a specific limitation of general-purpose LLMs in electronic design automation: the difficulty of understanding, adapting, and dimensioning electronic circuits when the task requires both datasheet reasoning and iterative SPICE verification. The target domain is not generic circuit generation but the adaptation of SMPS netlists, where design work commonly begins from a datasheet’s typical application circuit and proceeds through repeated edits to component values and pin connections. These edits must then be checked against simulation outputs rather than accepted as text-only hypotheses (Nau et al., 14 Jul 2025).
The framework is motivated by several challenges that are explicit in SMPS design. Datasheets are multimodal and may not be fully readable by the model; SPICE waveforms are difficult for the model to interpret reliably; the design process is multi-step and dependent; and hallucinations are risky in circuit synthesis. SPICEAssistant therefore replaces one-shot circuit editing with an iterative loop in which the model proposes a modification, simulates the modified circuit, extracts quantitative features, compares them against the target, and revises the netlist accordingly (Nau et al., 14 Jul 2025).
This positioning makes SPICEAssistant distinct from prompt-only SPICE generation systems. Its central claim is not that an LLM can directly solve SMPS synthesis from text, but that circuit design quality improves when the model can query both documentary and simulator-side evidence during the design process (Nau et al., 14 Jul 2025).
2. Architecture and interaction model
The architecture has three progressively richer configurations. The baseline is an instructed GPT-4o model that receives a reference circuit netlist and engineering requirements and outputs a modified netlist directly. A second configuration adds retrieval-augmented generation (RAG) over the relevant SMPS controller datasheet so that the model can pull in formulas, pin descriptions, operating-mode rules, and maximum input-voltage constraints. The full SPICEAssistant configuration combines GPT-4o, RAG, and simulation tools, enabling repeated interaction with LTSpice and structured post-processing of simulation results (Nau et al., 14 Jul 2025).
A key architectural feature is the replacement of raw waveform interpretation with prebuilt Python “reading tools.” The paper lists get_mean_output_voltage(), get_ripple(), get_switching_frequency(), and get_settle_in_time() as example functions. These tools operate on LTSpice output signals and return concise numerical summaries. This design is motivated by an explicit empirical observation: GPT-4o alone is weak at directly interpreting time-series waveforms or images of waveforms, so SPICEAssistant converts simulation outputs into features that can be used more reliably (Nau et al., 14 Jul 2025).
The workflow is therefore neither purely symbolic nor purely simulator-driven. Datasheet retrieval provides controller-specific rules and formulas, while LTSpice-derived tools provide behavioral verification. In practical terms, SPICEAssistant is an interface layer between an LLM and two external technical substrates: documentary specifications and circuit simulation (Nau et al., 14 Jul 2025).
3. Benchmark, task classes, and design operations
The benchmark introduced for SPICEAssistant contains 256 questions designed to test whether an LLM-based system can adapt, dimension, and understand SPICE netlists for SMPS circuits. It is organized around three circuit types of increasing difficulty: a general buck converter, classified as easy; the LTC3419 typical application circuit, classified as medium; and the LTC7802 typical application circuit, classified as hard. The question counts are 72 for the general buck converter, 72 for LTC3419, and 112 for LTC7802 (Nau et al., 14 Jul 2025).
Two task classes are distinguished. The first is topology adaptation, comprising 32 questions, and includes tasks such as selecting pulse-skipping mode, changing pin connections, and altering controller-mode circuitry. The second is parameter tuning, comprising 224 questions, and includes setting supply voltage, adjusting output voltage, achieving a target ripple current, tuning feedback resistors, and setting switching-related parameters. This division is important because the reported results show a marked asymmetry between the relative tractability of parameter tuning and the greater difficulty of topology editing (Nau et al., 14 Jul 2025).
Several benchmark tasks are explicitly multi-step. For LTC3419 output-voltage tuning, the framework uses the relation
which requires the agent to retrieve or infer the formula, rearrange it, identify the corresponding resistors in the netlist, edit their values, and verify the result through simulation. If the requested output voltage is too high, the agent may also need to retrieve the maximum allowed input voltage from the datasheet and revise that constraint as well. For LTC7802 pulse-skipping mode, the task requires reading the datasheet rule, identifying the mode pin and INTVcc pin, and wiring the mode pin to INTVcc through a 100 kΩ resistor (Nau et al., 14 Jul 2025).
| Benchmark element | Content |
|---|---|
| Circuit types | General buck converter; LTC3419; LTC7802 |
| Question classes | 32 topology adaptation; 224 parameter tuning |
| Total size | 256 questions |
The benchmark is therefore not limited to scalar regression on component values. It spans algebraic parameterization, datasheet-rule application, pin-semantic reasoning, and structural netlist modification (Nau et al., 14 Jul 2025).
4. Evaluation protocol and empirical results
Evaluation is fully automated through a JSON specification that stores the target value, the tolerance, the verification tool to call, and the question-construction details. For each question, the system generates the prompt, runs the LLM, simulates the produced netlist, extracts the relevant feature using the same tool logic available to the agent, and compares the result against the target. Two main metrics are used: Solve Rate and median absolute percentage error (median APE). A task is counted as solved when the result lies within the required tolerance, typically 5%; topology-adaptation questions are evaluated as binary correct or incorrect. The error metric is
with the median preferred to the mean because the distribution contains large outliers (Nau et al., 14 Jul 2025).
The main quantitative result is that simulation feedback dominates the performance gains. The total solve rates reported are 14.8% for baseline GPT-4o, 16.9% for GPT-4o + RAG, 49.0% for GPT-4o + SPICE, and 53.0% for the full SPICEAssistant. The paper also reports a median APE reduction from 64.3% for baseline GPT-4o to 4.2% for SPICEAssistant. Repeated interaction with the simulator matters: performance improves as the number of tool interactions grows and then plateaus after about five iterations. For statistical robustness, the benchmark was repeated 40 times on the simpler general buck converter cases, with mean values, confidence intervals, and significance at reported (Nau et al., 14 Jul 2025).
| Configuration | Total solve rate | Median APE |
|---|---|---|
| GPT-4o baseline | 14.8% | 64.3% |
| GPT-4o + RAG | 16.9% | — |
| GPT-4o + SPICE | 49.0% | — |
| SPICEAssistant | 53.0% | 4.2% |
The results also reveal clear difficulty gradients. Performance degrades from the general buck converter to LTC3419 and then to LTC7802. The reasons given are increased netlist complexity, more controller pins and topology complexity, more formulas and physical functions, and less publicly available data. RAG yields only modest gains overall, with somewhat larger benefits on the more specialized LTC3419 and LTC7802 cases than on the generic buck converter (Nau et al., 14 Jul 2025).
5. Relation to adjacent SPICE-oriented research
Within the emerging literature on LLM-supported SPICE workflows, SPICEAssistant occupies the niche of simulator-coupled netlist adaptation for power electronics. A closely related but differently scoped framework is SPICEPilot, which targets analog and digital circuit code generation through a Python-first, PySpice-based pipeline built around a generate → validate → feedback → regenerate loop and standardized Pass@k evaluation. SPICEPilot emphasizes dataset creation, prompt engineering, and validation for PySpice code, whereas SPICEAssistant emphasizes LTSpice-backed iteration, datasheet retrieval, and SMPS-specific netlist adaptation tasks (Vungarala et al., 2024).
A second adjacent line of work concerns simulation throughput rather than agent architecture. EEspice is an open-source C++ SPICE-like circuit simulation framework designed for optimization-in-the-loop flows, including AI and LLM-based analog sizing agents that repeatedly invoke SPICE. Its central technical contribution is lock-free parallel stamping via graph coloring, with up to 45x speedup on a 64-core workstation in low-conflict cases. This broader context matters because tool-augmented design agents become more useful as the latency and scalability of repeated SPICE invocation improve (Bao et al., 3 Apr 2026).
Taken together, these systems indicate that the phrase “SPICE assistant” now denotes a family of workflows rather than a single method. SPICEAssistant contributes the SMPS-specific version of that family: tight coupling between LLM reasoning, datasheet retrieval, and simulation-derived numerical feedback (Nau et al., 14 Jul 2025).
6. Limitations, misconceptions, and significance
The paper is explicit that SPICEAssistant is substantially better at parameter tuning than at topology adaptation. The reported explanation is structural: SPICE netlists have weak semantic structure, and pin naming and connectivity are harder for the model to interpret than scalar component values. This limitation is visible in qualitative failure cases, such as pulse-skipping-mode modification, where the model identifies the correct conceptual node but connects the wrong pin and later uses incorrect SPICE syntax (Nau et al., 14 Jul 2025).
A second limitation concerns waveform interpretation. A common misconception is that a frontier multimodal LLM should be able to read ripple, frequency, or settling behavior directly from raw time-series data or plotted waveforms. The paper tests this explicitly and reports that GPT-4o is not reliable at extracting correct ripple values from numeric vectors or waveform images. This finding motivates the use of specialized reading tools such as get_ripple() rather than direct visual or textual interpretation of simulator output (Nau et al., 14 Jul 2025).
The broader significance of SPICEAssistant lies in the design principle it operationalizes. RAG alone provides only modest benefit, whereas structured simulation feedback produces the major improvement. The framework therefore reframes SMPS design assistance as an iterative verification problem rather than a pure text-generation problem. In that sense, SPICEAssistant is best understood not as a stand-alone netlist generator but as a simulation-aware agent for adapting datasheet-derived SMPS circuits under explicit electrical targets (Nau et al., 14 Jul 2025).