User’s Manual
Preliminary PPC440x5 CPU Core
cache.fm.
September 12, 2002
Page 115 of 589
There are 10 parity bits stored in the RAM cells of each instruction cache line. Two of those bits hold the
parity for the tag information, and the remaining 8 bits hold the parity for each of the 8 32-bit instruction words
in 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 instruction data bits
are physically interleaved in such a way as to allow the use of a single parity bit per instruction word.) The
parity bits are calculated and stored as the line is filled into the cache. Usually parity is calculated as the even
parity for each set of bits to be protected, which the checking hardware expects. However, if any of the the
CCR1[ICTPEI] bits are set, the calculated parity for the corresponding bits of the tag are inverted and stored
as odd parity. Similarly, if any of the CCR1[ICDPEI] bits are set, the parity for the corresponding instruction
word is set to odd parity. Then, when the instructions stored with odd parity are fetched, they will cause a
Parity exception type Machine Check interrupt and exercise the interrupt handling software. The following
pseudo-code is an example of how to use the CCR1[ICDPEI] field to simulate a parity error on word 0 of a
target cache line:
; make sure all this code in the cache before execution
icbi <target line address> ; get the target line out of the cache
msync ; wait for the icbi
mtspr CCR1, 0x80000000 ; Set CCR1[ICDPEI
0
]
isync ; wait for the CCR1 context to update
icbt <target line address> ; this line fills and sets odd parity for word 0
msync ; wait for the fill to finish
mtspr CCR1, 0x0 ; Reset CCR1[ICDPEI
0
]
isync ; wait for the CCR1 context to update
br <word 0 of target line> ; fetching the target of the branch causes interrupt
Note that any instruction lines filled while bits are set in the CCR1[ICDPEI] or CCR1[ICTPEI] field will be
affected, so users must code carefully to affect only the intended addresses.
The CCR1[FCOM] (Force Cache Operation Miss) bit enables the simulation of a multi-hit parity error. When
set, it will cause an icbt to appear to be a miss, initiating a line fill, even if the line is really already in the
cache. Thus, this bit allows the same line to be filled to the cache multiple times, which will generate a multi-
hit parity error when an attempt is made to fetch an instruction from those cache lines. The following pseudo-
code is an example of how to use the CCR1[FCOM] field to simulate a multi-hit parity error in the instruction
cache:
; make sure all this code is cached and the “target line” is also
; in the cache before execution (use icbt as necessary)
mtspr CCR1, 0x00010000 ; Set CCR1[FCOM]
isync ; wait for the CCR1 context to update
icbt <target line address> ; this line fills a second copy of the target line
msync ; wait for the fill to finish
mtspr CCR1, 0x0 ; Reset CCR1[FCOM]
isync ; wait for the CCR1 context to update
br <word 0 of target line> ; fetching the target of the branch causes interrupt
4.3 Data Cache Controller
The data cache controller (DCC) handles the execution of the storage access instructions, moving data
between memory, the data cache, and the PPC440x5 core GPR file. The DCC interfaces to the PLB using
two independent 128-bit interfaces, one for read operations and one for writes. Both of these PLB interfaces