Module bfm
This document contains technical documentation for the bfm
module.
axi_bfm_pkg.vhd
Types and functions for the AXI BFMs.
axi_lite_master.vhd

Wrapper around VUnit BFM that uses convenient record types for the AXI-Lite signals.
Instantiates the VUnit axi_lite_master
verification component, which creates AXI-Lite
read/write transactions.
Is used by performing VUnit VC calls, such as read_bus
,
or by using the register convenience methods in reg_operations_pkg.vhd.
axi_lite_read_slave.vhd

Wrapper around VUnit BFM that uses convenient record types for the AXI-Lite signals.
Instantiates the VUnit axi_read_slave
verification component, which acts as an AXI slave
and reads data from the VUnit memory model.
axi_lite_slave.vhd

AXI-Lite slave BFM that will perform read/write operations on the VUnit memory model.
This entity instantiates axi_lite_read_slave.vhd and/or axi_lite_write_slave.vhd based on what generics are provided.
axi_lite_write_slave.vhd

Wrapper around VUnit BFM that uses convenient record types for the AXI-Lite signals.
Instantiates the VUnit axi_read_slave
verification component, which acts as an AXI slave
and writes data to the VUnit memory model.
axi_master.vhd

Wrapper around VUnit BFM that uses convenient record types for the AXI signals.
Instantiates the VUnit axi_lite_master
verification component, which creates AXI-Lite
read/write transactions.
The AXI-Lite interface are then connected to the “full” AXI interface of this module.
The fact that the BFM uses AXI-Lite means that there is no burst support.
This wrapper is typically only used for register read/write operations on the chip top level,
where the register bus is still AXI.
It is used by performing VUnit VC calls, such as read_bus
,
or by using the register convenience methods in reg_operations_pkg.vhd.
axi_read_master.vhd

BFM that creates AXI read transactions and checkers based on a simple interface.
AR
transactions will be created based on jobs (axi_master_bfm_job_t
) that the user
pushes to the job_queue
.
The data returned on the R
channel will be checked against the integer_array_t
data
pushed by the user to the reference_data_queue
.
The returned RID
will be checked that it is the same as the corresponding ARID
.
The RID
check is based on the assumption that R
transactions are returned in the same
order as AR
transactions are sent.
Also the job address is assumed to be aligned with the bus data width.
The byte length of the transactions (as set in the job, as well as indicated by the length of the data arrays) does not need to be aligned with the data width of the bus. If unaligned, the last AXI beat will not have all byte lanes checked against reference data.
axi_read_slave.vhd

Wrapper around VUnit BFM that uses convenient record types for the AXI signals.
Instantiates the VUnit axi_read_slave
verification component, which acts as an AXI slave
and reads data from the VUnit memory model.
axi_slave.vhd

AXI slave BFM that will perform read/write operations on the VUnit memory model.
This entity instantiates axi_read_slave.vhd and/or axi_write_slave.vhd based on what generics are provided.
axi_slave_pkg.vhd
Package with an init value for the axi_slave_t
type.
axi_stream_master.vhd

BFM for sending data on an AXI stream interface.
Data is pushed as a VUnit integer_array to a
VUnit queue.
Each element in the integer_array
should be an unsigned byte.
Little endian byte order is assumed.
The byte length of the packets (as indicated by the length of the data_queue
arrays)
does not need to be aligned with the data
width of the bus.
If unaligned, the last data beat will not have all byte lanes set to valid
data
and strobe
.
axi_stream_slave.vhd

Verify data on an AXI stream interface.
Reference data is pushed as a VUnit integer_array to a
VUnit queue.
Each element in the integer_array
should be an unsigned byte.
Little endian byte order is assumed.
An optional expected ID is pushed as a natural
to another queue
by the user.
The byte length of the packets (as indicated by the length of the reference_data_queue
arrays) does not need to be aligned with the data
width of the bus.
If unaligned, the last beat will not have all data
byte lanes checked against reference data.
axi_write_master.vhd

BFM that creates AXI write transactions based on a simple interface.
AW
transactions will be created based on jobs (axi_master_bfm_job_t
) that the user
pushes to the job_queue
.
A W
burst will be created based on the integer_array_t
data
pushed by the user to the data_queue
.
Each AW
transaction will result in a check that the eventually returned BID
is correct.
The job address is assumed to be aligned with bus data width.
The byte length of the transactions (as set in the job_queue
records, as well as indicated by
the length of the data_queue
arrays) does not need to be aligned with the data width of
the bus.
If unaligned, the last AXI beat will have a strobe that is not ‘1’ for all byte lanes.
Note that data can be pushed to data_queue
before the corresponding job is pushed.
This data will be pushed to the AXI W
channel straight away, unless in AXI3 mode.
axi_write_slave.vhd

Wrapper around VUnit BFM that uses convenient record types for the AXI signals.
Instantiates the VUnit axi_read_slave
verification component, which acts as an AXI slave
and writes data to the VUnit memory model.
bfm_pkg.vhd
Types and convenience methods used to implement the BFMs.
handshake_master.vhd

Toggle the valid
signal based on probabilities set via generics.
This realizes a handshake master with jitter that is compliant with the AXI-Stream standard.
According to the standard, valid
may be lowered only after a transaction.
This BFM can be more convenient to use than the VUnit axi_stream_master
BFM in some cases.
Specifically when the data is not an SLV, but instead a record.
When using VUnit BFMs we would need to have conversion functions to and from SLV.
When using this BFM instead for the handshaking,
the data can be handled as records in the testbench with no conversion necessary.
Using this simple BFM is also significantly faster.
A drawback of this BFM is that the testbench code becomes more “RTL”-like compared to the VUnit
BFM, which results in more “high level” code.
See the testbench tb_handshake_bfm
for example usage.
This entity can also optionally perform protocol checking on the handshaking data interface.
This will verify that the AXI-Stream standard is followed.
Assign the last
/data
/strobe
ports and set the correct data_width
generic in
order to use this.
handshake_slave.vhd

Toggle the ‘ready’ signal based on probabilities set via generics. This realizes a handshake slave with jitter that is compliant with the AXI-Stream standard. According to the standard, ‘ready’ can be lowered at any time, not just after a transaction.
This BFM can be more convenient to use than the VUnit ‘axi_stream_slave’ BFM in some cases. Specifically
When the data is not an SLV, but instead a record. When using VUnit BFMs we would need to have conversion functions to and from SLV. When using this BFM instead for the handshaking, the data can be handled as records in the testbench with no conversion necessary.
When full throughput in the slave is desirable. When using the VUnit BFM the pops must be queued up and “pop references” must be queued up in a separate queue before data is read. This is a lot of boilerplate code that is hard to read.
Using this simple BFM is also significantly faster. A drawback of this BFM is that the testbench code becomes more “RTL”-like compared to the VUnit BFM, which results in more “high level” code. See the testbench ‘tb_handshake_bfm’ for example usage.
This entity can also optionally perform protocol checking on the handshaking data interface.
This will verify that the AXI-Stream standard is followed.
Assign the valid
/last
/data
/strobe
ports and set the correct data_width
generic in order to use this.