Reference Guide

What is SPICE simulation? A plain-English guide

Updated August 2026 · By the CircuitSim team · 8 min read

SPICE stands for Simulation Program with Integrated Circuit Emphasis. It is a computer program, by now a family of programs, that predicts how an electronic circuit will behave by solving the circuit's equations numerically, and it has been the standard way to simulate circuits since it emerged from the University of California, Berkeley in the early 1970s. The first version was presented publicly in 1973, and Berkeley distributed the code openly rather than selling it. That one decision explains the next half century: more than 50 years later, nearly every serious electronics design tool, free or costing five figures a seat, runs a SPICE descendant at its core.

TL;DR: SPICE in five lines

SPICE = Simulation Program with Integrated Circuit Emphasis, developed at UC Berkeley in the early 1970s and released openly.
It works by nodal analysis: apply Kirchhoff's current law at every node, then solve the resulting equations numerically.
Device models supply the physics: .model for single devices, .subckt for multi-part blocks such as op-amps.
Dialects break portability: PSpice, LTspice, and HSPICE each extended the language differently, so models fail across tools.
Browser SPICE changes access, not math: engines now compile to WebAssembly and run locally in a tab, with nothing to install.

Where SPICE came from

By the early 1970s, integrated circuits had become too complex to design on paper and too expensive to debug by fabrication: building a chip to find out it was wrong cost months and a fortune. Researchers at UC Berkeley built a program to predict circuit behavior before committing silicon, presented SPICE1 in 1973, and then made the decisive move: they released the code openly, essentially for the cost of a tape. Universities taught with it, companies built on it, vendors sold polished versions of it, and its successor SPICE2 became the industry workhorse. The commercial simulators that dominate professional electronics and the free tools hobbyists use all descend from that lineage. When an engineer says "simulate it," they mean "run SPICE on it."

How SPICE works: nodal analysis in plain English

