Virtex-4 PowerPC 405 - Errata for all Virtex-4 FX Devices
Description
Keywords: PPC405, PPC405F6, PPC405F6X1, APU, UDI, NTWF, OPB Memory controller, PPC Errata, PVR, FCM, FPU, Instruction Parity, Data Cache Parity
The IBM PPC405F6 Errata for all of the Virtex-4 FX devices is available at:
http://www.xilinx.com/txpatches/pub/documentation/misc/ppc405f6v5_2_0.pdf
Category 1:
Major impact, no work-around is available. A problem has a major impact if it results in a system crash, a hard failure, an unrecoverable soft failure, a significant performance degradation, or the storage of incorrect data.
Category 2:
Major impact, a work-around is impractical to implement, or a substantial risk of encountering the same or additional problems (including performance issues) exists after the work-around is implemented.
Category 3:
Major impact, a work-around is available. Application of the work-around either eliminates the problem or reduces it to a minor impact issue.
Category 4:
Minor impact, no work-around is available. Minor impact problems result in slight to moderate performance degradation, or are a functional variance from the specification.
Category 5:
Minor impact, a work-around is available. Minor impact problems result in slight to moderate performance degradation, or are a functional variance from the specification.
Category 6:
Design enhancement.
NOTE:
- All Virtex-4 FX Production Devices and CES4 devices have the PVR of 20011470.
- All material with DGQ and higher top mark has PVR 20011470.
Solution
1
CPU_121: The ICCCI instruction might incorrectly cause a Data TLB exception.Category: 3
OVERVIEW:
When data-side relocation (data address translation) is enabled (MSR[DR]=1), an ICCCI instruction incorrectly attempts an access check for the associated page. The ICCCI invalidates the entire I-Cache, and the effective address it generates is unnecessary.
2
CPU_147: Virtual memory that is marked as nonexecutable storage (storage attribute EX=0) can be loaded into the instruction cache using the ICBT instruction.Category: 3
OVERVIEW:
An ICBT instruction whose effective address maps to a region of storage has the three characteristics listed below. These characteristics cause a cache-line fill to occur within the instruction cache (I-cache):
- Memory is marked as non-executable storage (storage attribute EX = 0)
- Memory is marked as cacheable (storage attribute I = 0)
- Access is not prohibited by a zone fault (the access control field ZSEL references a \ field that does not prohibit access).
The ICBT instruction should perform "no operation" (no-op) if the effective address belongs to a memory page marked as nonexecutable storage.
3
CPU_153: Floating-point enabled exceptions do not update the CR1 field of the CR.Category: 5
OVERVIEW:
The correct functioning happens when floating-point enabled exceptions (excluding Enabled Invalid Operation and Enabled Zero Divide Exceptions) occurring on floating-point instructions with the RC bit set should architecturally update the CR1 field of the CR.
4
CPU_162: When in Real Mode, the 405 Core might incorrectly make speculative instruction fetches from guarded storage.Category: 3
OVERVIEW:
In Real Mode, if instructions (Guarded Storage or not) and memory-mapped I/O (Guarded Storage) are within 1 KB of each other, the I/O can be speculative-accessed when the instructions are executed.
NOTES:
1. When instruction translation is disabled (MSR[IR]=0), the PPC405 Core accesses instructions in Real Mode.
2. Settings in the Storage Guarded Register (SGR) define Real Mode Guarded storage on 128 MB boundaries.
5
CPU_163: Floating-point-enabled exception handlers cannot reliably determine whether the SRR0 points to the exception instruction.Category: 3
OVERVIEW:
When a floating-point-enabled exception exists while the MSR[FE0] and MSR[FE1] bits are Off, and either or both of the MSR[FE] bits are re-enabled via a MTMSR, RFI, or RFCI instruction, the floating-point-enabled exception handler cannot determine whether the exception was caused by the instruction pointed to by SRR0 or by an earlier instruction.
6
CPU_187: Access to guard storage via APU load/store double-word or APU load/store quad-word instructions is not architecturally compliant.Category: 5
OVERVIEW:
Architecturally, a data-aligned load or store (not including multiples or strings) to storage marked as "guarded" should not be accessed speculatively. The PPC405 Core breaks double- and quad-word operations into 2- and 4-word transfers, respectively.
For example, consider aligned double-word transfers to guarded storage. Once the first word of a double-word transfer has reached load write-back (LWB), it is uninterruptible. If the second piece is still in the execute (EXE) or in the write-back (WB) pipeline stage, it might be interrupted because of an asynchronous interrupt.
When the interrupt handler returns to the interrupted load double-word, the instruction is restarted from the beginning. As a result, the guarded storage location accessed by the first piece of the load double-word is accessed a second time. Similarly, for double-word store instructions that are interrupted immediately after the first piece of data has left the write-back stage, returning from the interrupt handler restarts the instruction, causing the first piece to be accessed from the guarded location twice.
If the APU load/store double-word or APU load/store quad-word involves 32-bit or smaller RT or RS registers such that the double or quad-word transfer resembles a load/store multiple, the guarded requirement does not apply. If the APU load/store double-word or APU load/store quad-word involves 64- or 128-bit registers, respectively, the guarded requirement does apply and accessing the guarded location twice is not architecturally compliant.
This is currently a problem for floating-point load/store double-word operations to guarded storage.
7
CPU_197: Incorrect Real Mode attributes can be used when the last instruction is accessed in a 128 MB region.Category: 3
OVERVIEW:
When instructions are executed in Real Mode (MSR[IR]=0), an access to the last instruction in a 128 MB region uses the Real Mode attributes of the next consecutive 128 MB region under any of the following conditions:
1. The last instruction in a 128 MB region contains a branch target that is noncacheable or causes a cache miss.
2. The address restored by an RFI or RFCI is the last instruction in a 128 MB region, and this address is noncacheable or causes a cache miss.
3. The next-to-last instruction in a noncacheable 128 MB region contains a branch that is predicted taken, but is not taken.
4. The next-to-last instruction in a noncacheable 128 MB region contains an ISYNC instruction.
NOTES:
1. Real Mode attributes are specified by the ICCR, SU0R, and SLER registers.
2. All 128 MB regions have the same storage attributes after reset. Therefore, a branch instruction at the reset vector 0xFFFFFFFC is not affected by this erratum after a core, chip, or system reset.
3. In Real Mode, the storage regions wrap, making the last storage region (0xF8000000 - 0xFFFFFFFF) and the first storage region (0x00000000 - 0x07FFFFFF) consecutive.
8
CPU_208: ICBT instructions executed with data relocation enabled might cause incorrect instruction execution if the ICBT misses in the UTLB or does not have permission to access the page.Category: 3
OVERVIEW:
ICBT instructions executed with data relocation enabled (MSR[DR]=1) might cause incorrect instruction execution if the ICBT misses in the UTLB or does not have permission to access the page. For the ICBT to cause the instruction cache to deliver incorrect instructions to the fetcher, a number of conditions must be present:
1. Data relocation is enabled.
2. Either condition 2a or 2b is true:
a. The page referenced by the ICBT instruction is not found in the UTLB.
b. The TLB page referenced by the ICBT instruction is marked protected by its ZPR settings.
3. A cache line fill completes while the execute logic is requesting the ICU to perform an ICBT.
4. The fetcher must be requesting an address for a new cache line followed by a request for the previous cache line. This condition occurs when the fetcher re-request data is thrown away because there is inadequate room in the fetch queue.
5. In the same cycle as conditions 3 and 4, the ICBT must be presented to the instruction cache. The instruction cache must not accept the fetch request for this cycle, but does accept the ICBT.
9
CPU_212: While waiting for a Data Side PLB (DSPLB) load to complete, the PPC405 Core might ignore a valid store completion from Data Side OCM (DSOCM) when a particular sequence of operations occurs. This condition can occur in a system using both DSPLB and DSOCM interfaces. This can cause the PPC405 to hang or can result in incorrect values for registers in these operations.Category: 3
OVERVIEW:
In a normal operation, the PPC405 Core ensures completion of a load request to DSPLB memory space before completion of a second load request (to DSOCM or non-DSOCM memory space). A problem occurs when two store requests are made to DSOCM between these two load requests AND the first load to DSPLB is waiting to be completed (at the time when a second load request is initiated). In this case, if DSOCM issues a valid completion for the first and second store requests to the PPC405 Core, a second store completion is ignored (erroneously) by the PPC405 Core. This might cause the PPC405 to hang or to leave a second store operation in an incomplete state and eventually produces incorrect results.
To work around this issue, for a system using DSPLB and DSOCM, set the reserved bit [1] of register CCR0, described in the PowerPC 405 Processor Block Reference Guide, available at:
http://direct.xilinx.com/bvdocs/userguides/ug018.pdf
More information on this work-around and potential performance impact is available in the PPC405 Errata PDF files.
10
CPU_213: Incorrect data might be flushed from the data cache.Category: 3
NOTE: This resolution is applied only if the processor version register (PVR) matches PVR: 0x20011430 in PowerPC.
OVERVIEW:
Incorrect data might be flushed from the data cache as a result of a specific sequence of PLB operations between the PPC405 DCU and a PLB slave. Refer to the PDF file for full details.
A work-around is not needed if none of the PLB slaves in the system can return read data acknowledges in back-to-back PLB cycles.
Perform the following if the system contains a PLB slave that can return read data acknowledges in back-to-back PLB cycles:
- Set CCR0 bits 1 and 3.
The CCR0[1] and CCR0[3] bits cause the data cache unit (DCU) to block requests generated by the CPU when certain stages of the DCU control pipeline are full. These bits block further requests when a valid request occupies the corresponding stage in the DCU control flow. When these bits are set, both load and store data cache misses and load noncachables block further requests and might affect performance.
NOTE: When modifying bits 1 and 3 of the CCR0, use code sequence 2 of the CCR0 Programming Guidelines in the PowerPC Processor Reference Guide ( 'ppc_ref_guide' Page 169) in the EDK/doc repository.
11
APU Errata - Blocking UDI Could be Sent Twice to the FCM. This resolution applies only to Virtex-4 FX silicon with PowerPCs that have the following processor version register (PVR) values:hardware stepping 0: 0x20011430
hardware stepping 2: 0x20011470
Category: 3
OVERVIEW:
Occasionally, the APU controller sends the APU blocking instruction twice in a row to the FCM. Usually, this is not an issue when the FCM is simply loading data into a register or returning data from a register to the APU Controller. There can be circumstances in which sending the blocking instruction twice causes errors. One example of a blocking instruction error occurs when reading from a FIFO, and the returned data is missing after the second time the instruction is executed.
Scenario(s) of Occurrence
Branching to a UDI Blocking Instruction
The target of any branch instruction is an APU blocking instruction defined as a User-Defined Instruction (UDI). The UDI is defined by the APU controller's UDI registers. If the APU blocking instruction is decoded by the soft FCM, the error does not occur. The APU instruction must be defined through the APU controller's UDI registers, and it must be of type "Blocking" to manifest an error.
To work around this issue, the target of any branch instruction should be a no-op (or other CPU instruction) before the APU blocking instruction. An example of pseudo code follows:
loop: nop ! added nop here
apu_block Rx
. ! any instructions here
.
.
b loop ! Loops back to nop, not apu_block
UDI Blocking Instruction Stalling in the Decode Stage Due to a Pipeline Stall
Another scenario occurs when an APU blocking instruction (defined as a UDI) is stalled in the Decode stage. This happens when a previous instruction causes the CPU pipe to stall (for example, a load instruction misses in the cache, followed by an add instruction that is dependent on the load, followed by an APU blocking instruction). The load instruction stalls the add instruction until the data is ready (several clock cycles). During this time, the APU blocking instruction is stalled in the Decode stage and can be sent to the FCM two times, instead of only once. This case occurs only when the previous instructions are CPU instructions and not APU instructions.
To work around this issue, insert one non-APU instruction between a stalling instruction and an APU blocking instruction. In the case of a load, insert two non-APU instructions before the APU blocking instruction. Below is an example of pseudo code:
lwz Rx,0(Ry) ! load misses and causes pipe to stall
add Rz, Rz, Rx ! depends on load, stalls next instruction in Decode
nop ! stalls in Decode, prevents apu_block from stalling
apu_block Ry
1:1 PLB Clock with Caching Enabled and the APU (UDI) Blocking Instruction is the Seventh Instruction to be Fetched off the PLB
During an I-Cache miss, the instructions are bundled in groups of eight off the PLB. If the PLB runs at a 1:1 clock ratio with the CPU, a bubble in the pipeline occurs in the Decode stage when placing the seventh instruction. This scenario occurs when the seventh instruction is an APU blocking instruction (defined as a UDI). It does not occur if caching is turned off, or if the PLB clock ratio is 2:1 or above. This also does not occur if the instructions are already in cache. The "bubble" occurs because the instructions are read off the PLB, but the pre-fetch buffers are filled; at the seventh instruction, the decoder reads the instruction from cache instead of off the PLB.
To work around this issue, the PLB must run at 2:1 clock ratio or higher, or disable I-Cache for the APU instruction. Another solution for this scenario is to verify that the address of the UDI blocking instruction is not mapped to the seventh instruction in a cache line. Each cache line is 32 bytes, and the seventh instruction has an offset of 24 decimal.
12
APU Errata - APU load instruction can be flushed incorrectly. This resolution applies only to Virtex-4 FX silicon with PowerPCs that have the following processor version register (PVR) values:hardware stepping 0: 0x20011430
hardware stepping 2: 0x20011470
Category: 3
OVERVIEW:
In the case of an APU load instruction, the instruction can be flushed incorrectly. If a flush arrives while the last word of the load data is in the LWB stage, the load data is sent to the FCM but the FCMWRITEBACKOK signal is never asserted. Furthermore, if the CPU has finished sending the entire load data but the FCM has not yet received all the data and a flush is received by the APU Controller, the load instruction will abort prematurely in the APU controller.
Scenario(s) of Occurrence
Last word of APU load is sent by CPU (in LWB) and a flush is received in the same cycle
In this case, the load finishes correctly, but the APUFCMWRITEBACKOK signal is never sent to the FCM. However, if a flush is received before the last word is in LWB, the instruction is flushed. If the flush is received after all words have been sent by the CPU, the FCMWRITEBACKOK signal is asserted correctly.
All APU load data has been sent by the CPU, the APU load has not finished sending the entire load data to the FCM, and a later instruction causes a flush
In this case, the load instruction will abort in the APU Controller. This causes the FCM to not receive all of its data (in the case of multiple-word loads). This situation is critical because the clock ratio between the CPU and the FCM becomes larger.
One possible way to work around this issue is to insert nops until the APU load is completely finished in the FCM. To do this, you need to take into account the CPU/FCM clock ratio and if the FCM is asserting FCMAPULOADWAIT. The following is pseudo code for this software fix:
apu_qw_load Rz,Rx,Ry ! APU quad word load
nop
nop ! # of nops = clock ratio * # words transferred
. !+ clock ratio * # loadWait used
.
nop
cpu_instr ! instruction can cause flush
Another possible fix requires you to have an APU instruction that does not flush immediately following the APU load. This will prevent any other instruction from getting in a position of causing a flush while the APU load is executing. The following is an example of pseudo code:
apu_qw_load Rz,Rx,Ry ! APU quad word load
apu_nop ! prevents other instructions from flushing
! until apu_qw_load finishes, but does nothing
cpu_instr ! any cpu instruction
13
The return of a cacheline transaction that is not target word first (nontarget word first) can cause data corruption in the PPC405 Core data cache in Virtex-4 FX devices.NOTE: This issue does not occur in Virtex-4 FX100, FX40, FX140, or in devices with PVR 0x20011470.
Category: 3
Scenario(s)
This problem is common when running software on an OPB device that resides in a cached region of the PowerPC:
- Cacheline read transactions initiated from the PowerPC to an OPB slave device are through the PLB2OPB bridge.
- The PLB2OPB bridge returns all cacheline accesses as nontarget word first, which is compliant with the PLB specification.
- The return of a cacheline transaction nontarget word first can cause data corruption in the data cache.
All Xilinx PLB memory controllers and custom PLB cores that use PLB IPIF return cacheline transactions target word first to the PowerPC. As a result, this issue does not occur with PLB devices.
The following are ways to work around this issue:
- If the processor version register (PVR) matches PVR: 0x20011470, the issue has been resolved and no work-around is required.
- If the processor version register (PVR) matches PVR: 0x20011430, you can work around this issue using one of the following:
-- Move the memory controller from OPB to PLB.
-- Disable all cached accesses to OPB devices.
The following is an example of code to read the PVR value:
# include "xpseudo_asm.h"
..
int main(void)
{
Xuint32 Pvrvalue;
Pvrvalue = mfspr (0x11f);
...
}
NOTES:
- The affected devices are Virtex-4 FX devices, including FX12, FX20, FX60 device family members with Processor Version Register (PVR) 0x20011430.
- This issue does not occur in FX100, FX40, FX140, or devices with PVR 0x20011470.
- For more information, see the "Processor Version Register (PVR) Interface (Virtex-4-FX Only)" section of the PowerPC 405 Processor Block Reference Guide located at:
http://www.xilinx.com/ise/embedded/edk_docs.htm
- All Virtex-4 FX Production Devices and CES4 devices have the PVR of 20011470.
- All material with DGQ and higher top mark has PVR 20011470.
14
APU Errata - Potential APU lock-up can occur after a specific sequence of CPU instructions followed by an APU instruction without operands.Category: 3
The FCM/FPU usually receives a nonblocking instruction without operands being sent, and the APUFCMWRITEBACKOK signal is never received by the FCM. At this point, the APU Controller can lock up and the FCM will not receive any more instructions.
OVERVIEW:
This problem occurs only under very specific conditions. First, there is a CPU load that misses in the cache, followed by one or more CPU loads. The last CPU load is then followed immediately by a nonautonomous nonblocking APU/FPU instruction without operands. The CPU load with cache miss followed by at least one more CPU load causes a stall in the PPC405 pipeline until the load data has been received. If the FCM returns FCMAPUDONE before the stall goes away, the APU Controller can lock up. Below is an example of pseudo code in which this scenario occurs:
lwz r3, 0(r1) // this is a CPU load that misses in data cache
lwz r4, 8(r1) // this is another CPU load
apu_nonblock r5 // APU non-blocking instr without source operand
// this instr returns data to r5
// at this point the APU can experience lock-up
This scenario does not occur if the trailing APU instruction is an Autonomous instruction, a Blocking instruction, or a nonblocking instruction with operands. This is specific only to nonautonomous nonblocking instructions without operands.
Software Solution
The best way to fix this scenario through software is to insert a "nop" between the last CPU load and an APU/FPU nonblocking instruction without operands. One way to handle this with a compiler is to insert a "nop" after every CPU load instruction, or you can opt to fix it more intelligently by checking for a CPU load followed by a nonblocking instruction without operands. This method prevents the nonblocking instruction from being sent to the FCM until the PPC405 pipeline hold is over. Below is an example of pseudo code for the software fix:
lwz r3, 0(r1) // this is a CPU load that misses in data cache
lwz r4, 8(r1) // this is another CPU load
nop // prevents possible lock-up
apu_nonblock r5 // APU non-blocking instr without source operand
// this instr returns data to r5
Hardware Solutions
If the instruction is a User-Defined Instruction, not Floating Point, you can simply change the type from nonautonomous nonblocking to nonautonomous blocking. In this case, the FCM must wait until receiving the APUFCMWRITEBACKOK signal before returning data. This change can be made in the UDI configuration register (bits [26:27]=2?b00 for Blocking instead of bits [26:27]=2?b01 for Nonblocking). For more information on the differences between blocking and nonblocking instructions, refer to the PowerPC 405 Processor Block Reference Guide.
If the you cannot change the instruction to blocking (but is still using a UDI (not FPU)), you can make the instruction enable either source operand Ra or Rb even if the operands are not used by the FCM. In this case, the FCM must wait until it receives APUFCMOPERANDSVALID before returning FCMAPUDONE. The FCM can ignore the operand data buses. To make this change, you must set either bit [13] or bit [14] to 1 in the UDI configuration register for this instruction. For more information on changing the execution options of a User-Defined Instruction, refer to the PowerPC 405 Processor Block Reference Guide.
If the previous two hardware solutions are not available because the instruction in question is an FPU instruction, the UDI instruction cannot execute as Blocking, or the FCM cannot wait for the APUFCMOPERANDVALID signal, you can create a WritebackOK timeout counter for any nonblocking instructions without operands in their FCM/FPU. In this case, if the FCM/FPU has not received APUFCMWRITEBACKOK after a large number of FCM cycles (about 50), the FCM should pulse FCMAPUDONE one more time. For example, the FCM has a WritebackOK timeout counter set to 50. When the FCM receives a nonblocking instruction without operands, it begins counting down each clock cycle. If the FCM receives APUFCMWRITEBACKOK, the timeout counter gets reset back to 50. However, if the timeout counter reaches 0, the FCM pulses FCMAPUDONE. At this point, the APU Controller will unlock and execution will resume normally. In some special cases the locked-up nonblocking instruction might not complete 100 percent normally. If you have a system that does not generate external interrupts, there is a condition you must handle if you are using this hardware fix. In some cases, the PPC405 pipeline can flush just after the second FCMAPUDONE. In this case, you cannot receive APUFCMWRITEBACKOK for this instruction, although it has completed normally. If you do not receive the APUFCMWRITEBACKOK signal 2 FCM clock cycles after FCMAPUDONE, either the instruction is still stalled or the pipeline received a flush and you do not receive the signal even though the instruction did finish. To work around this, you can reset the timeout, and if the FCM receives APUFCMINSTRVALID before the timeout, you will know the APU is working normally again.
If you have a system that supports external interrupts, the APU cannot send the APUFCMWRITEBACKOK signal with 100 percent reliability if you are using the timeout method to send a second FCMAPUDONE. If the interrupt causes the PPC405 pipeline to flush the cycle after the second FCMAPUDONE is received, the FCM will receive APUFCMFLUSH in error. Similarly, if the external interrupt causes the PPC405 pipeline to flush the cycle after the pipe hold goes away but before the second FCMAPUDONE arrives, the instruction should be flushed, but the FCM does not receive APUFCMFLUSH.
15
APU Errata - Potential data corruption on first word of double or quad word APU store after specific sequence of CPU instructions.Category: 3
The first word of a double or quad word APU store can be corrupted under certain conditions in the PPC405 pipeline (this also includes Floating-Point double precision store instructions).
Scenario(s) of Occurrence
An APU store instruction of size double or quad word is stalled in the decode stage of the PPC405. If the FCM responds with the data before the hold conditions are over, the first word of the transfer can become corrupted. The following is an example of code that can cause this problem.
lwz r2, 0(r1) // load misses in cache
add r4, r5, r2 // stalls waiting for load to finish
apu_store_double // stalls in Decode stage
This code causes data corruption only if the FCM returns the data to the APU Controller before the stall in the pipeline is gone.
Software Solution
The best way to fix this problem is to make sure that the store instruction is not stalled in the decode stage. To ensure this, a compiler should insert two nop instructions before any APU double or quad word store (includes any FPU double precision store). The following is an example of code that will fix this problem:
lwz r2, 0(r1) // load misses in cache
add r4, r5, r2 // stalls waiting for load to finish
nop // two nops to prevent stall of store
nop
apu_store_double // does not stall in decode
16
APU Errata - Potential APU lock up if APU/FPU load flushed after branch is mispredicted not taken.Category: 3
If an APU or FPU load instruction attempts to execute after a branch is mispredicted not taken, the load instruction is flushed, but the APU can potentially get locked up if the next APU instruction is an autonomous instruction. The FCM usually processes this as a flushed Load instruction, followed by an autonomous instruction, and then no further instructions will arrive.
Scenario(s) of Occurrence
If running at a 2:1 clock ratio or larger, this scenario is possible. This will not occur at a 1:1 clock ratio.
This problem can occur when there is a branch instruction that is mispredicted not taken. The APU or FPU load instruction in the not taken path is flushed because the branch was mispredicted. If the next instruction to sent to the FCM is an autonomous instruction, the APU can lock up. An example of this code is as follows:
any instr
any instr
bne target_addr /* branch conditional, mispredicted */
apu_load /* APU load instr */
any instr
target_addr:
apu_autonomous /* APU autonomous instr, may hang */
Software Solution
The best solution is to make sure the APU load instruction does not get flushed after a branch is mispredicted not taken. The compiler needs to insert a nop in between any branch conditional instruction and any APU load. An example of the modified code is as follows:
instr
instr
bne target_addr /* branch conditional */
nop /* Added nop instr */
apu_load /* APU load instr */
instr
target_addr:
apu_autonomous /* APU autonomous instr will not hang */
Hardware Solution
This problem can also be fixed if you run the FCM interface at a 1:1 clock ratio.
17
Virtex-4 PowerPC 405 - When PPC405 Instruction Cache Parity is enabled, it always Triggers a Machine Check Interrupt.Category: 3
OVERVIEW:
Whenever the Instruction Cache with Parity checking Enabled for the PPC405, CCR1 = 0x0 and CCR0[IPE] = 1, and code is run out of cached memory, a machine check exception is continuously generated.
When read from the machine check interrupt service routine, the MCSR register indicates that an instruction parity error has occurred.
There is no work-around available. Please disable the Parity Checking with Instruction Cache CCR0[IPE] = 0.
18
Virtex-4, Data Cache Parity - When the PPC 405 data cache parity checking is enabled, a machine check can occur.Category: 3
OVERVIEW:
When the data cache parity checking is enabled by setting CCR0[DPE]=1, a machine check with DCU flush parity error, or an imprecise machine check, or both can occur.
This condition does not affect the correctness of the data in the data cache.
Work-around:
There is no work-around available; do not enable data cache parity checking on PPC405, i.e., CCR0[DPE] must be 0 (default/reset value).