Simulating Data Cache Parity Errors For Software Testing - IBM PPC440X5 CPU Core User Manual

User's Manual
PPC440x5 CPU Core
MCSR[DCSP] and MCSR[DCFP] indicate what type of data cache operation caused a parity exception. One
of the two bits will be set if a parity error is detected in the data cache, along with MCSR[MCS]. See Machine
Check Interrupts on page 161.
MCSR[DCSP] is set if a parity error is detected during these search operations:
1. Multi-hit parity errors on any instruction that does a CAM lookup
2. Tag or data parity errors on load instructions
3. Tag parity errors on
MCSR[DCFP] is set if a parity error is detected during these flush operations:
1. Data, dirty, or user parity errors on
2. Tag, data, dirty, or user parity errors on a line that is cast out for replacement

4.3.3.7 Simulating Data Cache Parity Errors for Software Testing

Because parity errors occur in the cache infrequently and unpredictably, it is desirable to provide users with a
way to simulate the effect of an data cache parity error so that interrupt handling software may be exercised.
This is exactly the purpose of the CCR1[DCDPEI], CCR1[DCTPEI], CCR1[DCUPEI], CCR1[DCMPEI],and
CCR1[FCOM] fields.
The 39 data cache parity bits in each cache line contain one parity bit per data byte (i.e. 32 parity bits per 32
byte line), plus 2 parity bits for the address tag (note that the valid (V) bit, is not included in the parity bit calcu-
lation for the tag), plus 1 parity bit for the 4-bit U field on the line, plus a parity bit for each of the 4 modified
(dirty) bits on the line. (There are two parity bits for the tag data because the parity is calculated for alternating
bits of the tag field, to guard against a single particle strike event that upsets two adjacent bits. The other data
bits are physically interleaved in such a way as to allow the use of a single parity bit per data byte or other
field.) All parity bits are calculated and stored as the line is initially filled into the cache. In addition, the data
and modified (dirty) parity bits (but not the tag and user parity bits) are updated as the line is updated as the
result of executing a store instruction or
Usually parity is calculated as the even parity for each set of bits to be protected, which the checking hard-
ware expects. However, if any of the the CCR1[DCTPEI] bits are set, the calculated parity for the corre-
sponding bits of the tag are inverted and stored as odd parity. Likewise, if the CCR1[DCUPEI] bit is set, the
calculated parity for the user bits is inverted and stored as odd parity. Similarly, if the CCR1[DCDPEI] bit is
set, the parity for any data bytes that are written, either during the process of a line fill or by execution of a
store instruction, is set to odd parity. Then, when the data stored with odd parity is subsequently loaded, it will
cause a Parity exception type Machine Check interrupt and exercise the interrupt handling software. The
following pseudocode is an example of how to use the CCR1[DCDPEI] field to simulate a parity error on byte
0 of a target cache line:
dcbt <target line address>
msync
mtspr CCR1, Rx
isync
stb <target byte address>
msync
mtspr CCR1, Rz
isync
lb <byte 0 of target line>
Page 130 of 589
dcbf , dcbi , or dcbst instructions
dcbf or dcbst instructions
dcbz .
; get the target line into the cache
; wait for the dcbt
; Set CCR1[DCDPEI]
; wait for the CCR1 context to update
; store some data at byte 0 of the target line
; wait for the store to finish
; Reset CCR1[ICDPEI ]
0
; wait for the CCR1 context to update
; load byte causes interrupt
Preliminary
cache.fm.
September 12, 2002