Run automatic SPICE simulations on subcircuits detected from KiCad schematic analysis — validates filter frequencies, divider ratios, opamp gains, LC resonance, and crystal load capacitance. Supports ngspice, LTspice, and Xyce (auto-detected). Generates testbenches, runs batch mode, produces structu

SPICE Simulation Skill Automatically generates and runs SPICE testbenches for circuit subcircuits detected by the kicad skill's schematic analyzer. Supports ngspice, LTspice, and Xyce (auto detected). Validates calculated values (filter frequencies, divider ratios, opamp gains) against actual simulation results and produces a structured report. This skill inverts the typical simulation workflow: instead of requiring users to create simulation sources and configure analysis (which ~2.5% of KiCad users do), it generates targeted testbenches automatically from the analyzer's subcircuit detections. Related Skills Skill Purpose kicad Schematic/PCB analysis — produces the analyzer JSON this skill consumes digikey Parametric specs for behavioral models, datasheet downloads mouser Parametric specs (secondary source), datasheet downloads lcsc Parametric specs (no auth needed), datasheet downloads element14 Parametric specs (international), datasheet downloads emc EMC pre compliance — uses this skill's simulator infrastructure for SPICE enhanced PDN impedance and EMI filter analysis Handoff guidance: The kicad skill's analyze schematic.py produces the analysis JSON with subcircuit detections in the flat findings[] array (filtered by detector field). This skill reads that JSON, generates SPICE testbenches for simulatable subcircuits, runs the detected simulator (ngspice/LTspice/Xyce), and produces a structured verification report. Always run the schematic analyzer first. During a design review, run simulation after the analyzer and before writing the final report — simulation results should appear as a verification section in the report. The emc skill reuses this skill's simulator backend for SPICE enhanced PDN impedance and EMI filter insertion loss checks — when ngspice is available, the EMC skill's spice enhanced flag activates these checks automatically. Requirements A SPICE simulator — one of the following (auto detected, first available wins): ngspice — sudo apt install ngspice (Linux) / brew install ngspice (macOS) / ngspice.sourceforge.io (Windows). Most common choice. LTspice — free from analog.com/ltspice. Popular on Windows, works via wine on Linux. Xyce — from xyce.sandia.gov. Parallel SPICE for large circuits. Override with simulator ngspice ltspice xyce or SPICE SIMULATOR env var. Python 3.10+ — stdlib only, no pip dependencies Schematic analyzer JSON — from analyze schematic.py output If no simulator is installed, skip simulation gracefully and note it in the report. Do not treat a missing simulator as an error — it's an optional enhancement. Workflow Step 1: Run the schematic analyzer Step 2: Run SPICE simulations Pass analysis dir analysis/ — the script auto resolves schematic.json from the manifest's current run, writes spice.json into the same run folder, and parks intermediate .cir / .raw files at <run /spice work/ by default. Step 2b (optional): PCB parasitic aware simulation When both schematic and PCB exist, run parasitic annotated simulation for more accurate results on analog circuits: With parasitics , testbenches include trace resistance and via inductance between components. The report shows the parasitic impact — e.g., "48mΩ trace resistance shifts RC filter fc down 0.3%." When to use parasitic simulation: Consider it when the design has high impedance feedback networks ( 100kΩ), LC filters or RF matching networks, long analog signal traces, or high frequency circuits where trace inductance matters. For typical digital designs with low impedance power regulation, the ideal simulation is sufficient. Step 2c (optional): Monte Carlo tolerance analysis Run N simulations per subcircuit with randomized component values within tolerance bands. Reports statistical distributions and sensitivity analysis — which component contributes most to output variation. Tolerance sourcing: Tolerances are extracted from component value strings first (e.g., "680K 1%" → 1%, "22uF/6.3V/20%/X5R" → 20%). When not specified in the value string, defaults are used: resistors 5%, capacitors 10%, inductors 20%. Output: Each simulation result gains a tolerance analysis section with: statistics : mean, std, min, max, 3 sigma bounds, spread percentage for the primary output metric (fc, Vout, gain, etc.) sensitivity : per component contribution percentage showing which component dominates variation (e.g., "C3 (10% tol) contributes 68% of fc variation, R5 (5% tol) contributes 32%") components : list of toleranceable components with their resolved tolerance values When to use Monte Carlo: Use it for feedback networks (regulator output accuracy), precision voltage dividers, RC/LC filters near spec limits, and any circuit where tolerance stacking could push behavior outside acceptable bounds. For N=100 at ~5 50ms per simulation, expect ~0.5 5s per subcircuit. Step 3: Interpret results and present to user Read the JSON report and incorporate findings into the design review. See the "Interpreting Results" and "Presenting to Users" sections below. What Gets Simulated The script selects subcircuits from the analyzer's findings[] array (grouped by detector type). Not every detection is simulatable — the script skips configurations that can't produce meaningful results (comparators, open loop opamps, active oscillators). Detector Analysis What's Measured Model Fidelity Trustworthiness rc filters AC sweep 3dB frequency, phase at fc Exact (ideal passives) High — mathematically exact lc filters AC sweep Resonant frequency, Q factor, bandwidth Near exact (ideal L/C + ESR) High — small Q error from ESR voltage dividers DC operating point Output voltage, error % Exact (ideal passives) High — unloaded feedback networks DC operating point FB pin voltage, regulator Vout Exact (ideal passives) High — cross refs power regulators opamp circuits AC sweep Gain, 3dB bandwidth Per part or ideal High with behavioral model, medium with ideal crystal circuits AC impedance Load capacitance validation Approximate (generic BVD) Medium transistor circuits DC sweep Threshold voltage, on state current Approximate (generic FET/BJT) Medium current sense DC operating point Current at 50mV/100mV drop Exact (ideal resistor) High protection devices DC sweep Diode presence, clamping onset Approximate (generic diode) Low decoupling analysis AC impedance PDN impedance profile Exact + ESR estimates High for passives power regulators DC operating point Feedback divider Vout Exact (ideal passives) High rf matching AC sweep Matching network resonance Exact (ideal L/C) High bridge circuits DC sweep FET switching verification Approximate (generic) Medium snubber circuits AC impedance Snubber damping frequency Exact (ideal R/C) High rf chains Gain budget Per stage gain/loss estimate Heuristic Low — role based bms systems DC operating point Cell balance resistor validation Exact High inrush analysis Transient Inrush current profile Approximate Medium What is NOT simulated Comparators / open loop opamps — no feedback network to validate, skipped Active oscillators — self contained modules, nothing to verify externally Regulator control loop stability — requires full compensator model (behavioral models cover DC feedback only) Level shifter FETs — require modeling both FETs together, skipped High side power switches — source and drain both on power rails, need full load context Fuses and varistors — require manufacturer specific models Anything without parsed component values — if parse value() couldn't extract R/C/L values, the detection is skipped Output Format Status values and what they mean: Status Meaning Action pass Simulation confirms the analyzer's detection within tolerance Report as confirmed. No action needed. warn Simulation shows something worth noting — small deviation, model limitation, or edge case Report with context. Often the "warn" reflects a real but minor issue (e.g., slight gain error from ideal opamp model). fail Simulation contradicts the analyzer — wrong frequency, large gain error, unexpected behavior Investigate. Could be a real design issue, a topology misdetection by the analyzer, or a testbench generation bug. Check the .cir file and log. skip Could not simulate — missing data, unsupported configuration, simulator error Note in report. Check the note field for the reason. Interpreting Results Passive circuits (RC filters, LC filters, voltage dividers) These simulations use ideal component models, so the simulation is mathematically exact . Any significant deviation ( 1%) from the analyzer's calculated value indicates a bug in either: The analyzer's topology detection (e.g., it misidentified which net is input vs output) The testbench generation (topology reconstruction error) The analyzer's value parsing (component value parsed incorrectly) In testing across real projects, passive simulations consistently show <0.3% error — essentially confirming the analyzer's math is correct. A "pass" here means the calculated cutoff frequency, resonant frequency, or divider ratio is accurate. What these simulations do NOT tell you: Whether the real circuit behaves this way. The simulation uses ideal isolated subcircuits without loading from downstream stages, PCB parasitics, or temperature effects. A voltage divider that simulates perfectly at 1.65V may actually produce 1.62V when loaded by a high impedance ADC input — but that loading effect is real circuit behavior, not an analyzer error. Opamp circuits For recognized parts (~100 common opamps in the lookup table), the skill uses a per part behavioral model with the correct GBW, slew rate, input offset, and output swing. For unrecognized parts, it falls back to the ideal model (Aol=1e6, GBW=10MHz). The model note field in the report indicates which model was used: "LM358 behavioral (lookup:LM358, GBW=1.0MHz)" — per part model, bandwidth results are accurate "ideal opamp (Aol=1e6, GBW~10MHz)" — fallback, bandwidth results are approximate When the behavioral model is used, the simulation correctly captures bandwidth limitations. An LM358 at gain= 100 shows bandwidth of ~10 kHz (correct for 1 MHz GBW), while the ideal model would misleadingly report ~100 kHz. For opamps with behavioral models, gain bandwidth limitation warnings are informational — they flag where the part's GBW constrains the circuit. These are valuable design insights, not simulation errors. Crystal circuits Crystal simulations validate load capacitor selection — they check that the effective load capacitance is in a reasonable range for the crystal's specified CL. They use a generic Butterworth Van Dyke equivalent circuit model with typical parameters, not the specific crystal's data. The primary value is catching missing or grossly wrong load capacitors, not precise frequency prediction. When simulations fail or skip Check the note field first. Common causes: Note Cause Fix "could not measure 3dB frequency" AC sweep range doesn't include the 3dB point Check if the filter fc is very low (<0.1 Hz) or very high ( 100 MHz) "AC measurement failed" Testbench topology error — the circuit doesn't converge Check .cir file for floating nodes or missing connections "Testbench generation failed: KeyError" Analyzer detection is missing expected fields Check analyzer JSON — the detection may be incomplete "ngspice/ltspice/xyce failed: ..." Simulator error Check .log file for