Ecc double bit error

From Wikipedia, the free encyclopedia

Error correction code memory (ECC memory) is a type of computer data storage that uses an error correction code^[a] (ECC) to detect and correct n-bit data corruption which occurs in memory. ECC memory is used in most computers where data corruption cannot be tolerated, like industrial control applications, critical databases, and infrastructural memory caches.

Typically, ECC memory maintains a memory system immune to single-bit errors: the data that is read from each word is always the same as the data that had been written to it, even if one of the bits actually stored has been flipped to the wrong state. Most non-ECC memory cannot detect errors, although some non-ECC memory with parity support allows detection but not correction.

Description[edit]

Error correction codes protect against undetected data corruption and are used in computers where such corruption is unacceptable, examples being scientific and financial computing applications, or in database and file servers. ECC can also reduce the number of crashes in multi-user server applications and maximum-availability systems.

Electrical or magnetic interference inside a computer system can cause a single bit of dynamic random-access memory (DRAM) to spontaneously flip to the opposite state. It was initially thought that this was mainly due to alpha particles emitted by contaminants in chip packaging material, but research has shown that the majority of one-off soft errors in DRAM chips occur as a result of background radiation, chiefly neutrons from cosmic ray secondaries, which may change the contents of one or more memory cells or interfere with the circuitry used to read or write to them.^[2] Hence, the error rates increase rapidly with rising altitude; for example, compared to sea level, the rate of neutron flux is 3.5 times higher at 1.5 km and 300 times higher at 10-12 km (the cruising altitude of commercial airplanes).^[3] As a result, systems operating at high altitudes require special provisions for reliability.

As an example, the spacecraft Cassini–Huygens, launched in 1997, contained two identical flight recorders, each with 2.5 gigabits of memory in the form of arrays of commercial DRAM chips. Due to built-in EDAC functionality, the spacecraft’s engineering telemetry reported the number of (correctable) single-bit-per-word errors and (uncorrectable) double-bit-per-word errors. During the first 2.5 years of flight, the spacecraft reported a nearly constant single-bit error rate of about 280 errors per day. However, on November 6, 1997, during the first month in space, the number of errors increased by more than a factor of four on that single day. This was attributed to a solar particle event that had been detected by the satellite GOES 9.^[4]

There was some concern that as DRAM density increases further, and thus the components on chips get smaller, while operating voltages continue to fall, DRAM chips will be affected by such radiation more frequently, since lower-energy particles will be able to change a memory cell’s state.^[3] On the other hand, smaller cells make smaller targets, and moves to technologies such as SOI may make individual cells less susceptible and so counteract, or even reverse, this trend. Recent studies^[5] show that single-event upsets due to cosmic radiation have been dropping dramatically with process geometry and previous concerns over increasing bit cell error rates are unfounded.

Research[edit]

Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10⁻¹⁰ error/bit·h (roughly one bit error per hour per gigabyte of memory) to 10⁻¹⁷ error/bit·h (roughly one bit error per millennium per gigabyte of memory).^[5][6][7] A large-scale study based on Google’s very large number of servers was presented at the SIGMETRICS/Performance ’09 conference.^[6] The actual error rate found was several orders of magnitude higher than the previous small-scale or laboratory studies, with between 25,000 (2.5 × 10⁻¹¹ error/bit·h) and 70,000 (7.0 × 10⁻¹¹ error/bit·h, or 1 bit error per gigabyte of RAM per 1.8 hours) errors per billion device hours per megabit. More than 8% of DIMM memory modules were affected by errors per year.

The consequence of a memory error is system-dependent. In systems without ECC, an error can lead either to a crash or to corruption of data; in large-scale production sites, memory errors are one of the most-common hardware causes of machine crashes.^[6] Memory errors can cause security vulnerabilities.^[6] A memory error can have no consequences if it changes a bit which neither causes observable malfunctioning nor affects data used in calculations or saved. A 2010 simulation study showed that, for a web browser, only a small fraction of memory errors caused data corruption, although, as many memory errors are intermittent and correlated, the effects of memory errors were greater than would be expected for independent soft errors.^[8]

Some tests conclude that the isolation of DRAM memory cells can be circumvented by unintended side effects of specially crafted accesses to adjacent cells. Thus, accessing data stored in DRAM causes memory cells to leak their charges and interact electrically, as a result of high cell density in modern memory, altering the content of nearby memory rows that actually were not addressed in the original memory access. This effect is known as row hammer, and it has also been used in some privilege escalation computer security exploits.^[9][10]

