Sie sind auf Seite 1von 7

HANDSHAKING

Why is the VALID signal sticky?

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.

Why is the VALID signal described as "sticky"?

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 READY signal not sticky?

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.

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?

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.

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?

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.
ORDERING

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.

Can BVALID be asserted before WLAST in a write transaction?

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.

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?

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?

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.

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?

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 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?

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.
When can a master consider a write transaction complete, when it is trying to determine which
write data sources it can interleave?

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?

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.

ATOMIC

Are there any issues with exclusive accesses passing from one width of data bus to another?

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?

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.

Can a master change the control signals for different transactions in a locked sequence?

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?

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?

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 an unlocking transaction be an exclusive access?

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)

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

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?

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.

When a master has issued a locked transfer with one ID can it start a different locked transfer
with a different ID?

Answer: - No, once a master has started a locked sequence it must complete the locked sequence,
ensuring that all transfers have the same AxID.
CONTROL

How should a 32-bit write accesses across a 64-bit bus be represented as AXI transactions?

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.

Should the protection/cache information for address regions be consistent between read and
write operations?

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?

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 are the allowable byte lane strobes for fixed address burst?

Answer: - For the purposes of determining legal write strobes, fixed bursts with an unaligned start
address remain unaligned for the duration of the burst.

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?

Answer: - The reason for including read and writes allocation on both read and writes address buses
is that it allows a system level cache to optimize 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.
RESPONSE

How should a bridge deal with an AXI transfer that is marked as non-secure and bufferable?

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?

Answer: - The data behavior 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.

Should a slave respond with an error or OKAY response when the user addresses memory space in the
slave that has no registers?

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.

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?

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?

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.

Das könnte Ihnen auch gefallen