Crossbar Switch (XBAR)
MPC5510 Microcontroller Family Reference Manual, Rev. 1
Freescale Semiconductor
15-3
Preliminary
— Shared between flash port 1 / EBI slave / AIPS peripheral bridge (XBAR s0)
•
32-bit address, 32-bit data paths
•
Two concurrent transfers between independent master and slave ports
— Only one device on the shared slave port can be accessed at a time. If the shared slave port is
occupied by a master, then another master’s access to a device on the shared slave port will be
blocked, even if the second master is requesting access to one of the other devices on the shared
slave port, until the first master’s access has completed. For example, if the Z0 is accessing the
AIPS, then the Z1 data bus will not be able to access flash port 1 until the Z0 access has
completed.
15.1.3
Modes of Operation
The XBAR has two arbitration modes. See
Section 15.4.3.2, “Round-Robin Priority Operation
Section 15.4.3.3, “Fixed Priority Operation
15.2
Signal Description
The XBAR has no external signals.
15.3
Memory Map and Registers
The XBAR has no memory mapped registers.
15.4
Functional Description
The main goal of the XBAR is to increase overall system performance by allowing up to two simultaneous
transfers between master ports and slave ports.
When a master makes an access to the XBAR from an idle master state, the access will be immediately
taken by the XBAR. If the targeted slave port of the access is available (i.e. the requesting master is
currently granted ownership of the slave port), the access will be immediately presented on the slave port.
If the targeted slave port of the access is busy or parked on a different master port, the requesting master
will see wait states inserted until the targeted slave port can service the master’s request. The latency in
servicing the request will depend on each master’s priority level and the responding slave’s access time.
A master will be given control of the targeted slave port only after a previous access to a different slave
port has completed, regardless of its priority on the newly targeted slave port. This prevents deadlock from
occurring when a master has an outstanding request to one slave port that has a long response time, has a
pending access to a different slave port, and a lower priority master is also making a request to the same
slave port as the pending access of the higher priority master.
After the master has control of the slave port it is targeting, the master will remain in control of that slave
port until it gives up the slave port by running an IDLE cycle or by leaving that slave port for its next
access. The master can also lose ownership of the slave port when a transfer boundary is reached if the
arbitration logic has selected another master. In this context, the transfer boundary is defined as the
completion of any “single” transfer, the completion of each transfer within an undefined-length burst, the
