How Do You Run SPICE Simulation in KiCad?

Detailed Explanation

KiCad's schematic editor includes an integrated ngspice simulator, letting you validate a circuit's behaviour against its design intent before laying out a single trace. This is a genuinely distinct workflow stage from the schematic-to-fabrication process covered in How to Use KiCad — it happens earlier, at the point where you're still deciding whether the circuit itself is correct, not yet how to route it.

What ngspice Is, and How KiCad Uses It

ngspice is a widely used open-source SPICE (Simulation Program with Integrated Circuit Emphasis) engine — the same class of simulator underlying most commercial circuit simulation tools, including LTspice and the SPICE engines built into other EDA suites. KiCad doesn't reimplement SPICE; it embeds ngspice directly and translates the schematic's connectivity and component values into a SPICE netlist automatically, so you interact with simulation results through the normal schematic view rather than hand-writing a netlist file.

Setting Up a Schematic for Simulation

1. Assign SPICE models to active components. Passive components (resistors, capacitors, inductors) work out of the box using their schematic value — ngspice has built-in ideal models for these. Active components need an explicit model. Right-click a symbol → Edit Simulation Model and either select from ngspice's built-in device models (for generic transistors and diodes) or import a manufacturer-supplied SPICE model file (.lib, .mod, or a .subckt block) for a specific real part — for example, an op-amp's actual SPICE macromodel from its manufacturer's datasheet page, which captures real gain-bandwidth, slew rate, and output swing behaviour far more accurately than an idealised model.

2. Add a ground/reference symbol. ngspice requires an explicit ground reference (net 0) somewhere in the schematic. KiCad's standard ground symbol serves this role — a schematic with no ground symbol will fail to simulate.

3. Add a simulation command. Open Simulation Command from the Simulator panel (or add a .tran, .ac, .dc, or .op directive as schematic text) to define what kind of analysis to run and over what range. See the FAQ below for what each analysis type answers.

4. Run the simulation. Open the Simulator panel (Tools → Simulator, or the toolbar icon) and run. Results plot directly — voltage and current probes can be placed on any net or component pin by clicking them in the schematic view while the simulator is active.

Practical Simulation Workflows

Validating a filter's frequency response. For an active filter design (see How Do You Design Active Filters?), an .ac sweep across the frequency range of interest produces a Bode plot that should match the calculated cutoff frequency and roll-off slope from the design equations — catching a component-value transcription error or a miscalculated pole/zero placement before any hardware exists.

Checking an amplifier's DC operating point. An .op simulation confirms an op-amp or transistor stage is biased where the design intends — for example, that an op-amp's output isn't sitting near a supply rail (which would clip any AC signal riding on it) before moving on to AC analysis. See What Is an Op-Amp? for the underlying parameters (gain-bandwidth, slew rate, offset voltage) a good SPICE macromodel should capture.

Verifying startup and transient behaviour. A .tran simulation with a time-varying source (a step input, a switching waveform, or a ramping supply) shows how the circuit responds over time — useful for sanity-checking a feedback loop's settling behaviour or a power-up sequencing circuit before it exists as a board.

Where Simulation Fits in the Design Process

SPICE simulation sits between schematic capture and PCB layout — after the circuit topology and component values are decided, but before the board is routed. It answers "is this circuit's intended behaviour correct?" It does not answer "will this specific PCB implementation of the circuit behave correctly?" — layout-dependent effects like parasitic trace inductance, ground bounce, and the physical routing constraints covered in Signal Integrity Basics for PCB Design are outside what schematic-level SPICE simulation can predict. Treat simulation as a design-intent check that catches gross errors cheaply, not as a replacement for prototyping and bench validation.

For teams weighing KiCad's simulation capability against a commercial alternative, see Altium Designer vs KiCad — Altium's integrated signal-integrity and PDN analysis tools go further than KiCad's ngspice integration for high-speed, high-layer-count board work, though for schematic-level circuit validation on the vast majority of designs, KiCad's built-in ngspice is sufficient.

For circuit design that benefits from simulation-validated schematics before layout begins, Zeus Design designs and simulates circuits through to production-ready PCB layout.

Design Considerations

• Use manufacturer SPICE models for critical active components, not generic substitutes. A generic ngspice op-amp model won't capture a specific part's actual gain-bandwidth product, slew rate, or output swing limitations — for any circuit where these parameters matter to the result, import the manufacturer's published macromodel instead of relying on a built-in generic device.
• Simulate corner cases, not just nominal values. Running an .ac or .tran sweep only at nominal component values and nominal supply voltage misses the tolerance-stack failures that show up in a real production batch. Where the design margin is tight, re-run key simulations at the component tolerance extremes.
• Keep simulation subcircuits organised in a project-local library. Imported SPICE models can be added to a KiCad project's simulation model library rather than duplicated per-schematic, keeping the project's models consistent and easier to update if a manufacturer revises a model.

Common Mistakes

• Forgetting to add a ground symbol. ngspice requires an explicit ground reference net; a schematic with a "0V" rail symbol that isn't actually KiCad's ground symbol, or with no ground reference at all, fails to simulate with an unhelpful error rather than a clear "missing ground" message.
• Simulating with default/ideal models and trusting the result as final validation. A circuit that simulates cleanly with ngspice's generic built-in transistor or op-amp model can still fail on real hardware if the actual part's parameters (offset voltage, parasitic capacitance, real saturation behaviour) differ meaningfully from the generic model. Import real manufacturer models for any component whose specific behaviour matters to the design outcome.
• Treating a clean simulation as proof the PCB layout will work. Simulation validates the schematic-level circuit; it says nothing about ground bounce, trace parasitic inductance, thermal behaviour, or EMI — all of which depend on the physical PCB implementation and require layout-stage analysis or bench measurement to verify.
• Not checking convergence warnings. ngspice can produce a plotted result even when the underlying numerical solution had convergence difficulty (common with highly nonlinear circuits or poorly chosen initial conditions) — check the simulation console output for convergence warnings rather than assuming a plotted curve is automatically a valid solution.