In Verilog, we all have used $display, $monitor, $write & $strobe System Tasks very frequently as part of our Testbench. Although all of these System Tasks are used with the purpose of reporting various different states of the desired elements with-in your environment yet their purpose differs from each other.

Without going into detail, lets have a quick recap about these Verilog Reporting System Tasks:

1. $display – Prints the message whenever the statement is executed & a newline is automatically added.
2. $monitor – Keeps running as a background process for the desired elements & prints the message as soon as any of the desired element changes.
3. $write – Similar to $display, except that no newline is added.
4. $strobe – Similar to $display, except that message is delayed to be printed until all the simulation events in the current simulation cycle have executed.

For detailed information about these System Tasks please refer any text book or available online material.

We are also familiar with “`ifdef DEBUG” construct in Verilog which we usually in-corporate in our Testbench environment to provide the ease of debugging or debug capability. But the challenge is to re-compile the whole RTL again to activate it which consumes time, energy & resources. Mostly above mentioned System Tasks are used to be part of `ifdef DEBUG construct with different set of desired components & elements which helps to debug the possible issue if it occurs.

UVM Reporting:

UVM Reporting or Messaging has a rich set of message-display commands & methods to alter the numbers & types of messages that are displayed without re-compilation of the design. UVM Reporting also includes the ability to mask or change the severity of the message to adapt the required environment condition.

UVM Reporting has the concepts of Severity, Verbosity and Simulation Handing Behavior. Each of them can be independently specified and controlled. Now lets see what each of these indicates:

• Severity
  • Severity indicates importance
  • Examples are Fatal, Error, Warning & Info
• Verbosity
  • Verbosity indicates filter level
  • Examples are None, Low, Medium, High, Full & Debug
• Simulation Handling Behavior
  • Simulation handling behavior controls simulator behavior
  • Examples are Exit, Count, Display, Log, Call Hook & No Action

Simulation Handling Behavior in-fact is the Action taken by the Simulator which is dependent on Severity being produced by the Verification Environment. We’ll see more details shortly about it.

Embed Report Messages:

UVM Reporting provides Macros to embed report messages. Followings are the Macros to be used:

• `uvm_info(string ID, string MSG, verbosity);
• `uvm_error(string ID, string MSG);
• `uvm_warning(string ID, string MSG);
• `uvm_fatal(string ID, string MSG);

From the syntax of the above mentioned Macros it is very well evident how we can embed the message of our choice with a particular macro. The provided message ID helps in easy search, e.g. grep, in the simulation log. In addition, total count of a particular severity can also be seen using message ID at the end of the simulation log.

Lets see an example using a piece of UVM code on how to use the macros:

---

virtual function void build_phase(uvm_phase phase);
  super.build_phase(phase);
  `uvm_info("BUILD", $sformatf("%m"), UVM_HIGH);
  if(!cfg.randomize()) begin
    `uvm_fatal("CFG_ERROR", "Configuration Randomization Failed");
  end
endfunction: build_phase

---

Simulation Handling Behavior:

Now, when we’ve seen the usage of the different severity macros, let see the associated default simulator action with each of these Severity.

Table 1: Severity & Simulator Action Relationship

There are in total six Simulator behaviors which can be associated with a particular UVM Reporting Severity depending upon the users choice. Lets see the description for each of Simulation Actions:

Table 2: Simulator Behavior/Actions Description

Modify Simulator Default Action:

As mentioned above, UVM allows to bind a Reporting Severity with a particular valid Simulator Action. Usually its done inside the start_of_simulation() phase.

Actions can be assigned using set_report_*_action() functions. These can be done for one or all in the priority order from lowest to highest.

• set_report_severity_action(Severity, Action);[Lowest Priority]
• set_report_id_action(ID, Action);
• set_report_severity_id_action(Severity, ID, Action);[Highest Priority]

Example:

---

virtual function void start_of_simulation_phase (uvm_phase phase);
   set_report_severity_action(UVM_FATAL | UVM_LOG, UVM_DISPLAY);
   set_report_id_action("CFG_ERROR", UVM_NO_ACTION);
   set_report_severity_id_action(UVM_ERROR, "CFG_ERROR", UVM_EXIT);
endfunction: start_of_simulation_phase

---

Controlling Messages Verbosity:

Fundamentally the Verbosity level describes how verbose a Testbench can be. The default Verbosity is UVM_MEDIUM. There are different Verbosity level being supported by UVM. These are UVM_NONE, UVM_LOW, UVM_MEDIUM (Default), UVM_HIGH, UVM_FULL, UVM_DEBUG. In case of default Verbosity level i.e. UVM_MEDIUM, any messages with UVM_HIGH or above are filtered out.

Table 3: Different Verbosity Levels

Important Notes:

• A message with the Verbosity level UVM_NONE can not be disabled.
• `uvm_fatal, `uvm_error & `uvm_warning can not be filtered out via Verbosity level.

We can set the Verbosity level of a uvm_component individually or hierarchically using following commands:

drv.set_report_verbosity_level(UVM_HIGH);

env.set_report_verbosity_level_hier(UVM_FULL);

Setting Verbosity from Command Line:

One of the biggest advantage of the controlling Verbosity level from the command line is that we don’t need to re-compile the Design & Testbench if we want to change the generate different log information from our next simulation run.

The simplest option is the command line switch:

+UVM_VERBOSITY=<verbosity>

e.g.

% simv +UVM_VERBOSITY=UVM_HIGH

Now lets see below some more advanced Verbosity setting from the command line:

If you find the messages from a simulation run is extremely verbose, the simulation can be re-run with command line switches to filter some of the noise that appears on the our screen and log:

+uvm_set_verbosity=<comp>,<id>,<verbosity>,<phase>

e.g.

To change the verbosity level to UVM_LOW for the uvm_test_top.env.agnt.drvr instance with ID as DRV during the run phase, which would suppress all the messages with verbosity setting of UVM_MEDIUM or higher, execute the following command:

% simv +UVM_TESTNAME=test1  +uvm_set_verbosity=uvm_test_top.env.agnt.drvr,DRV,UVM_LOW,run

---

With this I’ll pen down here currently on UVM Reporting. I hope & believe the above discussion should make you comfortable using various concepts like UVM reporting Macros, Severity, Simulation Action, Verbosity & How to take benefit of controlling Verbosity from the command line without re-compiling the whole Design cum Testbench. I wish you enjoyed your learning and time being spent on this blog.

See you soon with new article, till then enjoy every moment of your life..Take care!

Byee !! 🙂

---