Q1: What is UVM? What is the advantage of UVM?

Ans: UVM (Universal Verification Methodology) is a standardized methodology for verifying the
both complex & simple digital design in simple way.

UVM Features:
 First methodology & second collection of class libraries for Automation
 Reusability through testbench
 Plug & Play of verification IPs
 Generic Testbench Development
 Vendor & Simulator Independent
 Smart Testbench i.e. generate legal stimulus as from pre-planned coverage plan
 Support CDV –Coverage Driven Verification
 Support CRV –Constraint Random Verification
 UVM standardized under the Accellera System Initiative
 Register modeling

Q2: UVM derived from which language?

Ans: Here is the detailed connection between SV, UVM, OVM and other methodologies.
Q3. What is the difference between uvm_component and uvm_object?
OR
We already have uvm_object, why do we need uvm_component which is actually derived class of
uvm_object?

Ans:
uvm_component:
 Quasi Static Entity (after build phase it is available throughout the simulation)
 Always tied to a given hardware(DUT Interface) Or a TLM port
 Having phasing mechanism for control the behavior of simulation
 Configuration Component Topology

uvm_object:
 Dynamic Entity (create when needed, transfer from one component to other & then
dereference)
 Not tied to a given hardware or any TLM port
 Not phasing mechanism

Q4: Why phasing is used? What are the different phases in uvm?

Ans: UVM Phases is used to control the behavior of simulation in a systematic way & execute in a
sequential ordered to avoid race condition. This could also be done in system verilog but manually.
1. List of UVM Phases:
2. buid_phase
3. connect_phase
4. end_of_elaboration_phase
5. start_of_simulation_phase
6. run _phase (task)
Sub Phases of Reset Phase:
pre_reset_phase
reset_phase
post_reset_phase
pre_configure_phase
configure_phase
post_configure_phase
pre_main_phase
main_phase
post_main_phase
pre_shutdown_phase
shutdown_phase
 post_shutdown_phase
7. extract_phase
8. check_phase
9. report_phase
Below figure makes it more clear

Q5: Which uvm phase is top - down , bottom – up & parallel?

Ans: Only build phase is a top-down & other phases are bottom-up except run phase which is
parallel. The build phase works top-down since the testbench hierarchy may be configure so we
need to build the branches before leafs

Q6: Why build phase is top – down & connect phase is bottom – up?

Ans: The connect phase is intended to be used for making TLM connections between components,
which is why it occur after build phase. It work bottom-up so that its got the correct
implementation all the way up the design hierarchy, if worked top-down this would be not possible
Q7: Which phase is function & which phase is task?

Ans: Only run phase is a task (time consuming phase) & other phases are functions (non-blocking)

Q8: Which phase takes more time and why?

Ans: As previously said the run phase is implemented as task and remaining all are function. run
phase will get executed from start of simulation to till the end of simulation. run phase is time
consuming, where the testcase is running.

Q9: How uvm phases initiate?

Ans: UVM phases initiate by calling run_test(“test1”) in top module. When run_test() method call,
it first create the object of test top & then call all phases.

Q10: How test cases run from simulation command line?

Ans: In top module write run_test(); i.e. Don't give anything in argument.
Then in command line : +UVM_TESTNAME=testname

Q11: Difference between module & class based TB?

Ans: A module is a static object present always during of the simulation.

A Class is a dynamic object because they can come and go during the life time of simulation.

Q12: 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 different type of parameter
into the uvm database, So that it can be used by any component in the lower level of 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
"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 child class of uvm_resource_db#(T)

Q13: 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 because 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 inserts code that gives you a factory create() method that delegates
calls 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.

Q14: 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.

Q15: 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 .

Q16: Is uvm is independent of systemverilog ?

Ans: UVM is a methodology based on SystemVerilog language and is not a language on its own. It
is a standardized methodology that defines several best practices in verification to enable efficiency
in terms of reuse and is also currently part of IEEE 1800.2 working group.

Q17: What are the benefits of using UVM?

Ans: Some of the benefits of using UVM are :

 Modularity and Reusability – The methodology is designed as modular components (Driver,

Sequencer, Agents , env etc) which enables reusing components across unit level to multi-unit or
chip level verification as well as across projects.
 Separating Tests from Testbenches – Tests in terms of stimulus/sequencers are kept
separate from the actual testbench hierarchy and hence there can be reuse of stimulus across
different units or across projects
 Simulator independent – The base class library and the methodology is supported by all
simulators and hence there is no dependence on any specific simulator
 Better control on Stimulus generation – Sequence methodology gives good control on
stimulus generation. There are several ways in which sequences can be developed which includes
randomization, layered sequences, virtual sequences etc which provides a good control and rich
stimulus generation capability.
 Easy configuration – Config mechanisms simplify configuration of objects with deep
hierarchy. The configuration mechanism helps in easily configuring different testbench components
based on which verification environment uses it and without worrying about how deep any
component is in testbench hierarchy
 Factory mechanism – Factory mechanisms simplifies modification of components easily.
Creating each components using factory enables them to be overridden in different tests or
environments without changing underlying code base.

Q18: Can we have 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
new phase.
Below is a simple example

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

Q19: 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.

Q20: What is the difference between new() and create?

Ans: We all know about new() method that is use 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.