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.

Preemption mode for C6678 DSP

Dear all,

  These days I was learning about the memory protection about the C6678 DSP and the Keystone II SoC, I got confused by two question.

 1) I saw from here http://processors.wiki.ti.com/index.php/MAD_Utils_User_Guide that indeed the C6678 hardware support running multiple (different) applications at the same time on different cores, is it possible that when one application is running, another application preempts the running application? If so, how?

2)So from my understanding, when running multiple applications, all the applications needs to be loaded to the DSP cores at the same time (I'm not sure if I'm right). Say if I have two applications, one is running on two cores of the DSP, when it's running, can I load the second application to other cores (e.g. the 3rd and 4th or 6th and 7th)? This means that I don't need to load all the applications to DSP cores at the same time to run, and the applications don't have to be finished at the same time. If so, what's the support?

Thank you so much for any help.

Jie

  • Hi,

    1 - There's a few number of mechanisms used to do perform communication between cores. See SYS/BIOS and IPC user guides:

    BIOS: www.ti.com/lit/pdf/spruex3

    IPC: www.ti.com/lit/pdf/sprugo6

    So, one core can send some kind of signal to another core that will lead to a thread preemption in the core that received the signal.

    2 - This is not usual, but I don't know if it's possible or not.

    Regards

  • Hi  Johannes,

      Thank you so much for your replying.

      Regarding the preemption question, if one thread is preempted by another thread, is there any context switch? So does BIOS handle the context switch, the preempted thread will recover later or just be abandoned? 

      And do you have any resources that could check if the second question could be achieved? Because I didn't find any information talking about this, so any possible links or documents would be helpful, i can check them.

    Thanks,

    Jie

  • Hi,

    Yes BIOS takes care of it. Suppose you're running a task, then this task gets preempted by another task with higher priority of by an interrupt, after the action of the higher priority thread is done, the processing will return to the task that was preempted.

    I may look for, but let me tell what I consider a typical application. Usually your cores will be synchronized (look for Ipc_start), so you must load all working cores in order to get them syncronized. After this, they can start running any application, that can be completely different from other core's program, but if they share some kind of resource, they must have some kind of communication to avoid conflicts.

    Regards

    J

  • Hi Johannes,

      Yeah, it makes much sense in BIOS when switching between tasks with different priorities. Do you know if it's possible to do that without BIOS? Or even with different applications. As far as I know, the SYS/BIOS needs to be compiled with application to get it run on DSP cores, so that task switching is happening within actually one applications. What if one application is running (no matter with or without BIOS) on one core, then another application comes and wants to preempt the running application? Is that possible on such DSP? I think this approach will treat the DSP as a general multi-core CPU, but sometimes the multi-core DSP is acting like a general CPU, right?

    Thanks,

    Jie

  • Hi Johannes, 

      What do you mean cores will be synchronized? What if my different applications are totally separate ones with no possible or needed communication? Can I loaded them separately at different time? 

    Thanks,

    Jie

  • Hi,

    When you synchronize and attach them to each, they can communicate, but they don't need too. I think it doesn't work if you don't synchronize them, but I don't know what happens in the layer below that makes a synchronized application work and the un-synced one, doesn't.

    Regards

    J