JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Device Models and Why They Matter

The netlist names the parts and the analyses crunch the numbers — but how does SPICE know what a diode actually does? Behind every component sits a device model: equations plus numbers. This guide opens that box, shows why the friendly 0.7 V diode rule is a model and not a law, and drives home the one truth that decides whether a simulation is worth trusting — it is only as good as its models.

What a device model actually is

By now you can write a netlist that names every part and pins it to numbered nodes, and you can ask for the core analyses — operating point, DC sweep, AC, transient. But step back and ask the obvious question: when SPICE sees the line for a diode, how does it know that a diode passes current one way and blocks it the other? It does not just know. Behind that single letter sits a device model — a small bundle of equations, plus the numbers that feed them, describing exactly how that part turns voltage into current and back again.

Every model has two halves, and keeping them apart clears up a lot of confusion. First the type: the form of the equations, which is fixed and built into SPICE — the diode type uses the exponential Shockley equation, the resistor type uses Ohm's law. Second the parameters: the specific numbers that tune those equations to a real part — saturation current, series resistance, capacitance. It is exactly like a recipe: the method (whisk, fold, bake) is the type; the quantities (200 g flour, 3 eggs) are the parameters. Same method, different numbers, a different cake.

The diode: why 0.7 V is a model, not a law

Earlier on the ladder you leaned on a handy rule: a conducting silicon diode drops about 0.7 V, full stop. SPICE does not store the number 0.7 anywhere. Instead the diode model computes current from voltage with the exponential law I = Is times (e^(V/(n times VT)) - 1), where Is is the saturation current (a tiny number like a few nanoamps), VT is the thermal voltage (about 26 mV at room temperature), and n is a fudge-fit ideality factor. That equation is the famous curve — the diode I-V curve that stays nearly flat, then suddenly turns sharply upward. The 0.7 V you memorized is just the knee of that curve at ordinary currents.

* A SPICE diode: the TYPE is fixed (Shockley); the .model card sets the NUMBERS
D1    anode  cathode   D1N4148
.model D1N4148  D(Is=2.5n  N=1.9  Rs=0.6  Cjo=4p  Bv=100  Ibv=100u)

   forward current     forward voltage (this same model, ~25 C)
   ------------------------------------------------------------
   0.1 mA              ~ 0.50 V
   1   mA              ~ 0.61 V
   10  mA              ~ 0.72 V      <-- this is roughly the "0.7 V"
   100 mA              ~ 0.88 V          one snapshot, not a constant
One diode model, evaluated at four currents. The drop slides from 0.5 V to nearly 0.9 V — and it also shifts about -2 mV for every degree the part warms. The 0.7 V rule is a single point on a moving curve.

Read the table and the rule stops feeling like a law and starts feeling like what it is: a one-point summary of a living curve. The forward voltage is not 0.7 V — it is whatever the exponential says for the current you actually push and the temperature you are actually at. This is the deep reason the model matters more than the memorized number: SPICE gives you the whole curve for free, so a circuit that sets its bias from that drop will track current and temperature correctly in the sim, the way it does on the bench. Trust the model; treat 0.7 V as a back-of-envelope guess.

Primitives, .model cards, and the manufacturer subcircuit

SPICE ships with a short list of built-in primitive devices — resistor, capacitor, inductor, diode, bipolar transistor, MOSFET, and a few more. Each is a letter in the netlist (R, C, L, D, Q, M) backed by a .model card that lists its parameters. A BJT's card, for instance, carries the current gain beta as BF, plus Is and dozens of others in the Gummel-Poon equations. You almost never type these by hand; you point at a model name and let a library file supply the numbers.

But a real op-amp is hundreds of transistors on one chip — you would never model it primitive by primitive. Instead the manufacturer hands you a subcircuit (a .subckt block): a little sealed network of primitives and controlled sources that, looked at from its pins, behaves like the real part — same gain, same input offset, same bandwidth. This is the manufacturer SPICE model, and you drop it in like a single component. Some are full transistor-level models (slow but faithful); many are leaner macromodels that mimic the externals quickly without simulating every internal device.

A simulation is only as good as its models

Here is the sentence to tattoo on your bench, the one this whole rung circles back to: SPICE solves the mathematics flawlessly, but it solves your model's mathematics. Feed it a wrong or oversimplified model and it will hand you a confident, beautiful, wrong answer. The classic trap is the ideal op-amp block: it has infinite gain, infinite gain-bandwidth, and no slew limit, so your transient plot shows a crisp square wave snapping rail to rail — an output the real chip could never produce. The sim is not lying; you simply asked it the wrong question by choosing a perfect model.

Even a perfect model knows nothing about your board. It cannot see the parasitics your layout will add — the stray capacitance between crowded traces, the lead inductance of a long wire, the resistance of a thin copper run. So simulation is brilliant at catching the cheap, embarrassing blunders early: a divider with the wrong ratio, a transistor biased into cutoff, a feedback loop wired with the wrong sign. It is blind, by construction, to anything your physical layout creates. That is not a flaw to fix — it is the dividing line between what you simulate and what you must build and measure.

There is a happier flip side, too. Because the model carries the real spread of behaviour, you can ask SPICE the questions a single bench prototype can never answer at once. A Monte-Carlo run rolls the dice on every part's tolerance hundreds of times and shows you the whole cloud of outcomes — does the design still pass when this resistor is high and that transistor's beta is low? A temperature sweep runs the same circuit from -40 to +85 degC. The model is what makes this possible: it does not just give you the typical part, it gives you the family.

Choosing and trusting models — a short workflow

Model fidelity is a dial, not a switch, and spinning it to maximum on every part is a beginner's mistake — full transistor-level models everywhere make the sim crawl and choke its solver. The craft is matching the model to the question. To check a bias point, a simple model is plenty; to predict distortion or stability margins, you want the manufacturer's real one. Here is a sane order of operations.

  1. Match the model to the question. Use a simple built-in model for rough bias and DC checks; reach for the full manufacturer model only for the parts whose detailed behaviour the design actually depends on.
  2. Fetch the real model for critical parts. Download the vendor's .subckt from the product page, read its header for what it does and does not include, and confirm the pin order matches your netlist.
  3. Sanity-check against hand math. Run the operating point and compare it to a back-of-envelope estimate — a divider ratio, an LED resistor, a bias current. If they disagree wildly, suspect the model or a wiring slip before you trust the plot.
  4. Stress the family, not just the typical part. Sweep tolerances with Monte-Carlo and sweep temperature, so a design that passes on paper still passes across the spread of real components.
  5. Treat the result as a strong hint, then build and measure. The sim has caught the cheap blunders; the bench will catch the layout and parasitics it never could. Let the two cross-check each other.

Hold onto the one idea that outlasts every tool version: a model is a deliberate, useful simplification, and your job is to know which simplifications it made. That mindset carries straight into the final guide of this rung, where a circuit that is correctly described still refuses to converge — because even a perfect model can hand the solver a knot of equations it struggles to untie.