This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a thirdparty Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: www.mentor.com/trademarks.
The registered trademark Linux
®
is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
List of Tables
16
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
About This User Guide
Note
Preface
This user guide describes the AXI4-Lite application interface (API) of the Mentor®
Verification IP (VIP) Altera
TM
ACE
Issue E (ARM IHI 0022E).
Protocol Specification, AXI3TM, AXI4TM, and AXI4-LiteTM, ACE, and ACE-LiteTM
This release supports only the AMBA AXI3, AXI4, AXI4-Lite, and AXI4-StreamTM
protocols. The AMBA ACE protocol is not supported in this release.
®
Edition (AE) and how it conforms to the AMBA® AXITM and
AMBA AXI Protocol Specification
The Mentor VIP AE conforms to the AMBA® AXITM and ACETM Protocol Specification,
AXI3TM, AXI4TM, and AXI4-LiteTM, ACE and ACE-LiteTM Issue E (ARM IHI 0022E). For
restrictions to this protocol, refer to the section Protocol Restrictions.
This user guide refers to this specification as the “AXI Protocol Specification.”
Protocol Restrictions
The Mentor VIP AE supports all but the following features of this AXI Protocol Specification,
which gives you a simplified API to create desired protocol stimulus.
BFM Dependencies Between Handshake Signals
Starting a write data phase before its write address phase in a transaction is not supported.
However, starting a write data phase simultaneously with its write address phase is supported.
The above statement disallowing a write data phase to start before its write address phase in a
transaction modifies the AXI4-Lite Protocol Specification slave write response handshake
dependencies diagram, Figure A3-7 in Section A3.3.1, by effectively adding double-headed
arrows between AWVALID to WVALID and AWREADY to WVALID, with the provision
that they can be simultaneous.
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
17
Preface
Note
Mentor VIP AE License Requirements
Mentor VIP AE License Requirements
A license is required to access the Mentor Graphics VIP AE Bus Functional Models
(BFMs) and Inline Monitor.
•To access the Mentor Graphics VIP AE and upgrade to the Quartus II Subscription
Edition software version 14.0 from a previous version, you must regenerate your license
file.
•To access the Mentor VIP AE with the Quartus II Web Edition software, you must
upgrade to version 14.0 and purchase a Mentor VIP AE seat license by contacting your
Altera sales representative.
You can generate and manage license files for Altera software and IP products by visiting the
Self-Service Licensing Center of the Altera website.
Supported Simulators
Mentor VIP AE supports the following simulators:
•Mentor Graphics Questa SIM and ModelSim SE 10.2c/10.1e on Linux
•Mentor Graphics Questa SIM and ModelSim SE 10.1e on Windows
•Mentor Graphics ModelSim DE/PE/AE 10.1e on Linux and Windows
•Synopsys
•Cadence
®
VCS® and VCS-MX 2013.06 on Linux
®
Incisive® Enterprise Simulator (IES) 13.10.001 on Linux
Simulator GCC Requirements
Mentor VIP requires that the installation directory of the simulator includes the GCC libraries
shown in Table 1. If the installation of the GCC libraries was an optional part of the simulator’s
installation and the Mentor VIP does not find these libraries, an error message displays similar
to the following:
ModelSim / Questa Sim
# ** Error: (vsim-8388) Could not find the MVC shared library : GCC not
found in installation directory (/home/user/altera2/14.0/modelsim_ase) for
platform "linux". Please install GCC version "gcc-4.5.0-linux"
18
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
Note: Use the cds_tools.sh executable to find the Incisive installation. Ensure $PATH includes the
installation path and <install dir>/tools/cdsgcc/gcc/4.4/install/bin. Also, ensure the
LD_LIBRARY_PATH includes <install dir>/tools/cdsgcc/gcc/4.4/install/lib.
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
19
Preface
Simulator GCC Requirements
20
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
Chapter 1
Mentor VIP Altera Edition
The Mentor VIP AE provides BFMs to simulate the behavior and to facilitate IP verification.
The Mentor VIP AE includes the following interface:
•AXI4-Lite BFM with master, slave, and inline monitor interfaces
Advantages of Using BFMs and Monitors
Using the Mentor VIP AE has the following advantages:
•Accelerates the verification process by providing key verification test bench
components
•Provides BFM components that implement the AMBA AXI Protocol Specification,
which serves as a reference for the protocol
•Provides a full suite of configurable assertion checking in each BFM
Implementation of BFMs
The Mentor VIP AE BFMs, master, slave, and inline monitor components are implemented in
SystemVerilog. Also included are wrapper components so that you can use the BFMs in VHDL
verification environments with simulators that support mixed-language simulation.
The Mentor VIP AE provides a set of APIs for each BFM that you can use to construct,
instantiate, control, and query signals in all BFM components. Your test programs must use
only these public access methods and events to communicate with each BFM. To ensure
support in current and future releases, your test programs must use the standard set of APIs to
interface with the BFMs. Nonstandard APIs and user-generated interfaces cannot be supported
in future releases.
The test program drives the stimulus to the DUTs and determines whether the behavior of the
DUTs is correct by analyzing the responses. The BFMs translate the test program stimuli
(transactions), creating the signaling for the AMBA AXI Protocol Specification. The BFMs also
check for protocol compliance by firing an assertion when a protocol error is observed.
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
21
Mentor VIP Altera Edition
What Is a Transaction?
What Is a Transaction?
A transaction for Mentor VIP AE represents an instance of information that is transferred
between a master and a slave peripheral, and that adheres to the protocol used to transfer the
information. For example, a write transaction transfers an address phase, a data a phase,
followed by a response phase. A subsequent instance of transferred information requires a new
and unique transaction.
Each transaction has a dynamic Transaction Record that exists for the life of the transaction.
The life of a transaction record starts when it is created and ends when the transaction
completes. The transaction record is automatically discarded when the transaction ends.
When created, a transaction contains transaction fields that you set to define two transaction
aspects:
•Protocol fields are transferred over the protocol signals.
•Operation fields determine how the information is transferred and when the transfer is
complete.
For example, a write transaction record holds the protection information in the prot protocol
field; the value of this field is transferred over the AWPROT protocol signals during an address
phase. A write transaction also has a transaction_done operation field that indicates when the
transaction is complete; this field is not transferred over the protocol signals. These two types of
transaction fields, protocol and operation, establish a dynamic record during the life of the
transaction.
In addition to transaction fields, you specify arguments to tasks, functions, and procedures that
permit you to create, set, and get the dynamic transaction record during the lifetime of a
transaction. Each BFM has an API that controls how you access the BFM transaction record.
How you access the record also depends on the source code language, whether it is VHDL or
SystemVerilog. Methods for accessing transactions based on the language you use are
explained in detail in the relevant chapters of this user guide.
AXI4-Lite Transactions
A complete read/write transaction transfers information between a master and a slave
peripheral. Transaction fields described in “What Is a Transaction?” on page 22 determine what
is transferred and how information is transferred. During the lifetime of a transaction, the roles
of the master and slave ensure that a transaction completes successfully and that transferred
information adheres to the protocol specification. Information flows in both directions during a
transaction with the master initiating the transaction, and the slave reporting back to the master
that the transaction has completed.
An AXI4-Lite protocol uses five channels (three write channels and two read channels) to
transfer protocol information. Each of these channels has a pair of handshake signals, *VALID
22
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
Mentor VIP Altera Edition
Note
Master
interface
Slave
interface
Write
data
Write response channel
Write data channel
Write address channel
Write
response
Address
and
control
execute_transaction(t)
AXI4-Lite Transactions
and *READY, that indicates valid information on a channel and the acceptance of the
information from the channel.
AXI4-Lite Write Transaction Master and Slave Roles
The following description of a write transaction references SystemVerilog BFM API
tasks. There are equivalent VHDL BFM API procedures that perform the same
functionality.
For a write transaction, the master calls the create_write_transaction() task to define the
information to be transferred and then calls the execute_transaction() task to initiate the transfer
of information as Figure 1-1 illustrates.
Figure 1-1. Execute Write Transaction
The execute_transaction() task results in the master calling the execute_write_addr_phase()
task followed by the execute_write_data_phase() task as illustrated in Figure 1-2.
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
23
Mentor VIP Altera Edition
Master
interface
Slave
interface
Write
data
Write response channel
Write data channel
Write address channel
Write
response
Address
and
control
get_write_response_phase() - Master
execute_write_data_phase() - Master
execute_write_addr_phase() - Master
AXI4-Lite Transactions
Figure 1-2. Master Write Transaction Phases
The master then calls the get_write_response_phase() task to receive the response from the
slave and to complete its role in the write transaction.
The slave also creates a transaction by calling the create_slave_transaction() task to accept the
transfer of information from the master. The address phase and data phase are received by the
slave calling the get_write_addr_phase() task, followed by the get_write_data_phase()task as
illustrated in Figure 1-3.
24
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
Figure 1-3. Slave Write Transaction Phases
Note
Master
interface
Slave
interface
Write
data
Write response channel
Write data channel
Write address channel
Write
response
Address
and
control
execute_write_response_phase() - Slave
get_write_data_phase() - Slave
get_write_addr_phase() - Slave
Mentor VIP Altera Edition
AXI4-Lite Transactions
The slave then executes a write response phase by calling the execute_write_response_phase()
task and completes its role in the write transaction.
AXI Read Transaction Master and Slave Roles
The following description of a read transaction references the SystemVerilog BFM API
tasks. There are equivalent VHDL BFM API procedures that perform the same
functionality.
A read transaction is similar to a write transaction. The master initiates the read by calling the
create_read_transaction() and execute_transaction() tasks. The execute_transaction() calls the
the execute_read_addr_phase() task followed by the get_read_data_phase() task as illustrated
in Figure 1-4.
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
25
Mentor VIP Altera Edition
Read
data
Read data channel
Master
interface
Slave
interface
Read address channel
Address
and
control
execute_read_addr_phase() - Master
get_read_data_phase() - Master
Read
data
Read data channel
Master
interface
Slave
interface
Read address channel
Address
and
control
get_read_addr_phase() - Slave
execute_read_data_phase() - Slave
AXI4-Lite Transactions
Figure 1-4. Master Read Transaction Phases
The slave creates a read transaction by calling the create_slave_transaction() task to accept the
transfer of read information from the master. The slave accepts the address phase by calling the
get_read_addr_phase() task, and then executes the data burst phase by calling the
execute_read_data_phase()task as illustrated in Figure 1-5.
Figure 1-5. Slave Read Transaction Phases
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
26
April 2014
Chapter 2
SystemVerilog BFM API
Configuration
Creating
Transaction
Waiting Events
Executing
Transaction
Access
Transaction
create*_transaction
1
set_config/get_config
wait_on
get*_phase
3
Rx_Transaction
queue
queue
Tx_Transaction
Configuration
Wire level
Notes: 1. Refer to create*_transaction()
2. Refer to execute_transaction(), execute*_phase()
3. Refer to get*()
get_rw_transaction/get*_phase
3
get*_addr/get*_data
3
execute_transaction, execute*_phase
2
SystemVerilog interface
Test Program SystemVerilog
SystemVerilog API Overview
This chapter provides the functional description of the SystemVerilog (SV) Application
Programming Interface (API) for all BFM (master, slave, and monitor) components. For each
BFM, you can configure the protocol transaction fields that are executed on the protocol signals,
as well as control the operational transaction fields that permit delays to be introduced between
the handshake signals for each of the five address, data, and response channels.
In addition, each BFM API has tasks that wait for certain events to occur on the system clock
and reset signals, and tasks to get and set information about a particular transaction.
Figure 2-1. SystemVerilog BFM Internal Structure
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
27
SystemVerilog API Overview
Configuration
Configuration
Configuration sets timeout delays, error reporting, and other attributes of the BFM. Each BFM
has a set_config() function that sets the configuration of the BFM. Refer to the individual BFM
APIs for details.
Each BFM also has a get_config() function that returns the configuration of the BFM. Refer to
the individual BFM APIs for details.
set_config()
The following test program code sets the burst timeout factor for a transaction in the master
BFM.
// Setting the burst timeoutfactor to 1000
master_bfm.set_config(AXI4_CONFIG_BURST_TIMEOUT_FACTOR, 1000);
get_config()
The following test program code gets the protocol signal hold time in the master BFM.
To transfer information between a master BFM and a slave DUT over the protocol signals, you
must create a transaction in the master test program. Similarly, to transfer information between
a master DUT and a slave BFM, you must create a transaction in the slave test program. To
monitor the transfer of information using a monitor BFM, you must create a transaction in the
monitor test program.
When you create a transaction, a Transaction Record is created and exists for the life of the
transaction. This transaction record can be accessed by the BFM test programs during the life of
the transaction as it transfers information between the master and slave.
Transaction Record
The transaction record contains two types of transaction fields, protocol and operational, that
either transfer information over the protocol signals or define how and when a transfer occurs.
Protocol fields contain transaction information that is transferred over protocol signals. For
example, the prot field is transferred over the AWPROT protocol signals during a write
transaction.
28
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
SystemVerilog API Overview
Note
Creating Transactions
Operational fields define how and when the transaction is transferred. Their content is not
transferred over protocol signals. For example, the operation_mode field controls the
blocking/nonblocking operation of a transaction, but this information is not transferred over the
protocol signals.
AXI4-Lite Transaction Definition
The transaction record exists as a SystemVerilog class definition in each BFM. Example 2-1
shows the definition of the axi4_transaction class members that form the transaction record.
Example 2-1. AXI4 Transaction Definition
// Global Transaction Class
class axi4_transaction;
// Protocol
axi4_rw_e read_or_write;
bit [((`MAX_AXI4_ADDRESS_WIDTH) - 1):0] addr;
axi4_prot_e prot;
bit [3:0] region; // Not supported in AXI4-Lite
axi4_size_e size; // Not supported in AXI4-Lite
axi4_burst_e burst; // Not supported in AXI4-Lite
axi4_lock_e lock; // Not supported in AXI4-Lite
axi4_cache_e cache; // Not supported in AXI4-Lite
bit [3:0] qos; // Not supported in AXI4-Lite
bit [((`MAX_AXI4_ID_WIDTH) - 1):0] id; // Not supported in AXI4-Lite
bit [7:0] burst_length; // Not supported in AXI4-Lite
bit [((`MAX_AXI4_USER_WIDTH) - 1):0] addr_user; // Not supported in
AXI4-Lite
bit [((((`MAX_AXI4_RDATA_WIDTH > `MAX_AXI4_WDATA_WIDTH) ?
`MAX_AXI4_RDATA_WIDTH : `MAX_AXI4_WDATA_WIDTH)) - 1):0] data_words [];
bit [(((`MAX_AXI4_WDATA_WIDTH / 8)) - 1):0] write_strobes [];
axi4_response_e resp[];
int address_valid_delay;
int data_valid_delay[];
int write_response_valid_delay;
int address_ready_delay;
int data_ready_delay[];
int write_response_ready_delay;
// Housekeeping
bit gen_write_strobes = 1'b1;
axi4_operation_mode_e operation_mode = AXI4_TRANSACTION_BLOCKING;
axi4_write_data_mode_e write_data_mode = AXI4_DATA_AFTER_ADDRESS;
bit data_beat_done[]; // Not supported in AXI4-Lite
bit transaction_done;
...
endclass
This axi4_transaction class code is shown for information only. Access to each
transaction record during its life is performed by various set*() and get*() tasks described
later in this chapter.
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
29
SystemVerilog API Overview
Creating Transactions
The contents of the transaction record are defined in Table 2-1.
Table 2-1. Transaction Fields
Transaction FieldDescription
Protocol Transaction Fields
addrA bit vector (the length is equal to the ARADDR/AWADDR
signal bus width) containing the starting address of the first
transfer (beat) of a transaction. The addr value is transferred
over the ARADDR or AWADDR signals for a read or write
transaction, respectively.
protAn enumeration containing the protection type of a transaction.
The prot value is transferred over the ARPROT or AWPROT
signals for a read or write transaction, respectively.
data_wordsA bit vector (of length equal to the greater of the
RDATA/WDATA signal bus widths) to hold the data words of
the payload. A data_words is transferred over the RDATA or
WDATA signals per beat of the read or write data channel,
respectively.
write_strobesA bit vector (of length equal to the WDATA signal bus width
divided by 8) to hold the write strobes. A write_strobes is
transferred over the WSTRB signals per beat of the write data
channel.
respAn enumeration to hold the response of a transaction. The types
of response are:
AXI4_OKAY;
AXI4_SLVERR;
AXI4_DECERR;
A resp is transferred over the RRESP signals per beat of the
read data channel, and over the BRESP signals for a write
transaction, respectively.
30
Mentor Verification IP AE AXI4-Lite User Guide, V10.3
April 2014
Loading...
+ 383 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.