Intel® Arria® 10 SX Device Errata and Design Recommendations

ID 683161
Date 8/03/2022
Public
Document Table of Contents

4.1.9. 794074: A Write Request to an Uncacheable, Shareable Normal Memory Region Might be Executed Twice, Possibly Causing a Software Synchronization Issue

Description

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 condition might happen when the write request is followed by another write into the same naturally doubleword-aligned memory region, without a DMB between the two writes.

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.

This erratum requires the following conditions:

  • A write request is performed to an uncacheable, shareable normal memory region.
  • Another write request is performed into the same naturally doubleword-aligned memory region. This second write request must not be performed to the exact same bytes as the first store.

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.

Impact

This erratum might have implications in a multi-master system where control information is passed between several processing elements in memory using a communication variable, such as a semaphore. In this type of 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. This erratum means that the clearing of such a communication variable might occur twice. This error 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 Shareable memory
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.

Workaround

There are several possible workarounds:

  • 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 that the clear of any communication variable is complete.
  • Ensure there is no other data using the same naturally aligned 64-bit memory location as the communication variable:
    ALIGN 64
    communication_variable DCD 0 
    unsed_data DCD 0
    LDR r1 = communication_variable
  • Use a Store-Exclusive to clear the communication variable, rather than a non-Exclusive store.

Category

Category 3