A network chip passes every test in its verification plan, tapes out, and returns from the factory. Some parts fail on the tester because of a dust particle on one wafer. The parts that pass are shipped, and customers report that under real traffic the chip drops packets when a link flaps, a situation the specification never described. Three different things went wrong, and three different activities were supposed to catch them.
What exactly are verification, validation and test, and what does each one promise?
The obvious answer is that they are all "testing": you run the design and check it works. Treating them as one activity hides the fact that each asks a different question against a different reference. A team that verifies perfectly against a wrong specification ships a correct implementation of the wrong thing. A team that validates the product in the lab cannot tell whether a failing part is a design bug or a manufacturing defect. Each question needs its own evidence.
Activity | Question | Checked against | When |
|---|---|---|---|
Verification | Did we build the design right? | The specification | Before tape-out, on RTL and models (and continued in silicon) |
Validation | Did we build the right thing? | The real use: customers, software, systems | From architecture through silicon, with real workloads |
Manufacturing test | Was this particular chip made correctly? | The verified design itself | On every fabricated part, on a tester |
IEEE 1012 draws the first distinction formally: verification is evidence that each stage's product conforms to its requirements, validation is evidence that the product satisfies its intended use (fact V3). Manufacturing test assumes the design is right and looks for physical defects in each part.
Different failures: a spec gap escapes verification by definition, because verification only checks against the spec. Only validation can find it.
Different owners and tools: verification uses simulation, formal and emulation; validation uses software, systems and customer workloads; manufacturing test uses scan, built-in self-test and testers (the DFT course).
Different stopping rules: verification signs off on coverage of the specification; manufacturing test on fault coverage of the netlist; validation on readiness for real use.
This course is about verification, with validation entering where it feeds back into the specification and in post-silicon work (Part 11).
Activity | Typical evidence |
|---|---|
Verification | Verification plan, assertions, scoreboards, coverage, formal proofs, sign-off review |
Validation | Architecture models, software running on emulators and prototypes, silicon in reference systems |
Manufacturing test | Scan and ATPG patterns, memory built-in self-test, tester programs (see the DFT course) |
The opening chip (illustrative) shows all three failures. The dust particle was manufacturing test's job, and the tester caught it. The packet drops on link flaps were a specification gap: the specification never said what to do when a link went down mid-packet, so verification, checking against that specification, had nothing to check. A validation run with real link-flap traffic on an emulator would have exposed it. The fix was a specification change, a new verification rule, and a validation scenario added to every future project.
Validation: the design conforms to the specification, so verification passed; the specification did not match the real need.
No: if the design is correct and only some parts fail, it is a manufacturing defect, which manufacturing test exists to screen.
Verification: built right, against the specification. Validation: the right thing, against the real need.
Manufacturing test checks each fabricated part against the verified design.
In a post-mortem, ask which of the three should have caught the escape; that decides the fix.