Introduction

AXI, the third generation of AMBA interface AMBA 3 specification, is targeted at high performance,
high clock frequency system designs and suitable for high speed sub-micrometer interconnect:
• separate address/control and data phases
• support for unaligned data transfers using byte strobes
• burst based transactions with only start address issued & issuing of multiple outstanding addresses
• easy addition of register stages to provide timing closure

AXI consist of five different channels:

• Read Address Channel
• Write Address Channel
• Read Data Channel
• Write Data Channel
• Write Response Channel

AXI Read operation architecture:

AXI Write operation architecture:

Transaction channel handshake pairs:

Handshake process:
All five channels use the same VALID/READY handshake to transfer data and control information.
This two-way flow control mechanism enables both the master and slave to control the rate at which
the data and control information moves. The source generates the VALID signal to indicate when the
data or control information is available. The destination generates the READY signal to indicate that
it accepts the data or control information. Transfer occurs only when both the VALID and READY
signals are HIGH.

There are three scenarios when the transfer happens as shown below:

Signal Description:
Signal Description:
Master Slave configuration connected via interface through interconnect:
There are different encoding techniques used in AXI for burst length, busrt size, burst type, cache
encoding, protection, atomic access, response,
Timing Diagrams for read burst, overlapping read burst and write burst:
 Difference between Exclusive access and Locked access:

The basic process for an exclusive access is:

• A master performs an exclusive read from an address location

• At some later time, the master attempts to complete the exclusive operation by performing an
exclusive write to the same address location
• The exclusive write access of the master is signalled as:
• Successful if no other master has written to that location between the read and write accesses
• Failed if another master has written to that location between the read and write accesses. In this
case the address location is not updated
 Locked access:

When the ARLOCK[1:0] or AWLOCK[1:0] signals for a transaction show that it is a locked transfer
then the interconnect must ensure that only that master is allowed access to the slave region until an
unlocked transfer from the same master completes signalling the release of the locked trasnfer. The
arbiter within the interconenct is used to enforce this restriction.

Burst operation:

In AXI channel, the number of data transfers in a single burst are called as beats.

Burst Transfer Type:

Normal/Privileged access:

Normal/Privileged is used by some masters to indicate their processing mode. A privileged

processing mode typically has a greater lever of access within a system.
 Different kinds of burst type:

Fixed burst: In a fixed burst, the address remains the same for every transfer in the burst. This
burst type is for repeated accesses to the same location such as when loading or emptying a
peripheral FIFO.

Incrementing burst: In an incrementing burst, the address for each transfer in the burst is an
increment of the previous transfer address. The increment value depends on the size of the transfer.
For example, the address for each transfer in a burst with a size of four bytes is the previous
address plus four.

Wrapping burst: A weapping burst is similar to an incrementing burst, in that the address for each
transfer in the burst is an increment of the previous transfer address. However, in a wrapping burst
the address wraps around to a lower address when a wrap boundary is reached. The wrap boundary
is the size of each transfer in the burst multiplied by the total number of transfers in the burst. There
are two restrictions for wrapping bursts: the start address must be aligned to the size of the transfer
and the length of the burst must be 2, 4, 8, or 16.

AXI Benefits:

• Faster testbench development and more complete verification of AMBA AXI 3.0/4.0 designs
• Easy to use command interface simplifies testbench control and configuration of master and slave
• Simplifies results analysis
• Runs in every major simulation environment
Drawbacks of AXI:

• The AMBA AXI4 has limitations with respect to the burst data and beats of information to be
transferred
• The burst must not cross the 4k boundary. Bursts longer than 16 beats are only supported for the
INCR burst type
• Both WRAP and FIXED burst types remain constrained to a maximum burst length of 16 beats.
These are the drawbacks of AMBA AXI system which need to be overcome
AXI features:

• AMBA AXI 3.0/4.0 Verification IP provides a smart way to verify the AMBA AXI 3.0/4.0 component of
a SOC or a ASIC
• AMBA AXI 3.0/4.0 VIP is supported natively in SystemVerilog, VMM, RVM, AVM, OVM, UVM,
Verilog, SystemC, VERA, Specman E and non-standard verification environment
 Summary of AXI:

