UCInterfaceDocTransBasedTB < P1076/Ballots

P1076/Ballots Web>CollectedRequirements>P1076BallotsInterfaceAndBundleEnhancements>UCInterfaceDocTransBasedTB (2016-11-15, BrentHahoe) (raw view)EditAttach
---+ 3.1. Transaction Based Testbench

---++ 3.1.1. Basic Transactions

A transaction is an operation on a device interface. As such it could be a cpu read or a cpu write. A transaction is
often either specified or created using a procedure. A test is created by calling transactions in a given sequence with
specified values. For example,

<sticky><verbatim>
   CpuTestProc : process -- TestCtrl_UartRx1
      -- Declarations left out
   begin
      wait until nReset = '1' ;

      CpuWrite(CpuRec, UART_DIVISOR_HIGH, X"0000");
      CpuWrite(CpuRec, UART_DIVISOR_LOW, X"000A");
      CpuWrite(CpuRec, UART_CFG1, X"00" & "00" &
         PARITY_EVEN & STOP_BITS_1 & DATA_BITS_8);
      . . .
      CpuRead (CpuRec, UART_TX_INT_STAT, DataO);

      SyncTo(SyncIn => UartTxRdy, SyncOut => CpuRdy);

      for I in 0 to 3 loop
         CpuPoll(CpuRec, UART_RX_INT_STAT, RX_DATA_VALID, '1') ;
         CpuReadCheck (CpuRec, UART_DATA, X"4A" + I, true);
      end loop ;
      . . .
</verbatim></sticky>

A simple approach to transactions is to implement the interface behavior in the procedure call. The limitation to this
is that procedure is strictly sequential. While sequential code works well for some applications (like cpu read and
cpu write) it does not work well for applications that require detailed statemachines (such as a UART receiver).

---++ 3.1.2. Transaction Based Bus Functional Models

In the approach shown below, each independent interface behavior is implemented in a separate interface behavior
model (aka: transactor, server) and all of the transactions are grouped together in a single transaction source (aka:
test control, client). The transaction source specifies sequences of transactions. The interface behavioral model
creates the interface behavior specified in the transaction. The connection between the transaction source and
interface behavior model can be represented as an interface (!CpuIf, !UartTxIf, !UartRxIf).

<img src="%ATTACHURLPATH%/IFDocTransModelTBtop.png" alt="IFDocTransModelTBtop.png" width='730' height='444' />

The interface is used to abstractly carry the data items needed to support the transactions. Some interface elements
will have a single driver and some will have multiple drivers. There is also a need for handshaking between the
models. To support a wide range of modeling styles, the handshaking will need to support both blocking (such as
read request and return with the read data) and non-blocking (accept the data from serial port now or it is gone). It
may also need to support closed loop handshaking (ready-ready or ready-ack &#8211; perhaps only for blocking) and openloop
handshaking (event or edge based &#8211; perhaps only for non-blocking).

The interface behavior model receives transactions from the transaction source via the interface and creates
appropriate signaling to the UUT. Implementing the interface behavior model as an entity facilitates modeling
behavior that requires multiple processes (complex statemachines). In addition there are items that need to be
modeled (such as assertions and protocol checkers) that are convenient to group in the same model.
Grouping all transactions into a single transaction source facilitates creating interactions between different models.
Most interactions can be controlled by signals local to the transaction source rather than by signals that must go
through hierarchical levels of the design. Note that the transaction source has one interface per interface behavior
model. Hence an entity port list can contain multiple interfaces (interface here being more like a composite type and
not a separate IO list).

A further benefit of this modeling methodology is that if a model in the system needs to change, such as changing
the !CpuModel from an X86 type model to a 68000, only the model and the UUT need to change. Many or all of the
transactions specified in the transaction source remain unchanged.

Details of an approach that uses this methodology and implements the interface as a record with elements that are
based on std_logic is available in the second half of the paper titled, "Accelerating Verification Through Pre-Use of
System-Level Testbench Components" that is available at: http://www.synthworks.com/papers/index.htm.
Attachments
I	Attachment	Action	Size	Date	Who	Comment
png	IFDocTransModelTBtop.png	manage	56.8 K	2015-07-21 - 14:04	BrentHahoe	IF document transaction model test bench
Topic revision: r4 - 2016-11-15 - 18:23:41 - BrentHahoe
P1076/Ballots