Motorola MPC860 PowerQUICC User Manual page 378

Part IV. Hardware Interface
master must look at BB to ensure that no other master is driving the bus before it can assert
BB to assume bus mastership. If the arbiter removes the bus grant from a device that wants
another transfer, the device must rearbitrate for bus mastership. The MPC860, however,
guarantees data coherency for accesses to small ports and for decomposed bursts. This
means that the MPC860 does not release the bus before atomic transactions complete. For
example, a halfword transfer to a byte port is broken into two byte transfers; the MPC860
does not deassert BB until the second transfer completes, unless an error occurs.
Figure 14-19 shows basic bus arbitration protocol. Section 11.4.2, ÒSIU Module
ConÞguration Register (SIUMCR),Ó describes how prioritization can be conÞgured
Requesting Device
Request the bus
Assert BR
Request the bus
1. Wait for BB to be negated
2. Assert BB to become next master
3. Negate BR
Operate as bus master
Perform data transfer
Release bus mastership
Negate BB
14.4.6.1 Bus Request
The potential bus master asserts BR to request bus mastership. BR should be negated as
soon as the bus is granted, the bus is not busy, and the new master can drive the bus. If
requests are pending, the master can assert BR as long as needed. When conÞgured for
external arbitration, the MPC860 drives BR when it requires bus mastership. When the
internal on-chip arbiter is used, BR is an input to the internal arbiter and should be driven
by the external bus master.
14.4.6.2 Bus Grant
The arbiter asserts BG to indicate that the bus is granted to the requesting device. BG can
be negated after BR is negated or it can remain asserted to park the current master on the
bus. When conÞgured for external central arbitration, BG is an input to the MPC860 from
14-26
Figure 14-21 Bus Arbitration Flowchart
.
MPC860 PowerQUICC UserÕs Manual
Arbiter
Grant bus
Assert BG
Terminate arbitration
Negate BG (or keep it asserted to
park bus master)
MOTOROLA