
Ordering Model
8-2
Copyright © 2003, 2004 ARM Limited. All rights reserved.
ARM IHI 0022B
8.1
About the ordering model
The AXI protocol enables out-of-order transaction completion and the issuing of
multiple outstanding addresses. These features enable the implementation of a
high-performance interconnect, maximizing data throughput and system efficiency.
The ID signals support out-of-order transactions by enabling each port to act as multiple
ordered ports. All transactions with a given ID must be ordered, but there is no
restriction on the ordering of transactions with different IDs. The five transaction IDs
are:
AWID
The ID tag for the write address group of signals.
WID
The write ID tag for a write transaction. Along with the write data, the
master transfers a
WID
to match the
AWID
of the corresponding address.
BID
The ID tag for the write response. The slave transfers a
BID
to match the
AWID
and
WID
of the transaction to which it is responding.
ARID
The ID tag for the read address group of signals.
RID
The read ID tag for a read transaction. The slave transfers an
RID
to
match the
ARID
of the transaction to which it is responding.
Note
There is no requirement for slaves and masters to use these advanced features. Simple
masters and slaves can process one transaction at a time in the order they are issued.
The ability to issue multiple outstanding addresses means that masters can issue
transaction addresses without waiting for earlier transactions to complete. This feature
can improve system performance because it enables parallel processing of transactions,.
The ability to complete transactions out of order means that transactions to faster
memory regions can complete without waiting for earlier transactions to slower
memory regions. This feature can also improve system performance because it reduces
the effect of transaction latency.
Note
The reordering of transactions is always with respect to other transactions. There is no
facility for the reordering of data transfers within a burst. The address and control
signals that define the burst control the order of transfers within the burst.

Ordering Model
ARM IHI 0022B
Copyright © 2003, 2004 ARM Limited. All rights reserved.
8-3
8.2
Transfer ID fields
The AXI protocol provides an ID field to enable a master to issue a number of separate
transactions, each of which must be returned in order.
A master can use the
ARID
or
AWID
field of a transaction to provide additional
information about the ordering requirements of the master. The rules governing the
ordering of transactions are as follows:
•
Transactions from different masters have no ordering restrictions. They can
complete in any order.
•
Transactions from the same master, but with different ID values, have no ordering
restrictions. They can complete in any order.
•
The data for a sequence of write transactions with the same
AWID
value must
complete in the same order that the master issued the addresses in.
•
The data for a sequence of read transactions with the same
ARID
value must be
returned in order that:
—
when reads with the same
ARID
are from the same slave then the slave
must ensure that the read data returns in the same order that the addresses
are received.
—
when reads with the same
ARID
are from different slaves, the interconnect
must ensure that the read data returns in the same order that the master
issued the addresses in.
•
There are no ordering restrictions between read and write transactions with the
same
AWID
and
ARID
. If a master requires an ordering restriction then it must
ensure that the first transaction is fully completed before the second transaction is
issued.

Ordering Model
8-4
Copyright © 2003, 2004 ARM Limited. All rights reserved.
ARM IHI 0022B
8.3
Read ordering
At a master interface, read data from read transactions with the same
ARID
value must
arrive in the same order in which the master issued the addresses. Data from read
transactions with different
ARID
values can return in any order and it is also acceptable
to interleave the read data of transactions with different
ARID
fields.
A slave must return read data from a sequence of read transactions with the same
ARID
value in the same order in which it received the addresses. In a sequence of read
transactions with different
ARID
values, the slave can return the read data in a different
order than that in which the transactions arrived.
The slave must ensure that the
RID
value of any returned read data matches the
ARID
value of the address to which it is responding.
The interconnect must ensure that a sequence of read transactions with the same
ARID
value from different slaves complete in order.
The read data reordering depth is the number of addresses pending in the slave that can
be reordered. A slave that processes all transactions in order has a read data reordering
depth of one. The read data reordering depth is a static value that must be specified by
the designer of the slave.

Ordering Model
ARM IHI 0022B
Copyright © 2003, 2004 ARM Limited. All rights reserved.
8-5
8.4
Normal write ordering
If a slave does not support write data interleaving (see
page 8-6), the master must issue the data of write transactions in the same order in
which it issues the transaction addresses.
Most slave designs do not support write data interleaving and consequently these types
of slave design must receive write data in the same order that they receive the addresses.
If the interconnect combines write transactions from different masters to one slave, it
must ensure that it combines the write data in address order.
These restrictions apply even if the write transactions have different
AWID
values.

Ordering Model
8-6
Copyright © 2003, 2004 ARM Limited. All rights reserved.
ARM IHI 0022B
8.5
Write data interleaving
Write data interleaving enables a slave interface to accept interleaved write data with
different
AWID
values. The slave declares a write data interleaving depth that indicates
if the interface can accept interleaved write data from sources with different
AWID
values. The write data interleaving depth is statically configured. By default, the write
data interleaving depth of any interface is one.
Note
It is not permitted to interleave the write data of different transactions that have the same
AWID
.
The write data interleaving depth is the number of different addresses that are currently
pending in the slave interface for which write data can be supplied. For example, a slave
with a write data interleaving depth of two that has four different addresses, all with
different
AWID
values, pending can accept data for either of the first two pending
addresses.
The order in which a slave receives the first data item of each transaction must be the
same as the order in which it receives the addresses for the transactions.
Write data interleaving can prevent stalling when the interconnect combines multiple
streams of write data destined for the same slave. The interconnect might combine one
write data stream from a slow source and another write data stream from a fast source.
By interleaving the two write data streams, the interconnect can improve system
performance.
Note
If two write transactions with different
AWID
values access the same or overlapping
address locations then the processing order is not defined. A higher-level protocol must
ensure the correct order of transaction processing.
A master interface that is capable of generating write data with only one
AWID
value
generates all write data in the same order in which it issues the addresses. However, a
master interface can interleave write data with different
WID
values if the slave
interface has a write data interleaving depth greater than one.
For most masters that can internally control the generation of the write data, write data
interleaving is not necessary. Such a master can generate the write data in the same order
in which it generates the addresses. However, a master interface that is passing write
data from multiple sources with different speeds can interleave the sources to make
maximum use of the interconnect.