[Loq]

Fuzzing and constrained random, while both based on randomisation, are not the same thing.

A big problem of fuzzers from the point-of-view of hardware validation is that it's unclear what coverage guarantees they give. Would you tape out your processor design, once your fuzzer no longer finds bugs, if you had no idea about test coverage? OTOH, fuzzing has been very effective in software, so it is natural to ask if those gains can also be had for hardware.

[eYrKEC2]

The grandparent post is incorrect. H/w silicon validation or constrained random testing hasn't been the norm for 10 years, it's at least 20, which us when I first got into that industry.

And yes, we had coverage driven verification back in 2005 as well. No, we didn't "tape out" our CPUs until we'd hit our testing plan which was defined by coverage metrics.

P.s. pre-si verification had testing pipelines way back then before they became the norm in s/w.

[kramerger]

> we didn't "tape out" our CPUs until we'd hit our testing plan which was defined by coverage metrics.

Just because you reached the same coverage it doesn't mean your are doing the same thing or that you were equally efficient in reaching it.

Beside, as any tester can tell you coverage is not a fool-proof metric.

[RealiZM]

Coverage in hardware is different from coverage in software. Solid part of System Verilog deals with that plus part of UVM. Plus coverage from simulation and property checking (aka formal) can be used together.