RM0400
14.2.1
General operation
When a master sends an access to the crossbar switch, the access is immediately taken. If
the targeted slave port of the access is available, then the access is immediately presented
on the slave port. It is possible to make single-clock (zero wait state) accesses through the
crossbar. If the targeted slave port of the access is busy or parked on a different master 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 slave's access time.
Since 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 enters a wait state.
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:
–
–
•
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.
When a master has control of a given slave port, the crossbar returns all response
information from the slave back to the requesting 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 the XBAR_CRSn[PARK]. This is done in an attempt 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 in attempt to
save power by using XBAR_CRSn[PCTL].
14.2.2
Register coherency
Since the content of the registers has a real-time effect on the operation of the crossbar, it is
important to understand that any register modifications take effect as soon as the register is
written. The values of the registers do not track with slave-port-related master accesses;
instead, they track only with slave accesses.
An outstanding request to one slave port that has a long response time and
A pending access to a different slave port, and
DocID027809 Rev 4
Crossbar Switch (XBAR)
315/2058
317
Need help?
Do you have a question about the SPC572L series and is the answer not in the manual?
Questions and answers