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.

Parllelizing code between ARM968 and C64X+ on DM6467 EVM

Other Parts Discussed in Thread: CCSTUDIO

Hi All,

I am running my video decoder on DM6467 EVM. RIght now all my code is running on C64X+.

I want to make my code run in parllel (Scheduling) between  ARM and C64X+ subsystem.

Please can any one give inputs on this. Thanks in advance

Pradeep

 

 

  • Pradeep,

    Linux OS runs things in parallel by default.  When it calls on DSP to do some work, it does not wait idle; it continues to work on other Linux threads that may have work to do.  Therefore to ensure parallelization, you would need to design your application in a multithreaded fasion.

    Can you provide more details, perhaps a scenerio, of how you envision work being done in parallel among the two processors?  If so, perhaps we can offer more advice.

  • HI Juan,

    Right now I am trying to run the code on WIndows OS.

    Please advice me what all the steps I need to take care in order to make the code run in parllel between ARM and C64X+ on Windows OS as this is my requirement.

    Thanks in advace.

     

     

  • Scinerio

    For example: I want to trigger my HDVICP APIs (ex: CALC and LPF with 2MB delay) on ARM, and all the pre processing things for LPF and post processing for the CALC (with 2MB delay) should be done in parallel (on C64X+). Considering the case how to do scheduling between ARM and C64X+

    Thanks

    pradeep

  • pradeep sakhamoori said:
    Right now I am trying to run the code on WIndows OS.

    I assume you mean Windows CE here? For the most part Windows CE is supported through third party companies so we do not do too much work with it, but I suspect it has a similar threading structure to Linux, in that you should be able to have code running in parallel just by using multiple threads as Juan was describing for Linux. For help on doing this you may want to contact your third party Windows CE BSP provider, or look through the Windows CE documentation.

  • Pradeep,

    I am not too familiar with WinCE, but I would assume it is also a multithreaded OS, meaning it will jump to do work on another thread from time to time.  If you want finer control like telling the system to work in these two particular threads in parallel all the time, then you may need to bump these up in priority ( what Linux refers to as Real-time threads..., not sure if there is a similar mechanism in WinCE).  I would contact Microsoft for WinCE related OS questions...  Where did you get your WinCE distribution from ?

  • pradeep sakhamoori said:

    I am running my video decoder on DM6467 EVM. RIght now all my code is running on C64X+.

     I assume the code that is running on the C64X+ uses DSP/BIOS operating system.

    pradeep sakhamoori said:

    I want to make my code run in parllel (Scheduling) between  ARM and C64X+ subsystem.

    Please can any one give inputs on this. Thanks in advance

    The application needs to be designed to run on two processors. On DSP, DSP/BIOS operating system can be used and on ARM Linux operating can be used.

    The communication between the ARM and DSP will be through DSP/Link module.

  • Hi,

    I am running my code on WindowXP not on WinCE..sorry for not giving clear picture in my previous post..

    hi nag, If i am right...as per your answer..I can run my code in parallel between ARM and C64X+ using DSP/BIOS..

    If so can you please help me in getting the right doc which explains abt DSP/BIOS.

    Thanks in advance

  • ok, I guess I am a litle confused still about your setup.

    FYI, DSP/BIOS is the operating system normally found on our DSP CPUs (DM6467 is an SoC which includes two CPUs, an ARM and a 64x+ DSP), DSP/BIOS does not run in the ARM.

    That said, I think it is pretty safe to assume you are using DSP/BIOS on DSP side (FYI, you are if you are using codec engine framework included with DVSDK); but I am still a little confused about what you are running on the ARM side.  I think I jumped the gun when you mentioned Windows and assumed WinCE, but not that you mention WindowsXP, I assume you are referring to your host enviroment and not the ARM on DM6467.  Does this mean you are running Linux as originally assumed on ARM? 

    If you are running Linux, by virtue of creating a multithreaded program (our DVSDK demos do this), the Linux scheduler will do the parallelizing for you.  If you want finer control of when certain threads will run (keep in mind that some may not consider Linux a real-time OS), you can use real-time threads in Linux (they run at higher priority).  Whenever one of the Linux threads calls on DSP side to do work, ARM will not sit idle waiting for DSP to finish if it has other threads to work on... 

    Please confirm what is running on the ARM and feel free to ask additional question if this is not clear.

  • I am trying to do the same thing. I have the DM6467 EVM. The DM6467 chip on it has an ARM926J subsystem which runs linux OS, and the C64x+ DSP subsystem which runs its own DSP/BIOS. The DSP subsystem on DM6467 has a C64x+ core and two coprocessors each have one ARM968 inside (a separate ARM). I want to load my DSP program using the CCStudio v3.3 tool (which runs on Windows XP) onto the EVM and run. How do I program & run the second ARMs (ARM968) inside the DSP subsystem of my DM6467 EVM using the CCS?

  • The main problem I see with this approach is that CCS 3.3 is not Linux aware; therefore, you cannot run Linux on ARM and connect CCS to ARM at the same time.  You will need to run Linux on ARM and perhaps use CCS to only connect to DSP side running DSP/BIOS. 

    Another question I have is how do you plan to do ARM to DSP communication?  Do you plan on using codec engine (and underlying DSPLINK) to do this communication or will you be developing your own proprietary software stack for this...?

  • Is the second arm (ARM 968) in the DSP subsystem also running Linux? How do we program it? Not the main ARM as part of the ARM subsystem (ARM 926).

     

  • I believe what you are referring to the second ARMs on DM6467 are actually the 2 HDVICPs; these are closed and only accessible by codecs provided by either TI or our ASPs.  The primary reason for this is they are quite complex to program (no OS running on them) and expose TI intellectual property; you can try contacting your local sales representative (http://focus.ti.com/general/docs/salesrep/salesrep.tsp?DCMP=TIHomeTracking&HQS=Other+OT+home_b_salesrep) and state your business case and see if he can get you access to HDVICP collateral (will likely require NDA)..., but my understanding is that these are fairly closed.

  • Exactly. These are part of the HDVICP coprocessors. And yes, we are trying to develop our own codec engine. Thanks...

  • As Juan suggests you probably need to work with your local TI contact for further information on the HDVICP, as he mentions they are not generally meant to be programmed by end developers. On the other hand I believe you can connect to them with CCS (they are in the JTAG scan chain and all), though I have never tried it, I would not be suprised if they have limitations to their debug capabilities as they were not really meant for wide development.

  • Hi,

    Thanks to every one for replying to my query.

     

     

  • You would have to use the IPC module of HDVICP to make the internal ARM(968) and DSP run in parallel mode. Note that the internal ARM can only trigger the accelerators not initialize or prepare any kind of data. Data preparation and accelerator initialization has to be done by the DSP. The internal ARM should run in a continous polling mode (keeps waiting for an interrupt from DSP) and once the DSP has done all the data preparation for a particular SS, it sends an interrupt to ARM and then the ARM triggers the required accelerator and upon completion of task it sends back a signal to DSP notifying the same.

    The above can be achieved with/without DSP/BIOS on the EVM. 

  • Dear Vallabha:

    Does ARM968 sends an interrupt signal to DSP? DSP goes to an interrupt vector address?

    Can DSP use any interrupt methods to wait HDVICPs' signals, but not polling?

     

    If I use DSP/BIOS, I could create multi-tasks for polling, preparing data, and do other jobs on DSP side.

    But I worry about DSP/BIOS will draw down the DSP's optimization and pipeline performance.

    Could you give me some advices.

    Thanks a lot.

     

  • There are 2 IPC modes supported on DM6467 

    1.Polling Mode   - DSP polls ARM968 for completion

    2.Interrupt Mode - ARM interrupts DSP after completion

    The preferred method can be used while initializing/triggering the hardware (IPC module).

    I think using the DSP/BIOS is the best way to manage the various tasks you mentioned on the DSP side. But if codec operation is the only process running on the DSP, then I would prefer not using the DSP/BIOS.

    -Regards

    Vallabha 

     

  • Dear Vallabha:

    I use IPC API to initialize and send some data to ARM968,

    but I can't receive any interrupt signal at all.

    Should I set the INTC?

    I use HDVICP_TI_Ipc_hostinit() to configure ARM968 to interrupt mode, and run the encoder code on DVEVM.

    But I can't receive any one.

    Could you give me some hint, thanks a lot.

      

  • Vallabha,

    The ARM968 in the Hdvicp can interrupt the DSP by raisng a SW interrupt. Have you programmed the ARM 968 to write into the INTC register for this?

     

    Regards,

    Kapil