Table of Contents
Advertisement
2.1.1 Transactions
A transaction couples a commander node that issues the request and a
slave node that sequences the data bus to transfer data. This rule applies
to all transactions except CSR broadcast space writes. In these transac-
tions, the commander is responsible for sequencing the data bus. CPUs
and I/O nodes are always the commander on memory transactions and can
be either the commander or the slave on CSR transactions. Memory nodes
are slaves in all transactions.
Address bus transactions take place in sequence as determined by the win-
ner of the address bus arbitration. Data bus transactions take place in the
sequence in which the commands appear on the address bus. All nodes in-
ternally tag the command with a four-bit sequence number. The number
increments as each command is acknowledged. To return data, the slave
node sequences the bus to start the transfer.
2.1.2 Arbitration
The address bus protocol allows aggressive arbitration where devices can
speculatively arbitrate for the bus and where the winner can no-op out the
command if the bus is not needed. The bus provides eight request lines for
the nodes that permit normal arbitration. Node 8 has high and low arbi-
tration request lines that permit an I/O port to limit maximum read la-
tency.
2.1.3 Cache Coherency Protocol
The TLSB supports a conditional write-update protocol that permits the
use of a write-back cache policy, while providing efficient handling of
shared data across the caches within the system.
2.1.4 Error Handling
The TLSB implements error detection and, where possible, error correc-
tion. Transaction retry is permitted as an implementation-specific option.
Four classes of errors are handled:
2-2 TLSB Bus
• Soft errors, hardware corrected, transparent to software (for example,
single-bit ECC errors).
• Soft errors requiring PALcode/software support to correct (for example,
cache tag parity errors, which can be recovered by PALcode copying
the duplicate tag to the main tag).
• Hard errors restricted to the failing transaction (for example, a double-
bit error in a memory location in a user's process. This would result in
the process being aborted and the page being marked as bad). The sys-
tem can continue operation.
• System fatal hard errors. The system integrity has been compromised
and continued system operation cannot be guaranteed (for example,
bus sequence error). All outstanding transactions are aborted, and the
state of the system is unknown. When a system fatal error occurs, the
bus attempts to reset to a known state to permit machine check han-
dling to save the system state.
Advertisement
Table of Contents
