Filter
Top Products
Functional Overview
2-8 Copyright © 2006 ARM Limited. All rights reserved. ARM DDI 0389B
Undefined length INCR bursts
All undefined length INCR bursts are converted to INCR bursts of length four. Many
AHB masters rely on using undefined length INCR bursts to access data. If each INCR
transfer is processed as a single transfer by the internal protocol then the performance
is significantly degraded.
The bridge converts the incoming INCR transfers to INCR transfers of length four,
INCR4. This mean that the bridge speculatively requests data from the internal
interconnect, before it knows it is going to require it. If the AHB master continues the
burst, then the data can be returned quickly because it has already been requested. When
the INCR burst finishes, the bridge disregards any data requested from the internal
interconnect that is not required.
Any INCR burst of less than four beats results in a broken INCR4. Undefined length
INCR bursts of more than four beats are split into an appropriate number of INCR4s
plus a broken INCR4, if required.
Broken bursts
To fully support the AMBA AHB 2.0 specification, the bridge supports all broken AHB
bursts. Although bursts cannot be broken by an AHB master, if the AHB system has
multiple masters then the AHB system arbitration can break a burst. Also, because the
bridge converts INCR to INCR4, broken INCR4s occur when undefined length INCRs
of a length not equal to a multiple of four are performed.
To support broken bursts, the bridge must keep track of how many beats of a burst have
been performed and ensure it obeys the protocol of the interconnect. For read bursts, this
means draining the interconnect of any requested data that is not required. For write
bursts this means artificially extending write data with enough beats to obey the
protocol. The interconnect uses write strobes to indicate the bytes of the data bus that
are valid. When extending broken bursts, these strobes are deasserted so that the
artificial data does not corrupt the actual memory.
Bufferable bit of the HPROT signal
The bufferable bit of the HPROT signal determines whether the bridge must wait for a
write transfer to complete internally. The AHB protection control bits support the
concept of bufferable data accesses. The HPROT[2] signal determines this. The
internal interconnect supports the concept of a write response to indicate when data has
actually been written to memory. The bridge exploits these features by not waiting for
the write response if the access is described as bufferable. This enables numerous
bufferable writes to occur with minimum latency. These are accepted by the
interconnect and queued in the memory controller.