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

SystemVerilog API Overview
Operational Transaction Fields
Mentor VIP AE AXI3/4 User Guide, V10.2b 27
September 2013
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:
// 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
AXI3 BFM
Handshake Delay and AXI3 BFM Delay Mode 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.