Difference between set_type_override and set_type_override_by_name

OVM
1

Hi All,

Can anyone specify the difference between set_type_override and set_type_override_by_name.
set_type_override_by_name is clear to me as it configures the factory to create an object of type override_name whenever the factory is asked to produce a type of original_name. What about set_type_override?

Thanks
Rohit

2

I guess the only difference is that set_type_override is called on the type you want to override and set_type_override_by_name is generic which just registers the override and called on the factory directly.

For type override we do something like this :
// Replace all base drivers with derived drivers…
B_driver::type_id::set_type_override(D_driver::get_type());

And for by Name it should be something like
// - via a direct call to a factory method
factory.set_type_override_by_name(“B_driver”, “D_Driver”) ;

~Puneet

3

set_type_override_by_name can’t used for parameterized classes, If you use set_*_name for parameterized classes it will create only class with default parameters.

set_*_type can be used for parameterized classes, With the help of this function factory can create classes by overriding the default parameters of classes.

4

set_type_override_by_name can’t used for parameterized classes, If you use set_*_name for parameterized classes it will create only class with default parameters.

Correction: set_type_override_by_name can’t used for parametrized classes if you use the factory registration macros `ovm_*_utils.

If you can create a unique string name for your parametrized class based on one or more of its parameters, then you can register it with the factory by name using the ovm_object/component_registry class.

Dave Rich

5

Thanks dave for correcting me.

6

Hi Dave,

do you have any idea how to register with a unique name for a parametrized class other than passing a string to that class?

Thanks,

Holger

7

Holger,

Theoretically, you can use $typename to get a unique string, but the format of what is returned is not standardized, and could be quite lengthy especially when there are nested parametrizations.

If you can identify a minimum set of parameters that make the class unique, you can use $psprintf to create a string for you. For example,

class driver #(type REQ=req_type, int ADDRESS_WIDTH=8, DATA_WIDTH=16) extends ovm_component;
     driver #(REQ,ADDRESS_WIDTH,DATA_WIDTH) this_type;
     localparam string TYPENAME = $psprintf("driverA%0dD%0d",ADDRESS_WIDTH,DATA_WIDTH);

     typedef ovm_component_regisitry #(this_type, typename) type_id;
     static function type_id get_type();
         return type_id::get();
     endfunction
...

Note that REQ is not part of the generated string. You’d have to assume the other parameters are enough to make each specialization of driverhave a unique string type name.

Dave

8

Dave,

I thought of using $psprintf as well, but in contrast to Questa VCS does not allow compiling code that defines a local parameter using a function call. Now the question arises if using SystemVerilog system function calls is legal for determining the value of local parameters that need to be resolved at compile time.

Thanks,

Holger

9

Dave,

finally I saw that there is already an older post of you concerning this issue:

http://www.ovmworld.org/forums/showthread.php?312-register-parametrized-class-with-factory

and I have implemented the integer to string conversion in a package as follows:

package my_pkg;
…

function string int2str(int i);
string str;
str.itoa(i);
return str;
endfunction
…
endpackage

class my_agent #(int a=1) extends ovm_agents;

…
typedef ovm_component_registry #(my_agent#(a), {my_agent, “_”, my_pkg::int2str(a)} ) type_id;

…
endclass

Thanks,

Holger

10

Now the question arises if using SystemVerilog system function calls is legal for determining the value of local parameters that need to be resolved at compile time.

The LRM is ambiguous about the complete set of system tasks that can be used as constant functions. See

https://mantisbt.org/bugs/view.php?id=1568 and https://mantisbt.org/bugs/view.php?id=1152

However, the LRM does explicitly specify the requirements for a system function call to be used in constant expression. There is no ambiguity the when the arguments to $psprintf are constant expressions, the result is a constant as well. That meets the conditions set forth in section 11.2.1 for constant system function calls.

Dave