In Part 1 we said verification is a loop: drive inputs, predict the right output, compare, repeat. That loop can be run in more than one way, and each way trades off speed, confidence, and cost differently. Here are the three you'll actually run into.
Simulation-based verification
This is the one most beginners meet first, and the one this whole series is building toward. A simulator executes the RTL in software, cycle by cycle, against a testbench that drives inputs and checks outputs. Nothing is exhaustive here — you're only checking the specific scenarios your testbench happens to generate. But it's flexible, debuggable (you can look at any signal at any time), and fast to iterate on. Almost every verification role you'll interview for is, at its core, a simulation-based verification role — writing testbenches in SystemVerilog, usually with UVM, which is exactly why the rest of this series lives here.
Formal verification
Formal verification doesn't simulate anything. Instead, it uses mathematical proof techniques to check that a property holds for every possible input and every possible state — not just the ones a testbench happened to generate. You write a property, like "the FIFO's full and empty flags are never both asserted at once," and a formal tool either proves it holds for all reachable states, or gives you a specific counter-example where it doesn't.
The catch: formal tools struggle to scale to a full, complex design — the state space explodes. So formal verification is typically used on smaller, control-heavy blocks (arbiters, FIFOs, protocol-checking logic) where exhaustive proof is actually achievable, rather than on an entire SoC.
Emulation
A simulator running in software is orders of magnitude slower than real hardware. For a small block, that's fine. For a full SoC that needs to boot an operating system to be meaningfully tested, running that in a software simulator could take days for what should be seconds of real time. Emulation maps the design onto an FPGA-based or purpose-built hardware platform, so it runs close to real speed. That makes it possible to run software-level tests — booting firmware, running drivers — that would simply be impractical in simulation. The tradeoff is debug visibility: you don't get the same free, look-at-any-signal-anytime access that a simulator gives you.
| Method | Best at | Weak at |
|---|---|---|
| Simulation | Flexible, debuggable, targeted tests | Can't be exhaustive; slow for huge workloads |
| Formal | Exhaustive proof on smaller blocks | Doesn't scale to a full chip |
| Emulation | Near real-speed, software-level tests | Expensive setup, limited debug visibility |
Why real projects use more than one
None of these three subsumes the other two. A real verification plan typically uses simulation for the bulk of functional checking, formal for the handful of control-logic properties where an exhaustive guarantee is worth the setup cost, and emulation for the software-visible, system-level checks that simulation is simply too slow to attempt. Knowing which tool answers which question is itself a verification skill — and it's why job descriptions specify "UVM/SystemVerilog verification" separately from "formal verification engineer."
Takeaway
Simulation checks specific scenarios you thought to write. Formal checks every scenario, but only for logic small enough to prove. Emulation runs close to real speed, at the cost of debug visibility. This series focuses on simulation-based verification with UVM — the most common entry point into the field.