The few of you who regularly read this blog, may have wondered what happened to my friend Coverage in the past 3 months. It turns out he has been on a worldwide quest to collect wisdom from verification experts near and far. The other day I bumped into him and he was clearly troubled. After some prodding he grudgingly admitted to his concerns. “People are amassing coverage data as if it was an inflation hedge”, he blurted. “Soon it will overwhelm them to the point where it will be difficult to extract useful information from it and they will start ignoring it”.
If you’re nostalgically inclined like me, you probably fondly remember the times when testbenches were nothing but initial blocks with assignments and forces. Alas, those days are long gone. The serenity of the static pure Verilog testbenches has been replaced by the turbulence of the dynamic SystemVerilog ones where objects come and go as they please. Granted they brought revolutionary progress to usability, re-usability, scalability, portability, flexibility but let’s not forget that we paid for all these “bilities” with a significant increase in testbench complexity. Let’s face it, verification engineers of yore had to “just” understand the design in order to do a magnificent job at verifying it whereas their modern day counterparts have to acquire significant object oriented design skills as well as ramp up on VMM, UVM, OVM, etc. before they even attempt to write a single line of verification code. Add to that the fact that design sizes grow faster than the US National Debt and that testbenches can’t afford to be left behind and you’ll see why the other day I popped this question to my friend: how do we know that the testbench works as we intended or in other words how do we test the testbench?