An example of a single-bit error that would be ignored by a system with no error-checking, would halt a machine with parity checking, or would be invisibly corrected by ECC: a single bit is stuck at 1 due to a faulty chip, or becomes changed to 1 due to background or cosmic radiation; a spreadsheet storing numbers in ASCII format is loaded, and the character «8» (decimal value 56 in the ASCII encoding) is stored in the byte that contains the stuck bit at its lowest bit position; then, a change is made to the spreadsheet and it is saved. As a result, the «8» (0011 1000 binary) has silently become a «9» (0011 1001).

Solutions[edit]

Several approaches have been developed to deal with unwanted bit-flips, including immunity-aware programming, RAM parity memory, and ECC memory.

This problem can be mitigated by using DRAM modules that include extra memory bits and memory controllers that exploit these bits. These extra bits are used to record parity or to use an error-correcting code (ECC). Parity allows the detection of all single-bit errors (actually, any odd number of wrong bits). The most-common error correcting code, a single-error correction and double-error detection (SECDED) Hamming code, allows a single-bit error to be corrected and (in the usual configuration, with an extra parity bit) double-bit errors to be detected. Chipkill ECC is a more effective version that also corrects for multiple bit errors, including the loss of an entire memory chip.

Implementations[edit]

Seymour Cray famously said «parity is for farmers» when asked why he left this out of the CDC 6600.^[11] Later, he included parity in the CDC 7600, which caused pundits to remark that «apparently a lot of farmers buy computers». The original IBM PC and all PCs until the early 1990s used parity checking.^[12] Later ones mostly did not.

An ECC-capable memory controller can generally^[a] detect and correct errors of a single bit per word^[b] (the unit of bus transfer), and detect (but not correct) errors of two bits per word. The BIOS in some computers, when matched with operating systems such as some versions of Linux, BSD, and Windows (Windows 2000 and later^[13]), allows counting of detected and corrected memory errors, in part to help identify failing memory modules before the problem becomes catastrophic.

Some DRAM chips include «internal» on-chip error correction circuits, which allow systems with non-ECC memory controllers to still gain most of the benefits of ECC memory.^[14][15] In some systems, a similar effect may be achieved by using EOS memory modules.

Error detection and correction depends on an expectation of the kinds of errors that occur. Implicitly, it is assumed that the failure of each bit in a word of memory is independent, resulting in improbability of two simultaneous errors. This used to be the case when memory chips were one-bit wide, what was typical in the first half of the 1980s; later developments moved many bits into the same chip. This weakness is addressed by various technologies, including IBM’s Chipkill, Sun Microsystems’ Extended ECC, Hewlett Packard’s Chipspare, and Intel’s Single Device Data Correction (SDDC).

DRAM memory may provide increased protection against soft errors by relying on error correcting codes. Such error-correcting memory, known as ECC or EDAC-protected memory, is particularly desirable for high fault-tolerant applications, such as servers, as well as deep-space applications due to increased radiation. Some systems also «scrub» the memory, by periodically reading all addresses and writing back corrected versions if necessary to remove soft errors.

Interleaving allows for distribution of the effect of a single cosmic ray, potentially upsetting multiple physically neighboring bits across multiple words by associating neighboring bits to different words. As long as a single event upset (SEU) does not exceed the error threshold (e.g., a single error) in any particular word between accesses, it can be corrected (e.g., by a single-bit error correcting code), and an effectively error-free memory system may be maintained.^[16]

Error-correcting memory controllers traditionally use Hamming codes, although some use triple modular redundancy (TMR). The latter is preferred because its hardware is faster than that of Hamming error correction scheme.^[16] Space satellite systems often use TMR,^[17][18][19] although satellite RAM usually uses Hamming error correction.^[20]

Many early implementations of ECC memory mask correctable errors, acting «as if» the error never occurred, and only report uncorrectable errors. Modern implementations log both correctable errors (CE) and uncorrectable errors (UE). Some people proactively replace memory modules that exhibit high error rates, in order to reduce the likelihood of uncorrectable error events.^[21]

Many ECC memory systems use an «external» EDAC circuit between the CPU and the memory. A few systems with ECC memory use both internal and external EDAC systems; the external EDAC system should be designed to correct certain errors that the internal EDAC system is unable to correct.^[14] Modern desktop and server CPUs integrate the EDAC circuit into the CPU,^[22] even before the shift toward CPU-integrated memory controllers, which are related to the NUMA architecture. CPU integration enables a zero-penalty EDAC system during error-free operation.

