• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 100 subscribers
  • Views 457 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: A53 <-> R5F exclusive access support on shared DDR and MSRAM

Hiroki Hoshina
Prodigy 120 points

Part Number: AM6442
Other Parts Discussed in Thread: AM2434

Could you please confirm whether Arm exclusive accesses can be used reliably for cross-core shared-memory synchronization on AM6442?

Background:
- We are interested in shared-memory communication between Cortex-A53 and Cortex-R5F, and also some shared data visibility for Cortex-M4F.
- For the M4F side, we only need to share 32-bit data.
- For the A53 <-> R5F path, we would like to exchange 64-bit data if that is supported.
- If 64-bit data exchange is not supported or not guaranteed for A53 <-> R5F shared memory, we would also like to confirm whether 32-bit data exchange is supported and recommended instead.

For clarity, the type of Arm exclusives we have in mind is:
- Cortex-R5F: 64-bit exclusives such as LDREXD / STREXD (or 32-bit LDREX / STREX if only 32-bit is supported)
- Cortex-A53: 64-bit exclusives such as LDXR / STXR (or 32-bit word exclusives if only 32-bit is supported)

- We would like to understand this for both shared DDR and shared on-chip SRAM (called MSRAM in MCU+ SDK documentation). 
- We reviewed the public MCU+ SDK / IPC / SPINLOCK documentation, but we could not find a clear AM6442-specific statement about global exclusive monitor support (or equivalent support) for A53/R5F shared-memory exclusive accesses on DDR or MSRAM.
- We understand that HW SPINLOCK is available on AM6442. However, in our application, the measured time around the lock/unlock path appears longer than expected, so we are checking whether Arm exclusive accesses can be used as an alternative.

Could you please confirm the following points?

1. Does AM6442 implement a global exclusive monitor, external global monitor, or any equivalent SoC-level mechanism for shared-memory exclusive accesses between A53 and R5F?

2. Are Arm exclusive accesses supported across A53 <-> R5F on shared DDR memory?

3. Are Arm exclusive accesses supported across A53 <-> R5F on shared MSRAM?

4. For the A53 <-> R5F path:
   - is 64-bit shared data exchange supported using Arm exclusive accesses?
   - if 64-bit is not supported or not guaranteed, is 32-bit shared data exchange supported and recommended?

5. For the M4F side:
   - we only need 32-bit shared data visibility / exchange
   - is 32-bit shared data exchange supported for M4F with shared DDR and/or MSRAM?
   - if there are any restrictions for M4F compared to A53/R5F, please clarify

6. If supported, under what memory attributes are exclusive accesses expected to work correctly?
   For example:
   - Normal + Shareable + Non-cacheable
   - Normal + Shareable + Cacheable
   - any limitations related to Inner/Outer Shareable, MMU/MPU settings, cache enable state, write-back/write-through, etc.
   - in particular, are exclusive accesses expected to work correctly on DDR and on MSRAM when the region is configured as Normal Shareable Non-cacheable?

7. If Arm exclusives are not guaranteed for A53 <-> R5F shared memory on AM6442, should the HW SPINLOCK module be considered the only TI-recommended hardware primitive for cross-core mutual exclusion?

8. If there is any relevant TRM section, application note, or previous E2E thread for this topic, could you please share it?

We would like to confirm this before finalizing the shared-memory synchronization design.

