SpringSoft turns the power of Verdi on SystemVerilog test benches

SystemVerilog was supposed to be such a boon to verification engineers. By providing a Verilog-like language with extensions that made it easy to write transactors, assertions, and checkers, the language was supposed to make it easy for Verilog-familiar hardware engineers to write the sorts of elaborate test benches that previously would have been done in collaboration with software engineers working in C++.

Unfortunately complexity, like Salmonella, has a way of surviving measures meant to defeat it. What has actually happened, according to SpringSoft North America president Scott Sandler, is that with the availability of SystemVerilog, test benches have become even more complex. "Test bench code is now often larger than the Verilog for the design itself," Sandler said. And he added that—worse yet for hardware folks who never were lovers of C++, classes, and inheritance—when test bench code moved to SystemVerilog it brought along with it concepts from the C++ world, such as class libraries, zero-delay functions, and dynamic functions, that are utterly foreign to hardware description. These constructs can make it extraordinarily difficult for verification engineers to understand just what the test bench is doing at a particular moment in simulation time.

So after all this work, Sandler said, we are nearly back where we started: a design in Verilog that can be thoroughly explored with the Verdi debug-enhancement environment, and a test-bench that, while it is now in SystemVerilog, is so full of software-engineering constructs that it is a huge undertaking to correlate what is going on in the hardware design with what is going on in the test bench.

It’s not been an unsolvable problem. You can embed traditional software-debug weapons, such as and printf(), in the test bench code, and build a print log as the test bench executes. This can give you some idea of how your experiment traversed the test bench code, including in what order it invoked dynamic functions. And if you are clever about just what you print, it can even give you some idea what was going on in the test bench data structures just then. What it can’t do, without a great deal of manual work, is tell you what was going on in the design under test at a particular point in the execution of the test bench.

SpringSoft has taken a shot at solving this problem. Their idea is to define a task, , that you can insert anywhere in your test bench code. This task, instead of sending the values of its arguments to a print log, sends the values, along with the current state of the test bench’s call stack, to Verdi’s internal Fast Signal Data Base (FSDB). There, they are correlated with the signal data coming from the device under test. So presto: you explore the FSDB with Verdi’s powerful analysis tools—which need no introduction here—and you have spread out before you the interaction of the test bench and the design.

To close the loop on this integration process, SpringSoft has extended Verdi to let it invoke an interactive simulation of the test bench code. In this way verification engineers can identify a point of interest in the test bench source code, invoke the simulator using the state captured by Verdi, and explore that point in the code without having to initialize the bench and run it all the way to this point.

Adding a single element to the already extensive SystemVerilog libraries and a link to a GDB-style software simulator might seem like trivial steps. But in this case, the result will be to create a bridge between the ability to examine the operation of the design and the ability to understand the real-time workings of the test bench. Given the already-cited growing complexity of said test benches, and therefore the odds that they will have at least as many problems as the design itself, this ability seems indispensable.