As of 2009, the most-common error-correction codes use Hamming or Hsiao codes that provide single-bit error correction and double-bit error detection (SEC-DED). Other error-correction codes have been proposed for protecting memory – double-bit error correcting and triple-bit error detecting (DEC-TED) codes, single-nibble error correcting and double-nibble error detecting (SNC-DND) codes, Reed–Solomon error correction codes, etc. However, in practice, multi-bit correction is usually implemented by interleaving multiple SEC-DED codes.^[23][24]

Early research attempted to minimize the area and delay overheads of ECC circuits. Hamming first demonstrated that SEC-DED codes were possible with one particular check matrix. Hsiao showed that an alternative matrix with odd weight columns provides SEC-DED capability with less hardware area and shorter delay than traditional Hamming SEC-DED codes. More recent research also attempts to minimize power in addition to minimizing area and delay.^[25][26][27]

Cache[edit]

Many CPUs use error-correction codes in the on-chip cache, including the Intel Itanium, Xeon, Core and Pentium (since P6 microarchitecture)^[28][29] processors, the AMD Athlon, Opteron, all Zen-^[30] and Zen+-based^[31] processors (EPYC, EPYC Embedded, Ryzen and Ryzen Threadripper), and the DEC Alpha 21264.^[23][32]

As of 2006, EDC/ECC and ECC/ECC are the two most-common cache error-protection techniques used in commercial microprocessors. The EDC/ECC technique uses an error-detecting code (EDC) in the level 1 cache. If an error is detected, data is recovered from ECC-protected level 2 cache. The ECC/ECC technique uses an ECC-protected level 1 cache and an ECC-protected level 2 cache.^[33] CPUs that use the EDC/ECC technique always write-through all STOREs to the level 2 cache, so that when an error is detected during a read from the level 1 data cache, a copy of that data can be recovered from the level 2 cache.

Registered memory[edit]

Registered, or buffered, memory is not the same as ECC; the technologies perform different functions. It is usual for memory used in servers to be both registered, to allow many memory modules to be used without electrical problems, and ECC, for data integrity. Memory used in desktop computers is usually neither, for economy. However, unbuffered (not-registered) ECC memory is available,^[34] and some non-server motherboards support ECC functionality of such modules when used with a CPU that supports ECC.^[35] Registered memory does not work reliably in motherboards without buffering circuitry, and vice versa.

Advantages and disadvantages[edit]

Ultimately, there is a trade-off between protection against unusual loss of data and a higher cost.

ECC memory usually involves a higher price when compared to non-ECC memory, due to additional hardware required for producing ECC memory modules, and due to lower production volumes of ECC memory and associated system hardware. Motherboards, chipsets and processors that support ECC may also be more expensive.

ECC support varies among motherboard manufacturers so ECC memory may simply not be recognized by a ECC-incompatible motherboard. Most motherboards and processors for less critical applications are not designed to support ECC. Some ECC-enabled boards and processors are able to support unbuffered (unregistered) ECC, but will also work with non-ECC memory; system firmware enables ECC functionality if ECC memory is installed.

ECC may lower memory performance by around 2–3 percent on some systems, depending on the application and implementation, due to the additional time needed for ECC memory controllers to perform error checking.^[36] However, modern systems integrate ECC testing into the CPU, generating no additional delay to memory accesses as long as no errors are detected.^[22][37][38]

ECC supporting memory may contribute to additional power consumption due to error correcting circuitry.

Notes[edit]

References[edit]

External links[edit]

• SoftECC: A System for Software Memory Integrity Checking
• A Tunable, Software-based DRAM Error Detection and Correction Library for HPC
• Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing
• Single-Bit Errors: A Memory Module Supplier’s perspective on cause, impact and detection
• Intel Xeon Processor E3 — 1200 Product Family Memory Configuration Guide
• Linus Torvalds On The Importance Of ECC RAM, Calls Out Intel’s «Bad Policies» Over ECC

Skip to content

Error correcting codes (ECCs) are used in computer and communication systems to
improve resiliency to bit flips caused by permanent hardware faults or
transient conditions, such as neutron particles from cosmic rays, known
generally as soft errors. This note
describes the principles of Hamming codes that underpin ECC schemes, ECC codes
are constructed, focusing on single-error correction and double error
detection, and how they are implemented.

