September 7, 2009 -- Imagine you just started to figure out part of a great mystery novel. You flip back a few pages to reconfirm a particular detail. Then, you leaf forward to find another clue, and suddenly…you’ve lost your place in the book. Imagine the mystery novel is about 100 times longer than War and Peace. This is what it’s like to replicate traditional debug methods for many of today’s complex communication protocols.

Anyone who has ever had to debug any type of pipelined design has suffered through this painstaking process. So you try to be really clever with multiple cursors in the waveform window. Then you carefully craft debug messages for fast regex matching in the log. But, eventually, you succumb to the cruel realization that a piece of scratch paper next to your computer is really the quickest way. Now throw in something like "out of order execution" and you start feeling dangerous urges to use dry erase markers on your computer screen. There must be a better way, right?

Somewhere along the way, someone took a step back and realized that we could separate the information being passed (e.g., address, data, and control) from the implementation details (i.e., pin wiggles). Transaction-level modeling (TLM) was born. TLM techniques are very common now for both modeling and verification, and, these days, most decent waveform viewers have some level of transaction viewing built-in.

Problem solved, right? Take a closer look at the steps involved to get those transaction boxes into your favorite waveform window. A recent DAC presentation touting the benefits of transaction-level debugging gave a "simple" example. It took a flow chart, a process diagram with Greek letters and subscripts, and multiple slides of code and comments to describe how to add the necessary attributes and relationships. The example also assumes the person doing all of this work has access to when the transactions begin and end. If this person is also the designer of the block generating the transactions, this might be reasonable. But in today’s world, where IP/ VIP-reuse is king, good luck trying to decipher where to peek and poke in the code to get your transaction annotations correct. Pass the scratch paper and dry erase marker, please.

Luckily, there now exists ready-to-use VIP that has this transaction debug view already built-in. By including "multi-view" components (MVC), this type of VIP concurrently provides all levels of abstraction in a single model, from the transaction view down to the pin wiggles. So, for example, you can simply drag and drop all the information you need directly into your waveform viewer.

In addition, all of these levels of abstraction are connected, enabling them to cross-highlight each other. If you click on a transaction, all of its signals from all of the associated phases will be highlighted for the times they are valid for that transaction, and vice versa — clicking on the transition of a control signal or a particular beat on a data bus highlights the transaction to which they belong.

Figure 1. Protocol stack recognition allows debugging at the appropriate level.

This can be illustrated by going a little deeper to see how this is done. For example, Questa MVC is a SystemVerilog VIP that provides an OVM 2.0 compliant interface. This interface typically connects two devices — usually a TLM and an RTL implementation, although combinations of TLM-TLM or RTL-RTL can also be done. A transaction issued from the TLM device is decomposed (driven or transacted) into wire-level activities that are detected by the RTL device, which in turn performs the desired operation. Conversely, MVCs can monitor the wire activities caused by the RTL device and recognize the corresponding transactions. Any low-level or high-level transaction transmitted or received is correlated with an OVM sequence item. All of these items are visible as separate graphical entities in the waveform window, showing the hierarchical relationship between each of the associated items and wires.

MVCs also allows another level of control for issuing transactions, in which case the TLM device works on lower-level transactions. For instance, any "write transaction" can be broken into smaller phases (or lower-level transactions), such as address, data burst, or data phases. Any such TLM master can initiate address and data phases individually, rather than initiating the write transactions as a whole. Similarly, in read transactions, the TLM master will initiate an address phase and then wait for the response from the RTL slave. The MVC packs the response from the slave and makes it available to the master, and it facilitates debug by automatically combining these phases into higher-level transactions. These transactions can be viewed in a waveform window that has the capability of cross-highlighting each transaction phase and the wires associated with it. Transactions are also available as a sequence item that can be used in any analysis components; such as a traffic monitor, scoreboard, or coverage collector.

Figure 2. Questa MVCs simplify debugging multi-phased, overlapping transaction streams.

Finally, MVCs can help debug buses and interfaces that it is not driving. For example, an MVC can sit as a monitor on an internal bus (such as, AXI, AHB, or OCP) and recognize and extract the transaction information and timing, then display it using the cross-highlighting capability. Questa MVCs can even color code the transactions differently if it is not the driver, which is exceptionally useful on multi-master shared buses.

Questa Multi-view components ease the verification process by providing DUT connection and protocol debugging at various levels of abstraction. By providing transaction viewing, they considerably accelerate the time-to-debug. Of course, as VIP they reduce testbench development time, performing the traditional tasks of traffic generation, protocol and coverage monitoring, and help you create reusable verification platforms that span all abstraction levels.

So bring on AXI with all of its multiple outstanding pipelined out-of-order interleaved burst beat goodness. Debugging with Questa MVCs means I now have time to go finish that mystery novel.

By Steve Chappell

and Pankaj Goel

Steve Chappell is a Senior Applications Engineer at Mentor Graphics. He has been designing and verifying (or helping others design and verify) hardware and software products in the Semiconductor IP and EDA industries for over twelve years. He holds BSEE and MSEE degrees, both from Stanford University.

Pankaj Goel is a Senior Member Technical Staff at Mentor Graphics, specializing in the development of Questa MVC and Questa Verification Library (QVL). He received his B.Tech from IP University Delhi.