Jump to content

Using $display in UVM


Recommended Posts

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

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.

Guest
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.

 Share

×
×
  • Create New...