ECCs work by adding additional redundant bits to be stored or transported with
data. The bits are encoded as a function of the data in such a way that it is
possible to detect erroneous bit flips and to correct them. The ratio of the
number of data bits to the total number of bits encoded is called the code
rate, with a rate of 1 being a an impossible encoding with no overhead.

Simple ECCs

Parity coding adds a single bit that indicates whether the number of set
bits in the data is odd or even. When the data and parity bit is accessed or
received, the parity can be recomputed and compared. This is sufficient to
detect any odd number of bit flips but not to correct them. For applications
where the error rate is low, so that only single bit flips are likely and
double bit flips are rare enough to be ignored, parity error detection is
sufficient and desirable due to it’s low overhead (just a single bit) and
simple implementation.

Repetition coding simply repeats each data bit a fixed number of times. When
the encoded data is received, if each of the repeated bits are non identical,
an error has occurred. With a repetition of two, single-bit errors can be
detected but not corrected. With a repetition of three, single bit flips can be
corrected by determining each data bit as the majority value in each triple,
but double bit flips are undetectable and will cause an erroneous correction.
Repetition codes are simple to implement but have a high overhead.

Hamming codes

Hamming codes are an efficient family of codes using additional redundant bits to
detect up to two-bit errors and correct single-bit errors (technically, they are
linear error-correcting codes).
In them, check bits are added to data bits to form a codeword, and the
codeword is valid only when the check bits have been generated from the data
bits, according to the Hamming code. The check bits are chosen so that there is
a fixed Hamming distance between any two valid codewords (the number of
positions in which bits differ).

When valid codewords have a Hamming distance of two, any single bit flip will
invalidate the word and allow the error to be detected. For example, the valid
codewords 00 and 11 are separated for single bit flips by the invalid
codewords 01 and 10. If either of the invalid words is obtained an error
has occurred, but neither can be associated with a valid codeword. Two bit
flips are undetectable since they always map to a valid codeword. Note that
parity encoding is an example of a distance-two Hamming code.

00 < Valid codeword
|
10 < Invalid codeword (obtained by exactly 1 bit flip)
|
11 < Valid codeword

With Hamming distance three, any single bit flip in a valid codeword makes an
invalid one, and the invalid codeword is Hamming distance one from exactly one
valid codeword. Using this, the valid codeword can be restored, enabling single
error correction. Any two bit flips map to an invalid codeword, which would
cause correction to the wrong valid codeword.

000 < Valid codeword
 |
001
 |
011
 |
111 < Valid codeword

With Hamming distance four, two bit flips moves any valid codeword Hamming
distance two from exactly two valid codewords, allowing detection of two flips
but not correction. Single bit flips can be corrected as they were for distance
three. Distance-four codes are widely used in computing, where is it often the
case where single errors are frequent, double errors are rare and triple errors
occur so rarely they can be ignored. These codes are referred to as ‘SECDED
ECC’ (single error correction, double error detection).

0000 < Valid codeword
 |
0001
 |
0011 < Two bit flips from either codeword.
 |
0111
 |
1111 < Valid codeword

Double errors can be corrected with a distance-five code, as well as enabling
the detection of triple errors. In general, if a Hamming code can detect $d$
errors, it must have a minimum distance of $d+1$ so there is no way $d$ errors
can change one valid codeword into another one. If a code can correct $d$
errors, it must have a minimum distance of $2d+1$ so that the originating code
is always the closest one. The following table summarises Hamming codes.

Creating a Hamming code

A codeword includes the data bits and checkbits. Each check bit corresponds to
a subset of the data bits and it is set when the parity of those data bits is
odd. To obtain a code with a particular Hamming distance, the number of check
bits and their mapping to data bits must be chosen carefully.

To build a single-error correcting (SEC) code that requires Hamming distance
three between valid codewords, it is necessary for:

• The mapping of each data bit to check bits is unique.
• Each data bit to map to at least two check bits.

To see why this works, consider two distinct codewords that necessarily
must have different data bits. If the data bits differ by:

• 1 bit, at least two check bits are flipped, giving a total of three
  different bits.

• 2 bits, these will cause at least one flip in the check bits since any two
  data bits cannot share the same check-bit mapping (ie by taking the XOR of
  the two check bit patterns). This also gives a total of three different bits as required.

• 3 bits, this is already sufficient to give a Hamming distance of three.

To build a SECDED code that requires Hamming distance of four between valid
codewords, it is necessary for:

• The mapping of each data bit to check bits is unique.
• Each data bit to map to at least three check bits.
• Each check bit pattern to have an odd number of bits set.

