Usage of uvm_resource_db & uvm_config_db !!!

Both uvm_config_db and uvm_resource_db share the same underlying database to store and retrieve information. Infact you can write a value to the database using uvm_config_db ::set() method and retrieve the information using uvm_resource_db::read_by_name().  The recommended method is to use uvm_config_db when hierarchical   based access is required.  When you want to share object and access it from different location without using the hierarchy you can use uvm_resource_db.

You can set a resource to the resource db using the uvm_resource_db::set()  method

Example

uvm_resource_db# (int）::set("enable","*",1,this);

To retrieve the information from the resource db you can use uvm_resource_db::read_by_name() method

Example

   Bit success;

   Success=uvm_resource_db#（int)::read_by_name("enable",get_full_name(),value,this);

   If(success==1’b0)
      `uvm_error("ERROR","cannot locate the resource ");

Accessing components bottom up using set_config_* and get_config_* in UVM !!!

One of the requirements in verification is to access variable bottom up  in the hierarchy this can be done in UVM using set_config_*  and get_config_*methods. In bottom up access you need to use hierarchical reference like  uvm_test_top.set_config_*  or  uvm_test_top.get_config_*  from the component in the lower level hierarchy to access component in top level hierarchy.  Top down access does not require the hierarchical reference to uvm_test_top , set_config_* and get_config_* can be used directly. 

TLM 2.0 Non-blocking Transport in UVM !!!

Many times we need to generate a transaction reactively based on the response. One of the protocols i can think of which requires reactive generation of transaction is USB. UVM has non-blocking transport which is  an appropriate fit for reactive random stimulus generation. Non blocking transport can be used by the initiator and target to update each other’s progress. We have method like nb_transport_fw () which is used to send the transaction from initiator to target. nb_transport_bw () method is used to send transaction from the target to the initiator.  The initiator modifies the transaction before the call to the nb_transport_fw() after which the object should not be modified.  The target can modify the transaction object before the call to nb_transport_bw () after which the object should not be modified. Each call to the forward and backward methods are accompanied by phase change , different type of phases are UNINTIALIZED_PHASE, BEGIN_REQ, END_REQ, BEGIN_RESP & END_RESP. Forward and backward function return a status UVM_TLM_ACCEPTED,UVM_TLM_UPDATED & UVM_TLM_COMPLETED these status indicate the status of the transaction - accepted , updated and completed.

Command line processor in UVM !!!

Command line processor provides  general interface to the command line arguments from the simulator to the UVM  test bench. To use the command line processor in your test bench singleton instance of command line processor has to be created as described below

uvm_cmdline_processor commandline_processor = uvm_cmdline_processor::get_inst();

To obtain the command line argument  get_arg_value() should be used

string  value = "intial_value";

int rt_value = commandline_processor.get_arg_value("+DIRECTION=",value);

Singleton class is the one which returns the same object irrespective of the number of time an object is created .command line processor is used as a singleton class.

Factory replacement options like set_type_override() ,set_inst_override() can be done using  command line processor arguments like +uvm_set_type_override   +uvm_set_inst_override , 

Virtual sequences in UVM !!!

In a system level verification environment we require coordination of multiple components that run in parallel . Virtual sequence is used to have centralized control and coordinates stimulus generation across components. Virtual sequences executes on the virtual sequencer. Virtual sequencers have reference to other driver sequencers or other virtual sequencers. Virtual sequence can execute a transaction  items on other sequencers only.  By using virtual sequences you can reuse the sequence library of a component or a block level environment at system level.

Algorithmic comparator (Scoreboard) in UVM !!!

Algorithmic comparator (Scoreboard) in UVM is a useful utility to compare two different streams of transactions. Different types of transaction class can be compared with this scoreboard. Algorithmic comparator takes three parameters BEFORE, AFTER and TRANSFORMER. The TRANSFORMER class is the one that transforms one stream of transaction to other. TRANSFORMER class should implement a transform function with the following prototype

function AFTER transform ( BEFORE b )  

Transform function should implement how transaction class BEFORE is converted to AFTER and return the converted transaction object.  

Matches and Mismatches in this scoreboard is reported in terms of the AFTER transactions.

do_copy() , do_compare(), do_byte_pack() , do_is_vaild() , do_allocate() & do_byte_unpack() !!!

do_*  methods overrides the default implementation of the vmm_data methods that is created by the shorthand macros. If the do_* methods are defined, this method is used instead of the default implementation. do_* methods are very useful can work well with short hand macros example you can just override the default implementation of  byte_pack() & byte_unpack() methods using do_byte_pack and do_byte_unpack and rest of the vmm_data methods can be auto generated by short hand macros.