Jump to content

overwrite report_catcher

Recommended Posts

When I write my own report_catcher to change the severity of a message and attach that catcher to an object, messages from that object have their severity changed correctly according to the rules of my catcher.

When I tried doing the same with changing verbosity I found that it didn't work. I eventually traced it down to the uvm_report_server's report() function. This filters messages with insufficient verbosity first and then calles the report_catcher. So when I run with UVM_MEDIUM and change the verbosity of a message from UVM_HIGH to UVM_MEDIUM in the catcher, it will be filtered with original verbosity before it reaches the catcher and therefore will not be displayed when it should.

Likewise, when changing from UVM_MEDIUM to UVM_HIGH, it passes the first verbosity check, is then modified by the catcher but then no further verbosity check is done, so it now has HIGH verbosity and should not be displayed but it does. Furthermore, if the verbosity check depends on the ID and the catcher changes the ID, that won't work either.

Am I barking up the wrong tree or is that indeed a bug in the uvm_report_server?

Attached is a patch which fixes the problem. This is for uvm-1.1c. Earlier versions of uvm are the same. All it does is moving the verbosity check from the beginning of the function to the end, after the catchers are called, just before the message is composed and output.

This is part of the uvm_report_server.svh from uvm-1.1c:

virtual function void report(...);


if(!client.uvm_report_enabled(verbosity_level, severity, id)) begin




report_ok = rh.run_hooks(...);

if(report_ok) begin

m = compose_message(severity, name, id, message, filename, line);

process_report(severity, name, id, message, a, f, filename,

line, m, verbosity_level, client);



Edited by Gunther
added excerpt from source code
Link to comment
Share on other sites

  • 4 weeks later...

This still may not be sufficient since the `uvm_* report macros filter the messages before calling report at all. This is a big performance boost since generating message text is often expensive.

What I've done in the past is to raise the component verbosity sufficiently for all the desired messages to get to the report catcher and then have it filter out the messages that should not be reported. If you're filter is based on tag, you can use the set_report_verbosity_level instead.

Link to comment
Share on other sites

  • 4 months later...

I just realized I hadn't answered this one.

That's a good point. Raising the component's verbosity sounds like a bit of a hack to me, but even without doing that it fixed half the problem. In my particular instance I was downgrading warnings to infos, so they are guaranteed to come through to the report catcher.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...