Replace "reporter" string with module hierarchy in reporting functions (UVM 1.1d)

UVM
1

It seems to me that whenever a uvm error/warning/info is reported in the log it will include the hierarchical location only if it was generated in the object tree (ex. uvm_test_top.env0.agent0.driver0). Now we’re leveraging uvm reporting also for SVA that are instantiated in the rtl so that we can easily maintain the same log post_processing for all errors and determine the pass/fail criteria.

The issue with this approach is that whenever the report_server is not able to find the object tree it will automatically assign the source to the ‘reporter’ instance instead, making it extremely hard to find where the fired assertion is located. For example we have assertions on synchronizers that are scattered around the rtl and having the name of the assertion is not sufficient to indicate where the error was.

Here’s an example of the error message:

ERROR: UVM_ERROR /home/me/myproj/src/sva/com_sync_toggle_if.sv(122) @ 196439.500ns: reporter [com_sync_toggle] posedge on d_toggle_i should generate a pulse on d_pulse_o

So I have two questions:

  1. how can I replace the reporter reference with the full module hierarchy?
  2. where, in the UVM 1.1d library the reporter name is defined? I have been searching through but failed to find where it is defined.
    → found the answer to 2. The “reporter” string is defined in the uvm_root class constructor.

BTW, I’m aware of the various articles that explain how to build a custom report server, but before going about building my own server I’d like to know whether there’s not already a simple way to override the reporter string with something more useful.

Thanks a lot,

Al

2

In reply to abasili:

Anytime you call uvm_report_error from anywhere other than a class derived from uvm_report_object, it picks up this global report object called reporter. You can create a local report object in the module/interface containing the assertions and use that object for all report settings and messages.

module my_assertions;
import uvm_pkg::*;
`include "uvm_macros.svh"

uvm_report_object log = new($sformatf("%m")); // %m gives hierarchal pathname to log object. 

assertion1: assert property (something) else `uvm_error_contex("assertion1","you failed",log)
endmodule
3

In reply to abasili:

  1. how can I replace the reporter reference with the full module hierarchy?

I found some workaround, albeit not really what I wanted to do, based on work posted here:

By redefining the macro we are using I can reformat the message in order to add the wanted information. That’s unfortunately not the same as replacing the ‘reporter’ string with the hierarchy. In order to do that I might need to do some string manipulation which is way to painful with SystemVerilog lack of regex support (and yes, I’m aware of uvm_re_match, it would have been nicer to have uvm_re_replace as well).

4

In reply to dave_59:

Thanks a lot Dave, indeed your proposal sounds much more interesting then mine!
I tried to use the context macro, but I did not think hard enough to figure out I could pass a newly created report_object with the name of the module hierarchy.

EDIT: while trying to implement your solution I bumped in a different problem that makes the implementation much harder then the solution I adopted. We have defines (sva_error/sva_warning) that are used by the RTL team to create assertions and their reporting, so in order to modify them throughout the code we need to make sure that each module they are used in we have a uvm_report_object declared, which makes it difficult to do by modifying the sva_error/warning definitions only. We need to ensure the uvm_report_object is instantiated once per module and it will be difficult to achieve this without modifying the RTL as well.

To make it more explicit, we have the following code at the moment:


    `define sva_error(id, msg) `uvm_error(id, $sformatf("%s -- scope: %m", msg))
    `define sva_warning(id, msg) `uvm_warning(id, $sformatf("%s -- scope: %m", msg))

which is used by the assertions.

5

In reply to abasili:

Yes, there are many possible approaches to this depending on who is inserting the assertions depending on their comfort level putting a class into RTL. You could hide it under a macro
`initialize_sva_messages if they lack the confidence to do it otherwise.

If you are not going to adopt any of the approaches that create separate report objects or components for each module, I might suggest you embed the scope into id instead of the msg. That way you can use wildcards when changing report settings

`define sva_error(id, msg) `uvm_error($sformatf("%m-%s", id, msg))