UVM Interview Questions

 
1} What is UVM factory?

Ans:-  UVM Factory is used to manufacture (create) UVM objects and components. Apart from creating the UVM objects and components the factory concept essentially means that you can modify or substitute the nature of the components created by the factory without making changes to the testbench.

  For example, if you have written two driver classes, and the environment uses only one of them. By registering both the drivers with the factory, you can ask the factory to substitute the existing driver in the environment with the other type. The code needed to achieve this is minimal and can be written in the test.

2. What is the difference between new() and create?

Ans: We all know about new() method that is used to allocate memory to an object instance. In UVM (and OVM), the create() method causes an object instance to be created from the factory. This allows you to use factory overrides to replace the desired object with an object of a different type without having to recode.





1. What is uvm_config_db ? What is difference between uvm_config_db & uvm_resource_db?

Ans: uvm_config_db is a parameterized class used for configuration of the different type of parameter into the uvm database So that it can be used by any component in the lower level of a hierarchy.

uvm_config_db is a convenience layer built on top of uvm_resource_db, but that convenience is very important. In particular, uvm_resource_db uses a "last write wins" approach. The uvm_config_db, on the other hand, looks at where things are in the hierarchy up through end_of_elaboration, so "parent wins." Once you start start_of_simulation, the config_db becomes "the last write wins."

All of the functions in uvm_config_db#(T) are static, so they must be called using the:: operator
It is extended from the uvm_resource_db#(T), so it is a child class of uvm_resource_db#(T)

2. What is the advantage and difference of  `uvm_component_utils() and `uvm_object_utils()?

Ans: The utils macros define the infrastructure needed to enable the object/component for correct factory operation.

The reason there are two macros is that the factory design pattern fixes the number of arguments that a constructor can have. Classes derived from uvm_object have constructors with one argument, a string name. Classes derived from uvm_component have two arguments, a name, and a uvm_component parent.

The two `uvm_*utils macros insert code that gives you a factory create a () method that delegates call to the constructors of uvm_object or uvm_component. You need to use the respective macro so that the correct constructor arguments get passed through. This means that you cannot add extra constructor arguments when you extend these classes in order to be able to use the UVM factory.

3. Difference between `uvm_do and `uvm_rand_send ?

Ans: `uvm_do perform the below steps:
1. create
2. start_item
3. randomize
4. finish_item
5. get_response (optional)