Following a similar argument, consider two distinct codewords, data differing by:

• 1 bit flips three check bits, giving a total of four different bits.

• 2 bits flip check bits in two patterns, and since any two odd-length patterns
  must have at least two non-overlapping bits, the results is at least two
  flipped bits, giving a total of four different bits. For example:

Check bits:  0 1 2 3
data[a]      x x x
data[b]        x x x
-----------  --------
Flips        x     x

Check bits:  0 1 2 3 4
data[a]      x x x
data[b]      x x x x x
----------   ---------
Flips              x x

• 3 bits flip check bits in three patterns, and this time it is possible to
  overlap odd-length patterns in such a way that a minimum of 1 bit is flipped.
  For example:

Check bits:  0 1 2 3 4
data[a]      x x x
data[b]        x x x
data[c]      x     x x
-----------  ---------
Flips                x

Check bits:  0 1 2 3 4
data[a]      x x x x x
data[b]      x x x
data[c]      x     x x
-----------  ---------
Flips        x

• 4 bits is already sufficient to provide a Hamming distance of four.

An example SEC code for eight data bits with four parity bits:

Check bits:  0 1 2 3
data[0]      x x x
data[1]        x x x
data[2]      x   x x
data[3]      x x   x
data[4]      x x
data[5]        x x
data[6]          x x
data[7]      x     x

An example SECDED code for eight data bits with five parity bits:

Check bits:  0 1 2 3 4
data[0]      x x x
data[1]      x x   x
data[2]      x   x x
data[3]        x x x
data[4]      x x     x
data[5]      x   x   x
data[6]        x x   x
data[7]      x     x x

Note that mappings of data bits to check bits can be chosen flexibly, providing
they maintain the rules that set the Hamming distance. This flexibility is
useful when implementing ECC to reduce the cost of calculating the check bits.
In contrast, many descriptions of ECC that I have found in text books and on
Wikipedia describe a specific
encoding that does not acknowledge this freedom. The encoding they describe
allows the syndrome to be interpreted as the bit index of the single bit error,
by the check bit in position $i$ covering data bits in position $i$.
Additionally, they specify that parity bits are positioned in the codeword at
power-of-two positions, for no apparent benefit.

Implementing ECC

Given data bits and check bits, and mapping of data bits to check bits, ECC
encoding works by calculating the check bits from the data bits, then combining
data bits and check bits to form the codeword. Decoding works by taking the
data bits from a codeword, recalculating the check bits, then calculating the
bitwise XOR between the original check bits and the recalculated ones. This
value is called the syndrome. By inspecting the number of bits set in the
syndrome, it is possible to determine whether there has been an error,
whether it is correctable, and how to correct it.

Using the SEC check-bit encoding above, creating a codeword from data[7:0],
the check bits are calculated as follows (using Verilog syntax):

assign check_word[0] = data[0] ^ data[2] ^ data[3] ^ data[4] ^ data[7];
assign check_word[1] = data[0] ^ data[1] ^ data[3] ^ data[4] ^ data[5];
assign check_word[2] = data[0] ^ data[1] ^ data[2] ^ data[5] ^ data[6];
assign check_word[3] = data[1] ^ data[2] ^ data[3] ^ data[6] ^ data[7];

And the codeword formed by concatenating the check bits and data:

assign codeword = {check[3:0], data[7:0]};

Decoding of a codeword, splits it into the checkword and data bits, recomputes
the check bits and calculates the syndrome:

assign {old_check_word, old_data} = codeword;
assign new_check_word[0] = ...;
assign new_check_word[1] = ...;
assign new_check_word[2] = ...;
assign new_check_word[3] = ...;
assign syndrome = new_check_word ^ old_check_word;

When single bit errors occur, the syndrome will have the bit pattern
corresponding to a particular data bit, so a correction can be applied by
creating a mask to flip the bit in that position:

unique case(syndrome)
  4'b1110: correction = 1<<0;
  4'b0111: correction = 1<<1;
  4'b1011: correction = 1<<2;
  4'b1101: correction = 1<<3;
  4'b1100: correction = 1<<4;
  4'b0110: correction = 1<<5;
  4'b0011: correction = 1<<6;
  4'b1001: correction = 1<<7;
  default: correction = 0;
endcase

And using it to generate the corrected data:

assign corrected_data = data ^ correction;

The value of the syndrome can be further inspected to signal what action has
been taken. If the syndrome is:

