- Information
- AI Chat
This is a Premium Document. Some documents on Studocu are Premium. Upgrade to Premium to unlock it.
UVM Interview Questions
sss
Course
Bachelor of engineering
322 Documents
Students shared 322 documents in this course
University
Visvesvaraya Technological University
Academic year: 2023/2024
Recommended for you
Preview text
UVM Interview Questions
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. 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
The 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
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 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 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(“custom”,1,1);
endfunction
task call_task ( uvm_component parent);
my_comp_type comp;
if ( $cast(comp,parent) )
comp_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.
Q21: What is 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 write
implemented in another component, specifically a subscriber.
Raising an objection:
phase_objection(this);
Dropping an objection:
phase_objection(this);
Q26: What is p_sequencer? OR Difference between m_sequencer and p_sequencer?
m_sequencer is the default handle 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 typed-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. 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.
Q27: What is the difference between Active mode and Passive mode with respect to 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.
Q28: What is the difference between copy and clone?
The built-in copy() method executes the __m_uvm_field_automation() method with the required copy code
as defined by the field macros (if used) and then calls the built-in do_copy() virtual function. The built-in
do_copy() virtual function, as defined in the uvm_object base class, is also an empty method, so if field
macros are used to define the fields of the transaction, the built-in copy() method will be populated with
the proper code to copy the transaction fields from the field macro definitions and then it will execute the
empty do_copy() method, which will perform no additional activity.
The copy() method can be used as needed in the UVM testbench. One common place where the copy()
method is used is to copy the sampled transaction and pass it into a sb_calc_exp() (scoreboard calculate
expected) external function that is frequently used by the scoreboard predictor.
The clone() method calls the create() method (constructs an object of the same type) and then calls the
copy() method. It is a one-step command to create and copy an existing object to a new object handle.
Q29: What is UVM factory?
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
environment with the other type. The code needed to achieve this is minimal, and can be written in the test.
Q30: What are the types of sequencer? Explain each?
There are two types of sequencers :
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 its not ready to accept any new transactions. This type of sequencer is connected to a driver of type
uvm_push_driver #(REQ, RSP).
Q31: What is virtual sequencer and virtual sequence in UVM?
A virtual sequencer is a sequencer that is not connected to a driver itself, but contains handles for sequencers
in the testbench hierarchy. It is an optional component for running of virtual sequences - optional because
they need no driver hookup, instead calling other sequences which run on real sequencers.
A sequence which controls stimulus generation across more than one sequencer, coordinate the stimulus
across different interfaces and the interactions between them. Usually the top level of the sequence
hierarchy i. 'master sequence' or 'coordinator sequence'. Virtual sequences do not need their own
sequencer, as they do not link directly to drivers. When they have one it is called a virtual sequencer.
Here is a good article which explains how to use virtual sequence and virtual sequencer.
learnuvmverification/index.php/2016/02/23/how-virtual-sequence-works-part-1/
Q32: How set_config_* works?
The uvm_config_db class provides a convenience interface on top of the uvm_resource_db to simplify the
basic interface that is used for configuring uvm_component instances.
Configuration is a mechanism in UVM that higher level components in a hierarchy can configure the lower
level components variables. Using set_config_* methods, user can configure integer, string and objects of
lower level components. Without this mechanism, user should access the lower level component using
hierarchy paths, which restricts re-usability.
In Instance Overriding, as name indicates it substitutes ONLY a particular instance of the component OR
a set of instances with the intended component. The instance to be substituted is specified using the UVM
component hierarchy.
Syntax:
<original_type>::type_id::set_inst_override(<substitute_type>::get_type(), <path_string>);
Where “path_string” is the hierarchical path of the component instance to be replaced.
Q35: Explain end of simulation in UVM?
Different approaches to finish the UVM Test using the objection mechanism are
1. Raising & dropping objections
raise_objection() and drop_objection() are the methods to be used to do that.
2. phase_ready_to_end
phase_ready_to_end method is executed automatically by UVM once ‘all dropped’ condition is achieved
during Run Phase.
3. set_drain_time
Another approach supported by UVM is setting the drain time for the simulation environment. Drain time
concept is related to the extra time allocated to the UVM environment to process the left over activities e.
last packet analysis & comparison etc after all the stimulus is applied & processed.
Q36: What is the Difference between UVM_ALL_ON and UVM_DEFAULT?
UVM_ALL_ON and UVM_DEFAULT are identical. As per the UVM reference manual:
UVM_ALL_ON: Set all operations on (default).
UVM_DEFAULT: Use the default flag settings.
It is recommended to use UVM_DEFAULT instead of UVM_ALL_ON even though they both essentially
do the same thing today. At some point in time, the class library may add another "bit-flag" which may not
necessarily be the DEFAULT.
If you use UVM_ALL_ON, that would imply that whatever flag it is would be "ON".
Q37: What drain time in UVM?
The drain time means the access time that you use before ending the simulation. Suppose if we are done
with input traffic to the DUT didn't mean that nothing else would happen from that point as the DUT may
have required some additional time to complete any transactions that were still being processed. Setting a
drain time adds an extra delay from the time that all objections were dropped to the stop of the simulation,
making sure that there were no outstanding transactions inside DUT at that point.
You can set the drain time in the base test at the end_of_elobration phase as shown below:
class test_base extends uvm_test;
// ...
function void end_of_elaboration_phase(uvm_phase phase);
uvm_phase main_phase = phase_by_name("main", 0);
main_phase.phase_done_drain_time(this, 10);
endfunction
// ...
endclass
Q38: What is Virtual interface and how Virtual interface is used?
"Virtual interfaces are class data member handles that point to an interface instance. This allows a
dynamic class object to communicate with a Design Under Test (DUT) module instance without using
hierarchical references to directly access the DUT module ports or internal signals."
Below shown sample code is the easier way to use the virtual interface handles in the UVM environment.
module top;
...
dut_if dif;
...
initial begin
uvm_config_db#(virtual dut_if)::set(null, "*", "vif", dif);
run_test();
end
endmodule
Setting the interface:
initial begin
//put in the database the interface used by APB agent agent
uvm_config_db#(virtual apb_if)::set(null, "uvm_test_top.env*", "VIRTUAL_INTERFACE",
intf0);
//put in the database the interface used by APB agent agent
uvm_config_db#(virtual apb_if)::set(null, "uvm_test_top.env*", "VIRTUAL_INTERFACE",
intf1);
end
Getting the interface:
class cfs_apb_agent extends uvm_component;
//pointer to the interface
virtual cfs_apb_if vif;
virtual function void build_phase(uvm_phase phase);
super_phase(phase);
if(uvm_config_db::#(virtual apb_if)::get(this, "", "VIRTUAL_INTERFACE", vif) == 0) begin
`uvm_fatal("ISSUE", "Could not get from the database the virtual interface for the APB agent")
end
endfunction
endclass
Was this document helpful?
This is a Premium Document. Some documents on Studocu are Premium. Upgrade to Premium to unlock it.
UVM Interview Questions
Course: Bachelor of engineering
322 Documents
Students shared 322 documents in this course
University: Visvesvaraya Technological University
Was this document helpful?
This is a preview
Do you want full access? Go Premium and unlock all 13 pages
Access to all documents
Get Unlimited Downloads
Improve your grades
Already Premium?
UVM Interview Questions
Page | 1
UVM Interview Questions
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
Why is this page out of focus?
This is a Premium document. Become Premium to read the whole document.
Why is this page out of focus?
This is a Premium document. Become Premium to read the whole document.
Why is this page out of focus?
This is a Premium document. Become Premium to read the whole document.
Why is this page out of focus?
This is a Premium document. Become Premium to read the whole document.