SWRZ150A December   2024  – October 2025 AWR2544

 

  1.   1
  2. 1Introduction
  3. 2Device Nomenclature
  4. 3Device Markings
  5. 4Advisory to Silicon Variant / Revision Map
  6. 5Known Design Exceptions to Functional Specifications
    1.     MSS#25
    2.     MSS#27
    3.     MSS#28
    4.     MSS#29
    5.     MSS#30
    6.     MSS#33
    7.     MSS#40
    8. 5.1  MSS#49
    9. 5.2  MSS#52
    10. 5.3  MSS#53
    11. 5.4  MSS#54
    12. 5.5  MSS#55
    13. 5.6  MSS#56
    14. 5.7  MSS#57
    15. 5.8  MSS#58
    16. 5.9  MSS#59
    17. 5.10 MSS#60
    18. 5.11 MSS#61
    19. 5.12 MSS#62
    20. 5.13 MSS#63
    21. 5.14 MSS#64
    22. 5.15 MSS#65
    23.     MSS#68
    24.     MSS#71
    25. 5.16 ANA#12A
    26.     ANA#37A
    27.     ANA#39
    28.     ANA#43
    29.     ANA#44
    30.     ANA#45
    31.     ANA#47
    32.     ANA#59
  7.   Trademarks
  8. 6Revision History

5.15 MSS#65

Single MFENCE Issue

Revision(s) Affected:

AWR2544

Description:

The MFENCE instruction is used to stall the instruction fetch pipeline until the completion of all CPU-triggered memory transactions.

Under very particular circumstances, MFENCE may allow the transaction after the MFENCE to proceed before the preceding STORE completes.

For example,

  1. STORE_A

  2. MFENCE

  3. TRANSACTION_B

The MFENCE implementation stalls the CPU until the memory system asserts that there are no transactions "in flight," i.e. it is idle. This prevents the CPU from proceeding to TRANSACTION_B before STORE_A completes. A small window exists where the memory system prematurely asserts that it is idle when STORE_A moves from L1D to L2 when it is otherwise idle. This can cause incorrect program behavior if TRANSACTION_B must occur strictly after STORE_A. For example, suppose STORE_A writes to DDR3, and TRANSACTION_B triggers an EDMA which reads the location written by STORE_A. MFENCE should guarantee that STORE_A commits before the EDMA executes, so that the EDMA sees the updated value. Due to the issue in this advisory, TRANSACTION_B could trigger the EDMA before STORE_A commits, so that the EDMA sees stale data.

Workaround(s):

Replace a single MFENCE with two MFENCEs back to back. This remedies the issue by resuming the stall in the case where the memory system prematurely indicated that it was idle when STORE_A passed from L1D to L2.

  1. STORE_A
  2. MFENCE
  3. MFENCE
  4. TRANSACTION_B

Note on coherence operations: For the following advisory, double MFENCE can also be used as a workaround in addition to the workarounds already listed:

Note that the second advisory listed above does not cover L1D and L2 block and global writebacks. If L1D and L2 block and global writebacks are followed by an MFENCE and a transaction that depends on the completion of the writebacks, the double MFENCE workaround should be used.

Please also note that the current release of the MCSDK software package does not include this workaround. It will be included in a future release

Note: Special Considerations for Trace. When trace generation is expected through software that includes the use of MFENCE, there are additional requirements for the workaround. Trace generation for MFENCE requires that every occurrence of the MFENCE instruction be followed with a NOP and a MARK instruction. The workaround is described in this white paper.