Borrowing from software to use SystemVerilog test bench debug & analysis

Bindesh Patel and Amanda Hsiao

October 23, 2008

Bindesh Patel and Amanda Hsiao

Dumping data
The first thing that comes to mind when engineers examine or debug the dynamic behavior of their designs is waveform. Some debug tools have taken behavior analysis to a significantly advanced level by allowing engineers to examine dynamic activity within the context of the source code itself and to trace a specific behavior back in time with the push of a button.

This analysis relies on the well-understood notion of easily recording (dumping) value-change data from simulation. The data is usually recorded in a highly optimized, dedicated database, such as the Fast Signal Database (FSDB).

Once the simulation data has been recorded, tools accessing this database can provide specialized views and engines that automate and make more efficient the process of evaluating and debugging design behaviors. When debug tools also have access to the design source code, they can put two-and-two together to automatically trace to the root cause of problem behaviors. This state-of- the-art in design debug and analysis is well accepted today and continually evolving.

Unfortunately, this process is not applicable to testbenches. To start, there is really no concept of waveforms or value-changes in programmatic testbench code.

Instead, SystemVerilog testbenches have classes that can be created at any point in time with functions that are called to perform a particular task (such as drive a random transaction into the design). Most of these functions execute in zero-time. Hence the notion of value-changes and representation of these changes using traditional waveforms do not apply, at least not directly.

The SystemVerilog verification component is, for all intents and purposes, a software language. Designers and verification engineers alike rely on debug tools to understand how the design and verification environment is set up. Traditional hardware description languages (HDLs) are highly structured, and as such can be easily represented hierarchically in schematics or state diagrams.

Not only are these contextually appropriate for the task at hand, but they present information in a way that makes is possible for engineers to more easily comprehend.

By contrast, software programs like SystemVerilog and C++ have classes that are created, instantiated, and extended everywhere. For engineers, especially those that come from the hardware domain, it is no easy feat to make sense of it all. Thus, the burden now falls to debug tools, which are tasked with inferring data and creating static views that are both useful and intuitive.

Logging limitations
The obvious next question is: how are these verification challenges being addressed today? Studies show that SystemVerilog is becoming a widely adopted element of verification (testbench) methodologies. Today, there are two primary strategies employed to help engineers comprehend, analyze, and debug SystemVerilog testbench environments.

One approach uses the built-in support in the language for logging information. The two constructs employed are $display and printf, whether used directly or through a pre-packaged class library such as OVM or VMM.

Both allow engineers to log information to text files. The whole idea is to record some history into these log files, which can be analyzed after simulation to get a sense of what the testbench was doing through time. Remember, the design data can be recorded into the debug database for visualization and analysis in a debug tool.

However, for the testbench data, engineers must revert to the low-level text file logs, and then manually (and painfully) correlate to what the design is doing on the time axis. The result is a disparate flow that relies on low-tech, text-based recording of testbench activity as illustrated in Figure 1 below.

Figure 1: To help engineers comprehend, analyze, and debug SystemVerilog testbench environments, built-in support for logging information is useful. However, the result can become a disparate flow as shown.

Another strategy often employed by engineers is to use the simulator's interactive capability in a GDB debugger-like fashion. As with GDB debuggers for C/C++, engineers can set breakpoints as well as inspect variable values and stack traces at a particular time.

However, there are several drawbacks with this approach. First, the engineer has to know when and where to set breakpoints, so that the simulator stops at the simulation time and/or condition targeted for further probing. Often, this involves guesswork and requires several iterations to get to the exact point.

Moreover, to get to the breakpoint, the simulator run could take hours, or even worse, days because it has to simulate the whole environment up to that point. It is often not practical to consume valuable engineering resources waiting for the simulator to reach the desired breakpoint.