&quot;what I mean is that we regularly are manually looking through waveforms. At every stage of the flow, we are checking that our verification infrastructure is actually doing what it should to find bugs. Because a lot of the time, either we&#x27;ve stuffed up using the tool or the tool itself is stuffed.&quot;<p>Waveform-based verification is something I know nothing about. I haven&#x27;t seen it in any paper I&#x27;ve looked at. Is that what people do in logic analyzers and such? Do you have a link to a free reference discussing what people do with that stuff and how it&#x27;s used to verify digital designs? I really should have this info in mind and on hand if you all rely on it more than verification tools.<p>&quot;This is what happens with the UVM. A checker is written with a SystemVerilog interface by a third party or ourselves. &quot;<p>That makes sense.<p>&quot;If I am writing the prover, I know I probably threw a few bugs in there!&quot;<p>I like that you&#x27;re realistic. It&#x27;s how I used to look at code on a complex project. Even with Correct-by-Construction, I didn&#x27;t get to feel safe with my code: only wonder how obscure or unnecessarily simple a problem was left in it. I need to make a Philosoraptor meme along the lines of: &quot;Do we create coding schemes or does the code scheme against us?&quot; Haha.<p>&quot;If only it were all parallelised because it is slow as hell.&quot;<p>There&#x27;s the opportunity. Whether it can be acted on who knows. I do know so far that hardware is many blocks strung together with all kinds of tests that <i>should</i> be parallelizable. Now you&#x27;ve reinforced this potential in my mind. I have a trick for this but I&#x27;m holding off publishing it for now. Let&#x27;s just say it&#x27;s easier to parallelize stuff if one doesn&#x27;t force their implementation to be inherently sequential or even tied to CPU&#x27;s. And there&#x27;s a little-known, albeit alpha-quality, way of doing both at once. :)