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

Mentor VIP AE AXI3/4 User Guide, V10.2b 203
September 2013
Chapter 8
VHDL AXI3 and AXI4 Master BFMs
This section provides information about the VHDL AXI3 and AXI4 master BFMs. Each BFM
has an API that contains procedures to configure the BFM and to access the dynamic
Transaction Record during the life of the transaction.
Note
Due to AXI3 protocol specification changes, for some BFM procedures, you reference
the AXI3 BFM by specifying AXI instead of AXI3.
Overloaded Procedure Common Arguments
The BFMs use VHDL procedure overloading, which results in the prototype having a number
of prototype definitions for each procedure. Their arguments are unique to each procedure and
concern the protocol or operational transaction fields for a transaction. These procedures have
several common arguments which can be optional and include the arguments described below:
•
transaction_id is an index number that identifies a specific transaction. Each new
transaction automatically increments the index number until reaching 255, the
maximum value, and then the index number automatically wraps to zero. The
transaction_id uniquely identifies each transaction when there are a number of
concurrently active transactions.
•
queue_id is a unique identifier for each queue in a testbench. A queue is used to pass the
record of a transaction between the address, data and response channels of a write
transaction, and the address and data channels of a read transaction. There is a maximum
of five queues available within an AXI3 BFM and eight queues available within an
AXI4 BFM. Refer to
“AXI3 Advanced Slave API Definition” on page 630 “AXI4
Advanced Slave API Definition” on page 643 for more details on the application of the
queue_id.
•
bfm_id is a unique identification number for each master, slave, and monitor BFM in a
multiple BFM testbench.
•
path_id is a unique identifier for each parallel process in a multiple process testbench.
You must specify the path_id for testbench stimulus to replicate the pipelining features
of a protocol in a VHDL testbench. If no pipelining is performed in the testbench
stimulus (a single process), then specifying the path_id argument for the procedure is
optional. There is a maximum of five paths available within an AXI3 BFM and eight
paths available within an AXI4 BFM. Refer to
“AXI3 Advanced Slave API Definition”