How UVM Callbacks Simplify Assertion Validation

By Akshay Sarup and Mark Olen

Assertions bring immediate benefits to the whole design and verification cycle; thus any challenges engineers face in coding and testing them are worth resolving.

When a large number of assertions are to be validated, callbacks save time by eliminating the need to code a new sequence for each scenario. Callbacks also provide more dynamic and fine-grained control, including which packets and how many packets will be injected with an error.

A callback in UVM is a mechanism for changing the behavior of a verification component (such as a driver or monitor) without actually changing the code of the component. Callbacks allow for the creation of nuanced and complex stimulus creation with ease and are, hence, instrumental for assertion verification.

This article covers how callbacks implemented in Questa Verification IP can be used for assertion validation in designs using the PCIe and other packet-based protocols.

Fig. 1: The basic sequence of events that take place when callbacks are enabled in an agent.

Assertion verification is usually an integral part of the verification IP development cycle. The first step involves coding the assertions. The second step validates the assertions by creating scenarios that fully exercise the assertions to ensure they do not fire under intended design behavior and do fire under erroneous scenarios.

Callbacks can be very beneficial in the scenario-generation step since the verification engineer does not have to write additional tests. Instead they enable callbacks to modify the original stimulus in order to create interesting scenarios. This is achieved by simply extending the callback class to override the virtual method (do_callback(...)) that gets called when a sequence item is executed by the BFM. This is particularly useful in packet-based protocols, such as PCIe, where packet fields need to be corrupted and callbacks provide fine-grained control to do so.

The job of the validation engineer is to make sure that the assertions are validated in every relevant scenario. Callbacks can be of extreme importance when assertion validation is carried out by manipulating the fields of a sequence item or by initiating a sequence item in a state in which it is not allowed. Callbacks speed up assertion validation by providing the entire structure for such manipulation in a UVM testbench, with minimal updates and no interaction with the existing sequences responsible for generating the sequence items.

For a layered protocol like PCIe, where communication between the transmitter and receiver elements takes place via structures known as packets, the use of callbacks for assertion validation improves efficacy significantly. Using verification IP, the packet information can be modified via callbacks and all packet-based assertions can be easily verified by making use of this mechanism. Now let’s take a look at a scenario from each of the transaction, data link, and physical layer packets.

Case 1: Transaction Layer Based Callbacks

The high-level transactions occurring at the device core are known as transaction layer packets (TLP). Verification IP, such as Questa Verification IP, allows all fields of a TLP (both request and completion TLPs) to be altered. If users want to validate an assertion related to the fields of a TLP, they can simply do so by corrupting the TLP fields via a callback.

For example, the PCIe protocol states that for a request of “length = 1 DW” the value of the Last Byte Enable field should be zero; where Last Byte Enable is the Byte Enable value for the last DWORD of the request. In simulation, if users want to inject this error to every Memory Write packet of length 1 DW, then they may do so as illustrated in figure 2.

Fig. 2: Populating the do_callback method. tlp is the instance of the TLP sequence item.

Case 2: Data Link Layer Based Callbacks

Data link layer packets (DLLP) are used for a variety of purposes; such as ensuring the integrity of TLPs, flow control, and power management. Just as for TLPs, callbacks can be used to inject errors in DLLP packets. For instance, lcrc is used for checking the data integrity of TLPs and DLLPs. lcrc is appended in the TLP at the data link layer (DLL). If the value of the lcrc attached with a packet is not the same as the calculated value, then it is a protocol violation. This incorrect behavior, or assertion firing, can be verified, as illustrated in figure 3.

Fig. 3: Populating the do_callback method. tl_to_dll is an instance of the TLP sequence item at the DLL.

Case 3: Physical Layer Based Callbacks

Perhaps the most efficient use of callbacks comes from modifying ordered set fields. In the cases of DLLPs and TLPs, a packet can still be executed via a sequence once linkup is achieved. But using a sequence to inject an error into an ordered set before linkup can be more convoluted and more susceptible to errors because the ordered set rules change with each LTSSM state. Callbacks, on the other hand, allow the user to inject an error in a much more controlled way. For instance, if a control SKP ordered set is to be sent in place of a TS2 OS, one can easily use callbacks. And hence this invalid protocol scenario can be easily validated via callbacks, as illustrated in Figure 4.

Fig. 4: do_callback method populated to replace TS2 OS with CTRL_SKP in Recovery RcvrCfg state at Gen3 speed.

As can be seen, when a large number of assertions are to be validated, callbacks save time by making sure the engineer does not have to code a new sequence for each scenario. For a fuller treatment on how callbacks can help you accelerate assertion validation, download the whitepaper, Simplifying Assertion Validation Using UVM Callbacks.

Akshay Sarup is a Product Engineer for CXL and PCIe at Mentor, A Siemens Business, focusing on deployment and product definition of Questa Verification IP. Sarup has over 20 years of experience in the functional verification domain, with a background in developing industry standard interface protocols using the UVM methodology.

Mark Olen is the Product Marketing Group Manager for the ICVS Division at Mentor, A Siemens Business. His team is responsible for product management and marketing of Mentor’s Enterprise Verification Platform, including simulation, formal verification, verification IP, portable stimulus generation, unified verification management, and common debug technology. Olen has spent over 30 years in sales, marketing, and management positions in the semiconductor design, manufacturing, and test industries. He graduated from the Massachusetts Institute of Technology.