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

Zynq-7000 AP SoC, APU - Speculative Cacheable Reads to Aborting Memory Regions Clear the Internal Exclusive Monitor, can Lead to Livelock

Description

When a cacheable read receives an external abort, the aborted line is allocated as invalid in the Data Cache, and any allocation in the Data Cache clears the internal exclusive monitor. Therefore, if a program executes a LDREX/STREX loop, with the DSB instruction within, and it keeps on receiving an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds.

The issue happens in systems that might generate external aborts in answer to cacheable memory requests. There are two work-arounds: turn on the branch prediction or remove the DSB in the middle of the LDREX/STREX sequence.

Solution

Impact:

Minor

Work-around:

Turn on the branch prediction or remove the DSB in the middle of the LDREX/STREX sequence.

Configurations Affected:

Systems that use one or both processors.

Device Revision(s) Affected: All, no plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 AP SoC Silicon Revision Differences



On Cortex-A9, when a cacheable read receives an external abort, the aborted line is allocated as invalid in the Data Cache, and any allocation in the Data Cache clears the internal exclusive monitor. Therefore, if a program executes a LDREX/STREX loop which keeps on receiving an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds, leading to a possible processor livelock.

As an example, the following code sequence may exhibit the issue:

loop LDREX 
... 
DSB 
STREX 
CMP 
BNE loop 
...
LDR (into aborting region)

The LDREX/STREX does not succeed on the first pass of the loop, and the BNE is predicted, so the LDR afterwards is speculatively executed and the processor keeps on executing:

LDR to aborting region (this speculative LDR now appears "before" the LDREX & DSB) 
LDREX 
DSB 
STREX 

The LDR misses in the L1 cache, and never gets allocated as valid because it is aborting.

The LDREX is executed, and sets the exclusive monitor.

The DSB is executed. It waits for the LDR to complete, which aborts, causing an allocation (as invalid) in the Data Cache, which clears the exclusive monitor The STREX is executed, but the exclusive monitor is now cleared, so the STREX fails.

The BNE may be predicted again, so the LDR is speculatively executed again, and the code loops back on the same failing LDREX/STREX sequence.

Impact Details

The issue happens in systems which may generate external aborts in answer to cacheable memory requests. If the program reaches a stable state where the internal exclusive monitor keeps on being cleared in the middle of the LDREX/STREX sequence, then the processor may encounter livelock.

In practice, this scenario seems very unlikely to happen because several conditions may prevent the erratum to happen:

  • Usual LDREX/STREX code sequences do not contain any DSB, so that it is very unlikely that the system would return the abort answer precisely in the middle of the LDREX/STREX sequence on each iteration
  • Some external irritators (e.g., interrupts) can happen and cause timing changes which can exit the processor from livelock.
  • Branch prediction is very usually enabled, so the final branch in the loop will usually be correctly predicted after a few iterations of the loop, preventing the speculative LDR to be issued, so that the next iteration of the LDREX/STREX sequence will succeed.

Work-around Details

There are two work-arounds for this issue:

  • Turn on the branch prediction.
  • Remove the DSB in the middle of the LDREX/STREX sequence. If a DSB is truly required, it is strongly recommended to place it before the LDREX/STREX sequence, and implement the LDREX/STREX sequence as recommended by the ARM architecture.

Linked Answer Records

Master Answer Records

Answer Number Answer Title Version Found Version Resolved
47916 Zynq-7000 AP SoC Devices - Silicon Revision Differences N/A N/A
AR# 47586
Date Created 05/24/2012
Last Updated 05/22/2013
Status Active
Type Design Advisory
Devices
  • Zynq-7000
  • Zynq-7000Q
  • XA Zynq-7000