Monday, August 3, 2009

Creating Flexible and Consistent Transactions

Continuing on benefits for those who are used to working with RTL language and building on a methodology-based logging mechanism, we will next look into generation and use of transactions facilitated via a comprehensive VMM verification methodology.

Transactors are components of verification environment that interface between different levels of a protocol implementation. Going back to our ATM example, at a higher level, you will generate ATM frames that will eventually be driven on to a physical interface such as Utopia Level-1 or Level-2. An ATM cell generator mechanism that provides such an interface to the Utopia physical interface is a transactor. So generators, drivers, monitors, and checkers are example of such transactors.

Bus functional models (BFMs) are command-layer transactors which include transaction-level interface on one side and physical interface on the other. Other types of transactors include functional-layer and scenario-layer.

Transactors should be flexible and consistent given that they and consistent given that they are likely to be reused in multiple testcases and potentially across different verification environment. For example, a well-designed USB interface verification environment can be used across many designs that use USB interface. Transactors should meet specific needs for various test cases and hence need to be controllable. Also, transactors should be able to be extended to meet needs of a verification environment.

With the goals of creating flexible and consistent transactions, vmm_xactor provides a template from which we can derive various transactors of typical interest in a verification environment. It contains standard properties and methods to configure and control transactors in a way that results in a consistent usage model for all transactors derived from the same base class.

The properties of vmm_xactor class are similar to the vmm_data class as we discussed in a prior blog and the basic methods of the vmm_xactor class include:

· the constructor method, new()
· start_xactor(): controls execution of the main method, forks it off. It can be extended to include protocol specific behavior.
· reset_xactor(): control execution of the main method, terminates it.
· stop_xactor() and some variations of stop to allow blocking and non-blocking conditions, control execution of the main method, terminates it.
· main() is spawned when start_xactor() is called from upper layers and all threads are forked and join in the body if main() task.

So an ATM Utopia layer driving transactor will extend vmm_xactor to define a transactor as follows:

class utopia1_driver extends vmm_xactor;

//declare property members of the utopia1_layer_driver such as channels, interfaces

function new (string inst, int stream_id = -1, …);
//standard constructor specific code
endfunction: new

virtual function void start_xactor();
//any utopia1_driver specific code
endfunction: start_xactor

virtual function void reset_xactor();
//any utopia1_driver specific code
endfunction: reset_xactor

virtual function void stop_xactor();
//any utopia1_driver specific code
endfunction: stop_xactor

virtual protected task main();
// code for main functionality of utopia1_driver
forever begin
//generate transaction
//drive transaction
endtask: main

endclass: utopia1_driver

Physical interfaces when specified use “virtual modport interface” that allows each instance of transactor to be connected to a specific interface instance without hardcoding signal naming.

class utopia1_driver extends vmm_xactor;

virtual atm_if.utopia1 sigs;
endclass: utopia1_driver

The traditional BFMs are physical-level BFMs and are tied to specific physical-level interface. With vmm_transactor, BFMs need not be tied to physical interfaces but can purely be implementation independent transaction-level BFM.

Transaction-level interface also requires a concept of vmm_channels to remove higher-level layers from the physical interface details. Channel is a conduit that is used to exchange information between transactors and we will next look into channels and transaction-level interfaces

The latest release of VMM (VMM 1.2) also implements a set of transport interface classes based on OSCI TLM 2.0 standard that provide standard transaction-level modeling communication methods. This adds remote procedure call functionality between components and extends support to SystemC modules. As a result, one can now easily integrate reference models written in SystemC with TLM-2.0 transport interface directly in your VMM testbench. As we go further in this blog, we will look into also relevant SystemC developments and how this plays into system-level verification using a SystemVerilog verification methodology.