Difference Between UVM_OBJECT and UVM_COMPONENT

UVM
,
1

Dear Sir/Madam,

I understood few differences between UVM_OBJECT and UVM_COMPONENT as follows:

  1. uvm_component is derived from uvm_object.
  2. There is an extra argument for “uvm_component - new” function for which we need to define the parent class name.
  3. Classes derived from uvm_component, are only can talk to DUT. Where as object can’t do.

Can you please elaborate more on differences between uvm_component and uvm_object?

Thanks & regards,
Sudheer.

2

uvm_components are “static-like” in that they are created during build_phase() and persist throughout the simulation. Think of them as the class-based equivalent of modules.
uvm_objects are transient, such as transactions that are created when needed and disappear when not used anymore.

3

In reply to tfitz:

Thanks tfitz…

4

In reply to Girisha Angadi Basavaraja:

thanks girisha…

5

In reply to sudheer:

I had one more question.
uvm_component is derived from uvm_object. So can we use uvm_object_utils in uvm_component class(Ex: uvm_monitor child class)? If yes, what is the use of uvm_component_utils in uvm_component?

6

In reply to sudheer:

Use uvm_component_utils for components and uvm_object_utils for objects. The component_utils does a little bit more than object_utils, so the two are not interchangeable.

7

In reply to tfitz:

A more basic reason to have separate uvm_object_utils and uvm_component)utils macros is that the factory create methods need to be defined with a hard coded set of arguments for the constructors: a name for a uvm_object and a name and parent for uvm_component. This is why you cannot add constructor arguments to your own classes and still use the factory.

8

In reply to sudheer:

Hi,
Here my two cents with the compilation of the differences.
Please correct me if i am wrong

  1. Uvm_object use uvm_object_param_util() instead of uvm_component_param_util() to declare the classes in the factory. This macro is normally done right after the beginning of the class.
  2. Uvm_objects doesn’t have build phase, components have it. All that is built in build phase exists from the start of the simulation until the end of simulation.
  3. UVM_OBJECTS doesn’t have phases at all, only the new/constructor function is defined for them
  4. Uvm_objects doesn’t have “parent” argument in the super.new(name) . Component have it super.new(name,parent). The same for create function. Objects do obj_t::type_id::create(“obj”); and components can do comp_t::type_id::create(“comp”,this); where this is obviously the parent of the created component.
  5. Uvm_objects are dynamic objects that once created with “new” and only exist for a specific time in the simulation. They are eliminated once the scope of the task where they were created finish. On the other side, components are semi-static classes that exist from the beginning of the simulation until the end of simulation. In other words, uvm_objects are transient, such as transactions that are created when needed and disappear when not used anymore.
  6. Uvm_components contains all methods the uvm_objects have. e.g. uvm_objects have clone/do_copy virtual methods, that can be used to clone/ do a deep copy of an object.
    A list of the methods can be found under uvm_object
    A list of the specific uvm_component methods uvm_component

I hope it helps.
Jonathan

9

In reply to Jonathan_Alvarez:

Hi Jonathan,

you are saying a fwe things which are really incorrect.
In the UVM we know uvm_components and uvm_objects.

(1) uvm_components are used to construct the UVM environment. They are used to make testbench components. The registration with the factory is made with the macro uvm_component_utils. (2) uvm_objects are used for UVM transient objects like uvm_seq_item, uvm_transaction, uvm_sequence. The base class uvm_object is also used for configuration objects, i.e. classes which contain configuration data to configure uvm_components or other uvm_objects, like sequences, etc. They are regsitered with the factory using the macro uvm_object_utils.

The macros uvm_component_param_utils and uvm_object_param_utils are used for factory registration of parameterized classes.

It is recommended to avoid the factory registration of configuration objects. This gives you freedom to define the constructor. Then there is no need to have exactly one argument (name).

10

In reply to chr_sue:

In our environments all our test bench components and transaction items (objects) have parameters. I find very useful to add the bitwidth of variable members (not real behavior configuration). In other words, we can have parameterized VCs (Verification components) for different bitwidth interfaces.
That is the reason we use uvm_object_param_util/uvm_component_param_util.
Obviously if the user doesn’t want to use parameterized classes then if should use the macros you have written.

If i understood well you say that it is not recommended to use parameterized classed in the factory registration? Could you point me out where have you seen that recommendation?
Thanks

11

In reply to Jonathan_Alvarez:

Using parameterized classes adds always additional effort to your work. Defining parameters in a package and importing this package in any place you need them is a more elegant way.
Regarding the configuration objects I say only, do not register with the Factory. This allows you to define the constructor meeting your requirements.

12

In reply to sudheer:

UVM class reference manual would give you a more comprehensive description about the difference.

uvm_component Class Hierarchy

  • uvm_void
    • uvm_object
      • uvm_report_object
        • uvm_component

17.1 uvm_component
The uvm_component class is the root base class for UVM components. In addition to the features inherited from uvm_object and uvm_report_object,uvm_component provides the following interfaces:

Hierarchy - provides methods for searching and traversing the component hierarchy.
Phasing - defines a phased test flow that all components follow, with a group of standard phase methods and an API for custom phases and multiple independent phasing domains to mirror DUT behavior e.g. power
Reporting - provides a convenience interface to the uvm_report_handler. All messages, warnings, and errors are processed through this interface.
Transaction recording - provides methods for recording the transactions produced or consumed by the component to a transaction database (vendor specific).
Factory - provides a convenience interface to the uvm_factory. The factory is used to create new components and other objects based on type-wide and instance-specific configuration.

The uvm_component is automatically seeded during construction using UVM seeding, if enabled. All other objects must be manually reseeded, if appropriate. See uvm_object::reseed for more information.

13

In reply to dave_59:

hi,

Can you please tell me what is the purpose of macros,because as base class itself provides the methods of copy(),create()etc.Then why this macros?

14

In reply to Ayush:

The relevant macros I mention do the factory registration. See http://go.mentor.com/mcem