Accelerating Verification Component development with OSVVM Model Independent Transactions

Verification components have become an essential part of a structured VHDL environment.   In OSVVM we implement verification components as an entity and architecture.   This provides RTL engineers with a familiar environment to create model behavior.

The objective of any verification framework is to make the Device Under Test (DUT) “feel like” it has been plugged into the board.   Hence, the framework must be able to produce the same waveforms and sequences of waveforms that the DUT will see on the board.

The OSVVM testbench framework looks identical to other frameworks, including SystemVerilog.  It includes verification components (Axi4Master, Axi4Responder, and Axi4Memory) and TestCtrl (the test sequencer) as shown in Figure 1.  The top level of the testbench connects the components together (using the same methods as in RTL design) and is often called a test harness.  Connections between the verification components and TestCtrl use VHDL records (which we call the transaction interface).   Connections between the verification components and the DUT are the DUT interfaces (such as AxiStream, UART, AXI4, SPI, and I2C).

Figure 1.  OSVVM Testbench Framework

Writing tests is all about creating waveforms at an interface.   In a basic test approach, each test directly drives and wiggles interface waveforms.  This is tedious and error prone.

In OSVVM, signal wiggling is replaced by transactions.  A transaction is an abstract representation of an interface waveform (such as Write) or a directive to the VC (such as wait for clock).  A transaction is initiated using a procedure call.  In a VC based approach, the procedure call collects the transaction information and passes it to the VC via a transaction interface (a record).   The VC then decodes this information and creates the corresponding interface waveforms.

Using transactions simplifies creating tests and increases their readability.   Figure 2 shows calls to the Write, Read, and ReadCheck transactions for an Axi4Master VC.  In this test, the responses are provided by an Axi4Memory VC.

MasterProc : process
begin
    . . .
    log("Write and Read with ByteAddr = 0, 4 Bytes") ;
    Write(MasterRec, X"0000_0000", X"5555_5555" ) ;
    Read(MasterRec,  X"0000_0000", Data) ;
    AffirmIfEqual(Data, X"5555_5555", "Super Read Data: ") ;

    log("Write and Read with 1 Byte, and ByteAddr = 1") ;
    Write(MasterRec, X"0000_0011", X"22" ) ;
    ReadCheck(MasterRec, X"0000_0011", X"22" ) ;  

    log("Write and Read with 3 Bytes and ByteAddr = 0") ;
    Write(MasterRec, X"0000_0050", X"33_2211" ) ;
    ReadCheck(MasterRec, X"0000_0050", X"33_2211" ) ;

Figure 2. Calls to Axi4Master Write, Read, and ReadCheck Transactions

OSVVM Model Independent Transactions make the observation that from a transaction level perspective, many interfaces support the same transactions.   For example, Address Bus interfaces (such as AXI, AVALON, Wishbone, …) support write and read transactions using address and data.   Similarly, Streaming interfaces (such as AxiStream, UART, …) support either send or get transactions, or both.

For the test case developer, model independent transactions provide address bus interfaces and streaming interfaces with a common set of transactions (API).  This makes writing test cases easier since the transaction interface (API) is already familiar.  This also facilitates either re-use of test sequences between different verification components or porting tests from one interface to another.

Ordinarily in OSVVM, there are three steps required to create a verification component:

1. Define the transaction interface (in OSVVM it is a record)
2. Define the transaction procedures (the call API for the test sequencer)
3. Define the internals of the verification component itself.

With model independent transactions a testbench/verification component developer re-uses the transaction interface and procedures defined by model independent transactions.   This allows the VC developer to focus on just the behavior of the verification component.  In addition, many of the directive transactions can be copied from models of a similar class.  This helps save time in testbench development.

Our webinar on Thursday December 10^th provides a guided walk-through of the OSVVM model independent transactions.