• Productivity—By standardizing on the AXI interface, developers need to learn only single protocol
for IP
• Flexibility
• AXI4 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
• Availability—By moving to an industry-standard, access to a worldwide community of ARM
Partners.
• Many IP providers support the AXI protocol
• A robust collection of third-party AXI tool vendors is available that provide a variety of verification,
system development, and performance characterization tools

Comparison betweenAMBA AHB and AMBA AXI Bus System Modeling:

Simulation study between AMBA AHB and AMBA AXI Results:

Throughput:

• Throughput or network throughput is the average rate of successful message delivery over a
communication channel
• It is closely related to the channel capacity of the system, and is the maximum possible quantity of
data that can be transmitted under ideal circumstances
• The throughput is usually measured in bits per second (bit/s or bps), data packets per second or
data packets per time slot
AXI protocol notes and Interview Questions:
 AMBA AXI is targeted at high performance , suitable for high-speed submicron connect .

Features:

• separate address/control and data phases

• support for unaligned data transfer using byte strobes
• its backward compatibel with existing AHB and APB interface
Architecture-wise features:

• AXI protocol is burst based

Every transaction has address and control information on the address channel
• Total 5 channels
• Independently acknowledged address and data channels
• Out-of-order completion of bursts
• Write data interleaving
• Exclusive access (atomic transaction)
• Access security support
• System level cache support
• Unaligned address & byte strobe
• Static burst, which allows bursts to FIFO memory
• Low power mode
Difference between AXI3 and AXI4:

AXI3 Vs AXI4 The difference between AXI3 and AXI4

1. AXI3 supports burst lengths up to 16 beats only. While AXI4 supports burst lengths of up to 256
beats.
2. AXI3 supports write interleaving. AXI4 does NOT support write interleaving
3. AXI3 supports locked transfers, AXI4 does NOT support locked transfers
4. AXI4 supports QoS, AXI3 does NOT suppor QoS.

I have seen many IP providers e.g. Synopsys supporting burst lengths up to 256 beats in AXI3
I have also seen many IP providers e.g. Synopsys NOT supporting write interleaving in AXI3.

Looks like the industry norm is to use AXI3 with burst lenghts up to 256 beats without support for
write Interleaving.

2. why there is no separate response channel for read burst ?

I would guess it is because the VALID/READY handshake mechanism only allows for traffic flow in
one direction, so for read transactions the traffic flow is slave to master for both data and response,
sharing a VALID/READY handshake, whereas for write transactions the data is master to slave, but
the response is slave to master, hence the response needing a separate channel to support the
required VALID/READY controls.

Questions and Answers:

1) Why there was no Write response for each beat in burst Write. But there is a seperate Read
response for each beat in a Read burst?

All of the AXI channels pass information in only 1 direction (only the xREADY signal goes against
the channel direction), so for a slave to give a response back to the master for a write transaction,
would need a separate channel.
I guess this channel could have been defined to include a BRESP for each write data item, but this
would increase the bandwidth requirement for this channel, and as in most applications you will just
repeat the complete transaction for a non-OKAY response, few applications would make use of the
additional detail of which transfer in a write burst caused a failure.
You do give a RRESP response for each read data item because the higher bandwidth channel is
already there,

2) How to terminate A read/write burst? Specification says we can not stop bursts intermittantly.

Simple answer, you cannot.

As soon as the AXI master indicates that it will perform X number of transfers in a transaction, it
must complete X transfers. There is no "Early Burst Termination" concept like there was in AHB.
For write transactions the master could complete the burst, but driving the WSTRB bits all to logic '0'
(dummy accesses) so that no data is actually being transferred to the slave, but for read transactions
there is no equivalent, and so "real" read accesses will be completed.

In AHB Bursts can be early terminated either as a result of the Arbiter removing the HGRANT to a
master part way through a burst, or after a slave returns a non-OKAY response to any beat of a
burst. Note however that a master cannot decide to terminate a defined length burst unless
prompted to do so by the Arbiter or Slave responses.
All AHB Masters, Slaves and Arbiters must be designed to support Early Burst Termination.

