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

Mentor VIP AE AXI3/4 User Guide, V10.2b 28
SystemVerilog API Overview
Operational Transaction Fields
September 2013
Table 2-2. Handshake Signal Delay Transaction Fields
Note
The data channel handshake signal transaction fields (data_valid_delay[] and
data_ready_delay[]) are defined as arrays so that the *VALID to *READY delay can be
configured on a per data phase (beat) basis in a transaction.
AXI4 BFM Handshake Delay
The delay between the *VALID and *READY handshake signals for each of the five protocol
channels is controlled in a BFM test program using execute_*_ready(), get_*_ready(), and
get_*_cycle() tasks. The execute_*_ready() tasks place a value onto the *READY signals and
the get_*_ready() tasks retrieve a value from the *READY signals. The get_*_cycle() tasks wait
for a *VALID signal to be asserted and are used to insert a delay between the *VALID and
*READY signals in the BFM test program.
For example, the master BFM test program code below inserts a specified delay between the
read channel RVALID and RREADY handshake signals using the execute_read_data_ready()
and get_read_data_cycle() tasks.
// Set the RREADY signal to ‘0’ so that it is nonblocking
fork
bfm.execute_read_data_ready(1'b0);
join_none
// Wait until the RVALID signal is asserted and then wait_on the specified
// number of ACLK cycles
bfm.get_read_data_cycle;
repeat(5) bfm.wait_on(AXI4_CLOCK_POSEDGE);
// Set the RREADY signal to ‘1’ so that it blocks for an ACLK cycle
bfm.execute_read_data_ready(1'b1);
Signal Operational Transaction Field Configuration BFM
AWVALID address_valid_delay Master
AWREADY address_ready_delay Slave
WVALID data_valid_delay Master
WREADY data_ready_delay Slave
BVALID write_response_valid_delay Slave
BREADY write_response_ready_delay Master
ARVALID address_valid_delay Master
ARREADY address_ready_delay Slave
RVALID data_valid_delay Slave
RREADY data_ready_delay Master