Ug761 Axi Reference Guide PDF
Ug761 Axi Reference Guide PDF
Ug761 Axi Reference Guide PDF
Guide
[Guide Subtitle]
[optional]
Xilinx is providing this product documentation, hereinafter Information, to you AS IS with no warranty of any kind, express or implied.
Xilinx makes no representation that the Information, or any particular implementation thereof, is free from any claims of infringement. You
are responsible for obtaining any rights you may require for any implementation based on the Information. All specifications are subject to
change without notice.
XILINX EXPRESSLY DISCLAIMS ANY WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE INFORMATION OR
ANY IMPLEMENTATION BASED THEREON, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR REPRESENTATIONS THAT
THIS IMPLEMENTATION IS FREE FROM CLAIMS OF INFRINGEMENT AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Except as stated herein, none of the Information may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or
transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without
the prior written consent of Xilinx.
2011 Xilinx, Inc. XILINX, the Xilinx logo, Virtex, Spartan, ISE, and other designated brands included herein are trademarks of Xilinx in the
United States and other countries. All other trademarks are the property of their respective owners.
ARM and AMBA are registered trademarks of ARM in the EU and other countries. All other trademarks are the property of their
respective owners.
Revision History
The following table shows the revision history for this document:
Date
Version
09/21/2010
1.0
03/01/2011
2.0
Description of Revisions
Initial Xilinx release in 12.4.
Second Xilinx release in 13.1.
Added new AXI Interconnect features.
Corrected ARESETN description in Appendix A.
03/07/2011
3.0
www.xilinx.com
Table of Contents
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
8
8
9
9
9
9
13
13
13
14
14
14
14
17
www.xilinx.com
19
19
21
22
22
26
27
28
28
29
29
29
29
29
30
30
Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Centralized DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AXI Centralized DMA Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AXI Centralized DMA Scatter Gather Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Centralized DMA Configurable Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Centralized DMA AXI4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ethernet DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AXI4 DMA Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DMA AXI4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Video DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AXI VDMA Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VDMA AXI4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Control IP and the Memory Interface Generator . . . . . . . . . . . . . . . . . . . . . .
Virtex-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spartan-6 Memory Control Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
32
33
33
33
34
34
36
37
38
39
40
40
41
41
45
45
47
48
49
52
53
53
54
58
58
59
59
60
62
63
63
www.xilinx.com
63
63
63
63
64
65
65
67
67
68
68
69
69
70
71
72
73
73
74
75
75
76
www.xilinx.com
www.xilinx.com
Chapter 1
Introducing AXI for Xilinx System Development
Introduction
Xilinx has adopted the Advanced eXtensible Interface (AXI) protocol for Intellectual
Property (IP) cores beginning with the Spartan-6 and Virtex-6 devices.
This document is intended to:
Give an overview of what Xilinx tools you can use to create AXI-based IP
Note: This document is not intended to replace the Advanced Microcontroller Bus
Architecture (AMBA) ARM AXI4 specifications. Before beginning an AXI design, you need to
download, read, and understand the ARM AMBA AXI Protocol v2.0 Specification, along with the
AMBA4 AXI4-Stream Protocol v1.0.
These are the steps to download the specifications; you might need to fill out a brief
registration before downloading the documents:
1.
Go to www.amba.com
2.
3.
In the Contents pane on the left, click AMBA > AMBA Specifications >AMBA4.
4.
Download both the ABMA AXI4-Stream Protocol Specification and AMBA AXI Protocol
Specification v2.0.
What is AXI?
AXI is part of ARM AMBA, a family of micro controller buses first introduced in 1996. The
first version of AXI was first included in AMBA 3.0, released in 2003. AMBA 4.0, released
in 2010, includes the second version of AXI, AXI4.
There are three types of AXI4 interfaces:
Xilinx introduced these interfaces in the ISE Design Suite, release 12.3.
www.xilinx.com
AXI4 is for memory mapped interfaces and allows burst of up to 256 data transfer
cycles with just a single address phase.
AXI4-Stream removes the requirement for an address phase altogether and allows
unlimited data burst size. AXI4-Stream interfaces and transfers do not have
address phases and are therefore not considered to be memory-mapped.
Data can move in both directions between the master and slave simultaneously, and data
transfer sizes can vary. The limit in AXI4 is a burst transaction of up to 256 data transfers.
AXI4-Lite allows only 1 data transfer per transaction.
Figure 1-1, page 7 shows how an AXI4 Read transaction uses the Read address and Read
data channels:
www.xilinx.com
Slave
interface
Read
data
Read
data
Read
data
X12076
Figure 1-1:
Figure 1-2 shows how a Write transaction uses the Write address, Write data, and Write
response channels.
Write
data
Write
data
Write
data
Slave
interface
Write
data
X12077
Figure 1-2:
As shown in the preceding figures, AXI4 provides separate data and address connections
for Reads and Writes, which allows simultaneous, bidirectional data transfer. AXI4
requires a single address and then bursts up to 256 words of data. The AXI4 protocol
describes a variety of options that allow AXI4-compliant systems to achieve very high data
throughput. Some of these features, in addition to bursting, are: data upsizing and
downsizing, multiple outstanding addresses, and out-of-order transaction processing.
At a hardware level, AXI4 allows a different clock for each AXI master-slave pair. In
addition, the AXI protocol allows the insertion of register slices (often called pipeline
stages) to aid in timing closure.
www.xilinx.com
AXI4-Lite is similar to AXI4 with some exceptions, the most notable of which is that
bursting, is not supported. The AXI4-Lite chapter of the ARM AMBA AXI Protocol v2.0
Specification describes the AXI4-Lite protocol in more detail.
The AXI4-Stream protocol defines a single channel for transmission of streaming data. The
AXI4-Stream channel is modeled after the Write Data channel of the AXI4. Unlike AXI4,
AXI4-Stream interfaces can burst an unlimited amount of data. There are additional,
optional capabilities described in the AXI4-Stream Protocol Specification. The specification
describes how AXI4-Stream-compliant interfaces can be split, merged, interleaved,
upsized, and downsized. Unlike AXI4, AXI4-Stream transfers cannot be reordered.
With regards to AXI4-Stream, it should be noted that even if two pieces of IP are designed
in accordance with the AXI4-Stream specification, and are compatible at a signaling level,
it does not guarantee that two components will function correctly together due to higher
level system considerations. Refer to the AXI IP specifications at
http://www.xilinx.com/ipcenter/axi4.htm, and AXI4-Stream Signals, page 45 for more
information.
IP Interoperability
The AXI specification provides a framework that defines protocols for moving data
between IP using a defined signaling standard. This standard ensures that IP can exchange
data with each other and that data can be moved across a system.
AXI IP interoperability affects:
The AXI protocol defines how data is exchanged, transferred, and transformed. The AXI
protocol also ensures an efficient, flexible, and predictable means for transferring data.
About IP Compatibility
For more application-specific IP, like an Ethernet MAC (EMAC) or a video display IP using
AXI4-Stream, the compatibility of the IP is more limited to their respective application
spaces. For example, directly connecting an Ethernet MAC to the video display IP would
not be feasible.
Note: Even though two IP such as EMAC and Video Streaming can theoretically exchange data
with each other, they would not function together because the two IP interpret bit fields and data
packets in a completely different manner.
www.xilinx.com
IP Interoperability
Infrastructure IP
An infrastructure IP is another IP form used to build systems. Infrastructure IP tends to be
a generic IP that moves or transforms data around the system using general-purpose AXI4
interfaces and does not interpret data.
Examples of infrastructure IP are:
AXI Direct Memory Access (DMA) engines (memory mapped to stream conversion)
These IP are useful for connecting a number of IP together into a system, but are not
generally endpoints for data.
AXI4-Stream Protocol
The AXI4-Stream protocol is used for applications that typically focus on a data-centric
and data-flow paradigm where the concept of an address is not present or not required.
Each AXI4-Stream acts as a single unidirectional channel for a handshake data flow.
At this lower level of operation (compared to the memory mapped AXI protocol types), the
mechanism to move data between IP is defined and efficient, but there is no unifying
address context between IP. The AXI4-Stream IP can be better optimized for performance
in data flow applications, but also tends to be more specialized around a given application
space.
www.xilinx.com
Interface
AXI4
Features
Replaces
PLBv3.4/v4.6
OPB
NPI
XCL
AXI4-Lite
AXI4-Stream
Data-only burst.
Additional References
Additional reference documentation:
See the Introduction, page 5 for instructions on how to download the ARM AMBA AXI
specification from http://www.amba.com.
Additionally, this document references the following documents, located at the following
Xilinx website:
http://www.xilinx.com/support/documentation/axi_ip_documentation.htm.
10
www.xilinx.com
Additional References
Local-Link:
http://www.xilinx.com/products/design_resources/conn_central/locallink_member/sp06.pdf
www.xilinx.com
11
12
www.xilinx.com
Chapter 2
www.xilinx.com
13
Put the chipscope_axi_monitor into your bus interface System Assembly View (SAV).
2.
Select the bus you want to probe from the Bus Name field.
After you select the bus, an M for monitor displays between your peripheral and the
AXI Interconnect core IP.
3.
Add a ChipScope ICON core to your system, and connect the control bus to the AXI
monitor.
4.
In the SAV Ports tab, on the monitor core, set up the MON_AXI_ACLK port of the core to
match the clock used by the AXI interface being probed.
Optionally, you can assign the MON_AXI_TRIG_OUT port and connect it to other
chipscope_axi_monitor cores in the system.
AXI4-Stream interface is supported in IPs found in the System Generator AXI4 block
library.
14
www.xilinx.com
Figure 2-1:
Port Groupings
System Generator groups together and color-codes blocks of AXI4-Stream channel signals.
In the example illustrated in the following figure, the top-most input port, data_tready,
and the top two output ports, data_tvalid and data_tdata belong in the same
AXI4-Stream channel, as well as phase_tready, phase_tvalid, and phase_tdata.
www.xilinx.com
15
System Generator gives signals that are not part of any AXI4-Stream channels the same
background color as the block; the rst signal, shown in Figure 2-2, is such an example.
Figure 2-2:
Figure 2-3:
Multi-Channel TDATA
Note: Breaking out of multi-channel TDATA does not add additional logic to the design. The data is
correctly byte-aligned also.
For more information about System Generator and AXI IP creation, see the following
Xilinx website: http://www.xilinx.com/tools/sysgen.htm.
16
www.xilinx.com
Figure 2-4:
Figure 2-5, page 18 shows the IP catalog in PlanAhead with the equivalent AXI4 column
and the supported AXI4 interfaces in the IP details panel.
www.xilinx.com
17
Figure 2-5:
Centralized DMA
Ethernet DMA
Video DMA
Refer to Chapter 4, Migrating to Xilinx AXI Protocols, for more detailed usage
information. See the following for a list of all AXI IP:
http://www.xilinx.com/ipcenter/axi4.htm.
18
www.xilinx.com
The AXI Interconnect core IP is provided as an encrypted, non-licensed (free) pcore in the
Xilinx Platform Studio software.
Converts AXI4 bursts >16 beats when targeting AXI3 slaves by splitting
transactions.
Generates REGION outputs for slaves with multiple address decode ranges
Propagates USER signals on each channel, if any; independent USER signal width
per channel (optional)
Propagates Quality of Service (QoS) signals, if any; not used by the AXI
Interconnect core(optional)
AXI4-Lite: 32 bits
When connecting one master to one slave, the AXI Interconnect core can
optionally perform address range checking. Also, it can perform any of the
normal data-width, clock-rate, or protocol conversions and pipelining.
When connecting one master to one slave and not performing any conversions or
address range checking, the AXI Interconnect core is implemented as wires, with
no resources, no delay and no latency.
Each master and slave connection can independently use data widths of 32, 64,
128, or 256 bits wide:
-
The internal crossbar can be configured to have a native data-width of 32, 64,
128, or 256 bits.
www.xilinx.com
19
Each master and slave connection can use independent clock rates
Synchronous integer-ratio (N:1 and 1:N) conversion to the internal crossbar native
clock-rate.
Asynchronous clock conversion (uses more storage and incurs more latency than
synchronous conversion).
The AXI Interconnect core exports reset signals re-synchronized to the clock rate
of each connected master and slave.
The AXI Interconnect core can connect to any mixture of AXI4 and AXI4-Lite
masters and slaves.
The AXI Interconnect core saves transaction IDs and restores them during
response transfers, when connected to an AXI4-Lite slave.
-
The AXI Interconnect core detects illegal AXI4-Lite transactions from AXI4
masters, such as any transaction that results in a burst of more than one word. It
generates a protocol-compliant error response to the master, and does not
propagate the illegal transaction to the AXI4-Lite slave.
The AXI Interconnect core splits burst transactions of more than 16 beats from
AXI4 masters into multiple transactions of no more than 16 beats when connected
to an AXI3 slave.
Available on each AXI channel connecting to each master and each slave.
One latency cycle per register-slice, with no loss in data throughput under all AXI
handshaking conditions.
Available on Write and Read datapaths connecting to each master and each slave.
20
Parallel crossbar pathways for Write data and Read data channels. When
more than one Write or Read data source has data to send to different
destinations, data transfers may occur independently and concurrently,
provided AXI ordering rules are met.
www.xilinx.com
Shared write data, shared read data, and single shared address pathways.
Supports Write response re-ordering. Read data re-ordering, and Read Data
interleaving.
Configurable Write and Read transaction acceptance limits for each connected
master.
Configurable Write and Read transaction issuing limits for each connected slave.
One shared Write address arbiter, plus one shared Read address arbiter.
Arbitration latencies typically do not impact data throughput when
transactions average at least three data beats.
For each ID thread issued by a connected master, the master can have outstanding
transactions to only one slave for Writes and one slave for Reads, at any time.
Round-robin arbitration is used among all connected masters configured with the
lowest priority setting (priority 0), when no higher priority master is requesting.
Any master that has reached its acceptance limit, or is targeting a slave that has
reached its issuing limit, or is trying to access a slave in a manner that risks
deadlock, is temporarily disqualified from arbitration, so that other masters may
be granted arbitration.
Any non-secure accesses are blocked and the AXI Interconnect core returns a
DECERR response to the master
Support for Read-only and Write-only masters and slaves, resulting in reduced
resource utilization.
The AXI Interconnect core does not support the following AXI3 features:
Atomic locked transactions; this feature was retracted by AXI4 protocol. A locked
transaction is changed to a non-locked transaction and propagated to the slave.
Write interleaving; this feature was retracted by AXI4 protocol. AXI3 masters must be
configured as if connected to a slave with Write interleaving depth of one.
AXI4 QoS signals do not influence arbitration priority. QoS signals are propagated
from masters to slaves.
The AXI Interconnect core does not convert multi-beat bursts into multiple single-beat
transactions when connected to an AXI4-Lite slave.
The AXI Interconnect core does not support low-power mode or propagate the AXI
channel signals.
www.xilinx.com
21
The AXI Interconnect core does not time out if the destination of any AXI channel
transfer stalls indefinitely. All AXI slaves must respond to all received transactions, as
required by AXI protocol.
The AXI Interconnect core provides no built-in conversion to non-AXI protocols, such
as APB.
The AXI Interconnect core does not have clock-enable (ACLKEN) inputs. Consequently,
the use of ACLKEN is not supported among memory mapped AXI interfaces in Xilinx
systems.
Note: (The ACLKEN signal is supported for Xilinx AXI4-Stream interfaces.)
MI Hemisphere
Slave
Interface
Register Slices
Protocol Converters
Down-sizers
Clock Converters
Up-sizers
Data FIFOs
Data FIFOs
Down-sizers
Master 1
Clock Converters
Register Slices
Master 0
Up-sizers
Crossbar
Slave 0
Slave 1
Master
Interface
X12047
Figure 2-6:
22
Pass Through
Conversion Only
N-to-1 Interconnect
1-to-N Interconnect
www.xilinx.com
Pass Through
When there is one master device and one slave device only connected to the AXI
Interconnect, and the AXI Interconnect core is not performing any optional conversion
functions or pipelining, the AXI Interconnect core degenerates into direct wire connections
with no latency and consuming no logic resources.
Figure 2-7 shows the Pass Through diagram.
Interconnect
Master 0
Slave 0
Figure 2-7:
Conversion Only
The AXI Interconnect core can perform various conversion and pipelining functions when
connecting one master device to one slave device. These are:
In these cases, the AXI Interconnect core contains no arbitration, decoding, or routing logic.
There could be latency incurred, depending on the conversion being performed.
Figure 2-8 shows the one-to-one or conversion use case.
Interconnect
Master 0
Slave 0
Conversion
and/or
Pipelining
X12049
Figure 2-8:
www.xilinx.com
23
N-to-1 Interconnect
A common degenerate configuration of AXI Interconnect core is when multiple master
devices arbitrate for access to a single slave device, typically a memory controller.
In these cases, address decoding logic might be unnecessary and omitted from the AXI
Interconnect core (unless address range validation is needed).
Conversion functions, such as data width and clock rate conversion, can also be performed
in this configuration. Figure 2-9 shows the N to 1 AXI interconnection use case.
.
Master 0
Interconnect
Arbiter
Slave 0
Master 1
X12050
Figure 2-9:
1-to-N Interconnect
Another degenerative configuration of the AXI Interconnect core is when a single master
device, typically a processor, accesses multiple memory-mapped slave peripherals. In
these cases, arbitration (in the address and Write data paths) is not performed. Figure 2-10,
page 25, shows the 1 to N Interconnect use case.
24
www.xilinx.com
Interconnect
Decoder/Router
Master 0
Slave 0
Slave 1
X12051
Figure 2-10:
Master 0
AW
Slave 0
AW
Write
Transaction
Arbiter
AR
AR
Router
Master 1
Slave 1
AW
AW
AR
AR
Router
Master 2
Slave 2
AW
Read
Transaction
Arbiter
AR
AW
AR
X12052
Figure 2-11:
Figure 2-12, page 26 shows the sparse crossbar Write and Read data pathways.
www.xilinx.com
25
Interconnect
Master 0
Slave 0
Master 1
Slave 1
Master 2
Slave 2
Figure 2-12:
Parallel Write and Read data pathways connect each SI slot (attached to AXI masters on the
left) to all the MI slots (attached to AXI slaves on the right) that it can access, according to
the configured sparse connectivity map. When more than one source has data to send to
different destinations, data transfers can occur independently and concurrently, provided
AXI ordering rules are met.
The Write address channels among all SI slots (if > 1) feed into a central address arbiter,
which grants access to one SI slot at a time, as is also the case for the Read address
channels. The winner of each arbitration cycle transfers its address information to the
targeted MI slot and pushes an entry into the appropriate command queue(s) that enable
various data pathways to route data to the proper destination while enforcing AXI
ordering rules.
Width Conversion
The AXI Interconnect core has a parametrically-defined, internal, native data-width that
supports 32, 64, 128, and 256 bits. The AXI data channels that span the crossbar are sized to
the native width of the AXI Interconnect, as specified by the
C_INTERCONNECT_DATA_WIDTH parameter.
When any SI slots or MI slots are sized differently, the AXI Interconnect core inserts width
conversion units to adapt the slot width to the AXI Interconnect core native width before
transiting the crossbar to the other hemisphere.
The width conversion functions differ depending on whether the data path width gets
wider (up-sizing) or more narrow (down-sizing) when moving in the direction from
the SI toward the MI. The width conversion functions are the same in either the SI
hemisphere (translating from the SI to the AXI Interconnect core native width) or the MI
hemisphere (translating from the AXI Interconnect core native width to the MI).
26
www.xilinx.com
MI and SI slots have an associated individual parametric data-width value. The AXI
Interconnect core adapts each MI and SI slot automatically to the internal native
data-width as follows:
When the data width of an SI slot is wider than the internal native data width of the
AXI Interconnect, a down-sizing conversion is performed along the pathways of the
SI slot.
When the internal native data width of the AXI Interconnect core is wider than that of
an MI slot, a down-sizing conversion is performed along the pathways of the MI slot.
When the data width of an SI slot is narrower than the internal native data width of
the AXI Interconnect, an up-sizing conversion is performed along the pathways of the
SI slot.
When the internal native data width of the AXI Interconnect core is narrower than
that of an MI slot, an up-sizing conversion is performed along the pathways of the MI
slot.
Typically, the data-width of the AXI Interconnect core is matched to the smaller of the
widest SI slot or the widest MI slot in the system design.
The following subsections describe the down-sizing and up-sizing behavior.
Downsizing
Downsizers used in pathways connecting wide master devices are equipped to split burst
transactions that might exceed the maximum AXI burst length (even if such bursts are
never actually needed). When the data width on the SI side is wider than that on the MI
side and the transfer size of the transaction is also wider than the data width on the MI
side, then down-sizing is performed and, in the transaction issued to the MI side, the
number of data beats is multiplied accordingly.
When the transfer size of the transaction is equal to or less than the MI side data width, the
transaction (address channel values) remains unchanged, and data transfers pass through
unchanged except for byte-lane steering. This applies to both writes and reads.
Upsizing
For upsizers in the SI hemisphere, data packing is performed (for INCR and WRAP bursts),
provided the AW/ARCACHE[1] bit (Modifiable) is asserted.
In the resulting transaction issued to the MI side, the number of data beats is reduced
accordingly.
www.xilinx.com
27
Shared Access mode minimizes the resources used to implement the crossbar module of
the Interconnect. Figure 2-13 illustrates the Shared Access mode.
-ASTER
3LAVE
)NTERCONNECT
!7
!2
!7
!2
!RBITER
7
2
7
2
!DDRESS
3LAVE
-ASTER
!7
!2
!7
!2
7
2
7
2
7RITE $ATA
2EAD $ATA
Figure 2-13:
Clock Conversion
Clock conversion comprises the following:
A clock-rate reduction module performs integer (N:1) division of the clock rate from
its input (SI) side to its output (MI) side.
For both the reduction and the acceleration modules, the sample cycle for the faster clock
domain is determined automatically. Each module is applicable to all five AXI channels.
The MI and SI each have a vector of clock inputs in which each bit synchronizes all the
signals of the corresponding interface slot. The AXI Interconnect core has its own native
clock input. The AXI Interconnect core adapts the clock rate of each MI and SI slot
automatically to the native clock rate of the AXI Interconnect.
Typically, the native clock input of the AXI Interconnect core is tied to the same clock
source as used by the highest frequency SI or MI slot in the system design, such as the MI
slot connecting to the main memory controller.
Pipelining
Under some circumstances, AXI Interconnect core throughput is improved by buffering
data bursts. This is commonly the case when the data rate at a SI or MI slot differs from the
native data rate of the AXI Interconnect core due to data width or clock rate conversion.
To accommodate the various rate change combinations, data burst buffers can be inserted
optionally at the various locations.
Additionally, an optional, two-deep register slice (skid buffer) can be inserted on each of
the five AXI channels at each SI or MI slot to help improve system timing closure.
28
www.xilinx.com
The SI-side Write data FIFO is located before the Write data router of each SI slot.
The MI-side Write data FIFO is located after the Write data multiplexer of each MI
slot.
The MI-side Read data FIFO is located before (on the MI side of) the Read data router
of each MI slot.
The SI-side Read data FIFO is located after (on the SI side of) the Read data
multiplexers of each SI slot, including the MUX between multiple ID-thread pathways
for multi-threaded SI slots.
Data FIFOs are synchronized to the AXI Interconnect core native clock. The width of each
data FIFO matches the AXI Interconnect core native data width.
For more detail and the required signals and parameters of the AXI Interconnect core IP,
refer to the AXI Interconnect IP (DS768), available at the Xilinx website:
http://www.xilinx.com/support/documentation/axi_ip_documentation.htm.
Connects the master interface of one AXI Interconnect core module to slave interface
of another AXI Interconnect core module.
Directly connects all master interface signals to all slave interface signals.
Description
The AXI slave interface of the axi2axi_connector (connector) module always connects to
one attachment point (slot) of the master interface of one AXI Interconnect core module
(the upstream interconnect). The AXI master interface of the connector always connects
to one slave interface slot of a different AXI Interconnect core module (the downstream
interconnect) as shown in Figure 2-14, page 30.
www.xilinx.com
29
slave_1
AXI_Interconnect_2
M_AXI_IP
M_AXI_DP
mb_0
M_AXI_IC
M_AXI_DC
AXI_Interconnect_0
slave_2
axi2axi_connector
AXI_Interconnect_1
slave_3
X12036
Figure 2-14:
Master and Slave Interface Modules Connecting Two AXI Interconnect cores
Features
30
Connects an AXI master or slave interface to the AXI Interconnect core IP.
A master or slave AXI bus interface on one side and AXI ports on the other side.
Other ports are modeled as an I/O interface, which can be made external, thereby
providing the necessary signals that can be connected to a top-level master or slave.
www.xilinx.com
Figure 2-15, page 31 is a block diagram of the AXI external master connector.
EDK sub-system
ICAXI
Microblaze
DCAXI
Axi_interconnect
S_AXI
Memory controller
Axi_ext_master_conn
M_AXI
X12040
Figure 2-15:
S_AXI
ICAXI
Memory controller
Microblaze
DCAXI
Axi_interconnect
S_AXI
Axi_gpio
Individual AXI Ports made
external to sub-system
interface
S_AXI
Axi_ext_slave_conn
X12075
Figure 2-16:
The Platform Studio IP Catalog contains the external master and external slave connectors.
For more information, refer to the Xilinx website:
http://www.xilinx.com/ipcenter/axi4.htm.
www.xilinx.com
31
Centralized DMA
Xilinx provides a Centralized DMA core for AXI. This core replaces legacy PLBv4.6
Centralized DMA with an AXI4 version that contains enhanced functionality and higher
performance. Figure 2-17 shows a typical embedded system architecture incorporating the
AXI (AXI4 and AXI4-Lite) Centralized DMA.
AXI4 MMap
Interconnect
(AXI4-Lite)
AXI Intc
AXI4-Lite
Interrupt Out
(To AXI Intc)
Interrupts In
AXI CDMA
Interrupt
DP
AXI4-Lite
CPU
(AXI
MicroBlaze)
DC
AXI4
IC
AXI4
AXI4-Lite
AXI4 MMap
Interconnect
(AXI4)
AXI4
Registers
Scatter
Gather
Engine
AXI
DDRx
AXI4-Stream
AXI4 Read
AXI4
DataMover
AXI4 Write
AXI4-Stream
AXI
BRAM
AXI4
X12037
Figure 2-17:
The AXI4 Centralized DMA performs data transfers from one memory mapped space to
another memory mapped space using high speed, AXI4, bursting protocol under the
control of the system microprocessor.
32
www.xilinx.com
Waits for the microprocessor to program and start the next transfer
Also, the AXI Centralized DMA includes an optional data realignment function for 32- and
64-bit bus widths. This feature allows addressing independence between the transfer
source and destination addresses.
Use DataMover Lite for the main data transport (Data Realignment Engine (DRE) and
SG mode are not supported with this data transport mechanism)
Include or omit the DRE function (only available for 32- and 64-bit data transfer bus
widths)
Specify the main data transfer bus width (32, 64, 128, or 256 bits)
Specify the maximum allowed AXI4 burst length the DataMover will use during data
transfers
www.xilinx.com
33
Interface
AXI Type
Data Width
Description
Control
AXI4-Lite slave
32
Scatter Gather
AXI4 master
32
AXI4 Read
master
32, 64,
128, 256
AXI4 Write
master
32, 64,
128, 256
Ethernet DMA
The AXI4 protocol adoption in Xilinx embedded processing systems contains an Ethernet
solution with Direct Memory Access (DMA). This approach blends the performance
advantages of AXI4 with the effective operation of previous Xilinx Ethernet IP solutions.
Figure 2-18, page 35 provides high-level block diagram of the AXI DMA.
34
www.xilinx.com
AXI DMA
AXI Lite
MM2S_IntrOut
S2MM_IntrOut
Register Module
MM2S_DMACR
MM2S_DMASR
MM2S_CURDESC
Reserved
MM2S_TAILDESC
Reserved
SG Interface
S2MM_DMACR
S2MM_DMASR
S2MM_CURDESC
Reserved
S2MM_TAILDESC
Reserved
AXI Control
Interface
AXI Control
Stream (MM2S)
AXI Stream
(MM2S)
AXI DataMover
SG Engine
(Interrupt Coalescing)
AXI Stream
(S2MM)
SG Interface
AXI Status
Interface
Reset
Module
X12038
Figure 2-18:
Figure 2-19 shows a typical system architecture for the AXI Ethernet.
Figure Top x-ref 3
AXI Intc
AXI4-Lite
AXI Ethernet
AXI4 MMap
Interconnect
Registers
AXI4-Lite
Interrupts In
MIIM
Ethernet Tx
AXI DMA
Interrupt
Ethernet Rx
DP
AXI4-Lite
AXI4-Lite
Registers
AXI4
Scatter
Gather
Engine
AXI4-Stream
CPU
(AXI
MicroBlaze)
AXI4 MMap
Interconnect
DC
AXI4
IC
AXI4
Ethernet
Control
and Status
AVB
AXI4-Stream
AXI4-Stream
Tx
Control
AXI4-Stream
Rx
Status
AXI4-Stream
Tx
Payload
AXI4-Stream
Rx
Payload
AXI
DDRx
AXI4
AXI4 Read
DataMover
AXI4 Write
AXI
BRAM
Interrupt Out
(To AXI Intc)
Interrupt Out
(To AXI Intc)
AXI4
X12039
Figure 2-19:
www.xilinx.com
35
As shown in Figure 2-19, page 35, the AXI Ethernet is now paired with a new AXI DMA IP.
The AXI DMA replaces the legacy PLBv4.6 SDMA function that was part of the PLBv4.6
Multi-Port Memory Controller (MPMC).
The AXI DMA is used to bridge between the native AXI4-Stream protocol on the AXI
Ethernet to AXI4 memory mapped protocol needed by the embedded processing system.
36
www.xilinx.com
Interface
AXI Type
Data
Width
Control
AXI4-Lite slave
32
Scatter Gather
AXI4 master
32
Data MM Read
AXI4 Read
master
32, 64,
128, 256
Data MM Write
AXI4 Write
master
32, 64,
128, 256
AXI4-Stream
master
32, 64,
128, 256
Data Stream In
AXI4-Stream
slave
32, 64,
128, 256
AXI4-Stream
master
32
Status Stream In
AXI4-Stream
slave
32
Description
www.xilinx.com
37
Video DMA
The AXI4 protocol Video DMA (VDMA) provides a high bandwidth solution for Video
applications. It is a similar implementation to the Ethernet DMA solution.
Figure 2-20 shows a top-level AXI4 VDMA block diagram.
AXI VDMA
AXI Memory Map SG Read
AXI Lite
MM2S_IntrOut
S2MM_IntrOut
Register Module
MM2S_DMACR
MM2S_DMASR
MM2S_CURDESC
Reserved
MM2S_TAILDESC
Reserved
S2MM_DMACR
S2MM_DMASR
S2MM_CURDESC
Reserved
S2MM_TAILDESC
Reserved
MM2S
FSync
MM2S
Gen-Lock
MM2S Frame Size
MM2S Stride
MM2S Strt Addr 0
Down
Sizer
MM2S Line
Bufffer Status
AXI MM2S
Stream
Line
Buffer
SG Engine
(Interrupt Coalescing )
AXI DataMover
Up
Sizer
S2MM Line
Bufffer Status
AXI S2MM
Stream
Line
Buffer
MM2S Frame Size
MM2S Stride
axi_resetn
Reset
Module
m_axis_mm2s_aresetn
s_axis_s2mm_aresetn
S2MM
FSync
S2MM
Gen-Lock
x12054
Figure 2-20:
Figure 2-21, page 39 illustrates a typical system architecture for the AXI VDMA.
38
www.xilinx.com
&IGURE 4OP X REF
!8) )NTC
!8)
,ITE
!8) --AP
)NTERCONNECT
)NTERRUPTS )N
)NTERRUPT /UT
4O !8) )NTC
!8) 6$-!
)NTERRUPT
#05
!8)
-ICRO"LAZE
$0
!8) ,ITE
2EGISTERS
!8) ,ITE
!8) )NTERCONNECT
!8) 2EAD
$#
!8)
)#
!8)
3CATTER
'ATHER
%NGINE
--3 &3YNC
--3
'EN,OCK
6IDEO
4IMING
#ONTROLLER
--3
#ONTROLLER
!8) $$2X
6IDEO )0
!8)
!8) 3TREAM
!8) 2EAD
'EN,OCK
$ATA-OVER
6IDEO /UT
6IDEO )0
!8) "2!-
!8) 7RITE
!8)
!8) 3TREAM
6IDEO )N
3-#ONTROLLER
3--
'EN,OCK
3-- &SYNC
6IDEO
4IMING
#ONTROLLER
8
Figure 2-21:
www.xilinx.com
39
Interface
AXI Type
Data Width
Description
Control
AXI4-Lite slave
32
Scatter Gather
AXI4 master
32
Data MM Read
32, 64,
128, 256
Data MM Write
AXI4-Stream master
Data Stream In
AXI4-Stream slave
32, 64,
128, 256
8,16, 32,
64, 128, 256
8, 16, 32,
64, 128, 256
In the CORE Generator interface, through the Memory Interface Generator (MIG)
tool.
The underlying HDL code between the two packages is the same with different wrappers.
The flexibility of the AXI4 interface allows easy adaptation to both controller types.
40
www.xilinx.com
Virtex-6
The Virtex-6 memory controller solution is provided by the Memory Interface Generator
(MIG) tool and is updated with an optional AXI4 interface.
This solution is available through EDK also, with an AXI4-only interface as the
axi_v6_ddrx memory controller.
The axi_v6_ddrx memory controller uses the same Hardware Design Language (HDL)
logic and uses the same GUI, but is packaged for EDK processor support through XPS. The
Virtex-6 memory controller is adapted with an AXI4 Slave Interface (SI) through an AXI4
to User Interface (UI) bridge. The AXI4-to-UI bridge converts the AXI4 slave transactions
to the MIG Virtex-6 UI protocol. This supports the same options that were previously
available in the Virtex-6 memory solution.
The optimal AXI4 data width is the same as the UI data width, which is four times the
memory data width. The AXI4 memory interface data width can be smaller than the UI
interface but is not recommended because it would result in a higher area, lower timing/
performance core to support the width conversion.
The AXI4 interface maps transactions over to the UI by breaking each of the AXI4
transactions into smaller stride, memory-sized transactions. The Virtex-6 memory
controller then handles the bank/row management for higher memory utilization.
Figure 2-22 shows a block diagram of the Virtex-6 memory solution with the AXI4
interface.
axi_v6_ddrx (EDK) or memc_ui_top (COREGen) top level
AXI4 Master
AXI4
Interface
AXI4 Slave
Interface
Block
UI
Interface
Figure 2-22:
User
Interface
bllock
Native
Interface
Virtex-6
Memory
Controller
DFI
DDR2 /
DDR3 PHY
DDR2 / DDR3
DDR2 or
DDR3
SDRAM
external
www.xilinx.com
41
Converts AXI4 incremental (INCR) commands to MCB commands in a 1:1 fashion for
transfers that are 16 beats or less.
Breaks down AXI4 transfers greater than 16 beats into 16-beat maximum transactions
sent over the MCB protocol.
This allows a balance between performance and latency in multi-ported systems. AXI4
WRAP commands can be broken into two MCB transactions to handle the wraps on the
MCB interface, which does not natively support WRAP commands natively.
The axi_s6_ddrx core and Spartan-6 AXI MIG core from CORE Generator support all
native port configurations of the MCB including 32, 64, and 128 bit wide interfaces with up
to 6 ports (depending on MCB port configuration). Figure 2-23 shows a block diagram of
the AXI Spartan-6 memory solution.
fpga boundary
axi_s6_ddrx or mcb_ui_top
mcb_raw_wrapper
AXI4 Master
AXI4 Slave
Interface 0
Port 0
AXI4 Master
AXI4 Slave
Interface 1
Port 1
LPDDR/
DDR/
DDR2/
DDR3
SDRAM
MCB
AXI4 Master
AXI4 Slave
Interface 5
Port 5
X12046
Figure 2-23:
For more detail on memory control, refer to the memory website documents at
http://www.xilinx.com/products/design_resources/mem_corner.
42
www.xilinx.com
Chapter 3
AXI Feature
READY/VALIDY
Handshake
Transfer Length
Xilinx IP Support
Full forward and reverse direction flow control of AXI protocol-defined READY/VALID
handshake.
AXI4 memory mapped burst lengths of:
IP can be defined with native data widths of 32, 64, 128, and 256 bits wide.
For AXI4-Lite, the supported data width is 32 bits only.
The use of AXI4 narrow bursts is supported but is not recommended. Use of narrow bursts
can decrease system performance and increase system size.
Where Xilinx IP of different widths need to communicate with each other, the AXI
Interconnect provides data width conversion features.
Read/Write only
Designed to support AXI4 natively. Where AXI3 interoperability is required, the AXI
Interconnect contains the necessary conversion logic to allow AXI3 and AXI4 devices to
connect.
AXI3 Write interleaving is not supported and should not be used with Xilinx IP.
Note: The AXI3 Write Interleaving feature was removed from the AXI4 specification.
www.xilinx.com
43
Table 3-1:
AXI Feature
Xilinx IP Support
Infrastructure IP passes protection and cache bits across a system, but Endpoint IP generally
do not contain support for dynamic protection or cache bits.
Protections bits should be constant at 000 signifying a constantly secure transaction type.
Cache bits should generally be constant at 0011 signifying a bufferable and modifiable
transaction.
This provides greater flexibility in the infrastructure IP to transport and modify transactions
passing through the system for greater performance.
Quality of Service (QoS)
Bits
REGION Bits
The Xilinx AXI Interconnect generates REGION bits based upon the Base/High address
decoder ranges defined in the address map for the AXI interconnect.
Xilinx infrastructure IP, such as register slices, pass region bits across a system.
Some Endpoint slave IP supporting multiple address ranges might use region bits to avoid
redundant address decoders.
AXI Master Endpoint IP do not generate REGION bits.
User Bits
Infrastructure IP passes user bits across a system, but Endpoint IP generally ignores user bits.
The use of user bits is discouraged in general purpose IP due to interoperability concerns.
However the facility to transfer user bits around a system allows special purpose custom
systems to be built that require additional transaction-based sideband signaling. An example
use of USER bits would be for transferring parity or debug information.
Reset
Xilinx IP generally deasserts all VALID outputs within eight cycles of reset, and have a reset
pulse width requirement of 16 cycles or greater.
Holding AXI ARESETN asserted for 16 cycles of the slowest AXI clock is generally a sufficient
reset pulse width for Xilinx IP.
44
Not Supported. The optional AXI low power interfaces, CSYSREQ, CSYSACK, and CACTIVE
are not present on IP interfaces.
www.xilinx.com
AXI4-Stream Signals
Table 3-2 lists the AXI4-Stream signals, status, and notes on usage.
Table 3-2:
AXI4-Stream Signals
Signal
Status
Notes
TVALID
Required
TREADY
Optional
TDATA
Optional
TSTRB
Optional
TKEEP
Absent
TLAST
Optional
TID
Optional
TDEST
Optional
TUSER
Optional
The physical view describes how the logical view is mapped to bits and the
underlying AXI4-Stream signals.
Simple vectors of values represent numerical data at the logical level. Individual values
can be real or complex quantities depending on the application. Similarly the number of
elements in the vector will be application-specific.
www.xilinx.com
45
At the physical level, the logical view must be mapped to physical wires of the interface.
Logical values are represented physically by a fundamental base unit of bit width N, where
N is application-specific. In general:
N bits are interpreted as a fixed point quantity, but floating point quantities are also
permitted.
Complex values are represented as a pair of base units signifying the real component
followed by the imaginary component.
To aid interoperability, all logical values within a stream are represented using base units
of identical bit width.
Before mapping to the AXI4-Stream signal, TDATA, the N bits of each base unit are rounded
up to a whole number of bytes. As examples:
This simplifies interfacing with memory-orientated systems, and also allows the use of
AXI infrastructure IP, such as the AXI Interconnect, to perform upsizing and downsizing.
By convention, the additional packing bits are ignored at the input to a slave; they
therefore use no additional resources and are removed by the back-end tools. To simplify
diagnostics, masters drive the unused bits in a representative manner, as follows:
Signed quantities are sign-extended (the unused bits are copies of the sign bit).
The width of TDATA can allow multiple base units to be transferred in parallel in the same
cycle; for example, if the base unit is packed into 16 bits and TDATA signal width was 64
bits, four base units could be transferred in parallel, corresponding to four scalar values or
two complex values. Base units forming the logical vector are mapped first spatially
(across TDATA) and then temporally (across consecutive transfers of TDATA).
Deciding whether multiple sub-fields of data (that are not byte multiples) should be
concatenated together before or after alignment to byte boundaries is generally
determined by considering how atomic is the information. Atomic information is data that
can be interpreted on its own whereas non-atomic information is incomplete for the
purpose of interpreting the data.
For example, atomic data can consist of all the bits of information in a floating point
number. However, the exponent bits in the floating point number alone would not be
atomic. When packing information into TDATA, generally non-atomic bits of data are
concatenated together (regardless of bit width) until they form atomic units. The atomic
units are then aligned to byte boundaries using pad bits where necessary.
46
www.xilinx.com
Unsigned Real
16 bits
16 bits
X12056
www.xilinx.com
47
Alternatively, scalar values can also be considered as vectors of unity length, in which case
TLAST should be driven active-High (TLASTB). As the value type is unsigned, the unused
packing bits are driven 0 (zero extended).
Similarly, for signed data the unused packing bits are driven with the sign bits
(sign-extended), as shown in Figure 3-2:
X12057
Signed Complex
16 bits
16 bits
X12058
Figure 3-3:
Where re(X) and im(X) represent the real and imaginary components of X respectively.
48
www.xilinx.com
Note: For simplicity, sign extension into TDATA[15:12] is not illustrated here. A complex value is
transferred every two clock cycles.
The same data can be similarly represented on a channel with a TDATA signal width of 32
bits; the wider bus allows a complex value to be transferred every clock cycle, as shown in
Figure 3-4:
X12059
Figure 3-4:
The two representations in the preceding figures of the same data (serial and parallel)
show that data representation can be tailored to specific system requirements. For
example, a:
High throughput processing engine such as a Fast Fourier Transform (FFT) might
favor the parallel form
MAC-based Finite Impulse Response (FIR) might favor the serial form, thus enabling
Time Division Multiplexing (TDM) data path sharing
Use an AXI4-Stream-based upsizer to convert the serial form to the parallel form.
Use an AXI4-Stream-based downsizer to convert the parallel form to the serial form.
Signed Complex
16 bits
16 bits
www.xilinx.com
49
X12060
Figure 3-5:
As for the scalar case, the same data can be represented on a channel with TDATA width of
32 bits, as shown in Figure 3-6:
X12061
Figure 3-6:
50
www.xilinx.com
The degree of parallelism can be increased further for a channel with TDATA width of 64
bits, as shown in Figure 3-7:
x12062
Figure 3-7:
Full parallelism can be achieved with TDATA width of 128 bits, as shown in Figure 3-8:
X12063
Figure 3-8:
www.xilinx.com
51
As shown for the scalar data in the preceding figures, there are multiple representations
that can be tailored to the application.
Similarly, AXI4-Stream upsizers and downsizers can be used for conversion.
52
For Packetized Data, TKEEP might be needed to signal packet remainders. When the
TDATA width is greater than the atomic size (minimum data granularity) of the
stream, a remainder is possible because there may not be enough data bytes to fill an
entire data beat. The only supported use of TKEEP for Xilinx endpoint IP is for packet
remainder signaling and deasserted TKEEP bits (which is called "Null Bytes" in the
AXI4-Stream Protocol v1.0) are only present in a data beat with TLAST asserted. For
non-packetized continuous streams or packetized streams where the data width is the
same size or smaller than the atomic size of data, there is no need for TKEEP. This
generally follows the Continuous Aligned Stream model described in the
AXI4-Stream protocol.
www.xilinx.com
The AXI4-Stream protocol describes the usage for TKEEP to encode trailing null bytes
to preserve packet lengths after size conversion, especially after upsizing an odd
length packet. This usage of TKEEP essentially encodes the remainder bytes after the
end of a packet which is an artifact of upsizing a packet beyond the atomic size of the
data.
Xilinx AXI master IP do not to generate any packets that have trailing transfers with all
TKEEP bits deasserted. This guideline maximizes compatibility and throughput since
Xilinx IP will not originate packets containing trailing transfers with all TKEEP bits
deasserted. Any deasserted TKEEP bits must be associated with TLAST = 1 in the
same data beat to signal the byte location of the last data byte in the packet.
Xilinx AXI slave IP are generally not designed to be tolerant of receiving packets that
have trailing transfers with all TKEEP bits deasserted. Slave IP that have TKEEP inputs
only sample TKEEP with TLAST is asserted to determine the packet remainder bytes.
In general if Xilinx IP are used in the system with other IP designed for Continuous
Aligned Streams as described in the AXI4-Stream specification, trailing transfers with
all TKEEP bits deasserted will not occur.
All streams entering into a system of Xilinx IP must be fully packed upon entry in the
system (no leading or intermediate null bytes) in which case arbitrary size conversion
will only introduce TKEEP for packet remainder encoding and will not result in data
beats where all TKEEP bits are deasserted.
Sideband Signals
The AXI4-Stream interface protocol allows passing sideband signals using the TUSER bus.
From an interoperability perspective, use of TUSER on an AXI4-Stream channel is an issue
as both master and Slave must now not only have the same interpretation of TDATA, but
also of TUSER.
Generally, Xilinx IP uses the TUSER field only to augment the TDATA field with
information that could prove useful, but ultimately can be ignored. Ignoring TUSER could
result in some loss of information, but the TDATA field still has some meaning.
For example, an FFT core implementation could use a TUSER output to indicate block
exponents to apply to the TDATA bus; if TUSER was ignored, the exponent scaling factor
would be lost, but TDATA would still contain un-scaled transform data.
Events
An event signal is a single wire interface used by a core to indicate that some specific
condition exists (for example: an input parameter is invalid, a buffer is empty or nearly
full, or the core is waiting on some additional information). Events are asserted while the
condition is present, and are deasserted once the condition passes, and exhibit no latching
behavior. Depending on the core and how it is used in a system, an asserted event might
indicate an error, a warning, or information. Event signals can be viewed as AXI4-Stream
channels with an VALID signal only, without any optional signals. Event signals can also
be considered out-of-band information and treated like generic flags, interrupts, or status
signals.
www.xilinx.com
53
Ignored:
Unless explicitly stated otherwise, a system can ignore all event conditions.
In general, a core continues to operate while an event is asserted, although potentially
in some degraded manner.
As Interrupts or GPIOs:
An event signal might be connected to a processor using a suitable interrupt controller
or general purpose I/O controller. System software is then free to respond to events as
necessary.
As Simulation Diagnostic:
Events can be useful during hardware simulation. They can indicate interoperability
issues between masters and slaves, or indicate misinterpretation of how subsystems
interact.
As Hardware Diagnostic:
Similarly, events can be useful during hardware diagnostic. You can route events
signals to diagnostic LED or test points, or connect them to the ChipScope Pro
Analyzer.
TLAST Events
Some slave channels do not require a TLAST signal to indicate packet boundaries. In such
cases, the core has a pair of events to indicate any discrepancy between the presented
TLAST and the internal concept of packet boundaries:
Depending on the system design these events might or might not indicate potential
problems.
For example, consider an FFT core used as a coprocessor to a CPU where data is streamed
to the core using a packet-orientated DMA engine.
The DMA engine can be configured to send a contiguous region of memory of a given
length to the FFT core, and to correctly assert TLAST at the end of the packet. The system
software can elect to use this coprocessor in a number of ways:
Single transforms:
The simplest mode of operation is for the FFT core and the DMA engine to operate in
a lockstep manner. If the FFT core is configured to perform an N point transform, then
the DMA engine should be configured to provide packets of N complex samples.
54
www.xilinx.com
If a software or hardware bug is introduced that breaks this relationship, the FFT core
will detect TLAST mismatches and assert the appropriate event; in this case indicating
error conditions.
Grouped transforms:
Typically, for each packet transferred by the DMA engine, a descriptor is required
containing start address, length, and flags; generating descriptors and sending them to
the engine requires effort from the host CPU. If the size of transform is short and the
number of transforms is high, the overhead of descriptor management might begin to
overcome the advantage of offloading processing to the FFT core.
One solution is for the CPU to group transforms into a single DMA operation. For
example, if the FFT core is configured for 32-point transforms, the CPU could group 64
individual transforms into a single DMA operation. The DMA engine generates a
single 2048 sample packet containing data for the 64 transforms; however, as the DMA
engine is only sending a single packet, only the data for the last transform has a
correctly placed TLAST. The FFT core would report 63 individual missing TLAST
events for the grouped operation. In this case the events are entirely expected and do
not indicate an error condition.
In the example case, the unexpected TLAST event should not assert during normal
operation. At no point should a DMA transfer occur where TLAST does not align with
the end of an FFT transform. However, as for the described single transform example
case, a software or hardware error could result in this event being asserted. For
example, if the transform size is incorrectly changed in the middle of the grouped
packet, an error would occur.
Streaming transforms:
For large transforms it might be difficult to arrange to hold the entire input packet in a
single contiguous region of memory.
In such cases it might be necessary to send data to the FFT core using multiple smaller
DMA transfers, each completing with a TLAST signal. Depending on how the CPU
manages DMA transfers, it is possible that the TLAST signal never aligns correctly
with the internal concept of packet boundaries within the FFT core.
The FFT core would therefore assert both missing TLAST and unexpected
TLAST events as appropriate while the data is transferring. In this example case, both
events are entirely expected, and do not indicate an error condition.
A blocking case performs a transform only when both a control packet and a data
packet are presented to the core.
A non-blocking case performs a transform with just a data packet, with the core
reusing previous control information.
www.xilinx.com
55
There are numerous tradeoffs related to the use of blocking versus non-blocking interfaces:
Feature
Synchronization
Blocking
Non-blocking
Automatic
Not automatic
Signaling
Small
Minimized
Overhead
Connectivity
Resource Overhead
Simple
Complex
Small
None
56
www.xilinx.com
Chapter 4
Were created using the Create and Import IP Wizard in a previous version of
Xilinx tools.
Cannot be altered, and needs to be used as-is with its existing PLBv4.6 interface.
IP created from scratch is not discussed in this section; refer to Memory Mapped IP Feature
Adoption and Support, page 43 as well as the ARM AMBA AXI Protocol v2.0 Specification
specification available from the ARM website. New IP should be designed to the AXI
protocol.
IP that used the Create and Import Peripheral (CIP) Wizard in previous version of Xilinx
tools can be migrated using templates provided in solution record:
http://www.xilinx.com/support/answers/37425.htm.
IP that needs to remain unchanged can be used in the Xilinx tools using the AXI to PLB
bridge. See the following section, The AXI To PLB Bridge, for more information.
Larger pieces of Xilinx IP (often called Connectivity or Foundation IP): This class of IP has
migration instructions in the respective documentation. This class of IP includes: PCIe,
Ethernet, Memory Core, and Serial Rapid I/O.
DSP IP: General guidelines on converting this broad class of IP is covered in.
Local-Link Interface: Local-Link is a generic streaming, FIFO-like interface that has been
in service at Xilinx for a number of software generations. See Migrating Local-Link to
AXI4-Stream, page 60 for more information.
www.xilinx.com
57
Features
The Xilinx AXI (AXI4 and AXI4-Lite) to PLBv4.6 Bridge is a soft IP core with the following
supported features:
32- or 64-bit data buses on AXI and PLB interfaces (1:1 ratio)
58
Read/Write interface
Read-only interface
Write-only interface
Unaligned transactions
Interrupt generation for partial data strobes except first and last data beat
www.xilinx.com
Supports 32-, 64-, and 128-bit PLBv4.6 data bus widths with required data mirroring
PORT 2
AXI4 Lite
AXI4-PLBv46
Bridge
AXILitePLBv46
Bridge
PLB v46
PORT 1
AXI4
Registers
X12064
Figure 4-1:
The AXI data bus width is 32- and 64-bit and the PLBv4.6 master is a 32- and 64-bit
device (for example, C_MPLB_NATIVE_DWIDTH= 32/64).
PLBv4.6 data bus widths of 32-bit, 64-bit, and 128-bit are supported with the AXI to
PLBv4.6 Bridge performing the required data mirroring.
AXI transactions are received on the AXI Slave Interface (SI), then translated to
PLBv4.6 transactions on the PLBv4.6 bus master interface.
Both Read data and Write data are buffered (when C_S_AXI_PROTOCOL=AXI4) in
the bridge, because of the mismatch of AXI and PLBv4.6 protocols where AXI
protocol allows the master to throttle data flow, but PLBv4.6 protocol does not allow
PLB masters to throttle data flow.
www.xilinx.com
59
The bridge:
Buffers the Write data input from the AXI port before initiating the PLBv4.6 Write
transaction.
Implements a Read and Write data buffer of depth 32x32/64x32 to hold the data for
two PLB transfers of highest (16) burst length.
60
Signal Name
Direction
Description
Mapping to
AXI4-Stream
Signals
CLK
Input
ACLK
RST_N
Input
ARESETN
(or some other
reset)
DATA
src to dst
TDATA
SRC_RDY_N
src to dst
TVAILD
DST_RDY_N
dst to src
TREADY
SOF_N
src to dst
<none>
EOF_N
src to dst
TLAST
CLK
Input
ACLK
You can map clock and reset signals directly to the appropriate clock and reset for the
given interface. The ARESETN signal is not always present in IP cores, but you can
instead use another system reset signal.
www.xilinx.com
The Source and Destination Read are active-Low signals. You can translate these
signals to TVALID and TREADY by inverting them to an active-High signal.
Note: The TREADY signal is optional. It is assumed that when you convert an interface, you
chose to use this signal.
The EOF_N is an active-Low signal used to indicate the end of a frame. With an
inversion, this will connect directly to TLAST, which is an optional signal.
P0
P1
P2
P3
P4
P5
X12043
Figure 4-2:
Figure 4-2 shows how the flow control signals (SRC_RDY_N and DST_RDY_N) restrict data
flow. Also, observe how SOF_N and EOF_N signals frame the data packet.
Figure 4-3 shows the same type of transaction with AXI4-Stream. Note the only major
difference is the absence of an SOF signal, which is now implied.
ACLK
TLAST
TVALID
TREADY
TDATA
P0
P1
P2
P3
P4
P5
X12042
Figure 4-3:
AXI4-Stream Waveform
www.xilinx.com
61
Signal Name
62
Direction
Description
Mapping to AXI
SOP_N
src to dst
Start-of-Packet: Packetization
within a frame.
TUSER
EOP_N
src to dst
End-of-Packet: Packetization
within a frame.
TUSER
REM
src to dst
TKEEP
SRC_DSC_N
src to dst
TUSER
DST_DSC_N
dst to src
Destination Discontinue:
Indicates the destination
device is cancelling a frame.
<none>
CH
src to dst
TID
PARITY
src to dst
TUSER
Any optional signal that is not represented in this table must be sent using the TUSER
signal.
The SOP_N and EOP_N signals are rarely used in Local-Link. They add granularity to
the SOF/EOF signals. If there is a need for them, they must be created in the TUSER
field.
The REM signal specifies the remainder of a packet. AXI4-Stream has TKEEP bus that
may have deasserted bits when TLAST = 1 to signal the location of the last byte in the
packet.
The CH indicator can be mapped to the thread ID (TID). For parity, or any error
checking, the TUSER is a suitable resource.
www.xilinx.com
Variations in Local-Link IP
There are some variations of Local-Link to be aware of:
Some users create their own signals for Local-Link. These signals are not defined in
the Local-Link specification.
-
In cases where the signal goes from the source to the destination, a suitable
location is TUSER.
If the signals go from the destination to the source, they cannot use TUSER or any
other AXI4-Stream signal. Instead, one of the preferable methods is to create a
second return AXI4-Stream interface. In this case, most of the optional
AXI4-Stream signals would not be used; only the TVALID and TUSER signals.
Local-Link References
The Local-Link documentation is on the following website:
http://www.xilinx.com/products/design_resources/conn_central/locallink_member/sp06.pdf.
Resets
In System Generator, the resets on non-AXI IP are active-High. AXI IP in general, and in
System Generator, has an active-Low reset, aresetn. System Generator Inverter blocks
are necessary when using a single reset signal to reset both AXI and non-AXI IP.
A minimum aresetn active-Low pulse of two cycles is required, because the signal is
internally registered for performance. Additionally, aresetn always takes priority over
aclken.
Clock Enables
In System Generator, the clock enables on both non-AXI and AXI IP are active-High. AXI
IP in System Generator use an active-High clock-enable, aclken.
TDATA
In AXI protocols, data is consolidated onto a single TDATA input stream. This is consistent
with the top-level ports on DSP IP in CORE Generator. For ease of connecting data ports,
System Generator breaks TDATA down into individual ports in the block view.
www.xilinx.com
63
An example of this is the AXI Complex Multiplier block as shown in Figure 4-4:
Figure 4-4:
Port Ordering
When comparing non-AXI and AXI IP, such as the Complex Multiplier 3.1 and 4.0,
respectively, the real and imaginary ports appear in opposite order when looking at the
block from top to bottom. You must be careful to not connect the AXI block with the data
paths accidentally crossed. Figure 4-5 shows an example of the port signals.
Figure 4-5:
64
www.xilinx.com
Latency
With AXI IP in System Generator, the latency is handled in a different fashion than
non-AXI IP. In non-AXI IP, you can specify latency directly using either a GUI option or by
specifying -1 in the maximum performance option. With AXI IP, the latency is either
Automatic or Manual:
To manually set the latency, the parameter is called Minimum Latency for AXI blocks
because in blocking mode, the latency can be higher than the minimum latency
specified if the system has back pressure. In a non-blocking AXI configuration, the
latency is deterministic.
The following tables list the master-FSL and slave-FSL to AXI4-Stream signals conversion
mappings.
Signal
Direction
AXI Signal
Direction
FSL_M_Clk
Out
M_AXIS_<Port_
Name>ACLK
In
FSL_M_Write
Out
M_AXIS_<Port_
Name>TVALID
Out
www.xilinx.com
65
Table 4-3:
Signal
Direction
AXI Signal
Direction
FSL_M_Full
In
M_AXIS_<Port_
Name>TREADY
In
FSL_M_Data
Out
M_AXIS_<Port_
Name>TDATA
Out
FSL_M_Control
Out
M_AXIS_<Port_
Name>TLAST
Out
Direction
AXI Signal
Direction
S_AXIS_<Port_Name>ACLK
In
In
S_AXIS_<Port_Name>TVALID
In
FSL_S_Full
Out
S_AXIS_<Port_Name>TREADY
Out
FSL_S_Data
In
S_AXIS_<Port_Name>TDATA
In
FSL_S_Control
In
S_AXIS_<Port_Name>TLAST
In
FSL_S_Write
Out
Differences in Throttling
There are fundamental differences in throttling between FSL and AXI4-Stream, as follows:
The AXI_M_TVALID signal cannot be deasserted after being asserted unless a transfer
is completed with AXI_TREADY. However, a AXI_TREADY can be asserted and
deasserted whenever the AXI4-Stream slave requires assertion and deassertion.
For FSL, the signals FSL_Full and FSL_Exists are the status of the interface; for
example, if the slave is full or if the master has valid data
The MicroBlaze processor has an FSL test instruction that checks the current status of the
FSL interface. For this instruction to function on the AXI4-Stream, MicroBlaze has an
additional 32-bit Data Flip-Flop (DFF) for each AXI4-Stream master interface to act as an
output holding register.
When MicroBlaze executes a put fsl instruction, it writes to this DFF. The AXI4-Stream
logic inside MicroBlaze moves the value out from the DFF to the external AXI4-Stream
slave device as soon as the AXI4-Stream allows. Instead of checking the AXI4-Stream
TREADY/TVALID signals, the fsl test instruction checks if the DFF contains valid data
instead because the AXI_S_TREADY signal cannot be directly used for this purpose.
66
www.xilinx.com
The additional 32-bit DFFs ensure that all current FSL instructions to work seamlessly on
AXI4-Stream. There is no change needed in the software when converting from FSL to
AXI4 stream.
For backward compatibility, the MicroBlaze processor supports keeping the FSL interfaces
while the normal memory mapped AXI interfaces are configured for AXI4. This is
accomplished by having a separate, independent MicroBlaze configuration parameter
(C_STREAM_INTERCONNECT) to determine if the stream interface should be AXI4-Stream or
FSL.
Demonstration Testbench
Figure 4-6 shows an Example IP Data Sheet list.
Figure 4-6:
To assist with core migration, CORE Generator generates an example testbench in the
demo_tb directory under the CORE Generator project directory. The testbench instantiates
the generated core and demonstrates a simple example of how the DSP IP works with the
AXI4-stream interface. This is a simple VHDL testbench that exercises the core. The
demonstration testbench source code is one VHDL file, demo_tb/
www.xilinx.com
67
comprehensively commented. The demonstration testbench drives the input signals of the
core to demonstrate the features and modes of operation of the core with the AXI4-Stream
interface. For more information on how to use the generated testbench refer to the
Demonstration Testbench section in the individual IP data sheet.
Figure 4-7 shows the demo_tb directory structure.
Figure 4-7:
Figure 4-8:
Note: The upgrade mechanism alone will not create a core compatible with the latest version but will
provide a core that has equivalent parameter selection as the previous version of the core. The core
instantiation in the design must be updated to use the AXI4-Stream interface. The upgrade
mechanism also creates a backup of the old XCO file. The generated output is contained in the /tmp
folder of the CORE Generator project.
Latency Changes
An individual AXI4-Stream slave channel can be categorized as either a blocking or a
non-blocking channel. A slave channel is blocking when some operation of the core is
inhibited until a transaction occurs on that channel. In general, the latency of the DSP IP
AXI4-Stream interface is static for non-blocking and variable for blocking mode. To reduce
errors while migrating your design, pay attention to the Latency Changes and
Instructions for Minimum Change Migration sections of the IP data sheet.
68
www.xilinx.com
Signal
FSL_S_Clk
Direction
AXI Signal
Direction
S_AXIS_<Port_Name>ACLK
In
In
S_AXIS_<Port_Name>TVALID
In
FSL_S_Full
Out
S_AXIS_<Port_Name>TREADY
Out
FSL_S_Data
In
S_AXIS_<Port_Name>TDATA
In
FSL_S_Control
In
S_AXIS_<Port_Name>TLAST
In
FSL_S_Write
Out
www.xilinx.com
69
2.
Existing software that ran on a MicroBlaze PLBv4.6 big-endian system might need to
change:
a.
b.
In SDK, import the new AXI hardware handoff, create new board software
packages, and import the software applications.
c.
d. If running the GNU tools on the command line and writing make files, the correct
compiler flag mlittle-endian must be used.
3.
Do not mix object files (.o) and libraries created with different endian data
representations.
b.
c.
Do not use ELF files built for big-endian systems on a little-endian system (and vice
versa).
d. Do not use generated Xilinx data files that are affected by endianess (for example
BIT files that include block RAM data - like ELF files) across systems.
e.
Block RAM initialization and data sharing should reflect the endianess
requirements of the master.
f.
Do not use old application data files used by the application if it is affected by
endianess (byte ordering in the file).
g.
70
www.xilinx.com
Value
n
n+1
n+2
MSByte
n+3
LSByte
n+1
n+2
n+3
n+3
n+2
n+1
n+3
n+2
n+1
MSByte
LSByte
n+3
n+2
n+1
n+1
n+2
n+3
Bit Label
31
MSBit
LSBit
Bit Significance
Table 4-7:
Value
n
n+1
MSByte
LSByte
n+1
n+1
n+1
MSByte
LSByte
n+1
n+1
Bit Label
15
MSBit
LSBit
Bit Significance
www.xilinx.com
71
Table 4-8:
Byte Address
Bit Label
Bit Significance
MSBit
LSBit
72
www.xilinx.com
Appendix A
Signal
AXI4
AXI4-Lite
ACLK
ARESETN
Global reset source, active-Low. This signal is not present on the interface when a reset source (of either
polarity) is taken from another signal available to the IP. Xilinx IP generally must deassert VALID
outputs within 8 cycles of reset assertion, and generally require a reset pulse-width of 16 or more clock
cycles of the slowest clock.
Signal
AXI4
AXI4-Lite
Signal not present.
AWID
Fully supported.
Masters need only output the set of ID bits that it varies
(if any) to indicate re-orderable transaction threads.
Single-threaded master interfaces may omit this signal. Masters do not need to
output the constant portion that comprises the Master ID, as this is appended by the
AXI Interconnect.
AWADDR
Fully supported.
Width 32 bits, or larger as needed. High-order bits outside the native address range of a slave are ignored
(trimmed), by an end-point slave, which could result in address aliasing within the slave.
www.xilinx.com
73
Table A-2:
Signal
AXI4
AXI4-Lite
AWLEN
Fully supported.
Support bursts:
Up to 256 beats for incrementing (INCR).
16 beats for WRAP.
AWSIZE
AWBURST
AWLOCK
AWCACHE
AWPROT
AWQOS
AWREGION
AWUSER
AWVALID
Fully supported.
AWREADY
Fully supported.
Signal
AXI4
AXI4-Lite
WDATA
WSTRB
Fully supported.
WLAST
Fully supported.
WUSER
74
www.xilinx.com
Table A-3:
Signal
AXI4
WVALID
Fully supported.
WREADY
Fully supported.
AXI4-Lite
Signal
AXI4
AXI4-Lite
BID
Fully supported.
See AWID for more information.
BRESP
Fully supported.
BUSER
BVALID
Fully supported.
BREADY
Fully supported.
Signal
AXI4
AXI4-Lite
ARID
ARADDR
Fully supported.
Width 32 bits, or larger as needed. High-order bits outside the native address range of a slave are ignored
(trimmed) by an end-point slave, which could result in address aliasing within the slave.
ARSIZE
ARBURST
www.xilinx.com
75
Table A-5:
Signal
AXI4
AXI4-Lite
ARLOCK
ARCACHE
ARPROT
ARQOS
ARREGION
ARUSER
ARVALID
Fully supported.
ARREADY
Fully supported.
Signal
AXI4
AXI4-Lite
RID
Fully supported.
See ARID for more information.
RDATA
RRESP
Fully supported.
RLAST
Fully supported.
RUSER
RVALID
Fully supported.
RREADY
Fully supported.
76
www.xilinx.com
Default
(All Bits)
TVALID
No
N/A
No change.
TREADY
Yes
No change
TDATA
Yes
No change.
Xilinx AXI IP convention:
8 through 4096 bit widths are used by Xilinx AXI IP (establishes a testing limit).
TSTRB
Yes
Same as
TKEEP
else 1
TKEEP
Yes
In Xilinx IP, there is only a limited use of Null Bytes to encode the remainders bytes
at the end of packetized streams.
TKEEP is not used in Xilinx endpoint IP for leading or intermediate null bytes in the
middle of a stream.
TLAST
Yes
TID
Yes
No change.
Xilinx AXI IP convention:
Only 1-32 bit widths are used by Xilinx AXI IP (establishes a testing limit).
TDEST
Yes
No change
Xilinx AXI IP convention:
Only 1-32 bit widths are used by Xilinx AXI IP (establishes a testing limit).
TUSER
Yes
No change
Xilinx AXI IP convention:
Only 1-4096 bit widths are used by Xilinx AXI IP (establishes a testing limit).
Signal
Description
www.xilinx.com
77
78
www.xilinx.com
Appendix B
AXI Terminology
This appendix provides a list of AXI-specific acronyms, terminology, and definitions; and
gives the IP core types in which the terminology is used.
Table B-1:
AXI Terminology
Term
Type
Description
Usage
AXI
Generic
General description.
AXI4
AXI4-Lite
AXI4-Stream
All.
Interface
AXI4
AXI4-Lite
AXI4-Stream
AXI4
AXI4-Lite
AXI4-Stream
All.
Channel
Generic
Multiple-bit signal
(Not an interface or a channel).
All.
Bus
AXI4-Stream
AXI4
AXI4-Lite
AXI4
AXI4-Lite
AXI4-Stream
All.
Transfer
AXI4
AXI4-Lite
AXI4-Stream
All.
Burst
Transaction
www.xilinx.com
79
Table B-1:
Term
Type
Description
master
AXI4
AXI4-Lite
AXI4-Stream
All.
slave
AXI4
AXI4-Lite
AXI4-Stream
master
interface
(generic)
AXI4
AXI4-Lite
AXI4-Stream
All.
slave interface
(generic)
AXI4
AXI4-Lite
AXI4-Stream
All.
AXI4
AXI4-Lite
EDK.
SI
AXI4
AXI4-Lite
EDK.
MI
AXI4
AXI4-Lite
EDK.
SI slot
MI slot
EDK.
AXI4
AXI4-Lite
SI-side
AXI4
AXI4-Lite
EDK.
MI-side
AXI4
AXI4-Lite
EDK.
upsizer
AXI4
AXI4-Lite
AXI4-Stream
All.
downsizer
AXI4
AXI4-Lite
AXI4-Stream
All.
SAMD
Topology
Shared-Address, Multiple-Data
EDK.
Crossbar
Topology
All.
80
www.xilinx.com
Usage