3) Can A master can give WLAST in middle of a burst transfer?

No. WLAST can only be asserted while WVALID is high when the final WDATA of a burst is being
transferred. Indicating WLAST (and WVALID) too early in a burst would be a protocol violation.
Also, many slave designs will not use the WLAST input, and will simply count data items coming in,
so this would not be a safe (or legal) method of terminating a burst.

4) in the same way if slave assersts RLAST before the completion of a busrt read?

If the slave drives RLAST (and RVALID) too early, this too is a protocol violation, and just as for the
WLAST signal, some masters might not be monitoring RLAST, so this illegal use could be missed
anyway.

5) If WLAST and RLAST can not do the above cases, then what is the special use of WLAST and
RLAST because we are getting individual beat responses anyway?

WLAST and RLAST can be used by masters and slaves that need to be told when the final data in a
burst is being transferred.
Most masters and slaves will count the data coming in against how many transfers were indicated on
AWLEN and ARLEN, so in these designs the xLAST inputs would not be required.
However to support all master and slave designs, masters must always drive WLAST when
appropriate, and slaves must drive RLAST.

6 ) Whats the exact use of Exclusive Read and Write Pair transaction? Where exactly these will be
used?

Semaphore passing : Semaphore passing is a software requirement, whereas my background is

hardware, so please forgive any vagueness in the following answer.
If you have a shared area of memory used for passing control information between masters (or
processes running on a master), you want to make sure that you complete the READ/WRITE
sequence without another master changing the shared location.
If your master read the shared memory location, and it was changed by another master before your
master could complete the subsequent write to that location, the interim write from the other master
would be lost, which could have an impact on how your system works (control information lost).
So Exclusive Accesses are a hardware mechanism to support the software, indicating to the master
when it did have uninterrupted access to the shared location, meaning that no write accesses from
other masters will be accidentally overwritten.

7) Is there a possibility that A Read transaction can complete in One Cycle?

A default ARREADY value of LOW is possible but not recommended, because it implies that the
transfer takes at least two cycles, one to assert ARVALID and another to assert ARREADY.
No. It would take a minumum of 1 clock cycle to pass the address from the master to the slave
(assumes ARREADY was high when ARVALID was asserted), and then a minimum of 1 clock cycle
to pass the data from the slave to the master (assumes RREADY was high when RVALID was
asserted). If ARREADY is initially low when an address is signaled on ARVALID, it will take one
clock cycle for the slave to sample this ARVALID and then assert ARREADY (if it can accept the
address), and the address handshake then completes on the next clock rising edge (when both
ARREADY and ARVALID are high).
So 2 clock cycles just to pass the address from master to slave if ARREADY defaults to LOW.
It would then take at least a further clock cycle before the read data could be returned to the master.

AXI Interview Question

Are there any issues related to hazard detection on overlapping
locations?
Answer
Hazard detection needs to be done on the entire "container" of the transfer
as defined by ADDR, SIZE, BURST and LEN. Overlapping locations need to
be dealt with appropriately if forwarding is used. For the simpler schemes,
i.e. stalling until earlier transfers have completed, partially overlapping and
fully overlapping transactions can be treated the same.

Are there any issues with exclusive accesses passing from one width
of data bus to another?
Applies to: AXI
Answer
It is recommended that the restrictions listed below are used when
generating exclusive AXI bursts. This ensures that the address transaction
remains as a single transaction even if processed by certain AXI interconnect
blocks such as a downsizer (for connecting a wide bus to a narrower bus)
• If the burst type FIXED is used, then the length must be no greater
than 1 (AxLEN=0). This ensures that any downsizer component will
not split the burst into multiple bursts on the narrower bus.
• If the burst type is WRAP or INCR then it is recommended that the
total size be no greater than 16 bytes (e.g. length 4 for 32-bit bus,
length 2 for 64-bit bus). This ensures that the burst can always be
downsized to a single burst on a narrower bus (the limit being a length
16 burst on an 8-bit bus).
 • If the system design is known, then the maximum allowable total size
