[prbs23]

I don't understand why fuzzing hardware is being presented as a new thing here... In silicon validation, constrained random testing has been the standard methodology for at least 10 years. With the complexity of modern CPUs, it's effectively impossible to validate the hardware _without_ using some kind of randomized testing, which looks a whole lot like fuzzing to me. What is new here? Or is this a case of someone outside the industry rediscovering known techniques.

[bartlettD]

The claim here is that "existing hardware fuzzers are inefficient in verifying processors because they make many static decisions disregarding the design complexity and the design space explored".

"To address this limitation of static strategies in fuzzers, we develop an approach to equip any hardware fuzzer with a dynamic decision-making technique, multi-armed bandit (MAB) algorithms." (From their paper: https://arxiv.org/pdf/2311.14594.pdf)

They're saying their fuzzer is faster and better at finding bugs than other fuzzing aproaches.

[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.