Layering sequences in UVM !!!

We come across different types of layering requirement for different  protocols. Basic ones are as follows.

1. One to one mapping  --  One higher level protocol frame is mapped to the payload of one lower level protocol frame.
2. One to many mapping -- One higher level protocol frame is mapped to the payload of many lower level protocol frames.
3. Many to one mapping  -- Many higher  level protocol frames are mapped to the payload of single lower level protocol frame.
4. Many to many mapping  -- Many higher level protocol frames are mapped to the payload of many lower level protocol frames. 

What ever be the layering scenario , the basic principle to generate a layering transaction is to randomize the higher level sequence and use byte_pack to convert it to a byte stream and package the bytes in the lower level sequence.

System verilog 2012 features !!!

I recently came across a paper presented at DVcon 2012 which summarized the proposed features of system verilog 2012 standard. The feature that  first grabbed my attention was multiple inheritance  support in system verilog similar to Java. This feature will ease the test bench development effort in future. The current methodology based on system verilog will potentially leverage this feature when it is available. Other feature which is also a good addition is the soft constraints which allow the constraints to be overridden without creating a conflict , currently we have to turn of the conflicting constraints using constraint mode to override a constraint. another interesting addition is the unique constraint to generate unique values across a list of variable or array elements , currently most of the users use custom logic or algorithm to generate unique values.

Callback in UVM !!!

Callbacks are empty virtual methods that are embedded in the user components at strategic  points to allow the user to make customization which allows better reuse.

In UVM this can be achieved in two ways. 

1. Simply add  empty virtual methods in the component  say in a driver  and invoke the virtual methods at appropriate locations , test writer or  the user extends the driver class implements the virtual methods and uses  set instance override to accomplish the functionality.
2. Create a class which extends form uvm_callback class and it  implements the virtual methods.  Use `uvm_do_callbacks() to place the virtual methods at strategic points in the component say a driver. Now the test writer or user extends the callback class and implements the virtual methods and registers or associate the extended callback class with the instance of the component say the driver using add to accomplish the functionality.

Adding user defined phase using uvm_phase !!!

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 

1. name of the phase task or function
2. top down or bottom up phase
3. task or function

The call_task  or call_func and get_type_name need to be implemented to complete the addition of 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

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.