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

Zynq-7000 SoC, APU - A write request to Uncacheable, Shareable normal memory region might be executed twice, possibly causing a software synchronization issue


Under certain timing circumstances specific to the Cortex-A9 microarchitecture, a write request to an Uncacheable, Shareable Normal memory region might be executed twice causing the write request to be sent twice on the AXI bus.


This might happen when the write request is followed by another write into the same naturally aligned double-word memory region, without a DMB between the two writes. The second write request must not be performed to the exact same bytes as the first store. The repetition of the write usually has no impact on the overall behavior of the system, unless the repeated write is used for synchronization purposes.

A write request to Normal memory region is treated as Uncacheable in the following cases:

  • The write request occurs while the Data Cache is disabled.
  • The write request is targeting a memory region marked as Normal Memory Non-Cacheable or Cacheable Write-Through.
  • The write request is targeting a memory region marked as Normal Memory Cacheable Write-Back and Shareable, and the CPU is in AMP mode.

This behavior might have implications in a multi-master system where control information is passed between several processing elements in memory using a communication variable, for example a semaphore. In such a system, it is common for communication variables to be claimed using a Load-Exclusive/Store-Exclusive, but for the communication variable to be cleared using a non-Exclusive store. Due to this malfunction, the clearing of such a communication variable might occur twice. This might lead to two masters apparently claiming a communication variable, and therefore might cause data corruption to shared data.

A scenario in which this might happen is:

MOV       r1,#0x40     ; address is double-word aligned, mapped
; in Normal Non-cacheable Shareablememory
Loop: LDREX      r5, [r1,#0x0] ; read the communication variable
CMP       r5, #0       ; check if 0
STREXEQ   r5, r0, [r1] ; attempt to store new value
CMPEQ     r5, #0       ; test if store succeeded
BNE       Loop         ; retry if not
DMB                    ; ensures that all subsequent accesses
                       ; are observed when gaining of the
                       ; communication variable has been observed
; loads and stores in the critical region can now be performed
MOV       r2,#0
MOV       r0, #0
DMB                    ; ensure all previous accesses are observed
                       ; before the communication variable is cleared
STR       r0, [r1]     ; clear the communication variable with normal store
STR       r2, [r1,#0x4]
; previous STR might merge and be sent again, which might
; cause undesired release of the communication variable.

This scenario is valid when the communication variable is a byte, a half-word, or a word.

Detailed Work-arounds:

There are several possible work-arounds:

1) Add a DMB after clearing a communication variable:

STR    r0, [r1]     ; clear the communication variable
DMB                 ; ensure the previous STR is complete

Also, any IRQ or FIQ handler must execute a DMB at the start to ensure as well the clear of any communication variable is complete.

2) Ensure there is no other data using the same naturally aligned 64-bit memory location as the communication variable:

communication_variable DCD    0
unused_data            DCD    0
                       LDR    r1,= communication_variable

3) Use a Store-Exclusive to clear the communication variable, rather than a non-Exclusive store.


Work-around:There are several, refer to Detailed Work-arounds.
Configurations Affected:Systems that use the CPUs.
Device Revision(s) Affected:All. No plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 SoC Silicon Revision Differences.

Revision History

05/16/2013 - Initial release



Answer Number 问答标题 问题版本 已解决问题的版本
47916 Zynq-7000 SoC 器件:芯片修订差异 N/A N/A
AR# 52034
日期 06/14/2018
状态 Active
Type 设计咨询