Introduction

Digital Design's own introduction already used the word once, in passing: "Verification / UVM cover how to prove the RTL you wrote matches the design you intended." Every page up to this point on this site has been about building — a circuit, a line of RTL, a class, a testbench, a standardized environment. This topic is about the different question underneath all of that building: how do you actually know it's correct, how do you plan the effort to find out, and how do you decide when you've looked hard enough.

Verification vs. validation — a real distinction, not a synonym pair

The two words get used interchangeably in casual conversation, but they ask genuinely different questions, a distinction traced back to Barry Boehm's 1979 formulation and since formalized in IEEE 1012:

• Verification asks: are we building the product right? — does the design conform to its own specification, checked continuously during development through simulation and emulation.
• Validation asks: are we building the right product? — does the finished chip actually meet the real operational needs of whoever uses it, checked with real hardware, real interfaces, real software drivers.

A design can pass verification completely — every line of its specification satisfied, every testbench green — and still fail validation. A concrete, real example: an HDMI 2.0 receiver that passed every spec-conformance check in simulation, only for a validation lab to discover that a specific real transmitter, unexpectedly reconfiguring itself to 480p mid-session, exposed an interaction neither device's specification anticipated. Both chips individually met their specs. The two together, in the real world, didn't behave as intended — a gap only validation, not verification, could ever have caught.

This topic is entirely about verification — the specification-conformance question, checked pre-silicon. Validation (post-silicon, real hardware, real use) is a genuinely different discipline this topic doesn't cover.

The two words' roots actually reflect the distinction directly: verification shares a root with veritas — truth, correctness against a stated specification; validation comes from valere — to be worthy of, fit for actual use. "Right by the spec" versus "worthy of real use" isn't just a modern rephrasing — it's baked into where the two words came from.

Where this topic sits relative to everything else on this site

• SystemVerilog (complete) teaches the language mechanics verification code is written in.
• Testbench (complete) teaches how to architect a verification environment by hand, in plain SystemVerilog.
• UVM (complete) teaches the standardized version of that same architecture.
• This topic doesn't teach how to write any of that code again. It sits one level above all three, answering questions none of them do: what counts as "done," what a real verification plan document contains, what distinct kinds of verification a real front-end flow includes beyond functional simulation, and how a team actually decides a design is ready to tape out.

What's ahead

Section B covers coverage-driven verification as a named methodology — the loop, code coverage, functional coverage strategy, and closure. Section C covers formal verification. Section D — the newest addition to this plan — surveys the distinct, specialized verification domains a real flow includes beyond ordinary functional simulation: clock and reset domain crossing, RTL linting, gate-level simulation, power-aware verification, and timing verification. Section E covers the process itself: planning, regression, and signoff. Section F closes with the verification IP ecosystem and a capstone.

What's next

Before any of that, the next page makes the economic case for why verification effort is worth its cost at all — and why when a bug is found matters as much as whether it's found, using one of the most expensive bugs in the industry's history as the illustration.