Effective Reporting of UVM Transaction - Custom Transaction Printer
August 21, 2020
Story
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.
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
How to Use this Printer?
The user just needs to include the file in the package or file list to include in the compilation flow and needs to call it as a function. There are two methods of using this printer.
- Default printer mechanism - A user can set this printer as uvm_default_printer as shown in Figure 2 below, thus all the prints in the project/SoC will be printed in this format.
Fig 2. Setting custom transaction printer as uvm_default_printer
- Selective printer mechanism - A user can configure this printer for just selected blocks only by passing the printer in convert2string of transaction item in the sprint as shown in Figure 3 below.
Fig 3: Way to use xaction_custom_printer for the selected block
In order to print the packet with this printer, it can be done by calling this function as shown in Figure 4 below.
Fig 4: Way to use convert2string to print transaction item
A user can also print the transaction packet using Custom Transaction Printer such that the arrays are printed in a separate line and keep the scalar variables in the same line. This type of transaction packet printing mechanism would help the user to read the array content in a single go. An example of how this transaction packet would look like is shown in section 5.5
Illustration
Here is the example to demonstrate the superiority of xaction_custom_printer over the other three uvm_printer. In the example, we have taken a generic packet. The following variables are taken to explain the advantages of this custom printer over the default printer.
Fig 5: Generic packet (transaction item) in uvm_sequence_item
1.1 Output using the line printer
1.2 Output using the tree printer
5.3 Output using the table printer
5.4Output using the custom printer
5.5 Output using the custom printer with features of printing arrays in a separate line. 
Advantages of Custom Printer
- Shows the information needed most for debugging
- Reduces the log size
- Improves readability
- Saves time by improving debugging efficiency
- Concise appearance
Custom Transaction Printer is a component developed by us, at eInfochips to provide solution for one of the problems faced by verification engineers. The advantages of this customized printer over a built-in uvm printer are shown using a generic packet example.
References
[1] Khaled Salah, “A UVM-based smart functional verification platform: Concepts, pros, cons, and opportunities” In Design & Test Symposium (IDT), 2014 9th International, pp. 94-99. IEEE, 2014.
[2] Harry Foster, Part 8: 2018 Wilson Research Group Functional Verification Study - Where Verification Engineers Spend Their Time
[3] Khaled Salah, Hassan Mostafa “Constructing Effective UVM Testbench for DRAM Memory Controllers”
About the Author
Uzma Haque is working as ASIC Functional Verification Engineer in eInfochips, an Arrow Company with an experience of 3 years. She is proficient in SV and UVM based functional verification. She has worked on IP/ SoC level verification environment.