of an exclusive burst must be defined as 16x the width (in bytes) of
the narrowest bus which will carry exclusive accesses.
Are there any recommendations about the types of accesses that are
used for atomic accesses?
Applies to: AXI
Answer
It is recommended that atomic accesses are performed using single length
bursts and the size of the data transfer is such that the transaction can pass
from source to destination without any need for modification by width
conversion components.
Are there any recommendations for verifying AXI components?
Applies to: AXI
Answer
Verification of AXI components is a significant task which cannot be covered
in full detail here, but one useful hint is to make sure that during simulation
signals (such as address and control signals) are driven with random values
whenever they are not required to be set in a valid state.
This may be best avoided for initial debugging purposes as it can make the
waveforms confusing. However, when dealing with more mature IP, enabling
this feature will enhance any verification performed on an AXI port and may
well give improved RTL code coverage in the process.

At what point can the master consider that the transaction has been
accepted by the slave such that the responsibility for hazard
checking lies with the slave?
Applies to: AXI
Answer
If a master is performing hazard checking, to allow it to issue multiple
outstanding read and write transactions, as described in section 8.6 of the
AXI specification, then at what point can the master consider that the
transaction has been accepted by the slave and the responsibility for hazard
checking now lies with the slave.
According to the specification “In the case of reads the earlier transaction
can be considered complete when the last read data is returned to the
master. In the case of writes the transaction can only be considered
complete when the write response is received by the master, it is not
acceptable to consider the write transaction complete when all the write data
is sent."
The master cannot consider the transaction to have been accepted at the
point at which the address has been acknowledged. The reason for this is
that the address ready signal is simply showing that the address has been
registered, but this may be in the slave or it may be in some intervening
interconnect. Therefore this is no guarantee that the address has reached its
destination.
For a read transaction the guarantee that the address has reached its
destination is obtained when the read data (and associated response) are
returned to the master. The AXI specification requires a relationship between
the channels, as described in section 3.2 of the specification, which ensures
that a read response is only given after the address has been accepted.
For write transactions the situation is slightly more complex. In a similar
manner, the guarantee that a write has reached its final destination is given
by the response. According to the rules of the AXI specification, the only
requirement is that the write response is given after the last item of write
data has been accepted. This is the point at which the master can consider
that the responsibility for hazard checking has been passed to the slave.
There is no actual requirement in the specification that the address must
have been accepted by the slave at the point at which the write response is
given. However, in such a circumstance the slave must still take the
appropriate action to ensure that any subsequent transactions are treated
successfully, such as stalling any further transfers.
It is important to note that the recommended behavior for a slave is to only
gives a write response once both the address and the write data has been
accepted. This would be equivalent to a double headed arrow from AWVALID
to BVALID and also from AWREADY to BVALID.

Can BVALID be asserted before WLAST in a write transaction?

Applies to: AXI
Answer
No. For a write transaction, it is a protocol violation to assert BVALID before
the last data transfer completes. A master signals the last data transfer by
setting WLAST HIGH.
The AMBA AXI Protocol Specification, ARM IHI 0022, states:
a write response must always follow the last write transfer in the write
transaction to which the write response relates.

Can a master change the control signals for different transactions in

a locked sequence?
Applies to: AXI
Answer
It is recommended that a master should not change AxPROT or AxCACHE
during a sequence of locked accesses. This restriction ensures that the full
locked sequence (including the unlocking transaction) is seen by appropriate
components within the system.
Can an exclusive access use sparse write data strobes?
Applies to: AXI
Answer
There are no restrictions within the protocol to prevent the use of sparse
write data strobes during an exclusive access, as all the exclusivity checking
should be done on the address/control information for the transaction (and
hence the strobes have no effect on the exclusivity check). However, it is
generally recommended that sparse write data strobes are not used.

Can an unlocking transaction be an exclusive access?

Applies to: AXI
Answer
No. Although an unlocking transaction does not have AxLOCK[1] asserted, it
is still consider part of a locked sequence and therefore it must not be an
exclusive access (with AxLOCK[0] asserted).