SPICE does not understand circuits the way a person does. It reads a netlist, a plain-text list of components and the numbered nodes they connect, and turns it into arithmetic. The method is called nodal analysis, and the idea fits in a paragraph: at every node, the current flowing in must equal the current flowing out (Kirchhoff's current law). Writing that rule down for every node produces a system of simultaneous equations whose unknowns are the node voltages. Solve it, and you know the voltage everywhere, from which every current follows.

Resistors and sources give linear equations, and one matrix solve finishes the job. Diodes and transistors make the system nonlinear, so SPICE guesses a solution, measures the error, corrects, and repeats until the answer settles. That technique is Newton-Raphson iteration, and it is the origin of the dreaded convergence failure, which means the iteration never settled. For behavior over time, SPICE re-solves the entire system at every point on a fine time grid: a 100 ms transient can mean thousands of complete circuit solutions. That is why simulation was a mainframe workload in 1973 and is an ordinary browser-tab workload now.

Device models: where the physics lives

The solver is half of SPICE; the device model is the other half: the equations that make a simulated part behave like a bought one. A resistor's model is one line of algebra; a diode's is an exponential curve shaped by fitted parameters; a modern MOSFET model runs to dozens of parameters describing the silicon itself. A simulated 1N4148 conducts like a real 1N4148 because its parameters were measured from real parts. That is why manufacturers publish SPICE models for their components, and why the practical fix for a missing library part is to import the vendor's model text rather than approximate. The missing-component guide walks that workflow.

Why SPICE and not a simpler simulator?

Plenty of excellent circuit simulators are not SPICE. Falstad and Tinkercad Circuits use simplified, idealized component models, and for building intuition that is exactly right: you can watch current flow and voltages move in real time. The trade-off is prediction. An idealized diode conducts perfectly; a real 1N4148 drops about 0.7 V, leaks a little, and carries junction capacitance that matters at speed. SPICE models carry that measured behavior, which is why SPICE results transfer to the breadboard and idealized results sometimes do not. A reasonable rule: use an idealized simulator to understand a concept, and use SPICE the moment the answer has to match hardware you intend to build, buy, or grade.

.model versus .subckt

Vendor model files contain one of two constructs. A .model statement is a parameter set for a device SPICE already knows: the built-in diode, BJT, or MOSFET equations, filled in with one specific part's numbers. A line or a few is typical. A .subckt is a subcircuit: a self-contained block with its own named pins, used for anything beyond a single device equation: op-amps, regulators, sensor macromodels. Some are built from dozens of internal transistors, others from a few controlled sources that mimic the part from the outside. Either way, you wire up its pins and treat it as one component.

A netlist you can read

Netlists look forbidding and are not. Here is a complete, runnable netlist for an RC low-pass filter with a 1 kΩ resistor and a 100 nF capacitor:

* RC low-pass filter
V1 in 0 AC 1
R1 in out 1k
C1 out 0 100n
.ac dec 20 10 1meg
.end

Line by line: a comment; a 1 V AC source between node in and node 0 (ground is always node 0); a resistor from in to out; a capacitor from out to ground; and an .ac directive requesting a sweep from 10 Hz to 1 MHz at 20 points per decade. Run it and the output traces the filter's frequency response, rolling off above about 1.6 kHz. Every schematic you have ever drawn in a SPICE tool becomes text like this before the solver sees it.

Why models break between tools: the dialect problem

Berkeley defined the netlist language; four decades of vendors extended it, each in a different direction. The three dialects you will meet most often:

Dialect	Steward	Where you meet it
PSpice	Cadence Design Systems	A long-standing commercial standard; a large share of vendor macromodels and university course material is written in it.
LTspice	Analog Devices	The most widely used free desktop SPICE; Analog Devices publishes extensive models in its dialect.
HSPICE	Synopsys	The professional standard for IC-level verification; foundries deliver process model decks in it.

Each dialect earned its extensions honestly, solving real problems for its users. The cost landed on portability: a model that runs cleanly in the tool it was written for produces a cascade of syntax errors elsewhere. That, more than any solver difference, is why "SPICE-compatible" on a box does not mean your model files will load. The mitigations are three: hunt down a generic-SPICE version, hand-edit the offending lines, or use a simulator with compatibility modes. CircuitSim, as the worked example, detects the dialect of pasted model text automatically and adjusts.

What running SPICE in a browser changes

Nothing about the math. Browser simulators compile an industry-standard SPICE engine to WebAssembly and run the identical nodal analysis locally in the tab. In CircuitSim, nothing queues on a server, and a circuit with no schematic runs its pasted netlist verbatim, so the six-line filter above is a copy, a paste, and a Run button away. What changes is everything around the math: no installation, so SPICE runs on locked-down lab machines and Chromebooks; no OS requirement beyond a modern browser; sharing becomes a link instead of a zip file of model directories. The honest other side of the ledger: browser tools are young. CircuitSim ships six analyses (interactive, interactive operating point, transient, AC sweep, DC operating point, and DC sweep), while noise analysis, Monte Carlo, and parameter sweeps, long standard on the desktop, are not available today. And the page needs an internet connection to load, though the simulation itself runs locally once it has.

A reasonable way to hold it: the 1973 program made circuit simulation possible; the free desktop tools of the 2000s made it free; browser engines are making it ambient: available on whatever machine is in front of you, at the cost of some depth that will take time to rebuild.

Get started free at circuitsim.com →

Frequently asked questions

What does SPICE stand for?

Simulation Program with Integrated Circuit Emphasis. It is a circuit simulation program, by now a family of programs, that predicts circuit behavior by solving the circuit's equations numerically.

Who created SPICE?

SPICE was developed at the University of California, Berkeley in the early 1970s; the first version was presented publicly in 1973. Berkeley distributed it openly rather than selling it, which is why nearly every commercial and free circuit simulator since descends from it.

Is SPICE still used today?

Yes. It is the standard. More than 50 years after it appeared, nearly every serious electronics design tool runs a SPICE descendant at its core, from free desktop tools to IC design suites, and manufacturers publish SPICE models for their parts because engineers design with them.

Is SPICE free?

The original Berkeley code was distributed openly, and free descendants and free tools built on them exist today, including browser-based simulators such as CircuitSim, which has a free plan with no credit card required. Commercial SPICE variants such as PSpice and HSPICE are paid products.

What is the difference between SPICE and LTspice?

SPICE is the underlying simulation method and program family; LTspice is one particular SPICE implementation, published free by Analog Devices, with its own extensions to the netlist language. Every LTspice simulation is a SPICE simulation, but not every SPICE tool reads LTspice syntax.

Why do SPICE models fail when moved between tools?

Because of dialects. PSpice, LTspice, and HSPICE each extended the netlist language differently: behavioral expressions, parameter syntax, and library directives all diverge, so a model written for one dialect throws syntax errors in another. Fixes include finding a generic-SPICE version, hand-editing the model, or using a tool with compatibility modes that detect the dialect.

Is browser-based SPICE as accurate as desktop SPICE?

The math is the same. Browser tools such as CircuitSim compile an industry-standard SPICE engine to WebAssembly and run it locally in the browser, so the solver and device equations are the same class used in desktop tools. Differences between tools lie in feature depth: some desktop analyses, such as noise analysis and Monte Carlo, are not available in browser tools today.

Is Falstad a SPICE simulator?

No. Falstad's simulator uses its own simplified, idealized models, which makes it fast and wonderful for intuition but not predictive of real parts. SPICE tools use manufacturer-fitted device models, so their results transfer to hardware. Many people use both: Falstad to understand a concept, and SPICE to design the circuit they will actually build.

What is a SPICE netlist?

A plain-text description of a circuit: one line per component naming the nodes it connects and its value or model, plus directives that tell the simulator which analysis to run. Netlists are what SPICE actually reads; schematics are a drawing layer on top.

PSpice is a trademark of Cadence Design Systems, Inc. LTspice is a trademark of Analog Devices, Inc. HSPICE is a trademark of Synopsys, Inc. Tinkercad is a trademark of Autodesk, Inc.; Falstad is the work of its author. CircuitSim is not affiliated with any of these organizations or with the University of California, Berkeley. Capability details reflect each tool's public documentation as of August 2026.