Altera Mentor Verification IP Altera Edition AMBA AXI3/4TM - Manual (Page 217)

VHDL API Overview
Operational Transaction Fields
Mentor VIP AE AXI3/4 User Guide, V10.2b 199
September 2013
You can configure this behavior to be nonblocking by setting the operation_mode transaction
field to the enumerate type value **_TRANSACTION_NON_BLOCKING instead of the default
**_TRANSACTION_BLOCKING.
For example, in a master BFM test program you create a transaction by calling the
create_read_transaction() or create_write_transaction() tasks which creates a transaction
record. Before executing the transaction record the operation_mode can be changed as follows:
-- * = axi| axi4
-- ** = AXI | AXI4
-- Create a write transaction to create a transaction record
create_write_transaction(1, tr_id, bfm_index, *_tr_if_0(bfm_index));
-- Change operation_mode to be nonblocking in the transaction record
set_operation_mode(**_TRANSACTION_NON_BLOCKING, tr_id, bfm_index,
*_tr_if_0(bfm_index));
In the above example, the bfm_index specifies the BFM.
Channel Handshake Delay
Each of the five protocol channels have *VALID and *READY handshake signals to 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
AXI3 BFM
Handshake Delay and AXI3 BFM Delay Mode for details of the AXI3 BFM API, and AXI3
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
There are 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 7-2 below specifies which operational delay
transaction fields are configured by the master and slave BFMs.
Table 7-2. Handshake Signal Delay Transaction Fields
Signal Operational Transaction Field Configuration BFM
AWVALID address_valid_delay Master
AWREADY address_ready_delay Slave