• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1396 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.

Hardware semaphore support in BIOS?

Marvin Liang
Expert 3015 points

Hi,

   I am trying to implement a application scenarios with hardware semaphore between two different cores based on TCI6608 device (multi-core device).

  Task A is in core No.0; Task B is in core No.1;  When task A got the HW Sem No.1, it can be ready and task B is pending; when task A release the HW Sem No.1, task B can be ready and task A is pending.

  Has the application scenario supported in BIOS 6 already? If yes, could you give a example?

   If NOT, I have to implement a ISR for the hardware semaphore and maintain/switch the task state, it should be complex. Do you have any idea/suggestion for use HW semaphore with BIOS on multi-core condition? And does TI have any plan that using hardware semaphore to support task synchronization in different cores?

Thanks a lot.

   Marvin

  • 0
    Genius 4375 points

    Hi Marvin,
    I think you are asking how to implement a blocking multi-core semaphore using the hardware sempahores on TCI6608.  This functionality requires using the HW semaphores in 'indirect access mode'. When the lock is not available, a request to take the lock is added to a request queue (FIFO length = # of processors on device).  At that point the Task that is requesting the hardware semaphore can pend on a BIOS Semaphore since the lock isn't available yet.  Your ISR will execute when the hardware semaphore is free again--it should post the BIOS semaphore and unblock the task.

    Neither BIOS nor IPC ship with support for using HW Semaphores in 'indirect access mode'--you would have to implement this yourself (as described above).

    Alternatively, IPC has built-in support for using HW Semaphores in 'direct-access mode' where a core will spin while trying to take a lock that is taken by another core.  The philosophy behind this choice of operation is that it is more efficient when the lock is to be held for very short amounts of time (i.e. to read/write to shared memory, etc).  If you find that this will be suitable for your needs, refer to the 'GateMP' module documentation in IPC for more information.

    Regards,
    Shreyas

  • 0 in reply to Shreyas Oppanthaya
    TI__Expert 3015 points

    Shreyas,

          Thanks a lot for your explanation.

         I think GateMP module in IPC should be a good idea. I still have some questions about GateMP module.

        1. You said IPC has built-in support for using HW semaphores in 'direct-access mode' . Does it mean if I invoke GateMP_Params_init/GateMP_create with GateMP_RemoteProtect_SYSTEM in TCI6608, the GateMP instance will connect to HW semaphores automatically which means IPC initialize HW semaphores 'direct-access mode' ? No other operation need for HW semaphores by user side?  If that, how does GateMP module works on TCI6486, as you known, TCI6486 no HW semaphores.

        2. Presume there are Task A on cores No.0 and Taks B on core No.1 use a same GateMP instance. When task A entered the GateMP instance, task B is blocking, in that time frame, can any other tasks (such as task C)in core No.1 got the CPU?

        3. Which IPC version include GateMP module can support TCI6608? I used IPC 1_21_02_23, I am not sure whether it is the lastest version.

    Best Regards.

       Marvin

  • 0 in reply to Marvin Liang
    Genius 4375 points

    Marvin,

    Regarding your three questions:

    1) GateMP uses device-specific 'delegates' that interact with the locking mechanisms provided by the device.  Since TCI6608 offers hardware sempahores, GateMP will internally use the 'GateHWSem' IPC module.  The user does not need to have any knowledge of this--GateMP will automatically select the correct delegate which in turn performs all required register configuration.  The user doesn't need to take any steps to use HW Semaphores in direct-access mode. 

    The TCI6486 devices uses atomic access monitors and IPC has a different GateMP delegate (GateAAMonitor) for this mechanism.  Again, from the application's perspective, the gate delegate doesn't need to be known and is configured/used under-the-covers.

    2) A GateMP can be configured using 3 levels of local protection level (Hwi-level, Swi-level and Task-level).  When you successfully return from GateMP_enter, you have also entered the local gate that either disables Hwi's, Swi's or Task's from preempting the current thread.  In your scenario, Task 'B' is spinning, not blocking (a small but important difference).   If your GateMP is configured with Task level protection, the task scheduler will execute while Task 'B' is trying to acquire the lock. Therefore, Task C will be scheduled to run if it has a higher priority than Task 'B'. 

    Note that the GateAAMonitor delegate used on TCI6486 does not permit pre-emption while spinning on acquiring the lock.  However, GateHWSem supports this.

    3) You will have to update to IPC 1.22 for C66 support.  You can download it at http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/index.html.

    Regards,

    Shreyas

  • 0 in reply to Shreyas Oppanthaya
    TI__Expert 3015 points

    Thanks a lot for your help. It is very helpful. I am investigating IPC, any further questions, i will let you know.