• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 102 subscribers
  • Views 1398 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

66AK2H12/06 race condition

RY9983
Guru 10570 points
Other Parts Discussed in Thread: 66AK2H12


Hello,
I am evaluating 66AK2H12/06.
There is race condition in the datasheet.

Since 66AK2H has many master peripherals.
I would like to clarify what kind of master peripherals do we have to mind this condition.

I found following post.
It explains that this workarround is not needed for C66x if it uses MFENCE.
  http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/227184.aspx

Best regards, RY

  • 0
    Guru 10570 points

    Hello,

    If race condition will happen in C66x, I will take care of this workarround.
    I would like to clarify the case of this condition occurs.

    Best regards, RY

  • 0 in reply to RY9983
    TI__Guru* 81335 points
    Hi RY, We are working on you query and will update you soon. Thank you for your patience.
  • 0 in reply to Raja
    Guru 10570 points

    Rajasekaran-san,

    Thank you for your reply.
    I would like to ask my customer to wait a few days.
    Please let me know the time you need.

    Best regards, RY

  • 0 in reply to RY9983
    Guru 10570 points

    Raja-san,
    Can I have any updates? or How soon can you answer this?
    Best regards, RY

  • 0 in reply to RY9983
    TI__Guru* 81335 points

    Hi,

    We apologize for the delay. We are still working on this. We may need another 2-3 days to answer this post.

    Thank you for your patience. 

  • 0 in reply to RY9983
    TI__Expert 6815 points

    Hello RY,

    The text you refer to from the data manuals is part legacy that could be simplified to say

    "A race condition may exist where the coherency of transactions from different masters to on or off-chip memory is desired but not preserved. For example, if master A passes a software message via a buffer in external memory and does not wait for an indication that the write completes before signaling to master B that the message is ready, when master B attempts to read the software message, the master B read may bypass the master A write. Thus, master B may read stale data and receive an incorrect message. A handshaking mechanism should be implemented between the masters to avoid this race condition."

    Let me know if this addresses your concerns.

  • 0 in reply to Aditya
    Guru 10570 points

    Aditya-san,

    Your answer is :
    Master-A have to wait for write complete before signal to master-B. I have understood it.
    But, my question is how master-A to wait for write completes.

    Question)
    a) In the case that C66x core is master-A, it can wait for "write completes" by MFENCE command. Is that correct?
    b) In the case that ARM core is master-A, how can it wait for "write complete"?
    c) How about other master cases, sRIO, PCIe, USB, Ether, EDMA)?

    Best regards, RY 

  • 0 in reply to RY9983
    Guru 10570 points

    Aditya-san,
    Can I have your response?
    If you have any questions, please let me know.
    Best regards, RY

  • 0 in reply to RY9983
    TI__Expert 6815 points

    RY-san,

    Sorry the delay in response. The "wait" mechanism is not the same for all masters as you have pointed out.

    Yes, C66x cores can use MFENCE. For EDMA, the appropriate IPR bit will be flagged to indicate transfer completion.

    The signalling of transfer completion should be outlined in the appropriate peripheral user guides.

  • 0 in reply to Aditya
    Guru 10570 points

    Aditya-san,

    Thank you so much for your response!
    I could understand about C66x and EDMA. Thanks a lot.

    May I ask about ARM core again?
    Does it have any mechanism to know transfer completion?

    Best regards, RY

  • 0 in reply to RY9983
    Guru 10570 points

    Aditya-san,

    Sorry to trouble you.
    Can I see your status?

    Best regards, RY

  • 0 in reply to RY9983
    TI__Expert 6815 points

    RY-san,

    Sorry for the late response. Per my understanding, coherency between both cacheable and non-cacheable accesses is maintained by the ARM subsystem to/from the DDR so this should not be a concern for ARM.

  • 0 in reply to Aditya
    Guru 10570 points

    Aditya-san,

    Thank you so much.
    Your answer means the DDR race condition does not occur in ARM core. Right?

    I know that cache coherent memory access is supported in ARM core.
    But, I would mind whether the DDR race condition is occured between each ARM cores and other SoC.

    Best regards, RY

  • 0 in reply to RY9983
    TI__Expert 6815 points

    RY-san,

    That is correct, the race condition will not occur with ARM.

    If the data written to DDR3 is sufficiently important, then the ARM core can always read it back to verify. The ARM core could also write first to DDR and then trigger the appropriate master to pick up the written data. Conversely, an SoC master could signal an interrupt to the ARM core after the transfer is complete.

    There are other ways to ensure that other SoC traffic is deprecated in priority to the ARM by adjusting the Teranet level priority and/or by assigning the appropriate class-of-service to the master (DDR3 controller feature explained in the UG). Combine that with the fact that the ARM subsystem is "closer" to DDR3 compared to most other masters who have to go through sometimes multiple Teranet fabrics and bridges and compete with other SoC level traffic on the Teranet.

    The first paragraph is more specific and the second paragraph is more generic on traffic shaping. I hope this addresses your concerns.

  • 0 in reply to Aditya
    Guru 10570 points

    Aditya-san,

    I appreciate your strong support.
    Thank you so much!

    Best regards, RY

  • 0 in reply to Aditya
    Guru 10570 points

    Aditya-san,

    Aditya said:

    If the data written to DDR3 is sufficiently important, then the ARM core can always read it back to verify. The ARM core could also write first to DDR and then trigger the appropriate master to pick up the written data.

    Do you have any other ideas to verify ARM write completion?
    Can I use ISB, DSB, DMB instruction instead of "read back"?

    Read back is useful for DDR race condition between ARM and other SoC.
    But, it will waste DDR throughput performance.
    I need some other method to get performance.

    Best regards, RY

  • 0 in reply to RY9983
    TI__Expert 6815 points

    RY-san,

    Yes, that skipped my mind. You can use memory barrier instructions (DMB, DSB, ISB) to synchronize and/or enforce ordering of memory accesses similar to MFENCE on the C66x.

    The ARM Cortex-A Series programmers guide has more details on each of those instructions along with the options that can be specified with the instruction.