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# 24177

8.2i EDK - The FPU on the APU can experience potential lock-up


Potential APU lock-up can occur after a specific sequence of CPU instructions followed by an APU instruction without operands. The FCM/FPU usually sees a Non-blocking 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. 


Scenario of Occurrence 


This problem will manifest 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 Non-autonomous Non-blocking 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. 


This scenario will not occur if the trailing APU instruction is an Autonomous instruction, a Blocking instruction, or a Non-blocking instruction with operands. This is specific only to Non-autonomous Non-blocking instructions without operands.


Software Solution 

The best way to fix this scenario through software is to insert a nop in between the last CPU load and an APU/FPU Non-blocking instruction without operands. One possibility of handling this with a compiler is to insert a nop after every CPU load instruction, or you can choose to do it more intelligently by checking for a CPU load followed by a Non-blocking instruction without operands. This prevents the Non-blocking instruction from being sent to the FCM until the PPC405 pipeline hold goes away. 


Hardware Solutions 

If the instruction is a User-Defined Instruction, not Floating Point, the user can simply change the type from Non-autonomous Non-blocking to Non-autonomous 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]=2b00 for Blocking instead of bits [26:27]=2b01 for Non-blocking). For more information on the differences between Blocking and Non-blocking instructions please refer to the PowerPC 405 Processor Block Reference Guide. 


If the user cannot change the instruction to be Blocking, but is still using a UDI (not FPU), the user 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 will then need to wait until it receives APUFCMOPERANDSVALID before returning FCMAPUDONE. The FCM can ignore the operand data buses. To make this change, the user needs to 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, please 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, the user can create a WritebackOK timeout counter for any Non-blocking 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 Non-blocking 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. 


For other relevant information on this problem, please see (Xilinx Answer 23874)


These problems have been fixed in the latest EDK 8.2i Service Pack, available at: 

The first service pack containing the fix is EDK 8.2i Service Pack 2.

AR# 24177
Date Created 09/04/2007
Last Updated 05/20/2014
Status Archive
Type General Article