Can the WVALID signal for a write transfer be active before the
AWVALID? If so, how does the interconnect know which slave the
transfer is for?
Applies to: AXI
Answer
Whilst it is generally expected that WVALID will only be asserted at the same
or after AWVALID, there can be cases when WVALID is asserted before
AWVALID. For example this can occur when the address channel includes a
buffer or when the signals are crossing an asynchronous boundary.

Can write responses be re-ordered in the same way that read data
can be re-ordered?
Applies to: AXI
Answer
Yes. It is acceptable for a slave to re-order write responses, but typically this
would only be done if the slave was able to change the order in which it
completed the write transactions.

Does a master always have to perform the write portion of an

exclusive access?
Applies to: AXI
Answer
No. It is acceptable for a master to not perform the write portion of an
exclusive access. However, it is important to note that the opposite does not
apply. A master must not perform an exclusive write without first performing
a matching exclusive read.
How can a slave return a BRESP before knowing the AWADDR value
for the transaction ?
Applies to: AXI
Scenario
The AXI specification requires that a BRESP response is not signalled by the
slave until the final WLAST data transfer has been completed, but there is no
requirement that the AWADDR transfer has been completed or signalled.
How does the slave know what response to return, and what if it
subsequently needs to change this response once the AWADDR address is
known ?
Answer
Although the specification allows the BRESP to be returned before the
address transaction has completed, in reality most slaves will need to know
the address transfer details before a response can be determined.
If you only have one slave in your system (so no address decoding for
routing purposes), and the slave can always accept data regardless of the
address (so no possibility of an ERROR), then you could return an
OKAY response.
However once this response has been signalled, it cannot subsequently be
changed once the address transfer is known.

How do you calculate addresses used in WRAP type bursts?

Applies to: AXI
Answer
Page 4-7 of the AMBA 3 AXI Protocol specification gives example equations
to calculate the addresses used by slaves to perform burst accesses.
However for WRAP style bursts the final equation on this page is incorrect.
The final comment and equation are described in the specification as...
If Address_N = Wrap_Boundary + (Number_Bytes X Burst_Length),
use this equation:
. Address_N = Wrap_Boundary
...but this would not increment any address value after the boundary wrap
address.
Once the burst address has reached the wrap point, you should use the
following calculation for each address...
. Address_N = Wrap_Boundary + (N-1) x Number_Bytes

How do you ensure interoperability between AXI components?

Applies to: AXI
Answer
The approach to interoperability is that components must support all
combinations of inputs, but do not have to generate all combinations of
outputs. For example, a slave should support all the different possible
lengths of burst, but a master only has to generate the types of burst that it
wishes to use. This policy ensures that all components will work with all
other components.

How does a SWP operation on a CPU translate in to bus activity?

Applies to: AXI
Answer
A SWP operation will result in a locked sequence of a read transaction
followed by a write transaction to the same address.
An interesting case to note is that if an error is received on the read
operation the processor must perform another AXI transaction in order to
complete the locked sequence and unlock the interconnect for other masters
to use. In most cases it is likely that the locked sequence will be completed
with a write transaction which has no write strobes asserted.

How important is it that a sequence of locked transactions does not

cross a 4k byte boundary?
Applies to: AXI
Answer
The AXI protocol does allow for a sequence of locked transactions to cross a
4k byte boundary, but it is recommended that masters do not perform such
operations. It is possible that some implementations of AXI interconnect will
not support locked accesses that cross a 4k byte boundary as it adds a
significant level of complexity to the interconnect.
How should a 32-bit write accesses across a 64-bit bus be
represented as AXI transactions?
Applies to: AXI
Answer
If the access is word aligned then it could be performed using a burst of
length 1 and size 32-bit, all the strobes within this container will be
asserted. If the access is not word aligned, but does not cross a 64-bit
boundary then it could be performed using a burst of 1 length and size 64-
bit, this access will only have 4 out of the possible 8 strobes asserted. If the
access is across a 64-bit boundary then it could be performed using a burst
of length 2 with size 32.
This is just a recommendation on how the access should be performed, but it
is not the only legal way in which the transaction can occur. For example, it
would be correct protocol to perform a 32-bit burst of length 2 in all cases
and just assert the strobes as required, which in some cases would mean
that all the strobes are de-asserted for one of the two data transfers.

