Data Bus; Error Checking - Compaq AlphaServer GS60E Service Manual

4.1.2

Data Bus

The TSLB transfers data in the sequence order that valid address bus
commands are issued. In addition to 256 bits of data, the data bus contains
associated ECC bits and some control signals. Three signals are of particular
significance in read and write operations.
TLSB_SHARED – When a request is made to access memory, each CPU notes
whether the block of memory is currently resident in cache, and, if so, asserts a
signal that the data is shared. Thus, when the slave responds with the data, it
asserts the TLSB_SHARED signal on the data bus, so that CPU nodes can take
note and make sure that the block being accessed remains valid in the CPU's
cache. This signal is valid when driven in response to Read, Read Bank Lock,
Write, and Write Bank Unlock commands.
TLSB_DIRTY – This signal is used to indicate that the block being accessed is
valid in a CPU cache, and that the copy there is more recent than the copy in
memory. TLSB_DIRTY is guaranteed to be valid in response to Read and Read
Bank Lock commands.
TLSB_STACHK – This signal is asserted whenever TLSB_SHARED or
TLSB_DIRTY are asserted, to ensure that, should an error occur in
transmission or reception of either one of these signals, it can be detected. For
example, if TLSB_SHARED or TLSB_DIRTY is asserted, but TLSB_STACHK is
not, there is an error. Or, if TLSB_STACHK is asserted and TLSB_SHARED or
TLSB_DIRTY is not, there is also an error.
4.1.3

Error Checking

The TLSB is designed to implement error detection and, where possible, error
correction. The TLSB uses parity protection on the address bus. The data bus
is protected by ECC (error correction code). Protocol sequence checking is used
on the control signals across both buses. Cache coherency is monitored with the
use of the TLSB_SHARED and TLSB_DIRTY signals described above.
PALcode collects error information from module control and status registers and
formats it into a "logout frame" that is passed to the operating system, which
uses the information to determine the action to take on the error. Some errors
are fatal; they can cause a specific process or the entire system to fail. Other
errors can be corrected and do not halt processing. The operating system writes
the error information as an entry in a binary file that can then be used by the
DECevent bit-to-text translator to produce an error log.
DECevent Error Log 4-3