Filter
Top Products
14 Intel® PXA27x Processor Family Specification Update
Errata
E3. CORE: Performance monitor unit counts, using performance
monitoring event number 0x1, can be incremented erroneously by
unrelated core events.
Problem: The performance monitor unit can be used to count cycles in which the I-cache cannot deliver an
instruction. Performance monitoring event number 0x1 is used for this. According to EAS text, the
only cycles counted should be those due to an I-cache miss or an I-TLB miss. The following
unrelated events in the core also cause the corresponding count to increment when event number
0x1 is being monitored:
• Any architectural event (e.g. IRQ, data abort)
• mstr instructions that alter the CPSR control bits
• Some branch instructions, including indirect branches and those mis-predicted by the BTB
• CP15 mcr instructions to registers 7, 8, 9, or 10 which involve the I-cache or the I-TLB
Each of the items above might cause the performance monitoring count to increment several times.
The resulting performance monitoring count might be higher than expected if the above items
occur, but never lower. The performance monitor unit uses ic_instValid_qf2h. This signal asserts
not just at the proper time, but also due to the events described above.
Implication: TBD
Workaround: There is no way to obtain the correct number of cycles stalled due to I-cache misses and I-TLB
misses. One component of the unwanted noise may be filtered out: extra counts due to branch
instructions mis-predicted by the BTB. The number of mispredicted branches can also be
monitored using performance monitoring event 0x6 during the same time period as event 0x1. The
mispredicted branch number can then be subtracted from the I-cache stall number generated by the
performance monitor to get a value closer to the correct one. Depending on the nature of the code
monitored, this workaround might have limited value.
Status: No Fix
E4. CORE: In SDS mode, back-to-back memory operations where the first
instruction aborts might hang.
Problem: If back-to-back memory operations occur in SDS (special debug state, used by ICE and debug
vendors) and the first memory operation gets a precise data abort, the first memory operation is
correctly cancelled and no abort occurs. However, depending on the timing, the second memory
operation might not work correctly. The data cache might internally cancel the second operation,
but the register file may have scoreboarded registers for that second memory operation.
The effect is that the part might hang (due to a permanently scoreboarded register) or that a store
operation might be cancelled incorrectly.
Implication: TBD
Workaround: In SDS, any memory operation that might cause a precise data abort should be followed by a write-
buffer-drain operation. This operation precludes additional memory operations from being in the
pipe when the abort occurs. Do not use load multiple/store multiple, which might cause precise
data aborts.
Status: No Fix
E5. CORE: Lock aborts resulting from I-cache or I-TLB lock operations
are not presented properly on the trace interface.
Problem: This problem affects only processors that use the core’s trace interface. An I-cache or I-TLB lock
operation that results in lock abort creates a unique internal pipeline signal timing that causes