Thursday, May 28, 2009

Simplifying Management of Debug Statements

The importance of debug statements or simulation messages cannot be overstated in the context of efficient simulation process management. All of the components of a typical testbench such as transactors, assertions, monitors, scoreboards, and testcases use messages to indicate progress, important events, warnings, errors or potential efforts, and abnormal or normal completion of simulation. These indicators along with additional information to help diagnose the problems play a huge role in efficient simulation process management.

A common practice as used in the context of Verilog or VHDL simulation management is to either implement a simulation logging module with appropriate tasks to indicate notes, warnings, and errors or ensure results by parsing simulation output.

An implementation of logging module helps simulation keep track of its own progress and allows consistency of messages coming from various sources. However, this needs to be carefully thought out given a number of different possible sources of these messages in a given simulation environment, different severities associated with these debug messages, and multiple message types associated with each source. Any implementation of consistent and robust simulation messaging service requires a lot of effort and careful thinking to help enable efficient simulation process management.

It is great to see that all of this has been captured in the construction of vmm_log class (think of it as a module for reporting events and important occurrences) in VMM thus allowing to keep our focus on the main simulation tasks i.e., creation of appropriate testcases to reach the goals of functional coverage. Several convenient macros have been created simplifying use of the vmm_log class to report notes, warnings, errors, debug messages, and fatal issues.

For example, if you are working with the verification of PCI interface where data link layer implements sequencing of transaction layer packets and protects the contents of the packets using a 32-bit CRC. You want to be kept informed of the number of packets received so far and when computed CRC does not match received CRC, you will like to issue an error message. These two types of messages can be serviced as follows:

`vmm_note(log, $psprintf(“Received TLP packet number %d at time %d”, pcount, $time));
:
:
if (computedCRC != receivedCRC)
`vmm_error (log, $psprintf (“PCIXactor:Received CRC %h does not match computed CRC %h for packet number %d at time %d”, receivedCRC, computedCRC, pCount, $time) );

While transfer of packets are happening at one interface, we could be also be monitoring events to ensure adherence to the protocol. For example, a target must assert DEVSEL before any other response within 1 to 3 clocks following the address phase or else an error could be indicated as follows:

`vmm_error(log, $psprintf(“PCIChecker: At time %d the target erroneously asserted STOP or TRDY before asserting DEVSEL”, $time));

In the code examples above, log is simply an instance of vmm_log class. The underlying VMM infrastructure has several built-in handles and one of them counts message as an error if the logging severity is set to error. As a result, in our example, PCI errors would automatically increment the error count and simulation can be aborted when combined errors from different sources exceed certain threshold.

This simplifies simulation process management immensely. There is consistent messaging from different components of testbench while providing complete programmability of message types and severities along with typical simulation handles used in simulation process.

As a verification consultant, I always come across engineers who have been successfully doing verification using Verilog over the years and question any switch of methodology given the TTM pressures they face with every product. They are aware of some of limitations of their current methodology but want clear pointers to the features of any new methodology that help alleviate existing pain points. Being a long time Verilog user myself, I think VMM’s logging infrastructure is one such pointer. It is simple yet very effective in improving the overall simulation process management.

It will be great to hear about your experiences with management of debug statements during the course of verification process and the importance it plays in overall verification efficiency.