overwrite report_catcher

[Gunther]

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

return;

end

...

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);

end

endfunction

Edited October 15, 2012 by Gunther
added excerpt from source code

[petermonsson]

Hi,

I've reported the bug for you: http://www.eda.org/svdb/view.php?id=4363

Best Regards

Peter

[Gunther]

I uploaded a fixed server to the contributions section. Compile package and use with

ens_report_server_pkg::ens_report_server:install_server();

[jadec]

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.

[uwes]

yes, its kind of a chicken-and-egg problem. with the macros we do decisions very early to improve performance. this however may conflict with the late changes to the message properties.

/uwe

[Gunther]

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.