How should a bridge deal with an AXI transfer that is marked as

non-secure and bufferable?
Applies to: AXI
Answer
The AXI protocol allows a bridge (or system level cache) to provide the write
response for a transaction which is marked as bufferable. However, if the
transaction is also marked as Non-secure then the bridge can only provide
the correct response if it is known that the slaves on the other side of the
bridge or cache are unable to generate a security error.
Therefore a general recommendation is that the security determination for
memory locations should be performed before the bridge, or the bridge
should be configured to pass the write response through from the slaves on
the other side.

If BRESP indicates an error, does that mean that none of the

transaction's data was written to memory?
Applies to: AXI
Answer
The data behaviour with an error response is not specified and will be slave
specific. If an error is received and the software is going to attempt to
recover the situation then it is expected that the software will perform the
actions required to determine if any of the write burst succeeded. In some
case it may be acceptable for the entire write burst to be repeated (as would
be the case for a normal memory device), but for other devices it may be
necessary to interrogate the device for further information before attempting
recovery.
If a slave receives three addresses from different masters M1, M2
and M3 in that order and has an interleaving depth of 3 can the slave
expect to see any data from M3 before it sees data from masters M1
and M2?
Applies to: AXI
Answer
The protocol requires that the first item of write data is received in the same
order as the addresses and therefore before the master receives any write
data from M3 it must have received at a minimum the first data items from
both M1 and M2.

Should a slave respond with an error or OKAY response when the

user addresses memory space in the slave that has no registers?
Applies to: AXI
Answer
It is implementation dependent how a slave should respond when a user
accesses a location in the slave where there is no register present, but it is
recommended that the behaviour that is chosen is documented in the slave
manual.
Providing an error response to all illegal accesses has the advantage that it
helps to quickly detect when an erroneous software access occurs and
therefore can help to speed up the debug process.
However, there can be times when it is not recommended to provide an
error response for every possible illegal access. An example of this would be
where a master, which may be a DMA engine or possibly a debugger
interrogating a slave, simply performs a burst access across a number of
locations rather than reading individual locations. In such circumstances
providing an error response could cause the operation to fail.

Should slaves/bridges which have some form of write buffer

capability also include forwarding logic to return the result of a read
transaction when a write to the same location is stored in the write
buffer?
Applies to: AXI
Answer
Slaves/bridges may need additional logic if they are going to provide an
early write response (before the write is fully completed). The minimum that
it needs is hazard detection, which detects a read to an address that is
stored within the write buffer.
If a read-after-write hazard is detected then the slave/bridge can either stall
the read operation until the write has fully completed, or implement
forwarding logic to provide the correct read data prior to the write fully
completing.
The above complexity is avoided if a slave only provides a write response
when the write has fully completed.

Should the protection/cache information for address regions be

consistent between read and write operations?
Applies to: AXI
Answer
Generally the protection/cache information for an address region should be
consistent for reads and writes. If any changes are needed to the
protection/cache information for a region then appropriate higher level
measures must be taken, such as cache maintenance operations or clearing
out any secure/privileged data.

The specification mentions that AxPROT[2] information is just a hint.

Is the information given by the other AxPROT bits always accurate?
Applies to: AXI
Answer
The use of a cache can cause of misleading information on the AxPROT
signals where data with different AxPROT values (such as instruction and
data) resides in the same cache line. This can also be true where a write-
back cache line holds both privileged and user data. Typically when a line is
evicted from such a cache it will be written with privileged access although it
may contain non-privileged data.
The security information given by AxPROT[1] will always be accurate and
any cache used in a system that make use of the security features must be
able to generate accurate AxPROT[1] information.

What AXI response value should be given by a slave which contains

