RM0046 Crossbar Switch (XBAR)
Doc ID 16912 Rev 5 283/936
14.6.2 General operation
When a master makes an access to the XBAR from an idle master state, the access is taken
immediately by the XBAR. If the targeted slave port of the access is available (that is, the
requesting master is currently granted ownership of the slave port), the access is
immediately presented on the slave port. It is possible to make single clock (zero wait state)
accesses through the XBAR by a granted master. If the targeted slave port of the access is
busy or parked on a different master port, the requesting master receives wait states until
the targeted slave port can service the master request. The latency in servicing the request
depends on each master’s priority level and the responding slave’s access time.
Because the XBAR appears to be just another slave to the master device, the master device
has no indication that it owns the slave port it is targeting. While the master does not have
control of the slave port it is targeting, it is wait-stated.
A master is given control of a 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 the following conditions:
● Outstanding request to slave port A that has a long response time
● Pending access to a different slave port B
● Lower priority master also makes a request to the different slave port B.
In this case, the lower priority master is granted bus ownership of slave port B after a cycle
of arbitration, assuming the higher priority master slave port A access is not terminated.
After a 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, leaves that slave port
for its next access, or loses control of the slave port to a higher priority master with a request
to the same slave port. However, because all masters run a fixed-length burst transfer to a
slave port, it retains control of the slave port until that transfer sequence is completed.
When a slave bus is idled by the XBAR, it is parked on the master that did the last transfer.
14.6.3 Master ports
A master access is taken if the slave port to which the access decodes is either currently
servicing the master or is parked on the master. In this case, the XBAR is completely
transparent and the master access is immediately transmitted on the slave bus and no
arbitration delays are incurred. A master access stall if the access decodes to a slave port
that is busy serving another master, parked on another master.
If the slave port is currently parked on another master, and no other master is requesting
access to the slave port, then only one clock of arbitration is incurred. If the slave port is
currently serving another master of a lower priority and the master has a higher priority than
all other requesting masters, then the master gains control over the slave port as soon as
the data phase of the current access is completed. If the slave port is currently servicing
another master of a higher priority, then the master gains control of the slave port after the
other master releases control of the slave port if no other higher priority master is also
waiting for the slave port.
A master access is responded to with an error if the access decodes to a location not
occupied by a slave port. This is the only time the XBAR directly responds with an error
response. All other error responses received by the master are the result of error responses
on the slave ports being passed through the XBAR.
To Next Page
Loading...
