Say you write a piece of RTL — a small module, maybe a FIFO, maybe an arbiter. You simulate it once, feed it some inputs, and the output looks right. Does that mean it works?
Not really. It means it works for the one scenario you just tried. A real chip design has thousands of possible input combinations, timing relationships, and corner cases you didn't think to try. And once that design is sent to a foundry to be fabricated into silicon, there is no patch, no hotfix, no "we'll push an update." A bug found after fabrication can cost months of delay and, depending on the chip, a re-spin that runs into crores of rupees. That asymmetry — cheap to catch a bug before tape-out, extremely expensive to catch it after — is the entire reason verification exists.
"It compiles" is not the same claim as "it works"
A design engineer's job is to describe hardware behavior in a language like Verilog, in a way that a synthesis tool can turn into logic gates. That description can be perfectly synthesizable, produce no compiler warnings, and still be wrong — wrong meaning it doesn't do what the specification actually asked for. Off-by-one errors in a counter. A flag that gets set one cycle too early. A corner case where two conditions happen on the exact same clock edge that the designer didn't picture while writing the code. None of these show up as a "syntax error." They show up as silicon that doesn't behave, months after the code was written.
Verification is the discipline built around finding exactly this category of problem — not "does this parse," but "does this do the right thing, in every situation the real world can throw at it" — before that description becomes an unchangeable piece of silicon.
Why the designer doesn't just check their own work
It's tempting to ask: if the designer already tested their own module, why does a separate person need to re-check it? Two reasons, and both matter.
- Blind spots are personal. Whoever writes the RTL is testing against the mental model they used to write it. If their mental model missed a case, their tests will miss it too — the bug and the blind spot come from the same place.
- Verification is a different skill, practiced independently. A verification engineer's job is to build an environment that generates inputs the designer might never have thought to try, and to independently check the outputs against what the specification says should happen — not against what the RTL happens to do.
In an industry setting, these are usually two different people, sometimes two different teams, specifically so that one person's assumptions don't quietly become the other person's blind spot too.
What "verification" actually means
Strip away the tools and the acronyms, and verification is just this loop, repeated until confidence is high enough to tape out:
- Build an environment that can drive realistic (and unrealistic — edge-case) inputs into the design.
- Independently predict what the correct output should be for those inputs.
- Compare the design's actual output against that prediction.
- When they don't match, that's a bug. Report it, the designer fixes it, and you go again.
- Keep track of what you've actually exercised — so "we tested it" means something more specific than "we ran it a few times."
Every tool and methodology in the rest of this series — SystemVerilog, UVM, constrained-random stimulus, functional coverage — exists to make one or more of those five steps faster, more repeatable, and more trustworthy at the scale of a real chip. None of them replace the loop. They just make it practical to run thousands of times instead of a handful.
Takeaway
Verification exists because "the code compiles and one test passed" is a very weak claim, and silicon punishes weak claims expensively. The whole discipline is built to turn that weak claim into a strong, evidence-backed one — before it's too late to fix.
Next: verification isn't one technique — simulation, formal, and emulation each check a different kind of claim, and a real project usually needs more than one of them.