a mixture of secure and non-secure registers, when a non-secure
access is attempted to a secure register?
Applies to: AXI
Answer
It is recommended that slaves which contain a mix of secure and non-secure
registers should attempt to separate these registers in to different 4k decode
regions. If this is possible then a DECERR response can be given when a
non-secure access is attempted to a secure 4k region.
If the slave contains a mixture of secure and non-secure registers within the
same 4k region then it is recommended that the slave gives a SLVERR
response, in the same way that it would if an internal register had been
accessed incorrectly, such as an attempted write to a read only register.

What AXI response value should be given to a non-secure access to

a secure address location?
Applies to: AXI
Answer
In an interconnect, if a non-secure transaction address is decoded as being
destined for a secure peripheral then the access should be treated as if there
were no slave at that address and hence should be given a DECERR
response.

What are the allowable byte lane strobes for fixed address burst?
Applies to: AXI
Answer
For the purposes of determining legal write strobes, fixed bursts with an
unaligned start address remain unaligned for the duration of the burst.

What happens if the slave is keeping AWREADY low waiting for the
write response to be accepted while the master is keeping BREADY
low waiting for the address to be accepted by the slave?
Applies to: AXI
Answer
The specification does not require that the write address is accepted by a
slave before the slave gives a write response. If this happens then what
happens if the slave is keeping AWREADY low waiting for the write response
to be accepted while the master is keeping BREADY low waiting for the
address to be accepted by the slave.
The situation described above is not expected to occur. It is generally
expected, and recommended, that a slave accepts the address before giving
a write response. If such a situation were to occur then the AWREADY should
not be dependent on BREADY.

What is meant by the arrows in section 3.3, "Dependencies between

the channel handshake signals"?
Applies to: AXI
Answer
There are two aspects to cover when considering the relationships between
the AXI channel handshake signals and it is possible that much of the
confusion around this section of the specification comes from the fact that
these two aspects are covered in the same section.
The first aspect is the “must wait” dependencies, which are all to do with a
change in direction of a transaction. The returning read data/response “must
wait” until the read address has been accepted and the returning write
response “must wait” until the last item of write data has been accepted.
These “must wait” dependencies are shown in the diagrams by a double
headed arrow and are also described in section “3.2 Relationships between
the channels”.
The second aspect is the “Can wait” and “Must not wait” dependencies, that
are shown by the single headed arrows.
For channels that are traveling in the same direction (i.e. from master to
slave , or vice versa) there are “can wait” and “must not wait” dependencies
between the handshake signals. These dependencies are needed to prevent
the deadlock situation of A waiting for B, while B is waiting for A. In the
diagrams these dependencies are represented by a single headed arrow. The
signal at the head (point end) of the arrow “can wait” for the signal at the
tail of the arrow. The signal at the tail of the arrow “must not wait” for the
signal at the head of the arrow. For example, A --> B means B "can wait" for
A, but A "must not wait" for B.
It is this second part (the “must not wait”) that is actually the important one
in avoiding deadlock and some users may find it easier to understand the
diagrams by thinking about the single headed arrow in the opposite
direction. That is, you look at each signal in turn and make sure it is not
dependent on any of the signals that it has arrow pointing out towards. It
does not matter about single headed arrows pointing inwards towards the
signal in question, as this is just a “can wait” relationship, which means “can
wait if it wants to, but does not have to”.

What is the ACLKEN signal?

Applies to: AXI
Answer
Whilst the ACLKEN signal is not described within the AXI specification
document, it has become commonly used as a mechanism of generating a
lower speed AXI interface on a component that runs on high frequency clock.
For example, a CPU component that uses a 400 MHz main clock may wish to
interface to a system that is running at 200 MHz. Rather than supplying the
CPU with two different clocks, the ACLKEN signal is used to indicate which of
the higher speed clock edges can be used to generate and sample signals in
the lower speed clock domain.
The clock generator that generates the clocks and the ACLKEN signal is
responsible for ensuring that the ACLKEN signal is high on the rising clock
edge that is coincident with the lower speed rising clock edge.
___ ___ ___ ___ ___ ___
ACLK_FAST __| |___| |___| |___| |___| |___| |___
_______ _______ _______
ACLKEN ____/ \_______/ \_______/ \_____
_______ _______ _______
ACLK_SLOW __________| |_______| |_______|
Components that use the ACLKEN signal must observe the following rules:
• Outputs are only updated when the clock enable is high.
• Inputs are only sampled when the clock enable is high.

