Skip to content
Tech HistoryDeep Dive Published Updated 6 min readViews unavailable

Berkeley SPICE: From CANCER's Circuit Solver to a Shared Design Tool

Trace SPICE from Berkeley's earlier CANCER program through the 1973 report, Nagel's 1975 SPICE2 thesis, and the archived SPICE3F5 source.

SPICE is usually introduced as an acronym and a familiar file format. Its early history is more instructive when read as a sequence of research artifacts: Berkeley’s earlier simulation programs, a 1973 report describing SPICE as an improvement to CANCER, Laurence Nagel’s 1975 thesis documenting SPICE1 and SPICE2, and the later Berkeley archive that preserves SPICE3F5 source. Each artifact supports a different claim. The 1973 paper explains the algorithms and design limits the authors were working with; the 1975 thesis analyzes the next generation; the source archive shows that the lineage remained a practical software project rather than only a paper title.

The surviving reports make it possible to tell that history without projecting today’s simulator features backward. They also show how numerical methods, device models, teaching needs, and distribution shaped an engineering tool that became widely used in circuit design.

A classroom problem produced a family of simulators

In their April 1973 report, L. W. Nagel and D. O. Pederson expand SPICE as “Simulation Program with Integrated Circuit Emphasis.” The report’s introduction says Berkeley’s laboratory had already built BIAS, then developed CANCER and TIME when transient analysis was needed. SPICE is identified as the lab’s newest program and as an improvement on CANCER, used in classroom instruction and graduate research. The abstract describes one nodal-analysis program combining nonlinear DC analysis, small-signal analysis, and nonlinear transient analysis, with particular emphasis on bipolar-junction and field-effect transistor models.

That sequence matters. SPICE did not appear as an isolated invention with every feature arriving at once. It grew out of a laboratory that needed increasingly useful ways to analyze integrated circuits and to give students a “dry lab” that was quicker and cheaper than building each circuit. In the 1973 report, simulation is an engineering method for evaluating integrated circuits whose coupling and component characteristics made hand analysis impractical, not merely a substitute for plotting measured data.

The report’s technical choices show what “improvement” meant in that setting. Its circuit equations used nodal analysis; its sparse-matrix routines stored nonzero terms rather than a full two-dimensional matrix; and the report says SPICE and CANCER shared a basic Newton-iteration approach and implicit trapezoidal integration with a fixed, user-supplied transient time step. The authors describe SPICE as having more suitable BJT and FET models and improved program coding and organization. They also identify reliable automatic time-step control as a desirable future addition. That final caveat is important: an early release should not be credited with a later numerical capability simply because modern SPICE-family tools have it.

SPICE2 turned a successful program into a methods study

Nagel’s 1975 Berkeley thesis, SPICE2: A Computer Program to Simulate Semiconductor Circuits, takes a different form from the earlier conference report. Berkeley’s catalog describes it as documenting the theoretical and practical aspects of SPICE1 and SPICE2 and comparing the numerical methods needed for equation formulation, linear solution, nonlinear solution, and numerical integration. The thesis says the broad use of SPICE indicated that its algorithms applied to a wide range of practical circuit-simulation problems. That is a more specific historical claim than saying the software simply “won”: its methods were being studied, compared, and revised as users applied them to varied circuits.

By separating the solver’s stages, the thesis makes clear why circuit simulation is not just a transistor model wrapped in a parser. A netlist becomes a system of circuit equations; a linear solver handles one part of the calculation; nonlinear device equations require an iterative method; transient analysis integrates state over time. Choices at each stage affect convergence, accuracy, and cost. The different method names and comparisons in the thesis are evidence that the SPICE project was also a research vehicle for numerical analysis, not solely a fixed program distributed to engineers.

The timeline should still be stated with care. Nagel’s thesis is the primary source for SPICE1 and SPICE2’s technical details and its own account of use. The 1973 report is the primary source for the earlier program’s stated feature set. Neither source alone justifies every later story about institutional policy, licensing, or commercial adoption. When discussing a particular release, cite that release’s report or source archive rather than using a later recollection to fill gaps in the contemporary record.

From written report to a versioned software artifact

Berkeley’s historical software archive preserves a SPICE3F5 source tarball and identifies the relevant software copyright period as 1985–1991. The archive describes SPICE2 as the earlier Fortran version and notes that both SPICE2- and SPICE3-based commercial products existed. Those statements are useful institutional context, but the archive’s date range should not be misreported as a precise SPICE3F5 release date. Copyright years, branch names, and publication dates are different evidence.

For reproducibility, I fetched Berkeley’s archived spice3f5.tar.gz during this research and recorded its SHA-256 digest as cac11fe2a761241e6b6c9eaa31b938c7ffa76aeaecac09809609d3a4125cd269. This pins the archive bytes used for inspection even if the hosting page changes. It is not a claim that the tarball represents every SPICE3 build or that a checksum establishes authorship by itself; its provenance comes from the Berkeley archive URL and the accompanying historical page.

A source-led way to check a SPICE history claim

Consider the tempting statement, “SPICE already had automatic adaptive timesteps in its first release.” A careful historical check does not begin with a modern command-line manual. First, read the 1973 report’s account of transient integration: it describes an implicit trapezoidal formula with a fixed, user-supplied step, then calls reliable time-step control a desirable addition. Next, check Nagel’s later SPICE2 thesis for how methods were documented and compared. Finally, inspect the preserved SPICE3F5 source only when a claim specifically concerns that code snapshot. This sequence keeps the evidence attached to the right version and prevents a feature of a later implementation from leaking backward into a 1972 or 1973 description.

That method also improves present-day debugging. When two SPICE-compatible tools disagree, record the simulator name and version, input deck, device model, analysis mode, and solver options before comparing plots. “SPICE” is a family label, not a guarantee that every parser, model, integration method, or convergence strategy is identical. The historical papers themselves show that those numerical choices were active areas of change.

SPICE’s lasting significance was not that one early program solved every circuit or settled every numerical problem. It was that Berkeley produced a documented, general-purpose program whose evolving methods could be studied and reused, then preserved enough reports and code for later engineers to trace the design decisions. CANCER, SPICE1, SPICE2, and SPICE3F5 belong to a lineage, but each should be understood through its own contemporary evidence.

Related:

Sources:

Comments