Using the axi3 basic slave test program api – Altera Mentor Verification IP Altera Edition AMBA AXI3/4TM User Manual
Page 649
VHDL Tutorials
Verifying a Master DUT
Mentor VIP AE AXI3/4 User Guide, V10.2b
629
September 2013
Note
In addition to the above procedures, you can configure other aspects of the AXI3 Slave
BFM by using the procedures:
Using the AXI3 Basic Slave Test Program API
As described in the
AXI3 Basic Slave API Definition
section, there are a set of procedures that
you use to create stimulus scenarios based on a memory-model slave with a minimal amount of
editing. However, consider the following configurations when using the Slave Test program.
•
- the read and write channel interaction can cause simultaneous read and
write transactions to occur at the same address. With the default
read transaction, data burst is buffered at the start of the burst and the write data burst is
buffered at the end of the burst. This can result in the read data being stale at the time it
is transmitted over the protocol signals. If this is an undesirable result, then set the
to be AXI_PHASE_SLAVE.
•
delay_mode - by default, the handshake *READY signal always follows, or is
simultaneous with the *VALID signal. By configuring the delay_mode to be
AXI_TRANS2READY, *READY before *VALID scenarios can be achieved.
•
m_max_outstanding_read_trans - The maximum number of outstanding (incomplete)
read transactions that can be initiated by a master test program before the slave test
program applies back-pressure to the master by deasserting the ARREADY signal. When
subsequent read transactions complete, then the slave test program asserts ARREADY.
•
m_max_outstanding_write_trans - The maximum number of outstanding (incomplete)
write transactions that can be initiated by a master test program before the slave test
program applies back-pressure to the master by deasserting the AWREADY signal. When
subsequent read transactions complete, then the slave test program asserts AWREADY.