• Equal to zero, no error occurred.
• Has one bit set, then this is a flip of a check bit and can be ignored.
• Has a value matching a pattern (three bits set or two bits in the adjacent positions), a correctable error occurred.
• Has a value not matching a pattern (two bits set in the other non-adjacent positions: 4'b1010, 4'b0101), or four bits set, a multi-bit uncorrectable error occurred.

The above SECDED check-bit encoding can be implemented in a similar way, but
since it uses only three-bit patterns, mapping syndromes to correction masks
can be done with three-input AND gates:

unique case(syndrome)
  syndrome[0] && syndrome[1] && syndrome[2]: correction = 1<<0;
  syndrome[0] && syndrome[1] && syndrome[3]: correction = 1<<1;
  syndrome[0] && syndrome[2] && syndrome[3]: correction = 1<<2;
  syndrome[1] && syndrome[2] && syndrome[3]: correction = 1<<3;
  syndrome[0] && syndrome[1] && syndrome[4]: correction = 1<<4;
  syndrome[0] && syndrome[2] && syndrome[4]: correction = 1<<5;
  syndrome[1] && syndrome[2] && syndrome[4]: correction = 1<<6;
  syndrome[0] && syndrome[3] && syndrome[4]: correction = 1<<7;
  default:                                   correction = 0;
endcase

And any syndromes with one or two bits set are correctable, and otherwise uncorrectable.

References / further reading

• Error correction code, Wikipedia.
• Hamming code, Wikipedia.
• ECC memory, Wikipedia.
• Error detecting and error correcting codes (PDF),
  R. W. Hamming, in The Bell System Technical Journal, vol. 29, no. 2, pp. 147-160, April 1950.
• Constructing an Error Correcting Code (PDF),
  Andrew E. Phelps, University of Wisconsin, Madison, November 2006.

tected, the I/O port does not issue the transaction on the TLSB. It simply

aborts that transaction by transmitting a UTV_ERROR_A (or B) code

across its internal TL_CMD bus to each IDR. The I/O port then posts an

IPL 17 interrupt on the TLSB, if enabled by ICCNSE<INTR_NSES>.

Data bus errors are either ECC-detected errors on data transfers or control

errors on the data bus. In addition, all I/O port transceivers on the TLSB

check the data received from the bus against the expected data driven on

the bus.

The I/O port slices the TLSB_D<255:0> and TLSB_ECC<31:0> signals into

four parts, each containing 64 bits of data and 8 bits of ECC as follows:

The I/O port handles error detection on these signals independently in

each slice, setting error bits in a corresponding TLESRn register. The con-

tents of the four TLESRn registers is summarized in the TLBER register.

Broadcasting of the error is determined by the error type and whether or

not broadcasting of the error type is enabled.

6.7.8.1

Single-Bit ECC Errors

A single bit error on a memory data transfer is detected by the I/O port’s

ECC checking logic. The I/O port both checks and corrects the data. If the

I/O port detects a single-bit ECC error, it logs the error in its TLESRn reg-

ister by setting either <CRECC> or <CWECC>, depending on whether a

read or write command failed. If the error was detected on data that the

I/O port was writing to memory, then the TLESR<TDE> and TL-

BER<DTDE> bits are also set.

A CRECC error sets <CRDE> in the I/O port’s TLBER register. A CWECC

error sets <CWDE> in the I/O port’s TLBER register.

When the I/O port detects a single-bit data error, it asserts TLSB_DATA_

ERROR to signal the other nodes of the error. If correctable error inter-

rupts are not disabled by TLCNR<CWDD> and TLCNR<CRDD>, and ICC-

NSE<INTR_NSES> is set, an IPL 17 interrupt is posted to the proces-

sor(s).

The I/O port also latches the failing syndrome in the TLESRn registers, in-

dicating which cycle(s) failed during the transaction.

6.7.8.2

Double-Bit ECC Errors

A double-bit error on a data transfer is detected by the I/O port’s ECC

checking logic. The I/O port logs the error in its TLESRn register by set-

6-72 I/O Port

• TLSB_D<63:0> and TLSB_ECC<7:0> are handled by the IDR_0 gate

array

• TLSB_D<127:64> and TLSB_ECC<15:8> are handled by the IDR_1

gate array

• TLSB_D<191:128> and TLSB_ECC<23:16> are handled by the IDR_2

gate array

• TSB_D<255:192> and TLSB_ECC<31:24> are handled by the IDR_3

gate array