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.

synchronizing access to shared resources on omapl138

Other Parts Discussed in Thread: OMAPL138

Hello,

I would like to know which is the best way to synchronize access to a shared resource between the arm and dsp on the omapl138. In our application the arm writes several peripheral registers and the dsp reads out those registers asynchronously. While the arm updates those registers the dsp is not allowed to read out the values and while the dsp reads out the values the arm is not allowed to update the registers. So we need a kind of semaphore mechanism. What is the best way to achieve this? We are thinking of a simple spin lock mechanism without using communication interrupts.

On the arm processor there is a swp instruction which can read out memory content into a register and update the memory content with the values of another register. This instruction is atomar, e.g. while the memory content is read out and updated no other processor has access to this memory location. With this swp instruction a semaphore mechanism can be implemented. Is there a similar instruction on the dsp side which allows memory read and memory write in an atomar way?

Thanks for your efforts

  • There is no atomic operation on the DSP equivalent to the ARM swp instruction.  I would recommend trying to implement Peterson's algorithm.

    Regards, Daniel

  • Hi Daniel,

    thanks for your answer. I also already thought about using the Peterson's or Dekker's algorithm for implementing a spin lock mechanism. In Peterson's algorithm and also in Dekker's algorithm it is mentioned that care must be taken when memory accesses are reordered. This can either happen by reordering the instructions or by reordering memory accesses during runtime without modifying the instruction sequence. Do we have to care about this?

    Thank you

  • You won't need to worry about reordering instructions as these cores don't do that, but I think reordering of memory accesses is maybe conceivable, though I think that memory accesses coming from the same system master at the same priority will complete in order.  I will try to verify this. The issue arises because once the memory access request leaves the core and goes onto the system bus, it enters a queue in the bus architecture.I think the queue can reorder accesses from different system masters, but I'm not sure about from the same master.

    Regards, Daniel

  • Daniel, Marc,

    That's right.  The memory system will guarantee *perceived* ordering from a given processor (or master) to a given memory location. 

    A few other notes:

    The Dekker's Algorithm wikipedia article mentions the need to use "volatile" keyword to ensure that the compiler doesn't optimize away the write operation.  Keep this in mind...

    Also, it is likely simpler to place the shared variables in non-cached memory.  Otherwise, you will need to do a cache writeback operation to synchronize the shared variables (potentially modified in cache) to the common shared memory.

    I don't think this should be an issue ... but note that writes are "buffered" aka "posted", so the instant that the DSP does the store it takes some time for the store to actually land in memory.  As noted in the first point, a subsequent load from the same processor will always see the proper data, thus "in order".  The fact that the other processor just sees the data a little later shouldn't be an issue.

    Regards
    Kyle

  • Hi there,

    I just implemented the Peterson's Algorithm. The locking mechanism works fine.

    Thanks for your efforts and have a nice day.....

    Marc