Thank you.

  • 0
    TI__Guru 64608 points

    Hi,

    I am checking the above details. Please allow some time to revert back.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 120 points

    Hi Tushar-san,

    Thank you very much for checking into this — we really appreciate your support.

    Even if not all of the points can be confirmed at once, any information you are able to share as it becomes available would be very helpful for us. Also, if you have an estimated timeframe for when more details might be available, please feel free to let us know.

    Thank you again for your assistance.

    Best regards,
    Hiroki Hoshina

  • 0
    TI__Guru 64608 points

    Hi Hiroki-san,

    Thanks for your patience. I have checked internally and got the information that all the initiators, peripherals and DDR are connected via CBASS interface and User does not need to take care of the exclusive control. If an access to same memory point has been made by different initiators, CBASS arbitration will decide that only one initiator to access the memory and the other has to wait until it finishes.

    Please refer the image below.

    The CBASS interface arbitrates the transaction based on priority from high to low. If the transactions going to the same end point have the same priority, then the CBASS uses round robin method for these transactions.

    the CBASS IP provides QoS block to allow the user to program the transaction’s attributes such as priority level, ASEL coding and orderID. for more info, please refer DRIVERS_QOS 

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 120 points

    Hi Tushar-san,
    Thank you very much for the detailed explanation and for checking this.

    I will review the information you shared, including the CBASS priority and arbitration behavior, and confirm the behavior on our side. Based on the outcome, I will proceed accordingly—either consider this item resolved or follow up with any additional questions if needed.
    Thanks again for your support.

    Best regards,
    Hiroki Hoshina

  • 0 in reply to Hiroki Hoshina
    TI__Guru 64608 points

    Hi Hiroki-san,

    Thank you for the above update. Will look forward to hear from you.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 120 points

    Hi Tushar-san,

    Thank you for following up, and thank you again for your detailed explanation regarding CBASS arbitration and QoS.

    After reviewing the information you shared, the arbitration and priority aspects are now clear.

    However, I realized that one architectural point related to ARM exclusive access semantics across processor subsystems still remains unclear, so I would like to ask one additional question for confirmation.

    Could you please confirm whether ARM exclusive access–based atomic read-modify-write operations are supported on AM64x devices for shared memory (DDR or on-chip SRAM such as OCMC SRAM, as applicable)?

    Specifically, we are considering the following sequence:

    1. A Cortex-A53 core performs an exclusive load to address X.
    2. A Cortex-R5F core performs a normal CPU write to the same address X in between.
    3. The Cortex-A53 core performs the corresponding exclusive store to address X.

    In this scenario, is it guaranteed on these devices (as implemented) that the exclusive store on the Cortex-A53 core will fail?

    In other words, is the exclusive monitor state coherently maintained and invalidated across the Cortex-A53 and Cortex-R5F subsystems on these devices?

    In addition to the Cortex-A53 Left right arrow Cortex-R5F case, could you also please clarify whether ARM exclusive access semantics are supported in the following cases on AM64x devices:

    • Cortex-A53 Left right arrow Cortex-A53 (between multiple A53 cores)
    • Cortex-R5F Left right arrow Cortex-R5F (between multiple R5F cores)
    • Any case involving the Cortex-M4F core (for example, Cortex-A53 Left right arrow Cortex-M4F or Cortex-R5F Left right arrow Cortex-M4F)

    If possible, could you also indicate separately whether support differs by access width:

    • 32-bit exclusive access (e.g., LDREX/STREX in AArch32)
    • 64-bit exclusive access (e.g., LDREXD/STREXD in AArch32, or 64-bit LDXR/STXR where applicable)

    My understanding is that CBASS arbitration controls transaction ordering and arbitration, but does not by itself provide cross-subsystem ARM exclusive access semantics, so I would appreciate your confirmation on this point as well.

    Best regards,
    Hiroki Hoshina

  • 0 in reply to Hiroki Hoshina
    TI__Guru 64608 points

    Hi Hiroki-san,

    Apologies for the delay here. Please refer  RE: AM2434: AM2434: Data Abort on ldrexd during 64-bit atomic write to Shared MSRAM  response to know about exclusive atomic operation on R5F core. 

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 120 points

    Hi Tushar-san,

    Thank you for your previous clarification.

    From the referenced thread, I understand that 64-bit exclusive accesses (e.g., LDREXD/STREXD) are not supported for shared MSRAM, and may also not be supported for DDR. We will take this into account.

    However, I did not find any explicit mention of 32-bit exclusive accesses in the referenced thread.

    Following up on this, could you please clarify whether 32-bit exclusive accesses (LDREX/STREX) are supported on shared memory (MSRAM and/or DDR) on AM64x devices?

    As per my earlier question, this refers to the standard ARM exclusive access semantics across cores.

    Thank you very much for your support.

    Best regards,
    Hiroki Hoshina

  • 0 in reply to Hiroki Hoshina
    TI__Mastermind 23795 points

    Hi Hiroki-San,

    As mentioned in the thread shared by  , This limitation is dues to AM2434 interconnect/AXI bus not supporting the Global Exclusive Monitor. So 32-bit exclusive accesses (LDREX/STREX) are also not likely to be supported.

    Still I can do a test to confirm this, you can expect an update by Thursday EOD.

    Best Regards,

    Meet.

  • 0 in reply to Meet Thakar
    Prodigy 120 points

    Hi Meet-san,

    Thank you for your clarification.

    I agree with your explanation that the limitation is likely due to the lack of Global Exclusive Monitor support in the AM2434 interconnect/AXI bus.

    However, my understanding is that the confirmation in the referenced discussion was specifically about 64-bit exclusive accesses.

    Therefore, I believe it may not be sufficient to conclusively determine the behavior of 32-bit exclusive accesses based on that alone.

    I really appreciate your willingness to perform a test to confirm this for 32-bit accesses.

    Thank you very much for your support.

    Best regards,
    Hiroki Hoshina

  • +1 in reply to Hiroki Hoshina
    TI__Mastermind 23795 points

    Hi Hiroki-San,

    Hiroki Hoshina said:
    I really appreciate your willingness to perform a test to confirm this for 32-bit accesses.

    I tested this out and the behavior of this is similar to 64-bit access, this will only work for R5 internal access (cache/TCM) and will trigger an abort for MSRAM/DDR access.

    Best Regards,

    Meet.

  • 0 in reply to Meet Thakar
    Prodigy 120 points

    Hi Meet-san and Tushar-san,

    Thank you very much for your support and detailed clarifications.

    Meet-san, I especially appreciate the time taken to perform the test and confirm the behavior.
    The result that both 32-bit and 64-bit exclusive accesses are not supported for shared MSRAM/DDR is very helpful for our design considerations.

    Tushar-san, thank you as well for your continuous support and coordination throughout this discussion.

    With this understanding, we will proceed by assuming that atomic operations using ARM exclusive accesses are not available for shared memory across cores, and will design our synchronization accordingly.

    Thank you again for your great support.

    Best regards,
    Hiroki Hoshina