0% found this document useful (0 votes)
14 views

05 AXI Variations

Axi protocol

Uploaded by

Broke D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views

05 AXI Variations

Axi protocol

Uploaded by

Broke D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Participant Guide AXI: Variations

1 AXI: Variations

Slide 20-1:
111751**slide

2020.1
111751!*note

At the time of this writing the current version of AXI is "4", so technically,
each reference to AXI made here should be AXI4. However, in the interest
of brevity and future versions of AXI, the generic "AXI" term is used
instead of containing the version number. The exception to this is where
the version number is relevant.
After completing this module, you will be able to:
■ Describe the differences and similarities among the three primary AXI
variations.

Slide 20-2:

AXI (Full/Memory Mapped)


111752**slide

■ This is the base definition of


AXI
— Referred to as full or
memory mapped
— All other AXI types are
variations from this
definition

■ Contains all AXI features


— Single address multiple
data
— Burst up to 256 data beats
— Data width parameterizable
o 32, 64, 128, 256, 512,
1024 bits
o Xilinx limits the bus size to 256
— Support for overlapped transactions
111752!*note

This is the superset of the AXI variations that will follow in the next slides.
www.xilinx.com Page 1
© Copyright 2020 Xilinx
Participant Guide AXI: Variations

This model is more traditional in embedded processing systems as it has


address, data, and control lines and allows for full-featured operation and
interconnect schemes.
Remember, however, that the interconnect can be:
■ Shared bus
■ Point to point
■ Crossbar
Recall that the interconnect type and features are irrelevant to the AXI
protocol.
Slide 20-3:

AXI-Lite
111754**slide

■ The AXI-Lite
interface is a
subset of the
AXI interface
— Intended
for
communic
ation with
control
registers in
component
s

■ Goals of AXI-Lite
— Supports simple component interfaces
— Requires fewer resources
o Saves power and space, eases timing and routing
o Easier to design and validate

■ Formal AXI-lite protocol enables


— Components to be built using the same subset
— Building of common shim to interface between AXI-Full and AXI-Lite
111754!*note

Note the similarities between the AXI-Full channels and the AXI-Lite
channels shown here. The only difference is that only one piece of data (a
datum) can be written or read; that is, burst length is always 1.

www.xilinx.com Page 2
© Copyright 2020 Xilinx
Participant Guide AXI: Variations

The AXI4-Lite interface is targeted towards optimizing for fabric in system


implementation. This is mainly accomplished by limiting the transaction
data phase to a single operation, as a burst or multiple transfer data
phase requires more support and hence, more fabric.
Simple logic shim to connect AXI4 master to AXI4-Lite slave reflects the
transaction ID of the master.
Key features of the AXI4-Lite interface:
■ All transactions are burst length of 1.
■ All data accesses are the same size as the width of the data bus.
■ Support for data bus width of 32 or 64 bits. Xilinx only supports 32-bit
version.
■ All accesses are equivalent to AWCACHE, or ARCACHE equal to b0000.
■ Exclusive accesses are not supported.
Slide 20-4:

AXI Signals: Full versus Lite

www.xilinx.com Page 3
© Copyright 2020 Xilinx
AXI: Variations Participant Guide

111756**slide

■ By limiting the transaction phase to a single datum rather than


bursting, the number of supporting logic and signals is minimized

111756!*note

This slide is provided primarily as reference.

Slide 20-5:

AXI4 Master Transaction Implementation


80159**slide

■ AXI4 master transaction logic required for Xilinx attachments


— Ready/valid for all channels

— Transaction initiation logic

— Logic to emit read and write channel address

— Read and write data channel logic

Page 4 www.xilinx.com
© Copyright 2020 Xilinx
Participant Guide AXI: Variations

o Send or receive data


o Response logic
o Data burst counter
o Last data detection

— Error detection and handling logic


80159!*note

