• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 932 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.

The access authority to DDR of the two cores in the OMAP-L138.

Xingwang Xu
Prodigy 50 points
Other Parts Discussed in Thread: OMAP-L138

Hi,

   These days I am studying on the DSPlink of the OMAP-L138 chip, I've got a linux running on the ARM side, and then I want to use dsplink to boot the dsp core. In order to use dsplink, is the DSP/BIOS OS necessary on the dsp side? As if I get the two cores working together using DSPLink, how can I take control of the access authority to the DDR ram on the arm and dsp cores? for example, if the arm side and dsp side try to access to the same address of DDR ram, the data bus conflict may occur. How can I take control of this prblem, or does the Dsplink can avoid this kind of problems happen?

   Thanks for your help.

   Regards,

   Saul.

 

  • 0
    TI__Genius 14545 points

    Xingwang, 

       Yes - DSP/BIOS is needed on the DSP to run DSP/Link.I'm not sure about the memory authority, however you may find what you are looking for in the following Wiki Article on DSP/LINK FAQ

  • 0
    TI__Genius 17355 points

    Saul,

    In terms of accessing the contents of the memory, there won't be any kind of hardware conflicts.  As requests come over the internal bus to the memory controller, the memory controller will respond to access requests in the order requests are received.  But if you wish to share a portion of memory between cores, you should make sure that both cores are not manipulating any particular data structure at the same time. Depending on whether caches are enabled and other factors, you could quickly get to a point where both cores have an inconsistent view of the memory contents and changes made by one core could be overwritten by changes from the other core. 

    You can use the MPCS (multi-processor critical section) capability of DSPLink to lock resources so only one core is allowed (via a software checking mechanism, not hardware) to use a resource at a time.  In other words, you as the application/system architect will need to use software conventions to prevent issues.

    Regards, Daniel

  • 0
    TI__Genius 17355 points

    Xingwang Xu said:
    how can I take control of the access authority to the DDR ram on the arm and dsp cores? for example, if the arm side and dsp side try to access to the same address of DDR ram, the data bus conflict may occur. How can I take control of this prblem, or does the Dsplink can avoid this kind of problems happen?

    What you are asking about is how the two cores can correctly use a shared memory region without conflicts.  From a data bus/hardware perspective, there will never be a conflict - each read or write request from either core will be queued on the bus and will happen.  However, from a software perspective, this could be very bad, as one core may write data and then expect it to be there, and it won't know that the data has been overwritten by the other core. To eliminate conflicts, you can partition any shared memory into parts that one core is allowed to write to, and parts that the other core is allowed to write to.  If you don't want to do that then you can use something like Peterson's algorithm to allow true shared memory usage (basically this provides a multi-processor locking mechanism that prevents two cores from simultaneously using the same memory resource).

    Anyways, these are all software conventions/mechanisms that you would have to implement.

    Regards, Daniel