Information

port, the requesting master simply sees wait states inserted until the targeted slave port
can service the master's request. The latency in servicing the request depends on each
master's priority level and the responding peripheral's access time.
Because the crossbar switch appears to be just another slave to the master device, the
master device has no knowledge of whether it actually owns the slave port it is targeting.
While the master does not have control of the slave port it is targeting, it simply waits.
A master is given control of the targeted slave port only after a previous access to a
different slave port completes, regardless of its priority on the newly targeted slave port.
This prevents deadlock from occurring when:
• A higher priority master has:
• An outstanding request to one slave port that has a long response time and
• 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 remains 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 could also lose control of the slave port if another higher priority master
makes a request to the slave port; however, if the master is running a fixed-length burst
transfer it retains control of the slave port until that transfer completes. Based on
MGPCR[AULB], the master either retains control of the slave port when doing undefined
length incrementing burst transfers or loses the bus to a higher priority master.
The crossbar terminates all master IDLE transfers, as opposed to allowing the termination
to come from one of the slave buses. Additionally, when no master is requesting access to
a slave port, the crossbar drives IDLE transfers onto the slave bus, even though a default
master may be granted access to the slave port.
When a slave bus is being idled by the crossbar, it can park the slave port on the master
port indicated by CRSn[PARK]. This is done to save the initial clock of arbitration delay
that otherwise would be seen if the master had to arbitrate to gain control of the slave
port. The slave port can also be put into Low Power Park mode to save power, by using
CRSn[PCTL].
18.3.2 Register coherency
The operation of the crossbar is affected as soon as a register is written. The values of the
registers do not track with slave-port-related master accesses, but instead track only with
slave accesses.
Chapter 18 Crossbar Switch (AXBS)
K20 Sub-Family Reference Manual, Rev. 1.1, Dec 2012
Freescale Semiconductor, Inc.
Preliminary
357
General Business Information