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.

idk protocol/ethercat use of dsb/dmb

In the EtherCAT protocol stack included with the IDK, this code is often seen:

tiescbsp.c 1232:

ASSERT_DMB
ASSERT_DSB

From ARM's "Barrier Litmus Tests and Cookbook" page 6:

The DSB instruction is a special memory barrier, that synchronizes the execution stream with memory accesses.
The DSB instruction takes the required shareability domain and required access types as arguments.
If the required shareability is Full system then the operation applies to all observers within the system. A DSB
behaves as a DMB with the same arguments, and also has the additional properties defined here.

---

What is the rationale for the extra DMB instruction seen here?

From what I can see, in every case DSB provides the same behavior as a DMB, so the DMB is superfluous. Further, in many cases, the code is observing memory only, so a DMB would appear to be sufficient.

Finally, the use of function-like macros (e.g. ASSERT_DSB) without parenthesis is a bit jarring to my eyes. ASSERT_DSB -- if not for the name -- looks like a literal. 

  • Hi Dave,
     
    I will remove the unnecessary posts from your threads and move them to the RTOS forum.
  • Hi,

    Thank you for review and feedback. Memory barrier was added because PRU-ICSS memory is not configured as strongly ordered but shared device type (non-cached, buffered) for performance...

    DSB is used in places after we invoke API from PRUSS driver, as the driver when accessing PRU-ICSS address space does not issue a DMB explicitly. I went by following definition http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14041.html

    • A Data Synchronization Barrier (DSB) completes when all instructions before this instruction complete.
    • A Data Memory Barrier (DMB) ensures that all explicit memory accesses before the DMB instruction complete before any explicit memory accesses after the DMB instruction start.

    You are right that DMB looks redundant in this case, its just one instruction so I was just being safe. Cleaner solution might be to use DMB within PRUSS driver API.