TLM process communication using TLM FIFO !!!

With normal TLM ports put will result in the consumers ability to process the transaction right away , TLM FIFO component in UVM is used to buffer transactions so that producer and consumer are independent of each other. TLM FIFO has methods like put() , get() and peek() to access transaction from the TLM FIFO. peek() method gets the transaction without removing transaction from the TLM FIFO. Some of the applications of TLM FIFO is buffering transactions for score boarding. 

Build in command line options in UVM !!!

here are some of the useful build in command line options in UVM.

instance specific factory override  :   +uvm_set_inst_override

type specific factory override          :   +uvm_set_type_override

integer configuration                        :   +uvm_set_config_int

string configuration                           :   +uvm_set_config_string

Timeout                                               :   +UVM_TIMEOUT

Max quit count                                   :   +UVM_MAX_QUIT_COUNT

Objection trace                                  :   +UVM_OBJECTION_TRACE

These command line options helps in quick debug and test writing. 

System verilog assertion coverage !!!

Functional coverage collection with passive monitor is the method recommended by methodology to collect coverage. There is alternative ways to collect coverage in system verilog using assertion coverage. This feature is very useful if you want to collect coverage on some important DUT events , using assertion coverage has its own advantages  and disadvantages.

Advantages of assertion coverage 

1. Coverage monitors are not required to collect required coverage event and then trigger a cover group.
2. Coverage is collected using  assertions and using cover property , binding the assertion to the module or instance is required to collect coverage from the DUT. 
3. Implementing and collecting assertion coverage is faster compared to writing functional coverage for DUT events.
4. Assertion coverage is perfect fit for collecting coverage on important DUT events.

Disadvantages of assertion coverage

1. Assertions coverage if not coded appropriately takes considerable amount of simulation time.
2. Debugging assertion failures is slightly complex than debugging coverage events in a passive monitor.

Sequence library in UVM !!!

Sequences can be grouped using  uvm sequence library ,  sequences can be registered to sequence library using the macro `uvm_add_to_seq_lib(). When the sequence library is started it randomly selects and executes the sequence depending on the selection mode. Selection modes can be any of the following

UVM_SEQ_LIB_RAND      --  Random selection of sequence 

UVM_SEQ_LIB_RANDC   --  Random selection without repeating the sequences

UVM_SEQ_LIB_ITEM       --  Execute  a single sequence item

UVM_SEQ_LIB_USER      --  user selects  sequences using select_sequence() method

Selection mode of the sequence library is set using  uvm_config_db().

sequence library can be used to create system level scenario using random sequences.

Interrupt handling using grab() and ungrab() sequencer in UVM !!!

One of the basic functionality on the processor interface of a verification environment is to service interrupts along with register read / write operations. Servicing the interrupt requires  stoping the ongoing register access sequence and executing the ISR sequence . This can be achieved  using grab()  method on the sequencer on an interrupt to stop the register read/write sequence and execute the interrupt sequence. ungrab() method should be used to return the sequencer control back to the register read/write sequence.

Generic Payload in UVM !!!

Generic payload is the default transport vehicle for TLM2  blocking and non blocking transport interface. Generic payload is a transaction class derived from uvm_sequence_item which enables it to be generated in sequences and transported to drivers through sequencers. Generic payload can be used for any memory mapped bus based system. Generic payload has property like m_address , m_command, m_byte_enables etc. Generic payload class has access methods for each of the property which is virtual enabling it to be used in the class that extends generic payload class.

It would be good idea to explore the generic payload transaction class before writing your own transaction class for memory mapped bus interface.

Base class library specific to product on top of RVM/VMM/OVM/UVM !!!

RVM/VMM/OVM/UVM provides rich set of features that can be used to develop a sophisticated test bench. Extending your Driven/monitor/scoreboard/sequence directly from the methodology may not be an ideal solution with respect to product specific requirement. The ideal way is have a set of base class extending from the methodology class which adds specific requirement which will be product line specific. Having company/product specific base class helps in better reuse and isolates the users from the changes introduced  due to new releases in the methodology. When ever specific base class is changed it can be qualified with the supported version of tool,methodology and VIP. This approach also helps to incrementally move towards the latest releases of the methodology ensuring current development effort is not stalled.