Using $display in UVM

[cliffc]

Hi, All -

 

Pardon the question, but I thought I had seen documentation that suggested using $display to only print headers and trailers when printing using UVM, but I cannot find a reference for this recomendation.

 

BTW - I highly disagree with any usage of $display in UVM since it is not under UVM_VERBOSITY control.

 

Am I completely mistaken or has anyone else seen recommended usage of $display for UVM table headers and trailers. If anyone knows of such a reference I would be greatful if you would post it.

 

Thanks. This is not a critical issue, obviously!

 

Regards - Cliff Cummings

 

[dave_59]

Where did you see this?

 

The SystemC -> AVM -> OVM -> UVM methodologies have gone to great efforts to get everyone using a common messaging system. It's not just the Verbosity - it's all the the filters, catchers, and callback mechanisms around the messaging system that are subverted when you use $display. Many tool vendors have instrumented the UVM reporting mechanism to interact with their debugging environments, and using simple $displays will also subvert those efforts.

 

Dave

[cliffc]

Hi, Dave -

 

I agree. UVM Guideline #1 - quit using $display!

 

I am still trying to find where I read the part about using $display for table headers (and again, I disagree. You should not use $display ... period!)

 

Regards - Cliff

[uwes]

Hi, All -

 

Pardon the question, but I thought I had seen documentation that suggested using $display to only print headers and trailers when printing using UVM, but I cannot find a reference for this recomendation.

 

BTW - I highly disagree with any usage of $display in UVM since it is not under UVM_VERBOSITY control.

 

Am I completely mistaken or has anyone else seen recommended usage of $display for UVM table headers and trailers. If anyone knows of such a reference I would be greatful if you would post it.

 

Thanks. This is not a critical issue, obviously!

 

Regards - Cliff Cummings

 

 

hi,

 

prior to uvm12 the library code did contain a mix of raw $display,$write and messages routed through uvm messaging. with uvm12 ALL uvm library code is routed through the uvm messaging and can be affected with uvm message controls.

 

btw1: $display makes sense for instance in certain message callback functions and other special situations to avoid endless loops. that might happen through recursion and there is no guard in uvm to avoid this. 

 

btw2: the whole universe of verbosities, callbacks, severities, catchers, actions,... isnt that easy to use especially when it comes to adjusting/filtering and i could see that as a driver to use $display...

 

 

/uwe

[David Black]

Could you illustrate a specific example where $write was required? Unless you are writing catchers, I have a hard time seeing this. 99.9999% of the time, the built-in UVM reporting mechanisms should work.

[uwes]

hi,

 

in catchers, own report_server::(compose|execute)_report_message, own recording backend, the uvm_components::report_*_hook functions (and probably more places) it is problematic to invoke uvm_report_*. basically all places potentially invoked during message processing should not emit a new message while the old is processed.

 

/uwe

[dave_59]

Other than catchers, I do not recommend any user modifications to the reporting system. Even though the UVM allows it, you will get into trouble if everyone starts doing this and then you try to integrate different groups of VIP each with their own modifications.

 

With catchers, you can modify and add to the message that will be emitted - there is no need for $display. And you can still use uvm_report_ messages as long as you can ensure there is no recursion in your catchers.