Why should uvm_transaction be derived from uvm_object?

UVM
1

I’m kind of new to UVM. So have the following basic questions. Please help.

  1. The difference between uvm_object and uvm_component is that uvm_comp is derived from uvm_report_obj (which is derived from uvm_obj) along with additional capabilities (like hierarchy, phasing, config, factory etc) added. - Is my understanding right?
  2. Why should there be a new element called uvm_component. I mean why all the capabilites added in the uvm_component were not just added to uvm_object - will this not simplify having additional code (for lack of a better word)?
  3. Why should a uvm_transaction class be an uvm_object? Is it that a transaction does not need the additional functions of a uvm_component?

Kindly help with your answers.

Thanks.

2

One of the key principals in Software Engineering is the Separation of Concerns. The simple explanation is we don’t want to put everything in one class object for better maintenance, performance and potential re-use. The practical answer is that it is much more efficient this way. A test may create thousands of transaction, and we don’t want overburden the construction of these transactions with data structures they don’t need.

3

I think Dave has already replied to this in the most accurate possible way - separation of concerns!

Simply put, UVM testbenches are built from classes derived from the uvm_component base class. They are building blocks mostly of similar types - drivers, monitors, agents - require hierarchy, phasing mechanisms, configuring capabilities etc.,. UVM library helps end users by providing standard methods (embedded in uvm_component) to support these functional requirements.

On the other hand the transactions and configs are end-user-specific. There is no requirement for standardization there. All it needs is hooks for sequencers and body method, which one can implement as per their specific needs. Sequence layering is used for complex sequences but it too never requires hierarchy methods or phasing methods or any of the component-specific methods.

UVM thus helps here by keeping the hierarchy structures and data structures separate, aiding in building simpler, manageable and uncomplicated testbenches.

4

In reply to Sushrut Veerapur:

I would not exactly put it that way - all classes you write for a testbench are end-user-specific and all classes need some level of standardization, like copy, clone, print, factory registration, etc.