The above list includes the common needs for any AXI master
attachment.
The Lite version of the attachment does not require burst handling and
last data detection logic since all data phases are single transaction.
Address generation logic is required for all transactions. For Lite, this is a
simple driving of the channel address bus. For Full, the logic must also
generate M_AXI_AxBURST to determine proper transaction alignment and
generate the proper starting address. Transaction initiation logic is used
to begin address phases for the read or write channels.
For the Full master, burst counting data phase logic and last data phase
logic is required. The complexity of this logic will depend on the burst
features desired, which also determines how M_AXI_AxBURST generation
logic will be built.
Error handling logic is implemented according to the designer's needs,
from logic that is just always assuming an OK response, to more complex
response logic that may occur if a transaction has errors or cannot be
completed.

www.xilinx.com Page 5
© Copyright 2020 Xilinx
AXI: Variations Participant Guide

Slide 20-6:

AXI4 Slave Transaction Implementation


80160**slide

■ AXI4 slave transaction logic required for Xilinx attachments


— Ready/valid for all channels

— Latch target address based on burst type

— Burst data phase counter (not needed for AXI4 Lite)

— Transaction response
80160!*note

The above list is includes the common needs for any AXI slave
attachment.
The Lite version of the attachment just requires the ready/valid for all
channels, address latching, and transaction response since all data
phases are single transaction. The Full version requires a burst data phase
counter to keep track of the data coming across the interface.
The address latch is required for decoding internal read and write strobes
to the internal logic. For Lite, this is a simple latching of the channel
address bus. For Full, the logic must check S_AXI_AxBURST to determine
proper transaction alignment.
Transaction response is implemented according to the designer's needs,
from logic that is just always indicating an OK response, to more complex
response logic that may occur if a transaction has errors or cannot be
completed.

Page 6 www.xilinx.com
© Copyright 2020 Xilinx
Participant Guide AXI: Variations

Slide 20-7:

AXI Interface: Streaming


111759**slide

■ Data moves in a single direction, from a master to a slave


— Simplex communication: master-to-slave
— Dual direction would be dual simplex; individual channels, for
example

■ Data only
— No address channel
— Minimum control
— Unlimited burst length
— Sideband signals optionally used to condition data
— Contents of data stream interpreted by slave

111759!*note

Data flowing across the streaming connection may be in packet format or


not. The handshaking signals may provide packet start/end information or
the data itself may contain special characters to mark the beginning and
end of a packet. The important point here is that both master and slave
must have prior knowledge of data format. Just to drive the point home,
the use of hardware signaling is optional and may be used if the designer
deems it necessary or useful, or it may be completely disregarded.
AXI streaming does not have an address phase; all transactions go to the
same place. Also note that the direction is always from master to slave.
AXI streaming is very similar to the MicroBlaze™ processor fast simplex
link (FSL) except that there is no requirement that a processor be
involved.
Note that the AXI-Stream signals are less numerous than for AXI4 or AXI4-
Lite, as only a single channel is required. In many instances, not all of the
signals are required for a given application.

www.xilinx.com Page 7
© Copyright 2020 Xilinx
AXI: Variations Participant Guide

The following stream terms are used:


■ Transfer: A single transfer of data across an AXI4-Stream interface. A
single transfer is defined by a single TVALID, TREADY handshake.
■ Packet: A group of bytes that are transported together across an AXI4-
Stream interface. A packet is similar to an AXI4 burst. A packet can
consist of a single transfer or multiple transfers. Infrastructure
components can use packets to deal more efficiently with a stream in
packet-sized groups.
■ Frame: The highest level of byte grouping in an AXI4-Stream interface.
A frame contains an integer number of packets. A frame can be a very
large number of bytes; an entire video frame buffer, for example.
■ Data stream: The transport of data from one source to one
destination. A data stream can be:
— A series of individual byte transfers
— A series of byte transfers grouped together in packets

Page 8 www.xilinx.com
© Copyright 2020 Xilinx
Participant Guide AXI: Variations

Slide 20-8:

AXI4 Stream Transaction Implementation


80161**slide

■ AXI4 stream transaction logic required for Xilinx attachments


— Similar logic for stream master or slave

— Ready/valid for all channels

— Packet state machine: start and last data logic

— Very much application dependent


80161!*note

The AXI Stream attachment is probably the simplest to design and, as a


