UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 30579

PowerPC 440, APU - When the floating-point execution is disabled in the PowerPC 440 processor, but enabled in the APU controller, and an FPU instruction is executed, the processor can generate a spurious program exception

Description

Keywords: PPC440, TLB, FPU, program exceptions, floating-point

When the floating-point execution is disabled in the PowerPC 440 processor, but enabled in the APU controller, and an FPU instruction is executed, the processor can generate a spurious program exception, instead of an FPU-unavailable exception.

Refer to (Xilinx Answer 30529) for a list of other Errata.

Solution

Category: 3

Description

It is possible for the PowerPC 440 to generate spurious "program exceptions" whenever the floating-point execution is disabled in the Machine State Register (MSR) by setting MSR[FP] bit to 0. This can occur under the following conditions:
- MSR[FP] bit is set to 0 to signify that there is no FPU available.
- APUCONTROL[31] bit is set to 1, enabling the APU controller.
- APUCONTROL[8] bit is set to 0 to enable decoding of FPU instructions by the APU controller.

When an FPU instruction is decoded, the instruction is recognized by the APU controller and since MSR[FP] bit is 0, the CPU should cause an "FPU-unavailable exception". However, when the instruction is an FPU load/store and is held in the Decode and Issue Stage (DISS0/1) for more than one clock cycle, in some cases the APU controller and the CPU do not recognize this instruction. Consequently, the CPU causes a "program exception" instead of "FPU-unavailable exception".

Even if all of the conditions described above are true, the CPU might still not issue a spurious program exception. It is still possible that the correct FPU-unavailable exception is generated.

Software Solution

One way to work around this problem is to make the "program exception" handler execute twice for instructions that cause the "program exception". Since the spurious "program exception" is always followed by a correct "FPU-unavailable exception", by requiring every program exception to be executed twice, the spurious program exceptions can be filtered out. This requires changes to the exception handlers for the "program exception" (IVOR6) and the "FPU-unavailable exception" (IVOR7). A global (Boolean) variable can be added in the exception handling code. This variable is cleared in the "FPU-unavailable exception" handler. The "program exception" handler checks to see if the variable is clear (0) or set (1). If clear, it sets the variable and returns to the code that created the exception. As a result, any instruction that creates a "program exception" causes the program exception handler to be executed a second time. If the global variable is set, the handler continues with the execution of the "program exception". If the instruction is an FPU instruction, and it succeeds the second time, it will create an "FPU-unavailable exception" and the exception state is reset.
AR# 30579
Date Created 03/20/2008
Last Updated 04/23/2008
Status Active
Type General Article