Sequencer and driver parent classes are non-virtual?

UVM
1

I need some clarification on why driver and sequencer parent classes are non-virtual

Thanks & Regards,
KC Gopal.

2

In reply to Kapu Gopal:

uvm_sequencer and uvm_driver are exception in the uvm class which aren’t abstract/virtual classes.

uvm_sequencer sometime directly used inside the uvm test bench. so it isn’t declared as virtual class.

uvm_sequencer #(my_data) m_seqr0;

uvm_driver should have been virtual class as every useful test bench have it’s driver.

3

Thanks for the reply.
Can u elaborate more, still I’m in confusion.

4

In reply to Kapu Gopal:

you can’t create the instance of the virtual class. so if uvm_sequencer class is declare as virtual class then you can’t directly use it to create the instance of it.


 uvm_sequencer #(my_data) m_seqr0;

  //other code
  .......
  .......

 function void build_phase(uvm_phase phase);
      super.build_phase(phase); 

      //this isn't allowed if uvm_sequencer is virtual class, SV won't allow to create the virtual class instance 
      m_seqr0 = uvm_sequencer #(my_data)::type_id::create("m_seqr0");
 endfunction
5

In reply to Kapu Gopal:

Hi Kapu,

In uvm driver and sequencer not defined as virtual because of we can directly take instance of sequencer as Rahul mention and create it, virtual class not created with out user definition means first we have to extends virtual class and then we have to create that instance.

and if we talk about driver,“driver operates in pull mode. Its ports are typically connected to the corresponding exports in a pull sequencer” that means port define in driver is already uvm_sequence_item type so if you use sequencer directly then you have to use uvm_driver also,
to connect 1 to 1 connection. but this case not exist in real coding even in skeleton, we always extends driver to add driving functionality.

monitor is virtual class because not all monitor use to send data to scoreboard, some monitor is only use to data checks or other functionality, that’s why uvm_monitor has nothing in side it so they is no use to create empty class.

6

In reply to dhaval_sanepara:

What you are explaining is confusing.
All UVM component bas classes are NOT virtual classes.
A virtual class is a class which cannot be used to make directly an object.
For the uvm_sequencer in most cases we do not extend this base class. We are passing only a parameter indicating which seq_items has to be created.
On the other hand,we are using the keyword virtual together with methods. But this has no influence on the construction of a class object.

7

In reply to chr_sue:
The UVM is not consistent in its use of virtual classes. Any class in a base class library that is never constructed directly without extending it first should be marked as virtual class. uvm_driver should be virtual.

8

In reply to dave_59:

Hi Dave,
Will in further version of UVM, they would incorporate uvm_driver as virtual.