uvm_report_object -- why only uvm_component based classed are derived from uvm_report and not uvm_sequence_item/uvm_transaction

[dips1000]

uvm_report_object  -- why only uvm_component based classed  are derived from uvm_report and not uvm_sequence_item/uvm_transaction 

 

Observation : 

uvm_component and all child classes are derived from uvm_report_object - and hence have uvm reporting function calls access by default 

however , uvm_sequence_item and its children are not derived from uvm_report_object and hence do not have reporting functions defined by default and uvm reporting functions are actually redefined in uvm_squence_item class 

 

Question : 

Why not derive the uvm_sequence_item or uvm_transaction class also derive from uvm_report_object in base  class implementation ? 

 

 

 

 

[David Black]

Simplistic answer: Because that is how the standards committee defined it originally, and a lot code now depends on this behavior.

Rationale answer: Because most issues revolve around the component hierarchy (what component is broken or causing this issue?). You can obtain the effect you may seeking by creating a bogus transaction component at the top-level and then use the `uvm_info_context variants to specify the controlling component. You may need more than one of these for some situations.

[dave_59]

This goes back all the way back to Mentor's AVM, before any official standard. "Components" are essentially long-lasting objects that get constructed at the beginning of the test. There are relatively few of them compared to "transaction" classes. There is considerable overhead in creating a report_object because each object has to maintain a database of report setting or knobs that would be too expensive for the magnitude of transaction that get created. 

You can always use the context of the sequencer (m_sequencer), or create an independent report object if you need to control the reporting of sequences separately.