Axi BFM
Axi BFM
Axi BFM
Chapter 1: Overview
Core Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
BFM Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Licensing and Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix C: Debugging
Finding Help on Xilinx.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Interface Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Features Simulation
Model
Encrypted Verilog
Notes:
1. For a complete list of supported derivative devices, see
the Vivado IP catalog.
2. Windows XP 64-bit is not supported.
3. For the supported versions of the tools, see the
Xilinx Design Tools: Release Notes Guide.
4. This IP does not deliver BFM for Zynq PS. It only delivers
the BFM cores for AXI3, AXI4, AXI4-Lite, and AXI4-Stream
interfaces.
Overview
Core Architecture
The general AXI BFM core architecture is shown in Figure 1-1.
X-Ref Target - Figure 1-1
$;,%)0
&RQILJXUDWLRQ
)XQFWLRQ$3,
&KDQQHO$3,
6LJQDO,QWHUIDFH
Figure 1-1: Core Architecture
• Signal interface
• Channel API
• Function API
The signal interface includes the typical Verilog input/output ports and associated signals.
The channel API is a set of defined Verilog tasks (see Test Writing API) that operate at the
basic transaction level inherent in the AXI protocol, including:
This split enables the tasks associated with each channel to be executed concurrently or
sequentially. This allows the test writer to control and implement out-of-order transfers,
interleaved data transfers, and other features.
The next level up in the API hierarchy is the function level API (see Test Writing API). This
level has complete transaction level control. For example, a complete AXI read burst process
is encapsulated in a single Verilog task.
An important component of the AXI BFM core architecture is the configuration mechanism.
This is implemented using Verilog parameters and/or BFM internal variables and is used to
set the address bus width, data bus width, and other parameters. The reason Verilog
parameters are used instead of defines is so that each BFM can be configured separately
within a single test bench.
For example, it is reasonable to have an AXI master that has a different data bus width than
one of the slaves it is attached to (in this case the interconnect needs to handle this). BFM
internal variables are used for configuration variables that maybe changed during
simulation. For a complete list of configuration options, see Configuration Options.
The intended use of the AXI BFM cores are shown in Figure 1-2.
X-Ref Target - Figure 1-2
7HVWY
7HVWEHQFKY
$;,%)0
&RQILJXUDWLRQ
)XQFWLRQ$3,
7HVW3URJUDP
&KDQQHO$3,
&ORFNDQG5HVHW 6LJQDO,QWHUIDFH
*HQHUDWRU
'87
Figure 1-2 shows a single AXI BFM core. However, the test bench can contain multiple
instances of AXI BFM core. The DUT and the AXI BFM core are instantiated in a test bench
that also contains a clock and reset generator. Then, the test writer instantiates the test
bench into the test module and creates a test program using the BFM API layers. The test
program would call API tasks either sequentially or concurrently using fork and join. See
Chapter 5, Example Design and Chapter 6, Test Bench for practical examples of test
programs and test bench setups.
Configuration Options
In most cases, the configuration options are passed to the AXI BFM cores through Verilog
parameters. AXI BFM core internal variables are used for options that can be dynamically
controlled by the test writer because Verilog parameters do not support run time
modifications.
To change the AXI BFM core internal variables during simulation, the correct BFM API task
should be called. For example, to change the CHANNEL_LEVEL_INFO from 0 to 1, the
set_channel_level_info(1)task call should be made. For more information on the
API for changing internal variables, see Test Writing API.
Applications
The purpose of the AXI BFM cores are to verify connectivity and basic functionality of AXI
masters and AXI slaves. A basic level of protocol checking is included with the AXI BFM
cores. For comprehensive protocol checking, the Cadence AXI UVC [Ref 1] should be
deployed.
The following aspects of the AXI3 and AXI4 protocol are checked by the AXI BFM cores:
This section describes the checkers that are implemented as Verilog tasks.
BFM Limitations
The purpose of this IP is to enable Xilinx customers to verify that their designs are able to
communicate with Xilinx IP using AXI3 or AXI4 protocol. The complete verification of such
interfaces with regards to protocol compliance is not within the scope of the AXI BFM cores;
for compliance testing and complete verification of AXI interfaces then the Cadence AXI
UVC should be deployed.
The BFM cores are implemented in behavioral Verilog-2001 and as such are limited to the
constructs available for this version of Verilog. For that reason, some of the checking might
seem limited compared with other VIP offerings that can leverage from assertion languages
like SVA or PSL. Furthermore, there are no constructs inside Verilog-2001 to prevent or
handle test bench race conditions. This means that the test writer must ensure that they are
not causing race conditions by calling the Function Level API tasks within concurrent blocks
(for example, inside a fork... join block). It is possible to use the concurrent blocks to create
certain scenarios as illustrated in the example tests provided with this VIP.
The most common protocol violation caused by such race conditions is violation of the AXI3
write ordering rules: the first write transfer of each burst MUST be in the same order as the
address phase transfers that is. the WID of the first transfer in each burst must be in the
same order as the associated AWIDs. This is an incredibly difficult check to write in
Verilog-2001 but a limited debug check is available to help detect and debug such a
condition (see the function "set_write_id_order_check_feature_value" in Section
5 for more details on how to enable this).
Another limitation for BFM is that AXI Master BFM does not allow the same ID for
outstanding transactions. Each outstanding transaction must be given an unique ID.
The BFM cores are encrypted using the Verilog P1735 IEEE standard. End users should note
that while there are no import/export restrictions on this verification IP there maybe be a
need for the correct simulator license feature for 256-bit AES decryption.
For more information, visit the AXI Bus Functional Model web page.
Information about other Xilinx LogiCORE IP modules is available at the Xilinx Intellectual
Property page. For information on pricing and availability of other Xilinx LogiCORE IP
modules and tools, contact your local Xilinx sales representative.
IMPORTANT: When simulating AXI BFM cores, the license is checked out and held until the simulation
is completed.
Product Specification
Standards
The AXI BFM cores are AXI4, AXI4-Lite, AXI4-Stream, and AXI3 compliant.
AXI3 BFM
AXI3 Master BFM
Table 3-1 contains a list of parameters and configuration variables supported by the AXI3
Master BFM.
AXI4 BFM
AXI4 Master BFM
Table 3-3 contains a list of parameters and configuration variables supported by the AXI4
Master BFM.
It controls the gap between the write address phase and the write data
WRITE_BURST_ADDRESS_DATA_ burst inside the WRITE_BURST task. This value is an integer number and
PHASE_GAP is measured in clock cycles.
Default is 0.
It controls the gap between the write data burst and the write address
phase inside the WRITE_BURST_CONCURRENT. This enables you to start
WRITE_BURST_DATA_ADDRESS_
the address phase at anytime during the data burst. This value is an
PHASE_GAP
integer number and is measured in clock cycles.
Default is 0.
This value, measured in clock cycles, is the value used to determine if a
task that is waiting for a response should timeout.
RESPONSE_TIMEOUT
Default is 500 clock cycles.
A value of zero means that the timeout feature is disabled.
This configuration value is used to enable/disable the checks for the
reset values of input signals to the BFM. For example, the slave BFM
DISABLE_RESET_VALUE_CHECKS
checks at reset time if the signals from the master are at the expected
reset values.
This configuration variable is used to enable/disable the stopping of the
simulation on an error condition.
STOP_ON_ERROR
The default value of one stops the simulation on an error.
Note: This is not used for timeout errors; such errors always stop simulation.
This configuration variable controls the printing of channel level
information messages. When set to 1 info messages are printed, when
CHANNEL_LEVEL_INFO
set to zero no channel level information is printed.
The default (0) disables the channel level info messages.
For all functions in the API, the input and output values used for burst length and burst size
are encoded as specified in the AMBA® AXI Specifications [Ref 7]. For example, LEN = 0 as
an input means a burst of length 1.
Tasks and functions common to all BFM are described in Table 3-9.
AXI Slave Channel API inputs typically use inputs that are AXI Protocol transaction
arguments which use the data type reg signals (for example, AXI protocol BURST_TYPE,
PROT TYPE, etc.) that are passed between APIs.
Output arguments from APIs use the reg data type. For further clarification, see Chapter 6,
Test Bench delivered with the core.
tb.master_0.cdn_axi4_master_bfm_inst.set_write_burst_data_transfer_gap(0);
Table 3-10: Channel Level API for AXI3 Master BFM (Cont’d)
API Task Name and Description Inputs Outputs
RECEIVE_READ_BURST
This task receives a read channel burst based on the ID ID: Read ID tag DATA: Valid Data
input. The RECEIVE_READ_DATA from the channel level ADDR: Read Address transferred by the slave
API is used. LEN: Burst Length RESPONSE: This is a
This task returns when the read transaction is SIZE: Burst Size vector that is created by
complete. The data returned by the task is the valid concatenating all slave
BURST: Burst Type
only data, that is, re-aligned data. This task also checks
LOCK: Lock Type read responses together
each response and issues a warning if it is not as
expected.
SEND_WRITE_BURST
ID: Write ID tag
This task does a write burst on the write data lines. It
does not execute the write address transfer. This task ADDR: Write Address
uses the SEND_WRITE_DATA task from the channel LEN: Burst Length
level API. SIZE: Burst Size
This task returns when the complete write burst is BURST: Burst Type None
complete. DATA: Data to send
This task automatically supports the generation of DATASIZE: The size in bytes
narrow transfers and unaligned transfers; that is, this of the valid data contained
task aligns the input data with the burst so data in the input data vector
padding is not required.
The function level API for the AXI3 Master BFM is detailed in Table 3-11.
Table 3-11: Function Level API for AXI3 Master BFM (Cont’d)
API Task Name and Description Inputs Outputs
ID: Write ID tag
ADDR: Write Address
LEN: Burst Length
SIZE: Burst Size
WRITE_BURST_CONCURRENT
BURST: Burst Type
This task does the same function as the RESPONSE: The slave write
LOCK: Lock Type
WRITE_BURST task; however, it performs the response from the following:
write address and write data phases CACHE: Cache Type [OKAY, EXOKAY, SLVERR, DECERR]
concurrently. PROT: Protection Type
DATA: Data to send
DATASIZE: The size in bytes
of the valid data contained
in the input data vector
ID: Write ID tag
ADDR: Write Address
WRITE_BURST_DATA_FIRST LEN: Burst Length
This task does the same function as the SIZE: Burst Size
WRITE_BURST task; however, it sends the BURST: Burst Type
write data burst before sending the RESPONSE: The slave write
LOCK: Lock Type response from the following:
associated write address transfer on the
write address channel. This is used in CACHE: Cache Type [OKAY, EXOKAY, SLVERR, DECERR]
scenario wherein before the slave asserts PROT: Protection Type
AWREADY and/or WREADY the slave can DATA: Data to send
wait for WVALID. DATASIZE: The size in bytes
of the valid data contained
in the input data vector
Table 3-12: Channel Level API for AXI3 Slave BFM (Cont’d)
API Task Name and Description Inputs Outputs
RECEIVE_WRITE_DATA
This task drives the WREADY signal and monitors the
write data bus for write transfers coming from the ID: Write ID tag DATA: Data transferred
master that have the specified ID tag (unless the IDValid: Bit to indicate if the from the master
IDValid bit = 0). It then returns the data associated ID input parameter is to be STRB: Strobe signals used
with the transaction and the status of the last flag. used. When set to 1 the ID is to validate the data
Note: This would need to be called multiple times for a valid and used, when set to 0 LAST: Last transfer flag
burst > 1. it is ignored. IDTAG: Sampled ID tag
If the IDValid bit is 0 then the input ID tag is not used
and the next available write data transfer is sampled.
RECEIVE_WRITE_BURST
This task receives and processes a write burst on the
write data channel with the specified ID (unless the ID: Write ID tag
IDValid bit =0). It does not wait for the write address IDValid: Bit to indicate if the
transfer to be received. This task uses the DATA: Data received from
ID input parameter is to be
RECEIVE_WRITE_DATA task from the channel level API. the write burst
used. When set to 1 the ID is
If the IDValid bit is 0 then the input ID tag is not used valid and used, when set to 0 DATASIZE: The size in
and the next available write burst is sampled. it is ignored. bytes of the valid data
This task returns when the complete write burst is contained in the output
ADDR: Write Address
complete. data vector
LEN: Burst Length
This task automatically supports narrow transfers and IDTAG: Sampled ID tag
SIZE: Burst Size
unaligned transfers; that is, this task aligns the output
data with the burst so the final output data should BURST: Burst Type
only contain valid data (up to the size of the burst
data, shown by the output datasize).
RECEIVE_WRITE_BURST_NO_CHECKS
This task receives and processes a write burst on the
write data channel blindly, that is, with no checking of
length, size or anything else. DATA: Data received from
This task uses the RECEIVE_WRITE_DATA task from the the write burst
channel level API. This task returns when the complete DATASIZE: The size in
ID: Write ID tag
write burst is complete. This task automatically bytes of the valid data
supports narrow transfers and unaligned transfers; contained in the output
that is, this task aligns the output data with the burst data vector
so the final output data should only contain valid data
(up to the size of the burst data, shown by the output
datasize).
Table 3-12: Channel Level API for AXI3 Slave BFM (Cont’d)
API Task Name and Description Inputs Outputs
SEND_READ_BURST
This task does a read burst on the read data lines. It ID: Read ID tag
does not wait for the read address transfer to be ADDR: Read Address
received. This task uses the SEND_READ_DATA task LEN: Burst Length
from the channel level API.
SIZE: Burst Size
This task returns when the complete read burst is None
BURST: Burst Type
complete.
LOCK: Lock Type
This task automatically supports the generation of
narrow transfers and unaligned transfers; that is, this DATA: Data to be sent over
task aligns the input data with the burst so data the burst
padding is not required.
ID: Read ID tag
ADDR: Read Address
LEN: Burst Length
SIZE: Burst Size
SEND_READ_BURST_RESP_CTRL BURST: Burst Type
This task is the same as SEND_READ_BURST except DATA: Data to be sent over None
that the response sent to the master can be specified. the burst
RESPONSE: This is a vector
that should contain all of the
desired responses for each
read data transfer
The function level API for the AXI3 Slave BFM is detailed in Table 3-13.
Table 3-13: Function Level API for AXI3 Slave BFM (Cont’d)
API Task Name and Description Inputs Outputs
ID: Read ID tag
DATA: Data to send in
READ_BURST_RESP_CTRL
response to the master read.
This task is the same as READ_BURST_RESPONSE
RESPONSE: This is a vector None
except that the responses sent to the master can
that should contain all of the
be specified.
desired responses for each
read data transfer.
ID: Write ID tag DATA: Data received by
WRITE_BURST_RESP_CTRL
RESPONSE: The chosen write slave
This task is the same as WRITE_BURST_RESPONSE
response from the following DATASIZE: The size in bytes
except that the response sent to the master can be
[OKAY, EXOKAY, SLVERR, of the valid data contained
specified.
DECERR] in the output data vector
Table 3-14: Channel Level API for AXI4 Master BFM (Cont’d)
API Task Name Inputs Outputs
ID: Read Address ID tag
ADDR: Read Address
LEN: Burst Length
SIZE: Burst Size
BURST: Burst Type
SEND_READ_ADDRESS
LOCK: Lock Type
Creates a read address channel transaction. This task
CACHE: Cache Type None
returns after the read address has been acknowledged
by the slave. PROT: Protection Type
REGION: Region Identifier
QOS: Quality of Service
Signals
ARUSER: Address Read User
Defined Signals
RECEIVE_READ_DATA
This task drives the RREADY signal and monitors the
read data bus for read transfers coming from the slave DATA: Data transferred
that have the specified ID tag. It then returns the data by the slave
associated with the transaction and the status of the RESPONSE: The slave
last flag. The data output here is raw bus data; that is, read response from the
no realignment for narrow or unaligned data. following: [OKAY,
ID: Read ID tag EXOKAY, SLVERR,
Note: This would need to be called multiple times for a burst
> 1. DECERR]
Also, you must call the "remove_pending_transaction" LAST: Last transfer flag
task when all data is received to ensure that the RUSER: Read User
pending transaction counter is decremented. This is Defined Signals
done automatically by the RECEIVE_READ_BURST and
RECEIVE_WRITE_RESPONSE channel level API tasks.
RESPONSE: The slave
RECEIVE_WRITE_RESPONSE write response from the
This task drives the BREADY signal and monitors the following: [OKAY,
write response bus for write responses coming from ID: Write ID tag EXOKAY, SLVERR,
the slave that have the specified ID tag. It then returns DECERR]
the response associated with the transaction. BUSER: Write Response
User Defined Signals
Table 3-14: Channel Level API for AXI4 Master BFM (Cont’d)
API Task Name Inputs Outputs
DATA: Valid Data
transferred by the slave
RECEIVE_READ_BURST
RESPONSE: This is a
This task receives a read channel burst based on the ID ID: Read ID tag
vector that is created by
input. The RECEIVE_READ_DATA from the channel level ADDR: Read Address concatenating all slave
API is used. LEN: Burst Length read responses
This task returns when the read transaction is together
SIZE: Burst Size
complete. The data returned by the task is the valid
BURST: Burst Type RUSER: This is a vector
only data, that is, re-aligned data. This task also checks
LOCK: Lock Type that is created by
each response and issues a warning if it is not as
concatenating all slave
expected.
read user signal data
together
ADDR: Write Address
SEND_WRITE_BURST LEN: Burst Length
This task does a write burst on the write data lines. It SIZE: Burst Size
does not execute the write address transfer. This task
BURST: Burst Type
uses the SEND_WRITE_DATA task from the channel
level API. DATA: Data to send
This task returns when the complete write burst is DATASIZE: The size in bytes of None
complete. the valid data contained in
the input data vector
This task automatically supports the generation of
narrow transfers and unaligned transfers; that is, this WUSER: This is a vector that is
task aligns the input data with the burst so data created by concatenating all
padding is not required. write transfer user signal data
together
The function level API for the AXI4 Master BFM is detailed in Table 3-15.
Table 3-15: Function Level API for AXI4 Master BFM (Cont’d)
API Task Name and Description Inputs Outputs
ID: Write ID tag
ADDR: Write Address
LEN: Burst Length
WRITE_BURST SIZE: Burst Size
This task does a full write process. It is BURST: Burst Type
composed of the tasks LOCK: Lock Type
SEND_WRITE_ADDRESS,
CACHE: Cache Type
SEND_WRITE_BURST and
RECEIVE_WRITE_RESPONSE from the PROT: Protection Type RESPONSE: The slave write
channel level API. DATA: Data to send response from the following:
This task returns when the complete DATASIZE: The size in bytes of [OKAY, EXOKAY, SLVERR, DECERR]
write transaction is complete. the valid data contained in the BUSER: Write Response Channel
This task automatically supports the input data vector User Defined Signals
generation of narrow transfers and REGION: Region Identifier
unaligned transfers. This is used in QOS: Quality of Service Signals
scenario wherein before the slave asserts AWUSER: Address Write User
AWREADY and/or WREADY the slave can Defined Signals
wait for AWVALID. WUSER: This is a vector that is
created by concatenating all
write transfer user signal data
together
ID: Write ID tag
ADDR: Write Address
LEN: Burst Length
SIZE: Burst Size
BURST: Burst Type
LOCK: Lock Type
CACHE: Cache Type
WRITE_BURST_CONCURRENT PROT: Protection Type RESPONSE: The slave write
This task does the same function as the DATA: Data to send response from the following:
WRITE_BURST task; however, it performs DATASIZE: The size in bytes of [OKAY, EXOKAY, SLVERR, DECERR]
the write address and write data phases the valid data contained in the BUSER: Write Response Channel
concurrently. input data vector User Defined Signals
REGION: Region Identifier
QOS: Quality of Service Signals
AWUSER: Address Write User
Defined Signals
WUSER: This is a vector that is
created by concatenating all
write transfer user signal data
together
Table 3-16: Channel Level API for AXI4 Slave BFM (Cont’d)
API Task Name and Description Inputs Outputs
ADDR: Read Address
RECEIVE_READ_ADDRESS LEN: Burst Length
This task drives the ARREADY signal and monitors SIZE: Burst Size
the read address bus for read address transfers BURST: Burst Type
coming from the master that have the specified ID ID: Read Address ID tag
LOCK: Lock Type
tag (unless the IDValid bit = 0). It then returns the IDValid: Bit to indicate if the ID CACHE: Cache Type
data associated with the read address transaction. input parameter is to be used.
PROT: Protection Type
If the IDValid bit is 0 then the input ID tag is not When set to 1 the ID is valid
used and the next available read address transfer is and used, when set to 0 it is REGION: Region Identifier
sampled. ignored. QOS: Quality of Service
This task uses the SLAVE_ADDRESS and Signals
SLAVE_MEM_SIZE parameters to determine if the ARUSER: Address Read
address is valid. User Defined Signals
IDTAG: Sampled ID tag
Table 3-16: Channel Level API for AXI4 Slave BFM (Cont’d)
API Task Name and Description Inputs Outputs
ID: Read ID tag
SEND_READ_BURST ADDR: Read Address
This task does a read burst on the read data lines. LEN: Burst Length
It does not wait for the read address transfer to be
SIZE: Burst Size
received. This task uses the SEND_READ_DATA task
from the channel level API. BURST: Burst Type
This task returns when the complete read burst is LOCK: Lock Type None
complete. DATA: Data to be sent over the
This task automatically supports the generation of burst
narrow transfers and unaligned transfers; that is, RUSER: This is a vector that is
this task aligns the input data with the burst so created by concatenating all
data padding is not required. required slave read user signal
data together
ID: Read ID tag
ADDR: Read Address
SEND_READ_BURST_RESP_CTRL LEN: Burst Length
This task does a read burst on the read data lines. SIZE: Burst Size
It does not wait for the read address transfer to be BURST: Burst Type
received. This task uses the SEND_READ_DATA task DATA: Data to be sent over the
from the channel level API. burst
This task returns when the complete read burst is None
RESPONSE: This is a vector
complete. that should contain all of the
This task automatically supports the generation of desired responses for each
narrow transfers and unaligned transfers; that is, read data transfer
this task aligns the input data with the burst so RUSER: This is a vector that is
data padding is not required. created by concatenating all
required slave read user signal
data together
The function level API for the AXI4 Slave BFM is detailed in Table 3-17.
Table 3-17: Function Level API for AXI4 Slave BFM (Cont’d)
API Task Name and Description Inputs Outputs
READ_BURST_RESP_CTRL
Creates a semi-automatic response to a read ID: Read ID tag
request from the master. It checks if the ID tag
DATA: Data to send in
for the read request is as expected and then response to the master read
provides a read response using the data and
RESPONSE: This is a vector
response vector provided. It is composed of the
that should contain all of the
tasks RECEIVE_READ_ADDRESS and
desired responses for each None
SEND_READ_BURST_RESP_CTRL from the
read data transfer
channel level API. This task returns when the
complete write transaction is complete. RUSER: This is a vector that is
created by concatenating all
This task automatically supports the generation
required read user signal data
of narrow transfers and unaligned transfers;
together
that is, this task aligns the input data with the
burst so data padding is not required.
WRITE_BURST_RESP_CTRL
This is a semi-automatic task which waits for a
write burst with the specified ID tag and
responds appropriately using the specified
response. The data received in the write burst is DATA: Data received by slave
delivered as an output data vector. ID: Write ID tag
DATASIZE: The size in bytes of
This task is composed of the tasks RESPONSE: The chosen write
the valid data contained in the
RECEIVE_WRITE_ADDRESS, response from the following
output data vector
RECEIVE_WRITE_BURST and [OKAY, EXOKAY, SLVERR,
DECERR] WUSER: This is a vector that is
SEND_WRITE_RESPONSE from the channel level
created by concatenating all
API. BUSER: Write Response
master write transfer user
This task returns when the complete write Channel User Defined Signals
signal data together
transaction is complete. This task automatically
supports the generation of narrow transfers
and unaligned transfers; that is, this task aligns
the input data with the burst so data padding is
not required.
The function level API for the AXI4-Lite Master BFM is detailed in Table 3-19.
The function level API for the AXI4-Lite Slave BFM is detailed in Table 3-21.
Table 3-21: Function Level API for AXI4-Lite Slave BFM (Cont’d)
API Task Name and Description Inputs Outputs
ADDR: Read Address
ADDRValid: Bit to indicate if the
address input parameter is to be
used. When set to 1 the ADDR is
READ_BURST_RESP_CTRL
valid and used, when set to 0 it is
This task is the same as ignored. None
READ_BURST_RESPOND except that the
DATA: Data to send in response to
response sent to the master can be specified.
the master read
RESPONSE: The chosen write
response from the following
[OKAY, SLVERR, DECERR]
ADDR: Write Address
ADDRValid: Bit to indicate if the
address input parameter is to be
WRITE_BURST_RESP_CTRL DATA: Data received by slave
used. When set to 1 the ADDR is
This task is the same as valid and used, when set to 0 it is
DATASIZE: The size in bytes
WRITE_BURST_RESPOND except that the ignored.
of the valid data contained in
response sent to the master can be specified. the output data vector
RESPONSE: The chosen write
response from the following
[OKAY, SLVERR, DECERR]
RECEIVE_PACKET
This task receives and processes a
packet from the transfer channel. It PID: Packet ID Tag
returns when the complete packet has ID: Packet ID Tag
PDEST: Packet Destination
been sampled. IDValid: Bit to indicate if the ID
DATA: Packet data vector
This task uses the RECEIVE_TRANSFER input parameter is to be used.
When set to 1, the ID is valid and DATASIZE: The size in bytes of the
task from the channel level API.
used; when set to 0, it is ignored valid data contained in the output
If the IDValid or DESTValid bits are 0, packet data vector
the input ID tag and the DEST values DEST: Packet Destination
USER: This is a vector that is
are not used. In this case, the next DESTValid: Bit to indicate if the
created by concatenating all
values from the first valid transfer are DEST input parameter is to be used
master user signal data together
sampled and used for the full packet
irrespective of the ID tag or DEST input
values.
Protocol Description
Fore more information on AXI specification, see the ARM ® AMBA AXI4-Stream Protocol
Specification [Ref 2].
• Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
[Ref 5]
• Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 3]
• Vivado Design Suite User Guide: Getting Started (UG910) [Ref 4]
• Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 6]
If you are customizing and generating the core in the IP integrator, see the Vivado Design
Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) [Ref 5] for detailed
information. IP integrator might auto-compute certain configuration values when
validating or generating the design, as noted in Using AXI BFM Cores in Vivado IP
Integrator. To check whether the values change, see the description of the parameter in this
chapter. To view the parameter value, run the validate_bd_design command in the Tcl
Console.
You can customize the IP for use in your design by specifying values for the various
parameters associated with the IP core using the following steps:
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 3] and
the Vivado Design Suite User Guide: Getting Started (UG910) [Ref 4].
Note: Figures in this chapter are illustrations of the Vivado IDE. This layout might vary from the
current version.
Figure 4-1 and Figure 4-2 show the AXI BFM cores Customize IP dialog box with
information about customizing ports.
X-Ref Target - Figure 4-1Vivado
Basic
Note: For the run time parameter descriptions, see Table 4-1.
• Component Name – The base name of the output files generated for the core. Names
must begin with a letter and can be composed of any of the following characters: a to z,
0 to 9, and “_”.
• Protocol – Choose the specific AXI specification.
• Select the Master or Slave Mode – Select the Master or Slave mode.
Note: Based on the selection of Protocol and Mode, the next tab is updated accordingly. This guide
only shows the AXI4 Master tab.
X-Ref Target - Figure 4-2Vivado
AXI4 Master
• ID Width – ID Width default is 4.
• Data Width – Read and write data buses can be 8, 16, 32, 64, 128, 256, 512, or 1,024
bits wide. Default is 32.
• Addr Width – Address width can be configured between 12 to 64 bits. Default is 32.
• Read/Write Issuing Depth – Default is 8.
• Exclusive Access – This informs the master that exclusive access is supported by the
slave. A value of 1 means it is supported so the response check expects an EXOKAY, or
else give a warning, in response to an exclusive access. A value of 0 means the slave
does not support this so a response of OKAY is expected in response to an exclusive
access. Default is 1.
• AXI4
° Master – cdn_axi4_master_bfm_inst
° Slave – cdn_axi4_slave_bfm_inst
• AXI3
° Master – cdn_axi3_master_bfm_inst
° Slave – cdn_axi3_slave_bfm_inst
• AXI4-Lite
° Master – cdn_axi4_lite_master_bfm
° Slave – cdn_axi4_lite_slave_bfm
• AXI4-Stream
° Master – cdn_axi4_streaming_master_bfm
° Slave – cdn_axi4_streaming_slave_bfm
In this case, all of the ID width parameters (ID Width, Awuser Width, Wuser Width, Buser
Width, Aruser Width, Ruser Width) are auto set based on the AXI4 interface.
IMPORTANT: By default these parameters are automatically updated. You can override the propagated
value by changing the switch to Manual.
In this case, the ID Width parameter is auto set based on the AXI3 interface.
IMPORTANT: By default these parameters are automatically updated in IP integrator. You can override
the propagated value by changing the switch to Manual.
In this case, all of the parameters related to AXI-Stream slave interface are auto set based on
the interface connection.
IMPORTANT: By default these parameters are automatically updated in IP integrator. You can override
the propagated value by changing the switch to Manual.
AXI BFM cores can be used in IP integrator design to drive any of the supported interfaces.
You can instantiate this IP in IP integrator just like any other IP. For more information on IP
integrator, see Vivado Design User Guide: Designing IP Subsystems Using IP Integrator
(UG994) [Ref 5].
IMPORTANT: While using the AXI BFM cores in IP integrator, it is important to find the hierarchical
path of BFM instance in the IP integrator generated wrapper so that it can be called/driven from a
Verilog test bench.
The following example explains how to determine the hierarchical path of any BFM instance
in an IP integrator design.
Figure 4-6 shows a simple IP integrator design that has AXI4-Lite Master BFM on one side
of AXI Interconnect and two peripherals on the other side of the AXI Interconnect.
X-Ref Target - Figure 4-6
2. After the Output Products have been delivered, right-click bd design again and select
Create HDL Wrapper.
Note: AXI BFM cores support only Verilog language.
3. Figure 4-8 shows the complete hierarchy of the instances after the wrapper has been
generated.
X-Ref Target - Figure 4-8
4. The generated wrapper should be used as DUT module in the test bench.
5. Figure 4-9 and Figure 4-10 show how to identify the BFM instance in the hierarchy. After
the hierarchy is identified it can used in the Verilog test bench to drive the BFM APIs.
X-Ref Target - Figure 4-9
User Parameters
Table 4-1 shows the relationship between the GUI fields in the Vivado IDE and the User
Parameters (which can be viewed in the Tcl Console).
Output Generation
For more information, see the Vivado Design Suite User Guide: Designing with IP (UG896)
[Ref 3].
This section contains information about constraining the core in the Vivado Design Suite.
Required Constraints
This section is not applicable for this IP core.
Clock Frequencies
This section is not applicable for this IP core.
Clock Management
This section is not applicable for this IP core.
Clock Placement
This section is not applicable for this IP core.
Banking
This section is not applicable for this IP core.
Transceiver Placement
This section is not applicable for this IP core.
Simulation
This section contains information about simulating IP in the Vivado Design Suite. For
comprehensive information about Vivado simulation components, as well as information
about using supported third-party tools, see the Vivado Design Suite User Guide: Logic
Simulation (UG900) [Ref 6].
The IP and its example design can be simulated directly from Vivado by clicking the Run
Simulation button.
This section contains information about synthesis and implementation in the Vivado Design
Suite. For details about synthesis and implementation, see the Vivado Design Suite User
Guide: Designing with IP (UG896) [Ref 3].
Example Design
This chapter contains information about the example design provided in the Vivado ®
Design Suite.
IMPORTANT: The example design of this IP is a generic one. It is not customized to the IP configuration.
The intent of this example design is to demonstrate the usage of various APIs.
Overview
This section describes the example tests used to demonstrate the abilities of each AXI BFM
core pair. Example tests are delivered in Verilog. These example designs are available in the
AXI_BFM installation area. Each AXI master is connected to a single AXI slave, and then
direct tests are used to transfer data from the master to the slave and from the slave to the
master.
RECOMMENDED: The AXI BFM cores are not fully autonomous. For example, the AXI Master BFM is only
a user-driven verification component that enables you to generate valid AXI protocol scenarios.
Furthermore, if tests are written using the channel level API it is possible that the AXI protocol can be
accidentally violated. For this reason, Xilinx® recommends using the function level API for each BFM.
The ARM® AMBA ® AXI Protocol Specification, Section 3.3, Dependencies between Channel
Handshake Signals [Ref 7], states that:
• Slave can wait for AWVALID or WVALID, or both, before asserting AWREADY
• Slave can wait for AWVALID or WVALID, or both, before asserting WREADY
This implies that the slave does not need to support all three possible scenarios. However,
if the AXI Master BFM operates in such a way that is not supported by the slave, then the
simulation stalls. Each scenario is handled by the function level API:
Scenario 1
Before the slave asserts AWREADY and/or WREADY, the slave can wait for AWVALID. This is
modeled using the function level API, WRITE_BURST.
Scenario 2
Before the slave asserts AWREADY and/or WREADY, the slave can wait for WVALID. This is
modeled using the function level API, WRITE_BURST_DATA_FIRST.
Scenario 3
Before the slave asserts AWREADY and/or WREADY, the slave can wait for both AWVALID
and WVALID. This is modeled using the function level API, WRITE_BURST_CONCURRENT.
Test Bench
This chapter contains information about the test bench provided in the Vivado ® Design
Suite.
FGQBD[LBH[DPSOHBWHVWY
0DVWHU3URFHGXUDO%ORFN 6ODYH3URFHGXUDO%ORFN
FGQBD[LBH[DPSOHBWEY
$;,0DVWHU%)0 $;,6ODYH%)0
&RQILJXUDWLRQ &RQILJXUDWLRQ
)XQFWLRQ$3, )XQFWLRQ$3,
&KDQQHO$3, &KDQQHO$3,
6LJQDO,QWHUIDFH 6LJQDO,QWHUIDFH
Figure 6-1: Verilog Example Test Bench and Test Case Structure
The example test bench has the master and slave BFM connected directly to each other. This
gives visibility into both sides of the code (master code and slave code) required to hit the
scenarios detailed in the example test.
cdn_axi3_example_test.v
The example test (simulation/cdn_axi3_example_test.v) contains the master and
slave test code to simulate the following scenarios:
cdn_axi4_example_test.v
The example test (simulation/cdn_axi4_example_test.v) contains the master and
slave test code to simulate the following scenarios:
cdn_axi4_lite_example_test.v
The example test (simulation/cdn_axi4_lite_example_test.v) contains the
master and slave test code to simulate the following scenarios:
cdn_axi4_streaming_example_test.v
The example test (simulation/cdn_axi4_streaming_example_test.v) contains the
master and slave test code to simulate the following scenarios:
Nested for loops can be used to generate numerous combinations of traffic types, but care
must be taken to not violate protocol. AXI BFM cores check the input parameters of the API
calls, but this does not prevent higher level protocol being violated.
As shown in the code, it is possible to create the write datapath for a simple memory model
using three of the tasks from the slave channel level API. This is achieved in the following
four steps:
1. Wait for any write address request on the write address bus. This is done by calling
RECEIVE_WRITE_ADDRESS with IDVALID_FALSE. This ensures that the first detected and
valid write address handshake is recorded and the details passed back. This task is
blocking; so the WRITE_PATH process does not proceed until it has found a write
address channel transfer.
2. Get the write data burst that corresponds to the write address request in the previous
step. This is done by calling RECEIVE_WRITE_BURST with the ID tag output from the
RECEIVE_WRITE_ADDRESS call and with IDVALID_TRUE. This ensures that the entire write
data burst that has the specified id tag is captured before execution returns to the
WRITE_PATH process.
3. Take the data from the write data burst and put it into a memory array. In this case, the
memory array is an array of bytes.
4. Complete the AXI3 protocol is to send a response. The internal function
calculate_reponse is used to work out if the transfer was exclusive or not and to deliver
an EXOKAY or OK response (more code could be added here to support DECERR or
SLVERR response types). When the response has been calculated, the WRITE_PATH
process waits for the defined internal control variable WRITE_RESPONSE_GAP in clock
cycles before sending the response back to the slave with the same ID tag as the write
data transfer.
The following code illustrates the steps required to make the read datapath for a simple
slave memory model:
//-----------------------------------------------------------------
// Read Path
//-----------------------------------------------------------------always @(posedge
ACLK) begin : READ_PATH
//---------------------------------------------------------------
// Local Variables
//---------------------------------------------------------------
reg [ID_BUS_WIDTH-1:0] id;
reg [ADDRESS_BUS_WIDTH-1:0] address;
reg [`LENGTH_BUS_WIDTH-1:0] length;
reg [`SIZE_BUS_WIDTH-1:0] size;
reg [`BURST_BUS_WIDTH-1:0] burst_type;
reg [`LOCK_BUS_WIDTH-1:0] lock_type;
reg [`CACHE_BUS_WIDTH-1:0] cache_type;
reg [`PROT_BUS_WIDTH-1:0] protection_type;
reg [ID_BUS_WIDTH-1:0] idtag;
reg [(DATA_BUS_WIDTH*(`MAX_BURST_LENGTH+1))-1:0] data;
reg [ADDRESS_BUS_WIDTH-1:0] internal_address;
integer i;
integer number_of_valid_bytes;
//---------------------------------------------------------------
// Implementation Code
//---------------------------------------------------------------
if (MEMORY_MODEL_MODE == 1) begin
// Receive a read address transfer
RECEIVE_READ_ADDRESS(id,`IDVALID_FALSE,address,length,size,
burst_type,lock_type,cache_type,protection_type,idtag);
// Get the data to send from the memory.
internal_address = address - SLAVE_ADDRESS;
data = 0;
number_of_valid_bytes =
(decode_burst_length(length)*transfer_size_in_bytes(size))-(address %
(DATA_BUS_WIDTH/8));
As shown in the code, it is possible to create the read datapath for a simple memory model
using two of the tasks from the slave channel level API. This is achieved in the following two
steps:
1. Wait for any read address request on the read address bus. This is done by calling
RECEIVE_READ_ADDRESS with IDVALID_FALSE. This ensures that the first detected and
valid read address handshake is recorded and the details are passed back. This task is
blocking; so the READ_PATH process does not proceed until it has found a read address
channel transfer.
2. Take the requested data from the memory array and send it in a read burst. This is done
by extracting the data byte by byte into a data vector which is used as an input into the
SEND_READ_BURST task. Before sending the read data burst, the READ_PATH process
waits for the clock cycles determined in the internal control variable
READ_RESPONSE_GAP.
There is no special instructions for migration except that all of the wrappers are unified into
the AXI BFM cores.
Debugging
This appendix includes details about resources available on the Xilinx ® Support website
and debugging tools.
Documentation
This product guide is the main document associated with the AXI BFM. This guide, along
with documentation related to all products that aid in the design process, can be found on
the Xilinx Support web page (www.xilinx.com/support) or by using the Xilinx
Documentation Navigator.
Download the Xilinx Documentation Navigator from the Design Tools tab on the Downloads
page (www.xilinx.com/download). For more information about this tool and the features
available, open the online help after installation.
Answer Records
Answer Records include information about commonly encountered problems, helpful
information on how to resolve these problems, and any known issues with a Xilinx product.
Answer Records are created and maintained daily ensuring that users have access to the
most accurate information available.
Answer Records for this core can be located by using the Search Support box on the main
Xilinx support web page. To maximize your search results, use proper keywords such as:
• Product name
• Tool message(s)
• Summary of the issue encountered
A filter search is available after results are returned to further target the results.
AR: 54678
1. Navigate to www.xilinx.com/support.
2. Open a WebCase by selecting the WebCase link located under Additional Resources.
Interface Debug
AXI4-Lite Interfaces
Read from a register that does not have all 0s as a default to verify that the interface is
functional. If the interface is unresponsive, ensure that the following conditions are met:
Xilinx Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see Xilinx
Support.
References
These documents provide supplemental material useful with this product guide:
Revision History
The following table shows the revision history for this document.