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);

Collecting Coverage using white box assertion and functional coverage !!!

One of the essential requirement for verification closure  is to close functional coverage , coverage measured  should accurately measure if the event has occurred in the DUT and the DUT has responded as expected for the event , this requirement can typically be covered using white box assertion and having cover property on the assertion. Using assertion coverage instead of functional coverage is a tradeoff that has to be taken , assertion coverage removes the need for coding coverage monitor but the assertion coverage constructs are not as powerful as the the functional coverage construct in terms of covering cross coverage , having excludes in cross coverage. Most of the cross in assertion coverage need to be done manually. Best strategy one can use is to partition the coverage model between white box coverage assertion and functional coverage on the IO bus to get the best out of both the coverage approach.