![Freescale Semiconductor MPC5632M Manual Download Page 174](http://html.mh-extra.com/html/freescale-semiconductor/mpc5632m/mpc5632m_manual_2330659174.webp)
MPC563XM Reference Manual, Rev. 1
174
Freescale Semiconductor
Preliminary—Subject to Change Without Notice
Since the XBAR appears to be just another slave to the master device, the master device will have no
knowledge of whether or not it actually owns the slave port it is targeting. While the master does not have
control of the slave port it is targeting it will simply be wait stated.
Because the XBAR does appear as slave port to a master, it can be incorporated into a bus system as one
of multiple slave devices. The integrator will need to provide a valid
hsel
signal to the XBAR to indicate
the access is intended for a slave port present in the XBAR and the integrator will need to provide a read
data and termination mux to ensure the master receives the proper return data and control from the proper
slave. If the XBAR is the only slave to the master no external mux is required. In this case the XBAR’s
hready_out
should be connected to the XBAR’s
hready_in
and the master port’s
hsel
signal should be
tied asserted.
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
occuring 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.
Once 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 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 locked or fixed length burst transfer it will
retain control of the slave port until that transfer is completed. Based on the AULB bit in the MGPCR
(Master General Purpose Control Register) the master will either retain control of the slave port when
doing undefined length incrementing burst transfers or will lose the bus to a higher priority master.
The XBAR will terminate all master IDLE transfers (as opposed to allowing the termination to come from
one of the slave busses). Additionally, when no master is requesting access to a slave port the XBAR will
drive IDLE transfers onto the slave bus, even though a default master may be granted access to the slave
port. When the XBAR is controlling the slave bus (I.e. during low power park or halt mode) the
hmaster
field will indicate 4’b0000.
When a slave bus is being IDLEd by the XBAR it can park the slave port on the master port indicated by
the PARK bits in the SGPCR (Slave General Purpose Control Register) or ASGPCR (Alternate SGPCR).
This can be done in an attempt to save the initial clock of arbitration delay that would otherwise 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 in attempt to save power.
8.3
XBAR Registers
This section provides information on XBAR registers.
8.3.1
Register Summary
There are four registers that reside in each slave port of the XBAR and one register that resides in each
master port of the XBAR. These registers are IP bus compliant registers. Read and write transfers both
require two IP bus clock cycles. The registers can only be read from and written to in supervisor mode.
Additionally, these registers can only be read from or written to by 32-bit accesses.