UVM Questions - 3

Q. What is the advantage of using type_id::create() over new() while creating objects ?

There is nothing wrong in creating the objects for any uvm_component with constructor function new(), however if you are using UVM, there are some advantages of using factory way of creating objects i.e using

classname ::type_id::create("object name", parent)

This is what UVM1.1 Class Reference says

"Using the factory instead of allocating them directly (via new) allows different objects to be substituted for the original without modifying the requesting class"


Q: How to implement polymorphism in UVM?

The above advantage is illustrated through the polymorphism of a 'generic monitor' as follows:-

Any generic Monitor component's implementation will be

   class xyz_monitor extends uvm_monitor ;

      task run_phase ;

         // Implements monitor functionality here

      endtask

   endclass

Monitor has following modes of operation apart from basic xyz_monitor mode

     1. Mode1

     2. Mode2

   class monitor_mode1 extends xyz_monitor;

     // Implement monitor mode1

   endclass

   class monitor_mode2 extends xyz_monitor;

     // Implement monitor mode2

   endclass

    class parent extends uvm_env;

         .....

         ....

         xyz_monitor mon;

        mon = xyz_monitor::type_id::create("mon",this);

    endclass

Now during compilation you can specify which mode of the monitor you need for a particular simulation run using

    +uvm_set_type_override=<\req_type\>, <\overrid_type\>[,<\replace\>]

which work like the name based overrides in the factory--factory.set_type_override_by_name()

For the above example, If we need mode1 of monitor then the command line will be
    +uvm_set_type_override=xyz_monitor,monitor_mode1

For mode2, it would be
    +uvm_set_type_override=xyz_monitor,monitor_mode2

Effectively, there were no exclusive objects created for monitor mode1 or mode2, it basically override the object created for the object 'mon' which was originally of type 'xyz_monitor' and this is called Polymorphism because 'mon' object can potentially be any one of these types i.e. xyz_monitor or monitor_mode1 or monitor_mode2 for a given simulation run.

In fact, for the same monitor example if we have two instances(or objects) of xyz_monitor in your environment

    class parent extends uvm_env;

         .....

         ....

         xyz_monitor mon;

         xyz_monitor mon_extra;

        mon           = xyz_monitor::type_id::create("mon",this);

        mon_extra = xyz_monitor::type_id::create("mon",this);

    endclass

Now during compilation(command line) you can specify which modes of the monitor you need for a particular simulation run using
 +uvm_set_inst_override=<\req_type\>,<\overrid_type\>,<\full_inst_path\>

We can override 'mon' object to be of type monitor_mode1 using
 +uvm_set_inst_override=xyz_monitor,monitor_mode1,uvm_test_top.env.mon

We can override 'mon_extra' object to be of type monitor_mode2 using
 +uvm_set_inst_override=xyz_monitor,monitor_mode2,uvm_test_top.env.mon_extra

Please note that for 'uvm_set_inst_overrride', you need extra argument which is the path of 'object' and it has to start from uvm_test_top