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.
Sunday, December 22, 2013
Sunday, November 3, 2013
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.
Sunday, October 13, 2013
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.
Sunday, September 29, 2013
Thursday, August 15, 2013
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.
Saturday, July 13, 2013
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
- Coverage monitors are not required to collect required coverage event and then trigger a cover group.
- 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.
- Implementing and collecting assertion coverage is faster compared to writing functional coverage for DUT events.
- Assertion coverage is perfect fit for collecting coverage on important DUT events.
Disadvantages of assertion coverage
- Assertions coverage if not coded appropriately takes considerable amount of simulation time.
- Debugging assertion failures is slightly complex than debugging coverage events in a passive monitor.
Saturday, June 1, 2013
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.
Thursday, May 2, 2013
Saturday, April 6, 2013
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.
Sunday, March 10, 2013
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.
Saturday, February 2, 2013
We come across different types of layering requirement for different protocols. Basic ones are as follows.
- One to one mapping -- One higher level protocol frame is mapped to the payload of one lower level protocol frame.
- One to many mapping -- One higher level protocol frame is mapped to the payload of many lower level protocol frames.
- Many to one mapping -- Many higher level protocol frames are mapped to the payload of single lower level protocol frame.
- 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.
Tuesday, January 1, 2013
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.