LLM-Assisted SP Modeling Module
- LLM-Assisted SP Modeling Module is an integrated EDA framework that combines a language model, datasheet retrieval, and SPICE simulation for iterative SMPS circuit optimization.
- It employs lightweight function-calling and iterative netlist adaptations to adjust component parameters and validate designs using simulation metrics such as solve rate and APE.
- The module significantly improves design performance, achieving over a 3× boost in solve rate and a more than 10× reduction in median error compared to baseline methods.
A LLM-Assisted SP (Switched-Mode Power Supply) Modeling Module refers to an EDA system architecture in which a general-purpose LLM, integrated with retrieval-augmented generation (RAG) pipelines and a SPICE-based simulation toolset, orchestrates the iterative adaptation, simulation, and quantitative validation of SMPS circuit netlists on PCBs. The paradigm exploits a lightweight function-calling interface to manage circuit parameterization, simulation feedback, and datasheet context retrieval, yielding stepwise improvements in design performance, measured on explicit end-to-end benchmarks of SMPS design tasks (Nau et al., 14 Jul 2025).
1. Architecture of LLM-Assisted SP Modeling Module
The architecture comprises a core agent (commercial LLM, e.g., GPT-4o) wrapped by two extension layers: (a) a datasheet RAG module and (b) a SPICE simulation toolset. The LLM interacts with retrieved datasheet excerpts—covering formulas, pin functions, and device limits—and with a suite of Python wrappers over LTSpice, that expose netlist IO, simulation invocation, and advanced result parsers.
Key components:
- Core LLM: Accessed via API, stateless across iterations except for prompt history.
- Datasheet Retrieval (RAG): Fetches textual snippets from PDF datasheets for context- and formula-injection.
- SPICE Toolset:
- Netlist Editor (
read_netlist,write_netlist) - Simulator Controller (
run_simulation) - Result Parsers: Extracts mean output voltage (), ripple ( or ), switching frequency (), and settling time ()
- Netlist Editor (
- Prompt Orchestration: Each LLM call is appended the current netlist, design goal, datasheet context, and tool output history.
Interaction is implemented via function-calling, enabling the LLM to: (a) Request circuit simulation or feature extraction (e.g., ‘get_ripple(…)’), (b) Propose edited netlist code blocks for adaptation.
| Component | API Functionality | Role in Loop |
|---|---|---|
| Netlist Editor | read/write SPICE netlist | Textual circuit adaptation |
| Simulator Controller | run_simulation | Circuit behavior evaluation |
| Parsers | get_mean_output_voltage, get_ripple, get_switching_frequency, get_settling_time | Output feature quantification |
2. Iterative Optimization and Control Workflow
The design agent executes up to iterations per task, alternating between LLM-suggested netlist modifications and SPICE simulation-based feedback:
- Prompt is assembled with {netlist, goal, datasheet excerpts, tool output history}.
- LLM emits either:
- A tool call (e.g.,
get_ripple(...)), whose result is fed back into the next prompt - An updated netlist, which is simulated and its results parsed; the outcome is recorded in the prompt history
- A tool call (e.g.,
- Early termination occurs if the design criteria are met within the specified tolerance, or if the LLM signals task completion.
- The process is summarized by the following control pseudocode: 1 Empirically, five iterations are sufficient for convergence in the vast majority of cases (Nau et al., 14 Jul 2025).
3. Integration of SMPS Circuit Formulas and Data Retrieval
Canonical SMPS analysis formulas are injected into LLM context via RAG or within task prompts, enabling both procedural suggestions and algebraic verification steps. Representative expressions include:
- Duty cycle (ideal buck):
- Inductor ripple current (peak-to-peak):
- Output voltage ripple (triangular approx.):
- Feedback divider law:
- Settling time to 90%: 0
Formulas are either surfaced from datasheets (using RAG) or applied symbolically in LLM-generated rationale chains. When the LLM suggests new parameter values (e.g., 1, 2, 3, 4), these are immediately validated against simulated results to ensure quantitative alignment with the task objective.
4. Netlist Adaptation, Validation, and Criteria Enforcement
Each iteration comprises two tightly coupled processes: netlist adaptation and automated validation. Netlists are mutated as plain text with substitutions or insertions based on component labels (e.g., "R1 N1 N2 10k"). Validation—triggered after each netlist/simulation update—is bifurcated:
- Parameter Tuning: Numeric targets with ±5% tolerance; evaluation by calling the relevant parser (e.g.,
get_ripple) on the .raw file; failure to meet tolerance triggers re-iteration. - Topology Adaptation: Boolean predicates (e.g., “MODE pin is tied to INTVcc via 5 resistor”); parsed by direct inspection of the netlist text.
The system automatically rejects netlists that fail validation and iterates until success or iteration limit.
5. Benchmark Suite, Metrics, and Quantitative Outcomes
A comprehensive 256-task benchmark assesses end-to-end capability, comprising:
- Task Types:
- Parameter tuning (224 tasks: 6, 7, 8, 9)
- Topology adaptation (32 tasks: e.g., pulse-skipping mode enablement)
- SMPS Examples:
- Easy: General buck converter (72 tasks)
- Medium: LTC3419 (72 tasks)
- Hard: LTC7802 (112 tasks)
Evaluation metrics are:
- Solve Rate (SR): Fraction of tasks solved exactly (all goals within tolerance)
- Absolute Percentage Error (APE): 0, reported as the median across tasks
Aggregate results are tabulated:
| Method | Solve Rate | median(APE) |
|---|---|---|
| GPT-4o (baseline) | 14.8% | 64.3% |
| GPT-4o + RAG | 16.9% | 57.3% |
| GPT-4o + SPICE feedback | 49.0% | 4.7% |
| SPICEAssistant (full) | 53.0% | 4.2% |
SPICE-based iterative feedback is the primary driver of improvement, delivering a more than 3× boost to solve rate and >10× reduction in median APE over baseline LLMs. RAG in isolation is marginally beneficial. Performance improvement saturates at five simulation iterations (Nau et al., 14 Jul 2025).
6. Scope, Limitations, and Directions for Generalization
The LLM-Assisted SP Modeling Module architecture exhibits extensibility to other EDA domains (e.g., analog amplifier, RF filter, photonic circuit design) through analogous tool-wrapping and feature-exposing. Important limitations include:
- LLMs’ residual difficulty with complex pin-mapping and low-level SPICE semantics; future work may convert flat netlists to graph or object representations to facilitate more robust symbolic reasoning.
- The iterative loop may benefit from outer-loop optimizers (Bayesian, PSO) to accelerate convergence.
- Multi-agent or critic-based techniques may further reduce hallucinations or improve fine-grained editing.
A plausible implication is that this architecture serves as a general template for hybrid LLM-simulator design agents, where the combination of retrieval, simulator coupling, and stepwise validation can yield robust automated dimensioning and adaptation in domains characterized by multi-step, numerically driven engineering tasks (Nau et al., 14 Jul 2025).