It is a well-known fact that verification consumes approximately 70% time of the product cycle ^[1] and as per a survey conducted in 2018, verification engineers spend around 44% of their time debugging than any other activity ^[2]. An increase in the complexity of SoC leads to an increase in the number of components used in the verification environment, which results in a bulky log file as there are several information getting printed from these components. It becomes imperative to refine these logs as they are one of the most used means of debugging. This gives rise to the need of developing a custom printer that efficiently prints useful information for debugging. Custom transaction printers, known as xaction_custom_printer, is a customized printer that helps improve the efficiency in debugging, reducing the log size, improves readability, and thereby improves the overall productivity.

With the increasing area and complexity of the system-on-chip(SoC) design, there is a huge responsibility and workload on verification, making it the bottleneck of the entire SoC design flow ^[3]. Because veri?cation is all about checking the correctness of the design, one of the most critical parts of any veri?cation environment is the expected output calculation. There are a lot of verification components sitting on top of each block of such SoCs, and each design verification component generally consists of a monitor. These expected and actual outputs are observed by the monitor, which directly/indirectly prints this information in the log.

A considerable amount of time is spent by the design verification engineers on debugging if there is any discrepancy between actual output and the expected output. Despite the verbosity mechanism, verification engineers need minimal messages for debugging, as usually there are exceptionally long logs having exhaustive transaction packets. In order to address this issue, xaction_custom_printer was developed.

Section 2 explains how custom transition printer addresses the problems faced by verification engineers and thus the need for this component. Section 3 showcases the basic idea of how the component was developed. Section 4 shows the two ways in which this custom transaction printer can be used along with some piece of code for better understanding. Section 5 highlights the advantages of the custom transaction printer over line, tree and table printer using a generic transaction packet.

Why Do We Need the Custom Transaction Printer?

During the verification process, especially in the initial phase, when the RTL design is not mature, there could be many failures that may occur during testing. The engineer can identify the cause of failures through the log files. More often than not, an engineer needs to look at the transaction packet to look at the status of certain variables at a particular timestamp. Ideally, there are hundreds of such packets printed in the log file for a test. 

Taking an example of a packet of any protocol, it contains a lot of information like address, read address, write data, read data, operation (read/write), and mode (single/burst). At least one of these variable in a packet could have an array. For the cases when the array size ranges from few tens to few hundreds, the log file becomes very bulky with these packets printed several times. Along with this, the debugging process involves spending a considerable amount of time going through these logs. In these logs, the transition packet from the component gets printed very frequently and displays the data stored in them at different timestamp whenever they are called from the component. In order to debug, a user would need to go back and forth in the log when the logs will have a large array size while using the uvm_default_table_printer.

The SystemVerilog UVM contains a uvm_printer class, which provides an interface for printing uvm_objects in various formats. Subtypes of uvm_printer implement different print formats, or policies. These Subtypes include uvm_printer, uvm_line_printer, uvm_tree_printer, uvm_table_printer. A user-defined printer has been developed by us which will work on removing the shortcomings of the uvm_table_printer.

xaction_custom_printer is extended from uvm_printer and the output format of the printer looks like a mixture of uvm_table_printer and uvm_line_printer and thus combines the advantages of both. xaction_custom_printer concisely shows the packet displaying Name and Value of a variable in a well-partitioned way like a table printer and in multiple lines which resembles the line printer to some extent.

The output of this printer is available in a single line up-to some pre-defined character, and it gets continued in different lines after that. This style of output becomes easy to read where there is an array having a huge size. If the same array was printed in uvm_table_printer, the engineer would need to scroll through the log up and down many times. Since it is in a single line, it does not need to go up and down multiple times. The format of the printer allows clear visibility to the name and value of the variables which is all that is needed to debug.

How is this Printer Developed?

In order to develop a custom printer, the required format of printing was programmed in the emit() function, which overrides the same function of the parent class (uvm_printer). Pictorial representation of the basic idea of how the component was developed is shown here.

Fig 1. Top Level Idea of how Custom Transaction Printer was developed