while `uvm_rand_send perform all the above steps except create. User needs to create sequence / sequence_item.

4. Difference between uvm_transaction and uvm_seq_item?

Ans: class uvm_sequence_item extends uvm_transaction

uvm_sequence_item extended from uvm_transaction only, uvm_sequence_item class has more functionality to support sequence & sequencer features. uvm_sequence_item provides the hooks for sequencer and sequence So you can generate transaction by using sequence and sequencer, and uvm_transaction provide only basic methods like do_print and do_record etc.
5. Can we have a user-defined phase in UVM?

Ans: In addition to the predefined phases available in uvm, the user has the option to add his own phase to a component. This is typically done by extending the uvm_phase class the constructor needs to call super.new which has three arguments
Name of the phase task or function
Top down or bottom up phase
Task or function


The call_task  or call_func and get_type_name need to be implemented to complete the addition of the new phase.

Example
class custom_phase extends uvm_phase;
   function new();
      super.new(“custom”,1,1);
   endfunction

   task call_task  ( uvm_component parent);
     my_comp_type comp;
     if ( $cast(comp,parent) )
             comp.custom_phase();
   endtask

   virtual function string get_type_name();
      return “custom”;
   endfunction
endclass


6. What is UVM RAL model? why it is required?

Ans: In a verification context, a register model (or register abstraction layer) is a set of classes that model the memory mapped behavior of registers and memories in the DUT in order to facilitate stimulus generation and functional checking (and optionally some aspects of functional coverage). The UVM provides a set of base classes that can be extended to implement comprehensive register modeling capabilities.

7. What is the difference between new() and create?

Ans: We all know about new() method that is used to allocate memory to an object instance. In UVM (and OVM), the create() method causes an object instance to be created from the factory. This allows you to use factory overrides to replace the desired object with an object of a different type without having to recode.
8. What is the analysis port?

Analysis port (class uvm_tlm_analysis_port) — a specific type of transaction-level port that can be connected to zero, one, or many analysis exports and through which a component may call the method to write implemented in another component, specifically a subscriber.

port, export, and imp classes used for transaction analysis.

uvm_analysis_port
Broadcasts a value to all subscribers implementing a uvm_analysis_imp.
uvm_analysis_imp
Receives all transactions broadcasted by a uvm_analysis_port.
uvm_analysis_export
Exports a lower-level uvm_analysis_imp to its parent.


9. What is TLM FIFO?

In simpler words, TLM FIFO is a FIFO between two UVM components, preferably between Monitor and Scoreboard. Monitor keep on sending the DATA, which will be stored in TLM FIFO, and Scoreboard can get data from TLM FIFO whenever needed.

// Create a FIFO with depth 4
      tlm_fifo = new ("uvm_tlm_fifo", this, 4);


10. How the sequence starts?
start_item starts the sequence

virtual task start_item ( uvm_sequence_item item,  
                                          int  set_priority =  -1,
                                        uvm_sequencer_base  sequencer =  null )

start_item and finish_item together will initiate operation of a sequence item.  If the item has not already been initialized using create_item, then it will be initialized here to use the default sequencer specified by m_sequencer.

11. What is the difference between UVM RAL model backdoor write/read and front door write/read?

Front door access means using the standard access mechanism external to the DUT to read or write to a register. This usually involves sequences of time-consuming transactions on a bus interface.

Backdoor access means accessing a register directly via hierarchical reference or outside the language via the PLI. A backdoor reference usually in 0 simulation time.

12. What is the objection?

The objection mechanism in UVM is to allow hierarchical status communication among components which is helpful in deciding the end of the test.

There is a built-in objection for each in-built phase, which provides a way for components and objects to synchronize their testing activity and indicate when it is safe to end the phase and, ultimately, the test end.

The component or sequence will raise a phase objection at the beginning of an activity that must be completed before the phase stops, so the objection will be dropped at the end of that activity. Once all of the raised objections are dropped, the phase terminates.

Raising an objection: phase.raise_objection(this);
Dropping an objection: phase.drop_objection(this);
13. What is p_sequencer ? OR Difference between m_sequencer and p_sequencer?

m_sequencer is the default handler for uvm_vitual_sequencer and p_sequencer is the hook up for child sequencer.

m_sequencer is the generic uvm_sequencer pointer. It will always exist for the uvm_sequence and is initialized when the sequence is started.

p_sequencer is a type-specific sequencer pointer, created by registering the sequence to the sequencer using macros (`uvm_declare_p_sequencer). Being type specific, you will be able to access anything added to the sequencer (i.e. pointers to other sequencers, etc.). p_sequencer will not exist if we have not registered the sequence with the `uvm_declare_p_sequencer macros.

The drawback of p_sequencer is that once the p_sequencer is defined, one cannot run the sequence on any other sequencer type.


13. What is the difference between Active mode and Passive mode with respect to the agent?

An agent is a collection of a sequencer, a driver and a monitor.

In active mode, the sequencer and the driver are constructed and stimulus is generated by sequences sending sequence items to the driver through the sequencer. At the same time, the monitor assembles pin level activity into analysis transactions.

In passive mode, only the monitor is constructed and it performs the same function as in an active agent. Therefore, your passive agent has no need for a sequencer. You can set up the monitor using a configuration object.


14. What are the types of sequencer? Explain each?

There are two types of sequencer:

uvm_sequencer #(REQ, RSP) :
When the driver initiates new requests for sequences, the sequencer selects a sequence from a list of available sequences to produce and deliver the next item to execute. In order to do this, this type of sequencer is usually connected to a driver uvm_driver #(REQ, RSP).

uvm_push_sequencer #(REQ, RSP) :
The sequencer pushes new sequence items to the driver, but the driver has the ability to block the item flow when it's not ready to accept any new transactions. This type of sequencer is connected to a driver of type uvm_push_driver #(REQ, RSP).