Derive from uvm_object or not?

UVM
1

In the testbench (but actually outside the agents - i.e. I am not writing about sequence items or so) I could do with a class for a pretty atomic thing. E.g. consider a class for a complex sample with a clip bit or so:

class Complex;

    // members
    bit [W-1:0] Re;
    bit [W-1:0] Im;
    bit Clip;

    // methods
    ....
    
endclass

I am doubting if it would be worthwhile to derive such a class from uvm_object?
We will have very large arrays, queues, of objects of this class.
My main concern in deriving from uvm_object would be the impact on memory usage and simulation speed.
How are these impacted by being a uvm_object or not?

2

In reply to NiLu:

The only reason you would want to extend from UVM object is to be able to do factory overriding and stuff. If you don’t need this, then why couple your code with UVM?

3

In reply to Tudor Timi:

Just because it gives a nice framework for methods like copy, clone, etc…

4

Most classes that will be processed by other built-in UVM classes need to be derived from uvm_object so that they can be copied, cloned, compared, printed etc. with virtual methods so they do not need to know the exact type of the class. One exception is a configuration object, although recommended, there is no requirement for it to be derived from uvm_object.

However, if you are using a class to build a large data structure that will only be referenced by one of your classes directly, you should not derived these objects from uvm_object - the overhead is to high.

5

Thanks!

With overhead do you mean:

  • coding overhead (implementing the do_* methods)
  • memory usage by base class members
  • runtime (e.g. time to create)

I would need to create copy, clone, compare, … methods for these objects anyway.
And my classes would also need to be polymorphic (all derived from virtual base class)

The nice thing about deriving from a uvm_object is that all the infrastructure to do it right and consistent is already there (e.g. copy that calls do_copy, etc…)
If I would have to make my own copy, clone, etc… method I would want them to behave like the uvm_object ones do, but I fear that I might then be redoing some code that is present in uvm_object already.

For example I believe the uvm_object copy is not virtual, but because it calls the virtual do_copy it still does a deep copy? So I would want my own object’s copy also to have that behavior but maybe without having do_* and non-do_* methods that becomes complicated, etc…

6

In reply to NiLu:

With overhead, I meant all of it. But it all has to be looked at relative to the cost of the the class you want to build, and the relative number of object you need to work with.

Every object derived from uvm_object has a string name and int id variable. An then there is the extra constructor call.

BTW, copy() is non-virtual, but most often you will want to use clone(), which is virtual.

7

In reply to dave_59:

I just looked into the uvm_object source code. I think I will just ‘steal’ some of the code from there to make my own ‘slimmer’ base class. Thanks for all the answers!