Bank Collision; Bank Lock And Unlock; Csr Bank Contention - DEC AlphaServer 8200 Technical Manual

CPUs can request the bus without first checking that the bank is busy. If
the bank does turn out to be busy, this is considered a false arbitration,
and the command is a no-op. The device can request the bus again when
the bank is free. To prevent lockout of devices that might have been wait-
ing for the bank, CPUs early arbitrating for the bus cannot issue the com-
mand if they request in the cycle when <TLSB_BANK_AVL> asserts on
the bus, or in the subsequent cycle. If a CPU requests a bank before
<TLSB_BANK_AVL> is asserted, it drives a no-op.

2.2.4.12 Bank Collision

If two CPUs request the bus for access to the same bank, the higher prior-
ity device is granted the bus and drives the command, address, and bank
number. The lower priority device deasserts its request when it receives
the command and bank number. But if the request cannot be withdrawn
before it gets granted the bus, it must drive a no-op and request again
when the bank becomes free. This conflict is referred to as "bank colli-
sion."
Relative bus priorities are only updated when a valid data transfer com-
mand is asserted on the bus. If a bank collision occurs, the bus priorities
are not updated as a result of the no-op cycle.

2.2.4.13 Bank Lock and Unlock

I/O ports must merge I/O data into full memory blocks. Commands are
provided on the bus to allow the I/O port to read the block from memory,
merge the I/O data, and write the block back to memory as an atomic
transaction. These commands are the Read Bank Lock and Write Bank
Unlock. In response to a Read Bank Lock, memory deasserts
TLSB_BANK_AVL for that bank and keeps it deasserted until the I/O port
issues a Write Bank Unlock. This effectively denies any other device ac-
cess to the same block as the bank appears busy.

2.2.4.14 CSR Bank Contention

Nodes arbitrate for CSR accesses in the same manner as they do for mem-
ory accesses. CSR accesses must follow the rules relating to early arbitra-
tion and look-back-two.
The TLSB protocol allows only one CSR access at a time. There is no ex-
plicit CSR bank busy line. Modules must monitor all transactions on the
bus to set an internal CSR busy status and check sequence numbers on re-
turn data to clear the CSR busy status. The duration of a CSR access is
from the assertion of the command on the bus to initiate the transaction
until two cycles following the time when the shared and dirty status is
available on the bus (that is, TLSB_HOLD is deasserted). A new request
can be asserted one cycle later. If the command is not acknowledged, the
CSR access ends two cycles after TLSB_CMD_ACK should have appeared
on the bus. A new request can be asserted one cycle later.
If two devices arbitrate for the bus for CSR accesses, the winner drives the
bus. If the second device cannot deassert its request line in time and wins
the bus, it drives a no-op and requests the bus again at a later time.
In the case of a write, a module may be busy writing the data into its CSR
registers after the data transaction on the bus. If this module is involved
TLSB Bus 2-15