Classical Verification
Verifying correctness empirically through testing, simulation, and coverage, the practical counterpart to formal (proof-based) verification.
Classical verification checks that a system behaves correctly by exercising it: running many inputs through it, comparing the outputs against expectations, and measuring how much of the design the tests actually reached. Where formal verification tries to prove the absence of bugs, classical verification hunts for their presence.
Why I’m digging in
- It is what ships almost every real system. Formal methods are powerful but costly, and classical verification is the default workhorse.
What I want to understand
- Simulation-based functional verification: testbenches, stimulus, and checking behavior against a reference model.
- Constrained-random and coverage-driven verification, and what “coverage” actually guarantees (and what it does not).
- The hardware methodology (UVM) versus the software analog (unit, integration, property-based, and fuzz testing).
- Where classical and formal verification complement each other inside a real flow.
Starting points
- Coverage-driven verification, and the difference between functional and code coverage.
- Property-based testing (QuickCheck, Hypothesis) as a bridge toward formal thinking.
- Fuzzing (AFL, libFuzzer) as automated bug-finding.
- UVM as the standard hardware verification methodology, for the hardware side.