AT697

1. Multiplier/Divider Failure on Negative Operands Treatments
    The embedded multiplier/divider block can generate wrong values when negative operands are used.This Multiplier/Divider failure is due to a LEON2 VHDL model error.
Workarounds
Do not use the -mv8 flag when compiling the project (under LECCS environment).
2. Call Return Address Failure with Large Displacement
    CALL instruction saves the return address in an FPU register rather then in an IU register when the call address is larger than 16 Mbyte (forward) or 2 Mbyte (backward).This "Call Return Address" failure is due to a LEON2 VHDL model error.
Workarounds
None
3. Byte and Half-word Write to SRAM Failure when Executing from SDRAM
     If an application is executing in SDRAM, byte- and half-word writes to SRAM can fail if the EDAC or read-modify-write cycles are used.This "SRAM Write access" failure is due to a LEON2 VHDL model error
Workarounds
None.
4. Wrong PC stored during FPU exception trap
When a trap is taken by the processor, the program counter (PC) is stored into %l1 of the trap window and the next program counter (nPC) is stored into %l2.This operation works correctly for all traps except FPU exception (trap type 0x08).During FPU exception, the nPC is erroneously stored into both %l1 and %l2. This means that the exception handler can not return and re-execute the trapped FPU instruction. During normal operation, this is not a problem since re-executing the trapped instruction would just cause the instruction to trap again.
Workarounds
None
5. Single-stepping over SWAP and LDSTUB instruction locks AHB bus
    During a debug session using the debug support unit (DSU), it is possible to perform singlestepping. If an attempt to single-step a SWAP or LDSTUB instruction is made, the AHB bus will be locked and further debugging will be impossible.The reason for this behaviour is that SWAP and LDSTUB instruction perform a read-modify-write cycle which locks the AHB bus to insure atomicity. When such an instruction is single-stepped, the lock signal will be kept active even after the processor enters debug mode, thereby preventing further bus arbitration. Since the communications with the DSU is done over the AHB bus, further debugging is impossible and the device is in principle dead-locked. This state can only be exited by deasserting the DSUEN signal (resuming execution) or asserting the RESET signal.
Workarounds
None
6. Divide overflow will not clear zero flag
    The divide instructions SDIVCC and UDIVCC set the integer condition codes (negative, overflow and zero) with respect to the final result. When a divide overflow occurs, a pre-defined non-zero value is returned, the overflow bit is
set and the zero bit is cleared. However, under certain overflow conditions, the zero bit is wrongly set even though the result is always nonzero.
Workarounds
None
7. Register file fault-injection incorrectly implemented
The LEON2-FT processor has a fault-injection function which allows the insertion of errors into the 7-bit EDAC checksum
that protects each word of the register file. When fault-injection is enabled, the EDAC checksums are supposed to
be XORed with the value of the TCB field in the %asr16 register. The fault injection is instead implemented as follows:
check bits[6:4] of dual-port ram 1 (corresponding to %rs1 operand) are XORed with TCB[2:0]
check bits[6:4] of dual-port ram 2 (corresponding to %rs2 operand) are XORed with TCB[5:3].
Workarounds
Fault-injection is still possible as intended, but the injection software must be aware of the difference bit location of the injected errors. Here is a simple example for the test of a single error in register file %rs1
! 0x32 =
! register file test enable
! tcb[2:0] = 0x4
! tcb[5:3] = 0x1
mov 0x32, %l1
mov %l1, %asr16
! clear %l3
! => write 0x0 to %l3
! forces 0x08 as checkbit for %l3 (error insertion in %rs1 dual-port ram)
mov %g0, %l3
! disable EDAC test mode
mov %g0, %asr16
! access to %l3 as %rs1 operand
! => single error detection and correction
add %l3,%l2,%l1
8. 'Data cache tag' error counter counting error
      The data tag error counter doesn't show the correct number of errors.If a data tag error is detected on a write cycle, the data cache is not updated but the tag error is counted. Since the tag is not written the error remains, and on sub-sequent writes to the same address the error will be counted again.It is also possible that a tag error occurs on the same address offset as an on-chip register. A tag error will then be reported every time the register is accessed, since the access is not cacheable and the tag will not be written. If the application software does not use this particular location of the cache, the error will never be removed but continously reported.
Workarounds
Applications that do not use all locations of the cache should monitor the error counters and perform a flush operation
when an error has been registered.