Functional Overview
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.
Copyright © 2006 ARM Limited. All rights reserved. | ARM DDI 0389B |
