Interface class in system verilog !!!

System verilog 2012 has introduced interface class. Interface class is nothing but class with pure virtual methods declaration. The class which implements the interface class should implement the pure virtual methods. Interface class can extend from another interface class but it cannot extend from virtual class or regular class. Regular class can implement multiple interface class and also extend from regular class. Interface class enables better code reusability and also enables multiple inheritance.

Example 

interface class A;

    pure virtual function int get();

endclass

interface class B;

    pure virtual function void put()

endclass

class C implements A , B;

    virtual function int get();

       $display(“ Get  \n”);

     endfunction

    virtual function void put();

       $display(“ Put \n”);

    endfunction

endclass 

p_sequencer usage in UVM !!!

UVM sequences generally do not have access to the TLM ports  In that case the TLM ports and other features available in the sequencer can be accessed from the sequence using p_sequencer reference. This feature is very useful in a layering scenario when higher level sequence is layered into the lower level sequence.

Barrier in UVM !!!

uvm_barrier class is used for multi process synchronization mechanism. set of processes can be allowed to wait using the wait_for() method until  desired number of process reach a synchronization point. set_threshhold() method specifies how many process must be waiting on the barrier synchronization point before all the processes may proceed. reset() method resets the barrier waiter count to zero , after reset all the process should wait for the threshold again.

uvm_event and uvm_event_pool !!!

Synchronization in a multithreaded environment in system verilog is done using event’s. In UVM uvm_event and uvm_event_pool can be used for synchronization of multiple threads or components. Simple example of uvm event is as follows.

uvm_event_pool  event_pool_s=uvm_uvm_event_pool::get_global_pool()

uvm_event           event_s=event_pool_s.get(event_s);

fork

begin

    ........

    event_s.trigger();

end

begin

    .......

  

   event_s.wait_ptrigger();

end

join

Parameterized class in system verilog !!!

Verification component reuse is one of the basic requirement when building verification components.Parameterized class play a very important role in making a code generic. With parameterized class in system verilog data types , size of bit vectors can be declared generic in the class , different variations of the class can be created by varying the parameter value.

Example of a parameterized class

class data # ( type t=int , int size=8 )

      t                        a ;

      bit [ size-1 : 0] b ;

endclass

data # ( shortint , 16 )          halfword_data;

data # ( longint ,  32)                  word_data;

Pure virtual functions and tasks in system verilog !!!

Virtual function/tasks defined in the base class may or may not be overridden in the derived class and the base class can have an implementation of the virtual function/task. sometime the definition of virtual functions/task in base class may not have any clarity on what need to be implemented these virtual functions/task must be overridden in the derived class and just a declaration is need in the base class. In this scenario virtual function / task is declared as pure. Declaring virtual method pure means no implementation for the function/task is required in the base class and the derived class must override the virtual function/task. 

OOP method to access variables of the derived class !!!

We typically use virtual set_() and get_() methods to access the variables added in the extended class from the base class. class handles are created using the base class and type and instance factory overrides are used to replace the class handles respectively. Any reference to the derived class variable from base class is done using virtual set_() and get_() methods which are just empty methods in the base class. At runtime the derived class virtual methods are linked and variables are written or read using set and get methods after a type or instance override.

Mirrors in UVM RAL !!!

RAL mirrors are shadow location of the DUT registers that are updated when RAL read or write methods are accessed from the test bench  , RAL mirror give the user test bench access to the register values for synchronizing test bench events without reading the DUT register. If the DUT internally modifies the content of any field or register through its normal operations (e.g., by setting a status bit or incrementing an accounting counter), the mirrored value becomes outdated. Memory are not mirrored in UVM RAL.RAL mirror value can be set using mirror() method , Mirror value can be updated to the DUT using update() method. At any point of time mirror value can be got using the get() method. set() method can be used to set the mirror value to DUT , the value actually written only when update() method is called.

Creating directed scenario in UVM !!!

Recommended  method  for closing coverage is to have test to run with multiple seeds , but many times certain scenarios can never be covered by the randomness and we require a directed test case. The way to write a directed test in UVM  is as follows.

• Disable the regular sequence from executing on the sequencer by setting count as 0 in the directed test case.

               set_config_int("*.sequencer", "count", 0);

• randomize the sequence in the directed way and execute the sequence on the sequencer using execute_item() method.

                 success = item.randomize();

               *.sequencer.execute_item(item);