Channel handshake delay, Axi3 bfm handshake delay, Axi3 bfm handshake signal delay transaction fields – Altera Mentor Verification IP Altera Edition AMBA AXI3/4TM User Manual

Page 45

SystemVerilog API Overview

Operational Transaction Fields

Mentor VIP AE AXI3/4 User Guide, V10.2b

September 2013

For example, in a master BFM test program you create a transaction by calling the

create_read_transaction()

create_write_transaction()

tasks which creates a transaction

record. Before executing the transaction record, the operation_mode can be changed as follows:

// Create a write transaction to create a transaction record
trans = bfm.create_write_transaction(1);

// Change operation_mode to be nonblocking in the transaction record
trans.operation_mode(AXI_TRANSACTION_NON_BLOCKING);

Note

The above test program code segments are for AXI3 BFMs. Substitute the
AXI_TRANSACTION_NON_BLOCKING enumeration with
AXI4_TRANSACTION_NON_BLOCKING for AXI4 BFMs.

Channel Handshake Delay

Each of the five protocol channels have *VALID and *READY handshake signals that control
the rate at which information is transferred between a master and slave. The API to control these
handshake signals differs between the AXI3 BFMs and AXI4 BFMs. Refer to the

for details of the AXI3 BFM API, and

AXI4

BFM Handshake Delay

for details of the AXI4 BFM API.

AXI3 BFM Handshake Delay

The delay between the *VALID and *READY handshake signals for each of the five protocol
channels can be configured. The delay can be defined per phase (beat) basis for a particular
transaction, measured from the positive edge of ACLK when *VALID is asserted. The delay can
also be set from the completion of a previous transaction phase (*VALID and *READY both
asserted).

AXI3 BFM Handshake Signal Delay Transaction Fields

The transaction record contains transaction fields to configure the desired handshake delay
pattern for a particular transaction phase on any of the five protocol channels. The master BFM
configures the *VALID and *READY signal delays that it asserts, and the slave BFM configures
the *VALID and *READY signal delays that it asserts.

Table 2-2

specifies which operational

delay transaction fields are configured by the master and slave BFMs.