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.e. '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.
http://www.learnuvmverification.com/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.
This mechanism can be used only with components. Sequences and transactions cannot be configured using this mechanism. When set_config_* method is called, the data is stored w.r.t strings in a table. There is also a global configuration table.
Higher level component can set the configuration data in level component table. It is the responsibility of the lower level component to get the data from the component table and update the appropriate table.
following are the method to configure integer, string and object of uvm_object based class respectively.
function void set_config_int (string inst_name, string field_name, uvm_bitstream_t value)
function void set_config_string (string inst_name, string field_name, string value)
function void set_config_object (string inst_name, string field_name, uvm_object value, bit clone = 1)
Q33: What are the advantages of uvm RAL model ?
- The RAL (register abstraction layer) provides accesses to DUT and also keeps a track of register content of DUT.
- UVM RAL can be used to automate the creation of high level, object oriented abstraction model of registers and memory in DUT.
- Register layer makes the register abstraction and access of its contents independent of the bus protocol which is used to transfer data in and out of registers inside the design.
- Hierarchical model provided by RAL makes the reusability of test bench components very easy.
- The changes in initial configuration of registers or specifications can be easily communicated in the entire environment. RAL layer supports both front door and backdoor access. The backdoor access does not use the bus interface rather it uses the HDL defined paths for direct communication with the device. Thus in zero simulation time the registers of device can be reconfigured using the backdoor access and verification can be started.
- One more advantage of backdoor access is that it can be used for verify if the access through front door are happening correctly. To achieve this the front door, write is verified using backdoor read.
Q34: What are the different override types?
Two type of overriding is supported by UVM
1. Type overriding
Type overriding means that every time a component class type is created in the Testbench hierarchy, a substitute type i.e. derived class of the original component class, is created in its place. It applies to all the instances of that component type.
Syntax:
<original_type>::type_id::set_type_override(<substitute_type>::get_type(), replace);
where “replace” is a bit which is when set equals to 1, enables the overriding of an existing override else existing override is honoured.
2. Instance overriding
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.g. last packet analysis & comparison etc after all the stimulus is
applied & processed.