result, most of its capabilities are going to be design dependent.
Master and slave attachments are typically symmetrical in nature.
The AXI Stream specification does not speak to single or burst data
phases or to packet versus continuous operation. The concept of a packet
is introduced by the user application, as is the concept of a continuous
stream of data. Typically, both of these concepts give rise to the use of
state machine logic to implement.

www.xilinx.com Page 9
© Copyright 2020 Xilinx
AXI: Variations Participant Guide

Slide 20-9:

AXI Coherency Extension (ACE)


106914**slide

■ ACE: Not really a variation, more of an extension to AXI

■ The ACE protocol extends the AXI4 protocol and provides support for
hardware-coherent caches
— A five-state cache model to define the state of any cache line in the
coherent system
— Additional signaling on the existing AXI4 channels that enables new
transactions and information to be conveyed to locations that
require hardware coherency support
— Additional channels that enable communication with a cached
master when another master is accessing an address location that
might be shared
— Barrier transactions that guarantee transaction ordering within a
system
— ACE-Lite variation for I/O coherency

■ Currently available in the Zynq® MPSoC family of devices


106914!*note

The AXI coherency extension (ACE) protocol extends the AXI4 protocol
and provides support for hardware-coherent caches. The ACE protocol
enables system architects to select the most appropriate technique for
sharing data between system components.
The protocol does not define specific usage cases, but typical usage cases
are:
■ Coherent connection of system components
■ Coherent connection of subsystems that have non-uniform memory
resources
■ Coherent connection of components that have a highly optimized local
coherency system
■ Filtering of coherency communications
■ Coherent connection of components that support different coherency
protocols, such as MESI, ESI, MEI, and MOESI
■ Wrapping of components that do not support coherency natively,
enabling them to be used effectively within a coherent system level
design

Page 10 www.xilinx.com
© Copyright 2020 Xilinx
Participant Guide AXI: Variations

■ Support for cached components that might include multiple levels of


cache and non-cached components
■ Support for components that store coherency information at different
granularities, including cache line granularity and large buffer
granularity
■ Implementations that facilitate optimization of:
— Primary interconnect within a system
— Multiple subsystems

The Zynq UltraScale+™ MPSoCs have two ACE masters (PS-APU and PL).
The ACE port uses a 40-bit wide physical address. The ACE port enables
the PL masters to have their caches in PL. The PL-ACE master cannot
allocate into the APU L2 cache; however, it has coherent access to L2
cache.
Full-coherent masters can snoop each other's caches. For fine-grain data
sharing between the APU and the PL, a system can have cache
implemented in PL. Full coherency is provided through the cache coherent
interface (CCI) ACE ports. ACE provides additional signals that allow a CCI
to request data from various masters (APU or PL).
The ACE-Lite interface is a defined subset of the full ACE interface. ACE-
Lite is used by master components that do not have hardware-coherent
caches, but can issue transactions that could be held in the hardware
coherent caches of other masters. ACE-Lite enables un-cached masters to
snoop ACE coherent masters.
Additional Channels Defined by ACE
Three new channels are supported (snoop address channel, snoop data
channel, and snoop response channel):
■ The snoop address (AC) channel is an input to a cached master that
provides the address and associated control information for snoop
transactions.
■ The snoop response (CR) channel is an output channel from a cached
master that provides a response to a snoop transaction. Every snoop
transaction has a single response associated with it. The snoop
response indicates if an associated data transfer on the CD channel is
expected.
■ The snoop data (CD) channel is an optional output channel that passes
snoop data out from a master. Typically, this occurs for a read or clean
snoop transaction when the master being snooped has a copy of the
data available to return.

www.xilinx.com Page 11
© Copyright 2020 Xilinx
AXI: Variations Participant Guide

Changes to Existing AXI4 Channels

Acknowledge Signaling
ACE supports two additional acknowledge signals. These signals indicate
that a master has completed a read or write transaction.

Page 12 www.xilinx.com
© Copyright 2020 Xilinx
Participant Guide AXI: Variations

Capture Your Notes Here

www.xilinx.com Page 13
© Copyright 2020 Xilinx

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy