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

Page 218

Advertising
background image

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

200

VHDL API Overview
Operational Transaction Fields

September 2013

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() procedures. The execute_*_ready() procedures place a value onto the *READY
signals, and the get_*_ready() procedures retrieve a value from the *READY signals. The
get_*_cycle() procedures 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() procedures.

-- Set the RREADY signal to ‘0’.
execute_read_data_ready(0, 1, bfm_index, AXI4_PATH_6,

axi4_tr_if_6(bfm_index));

-- Wait for the RVALID signal to be asserted.
get_read_data_cycle(bfm_index, AXI4_PATH_6,

axi4_tr_if_6(bfm_index));

-- Add delay between RVALID and RREADY.
for i in 0 to 2 loop

wait_on(AXI4_CLOCK_POSEDGE, bfm_index, AXI4_PATH_6,

axi4_tr_if_6(bfm_index));

end loop;
execute_read_data_ready(1, 1, bfm_index, AXI4_PATH_6,

axi4_tr_if_6(bfm_index));

In the above example, the bfm_index specifies the BFM.

AXI4 BFM *VALID Signal Delay Transaction Fields

The transaction record contains a *_valid_delay transaction field for each of the five protocol
channels to configure the delay value prior to the assertion of the *VALID signal for the
channel. The master BFM holds the delay configuration for the *VALID signals that it asserts,

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

Advertising