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. 

TLM 2.0 Sockets in UVM !!!

Normally the connection between two processes is through port and export , but with TLM 2.0 we have sockets which provide asynchronous pipelined bi directional connectivity between components. Socket has both a export and port packaged together. A socket can  be initiator socket or target socket. Data flows in the forward direction from the initiator socket to target socket , there is also a backward path between Target socket to initiator socket. TLM connectivity between components can be easily encapsulated using sockets.

Phases in UVM !!!

UVM component have different phases like build() , connect() , end_of_elaboration() , start_of_simulation(), run() , extract() , check() & report().  Except run() all other phases are virtual functions , run() phase is a virtual task.

phases operate in a particular sequence  as follows build ->  connect  -->  end_of_elaboration --> start_of_simulation --> run --> extract --> check --> report. All the phases except build() phase is bottom up , build phase is top down. In UVM we have provision to add custom phase.

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.