When a master has issued a locked transfer with one ID can it start
a different locked transfer with a different ID?
Applies to: AXI
Answer
No, once a master has started a locked sequence it must complete the
locked sequence, ensuring that all transfers have the same AxID.

When an interconnect adds bits to the ID field does it add high-order

bits or low-order bits?
Applies to: AXI
Answer
The protocol allows an interconnect to add ID bits to either end of the ID
field. A common choice will be to add low-order bits and shift the ID bits
from the master to higher order bits in the ID field. This allows the
interconnect itself to always use the same ID bits.

When can a master consider a write transaction complete, when it is

trying to determine which write data sources it can interleave?
Applies to: AXI
Answer
For the purposes of determining legal write data, in relation to write
interleave depth, a master can consider a burst to be completed (on the
write data bus) when the last write data for a transaction is transferred. If
the slave cannot actually accept the new item of interleaved write data
(because it does not free up the internal buffer) until the write response for
that transaction is transmitted, then the write data channel will be stalled
until the slave can accept the data.
When there are several bursts with same ID to a slave, are they
counted separately or as one in regard to the write data
interleaving-depth of the slave?
Applies to: AXI
Answer
Each burst is counted separately, even if they share the same ID. This is
because, in most slave designs, each address would take up space in the
slave's address storage.

Why are the read and write address buses defined with all four bits
of ACACHE. Does a read transaction need to give the write allocate
information and vice versa?
Applies to: AXI
Answer
The reason for including read and write allocation on both read and write
address buses is that it allows a system level cache to optimise it
performance. For example, if a cache sees a read access that is defined as
"write allocate, but not read allocate" then it knows that the address may
actually be stored in the cache (because it could have been allocated on a
previous write) and hence it must do a cache lookup. However, if the cache
sees a read access that is defined as "no write allocate and no read allocate"
then it knows that the address will not have been allocated in the cache and
hence it can avoid the cache lookup and immediately pass the transaction
through to the other side. It can only do this if it knows both the read and
write allocate for every transaction.
It is not a requirement that caches operate in this way, but the protocol is
defined with RA/WA for both reads and writes to allow this mode of
operation if the cache designer wants to implement it.
Why is AXI spec suitable for "high bandwidth" designs ?
Applies to: AXI
Scenario
What is the meaning of the AXI Specification statement that
"The objectives of the latest generation AMBA interface are to
be suitable for high-bandwidth and
low-latency designs."?
Answer
AXI was designed for moving a lot of data round, quickly. 'High
bandwidth' peripherals are those
that do just that - eg memory controllers, DMA controllers etc.
 High Bandwidth is a subjective term but generally it refers to
the sort of peripherals
mentioned and the moving around of sizeable quantities of data.

Why is the READY signal not sticky?

Applies to: AXI
Answer
The READY signal is not sticky so that it can be held high by default if
needed, but can also be negated before a transfer occurs, for example if a
device enters a low power state or if a multi-ported device has activity on
another port that makes it unable to receive a transfer immediately.

Why is the VALID signal described as "sticky"?

Applies to: AXI
Answer
The word "sticky" is used to describe a signal that must stay asserted until it
is acknowledged. The VALID signal is sticky because once it has been driven
high it must remain asserted until a corresponding READY signal is received.

Why is the VALID signal sticky?

Applies to: AXI
Answer
The main advantage of keeping a VALID signal constant (and the associated
information, such as address) is that it can remove the need to put
additional registering in some places. For example, the APB bridge can just
use the READY signal to hold the address stable for 2 cycles rather than
registering the address. The same technique could be used by any slave that
wants to keep the address stable for more than one cycle.
Another example would be the address decode within the interconnect. The
result of the address decode can be used to determine whether or not the
interconnect will allow an address to be passed to a slave. If the address
were allowed to change this would force the address decode to occur in a
single cycle.
A third example would be a clock domain boundary. If the address is not
guaranteed stable then it would always be necessary to place a holding
register before the clock boundary, adding an extra cycle.