• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 4 answers
  • Subscribers 98 subscribers
  • Views 2579 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.

Linux/AM5718: Alternatives to IPC

Sergey Danilov
Intellectual 650 points
Part Number: AM5718

Tool/software: Linux

Hello!

We just tried the MessageQ Linux/TI-RTOS communication example and got the results like ~100usecs per message

In our usage scenario, DSP should be able to process relatively small chunks of data (float arrays sized about 128-256 items) in parallel with a cortex A15 core that receives and prepares data. And in that case we are getting the ARM->DSP data delivery time about x100  of the DSP processing time itself (for one data chunk).

Is there any other way to deliver data from ARM to DSP and start DSP processing that will take significantly lower time overhead? 

I believe we can use shared memory to allocate the data exchange buffer, but we need to let the DSP know that it should start processing the new data

Thanks for your help!

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru 50170 points
    Hi, Sergey,

    The bottom line of the IPC is using shared memory. There are several ways of communicating between ARM and DSP which described in the document, processors.wiki.ti.com/.../Processor-sdk-MultiWay-of-ARM-DSP-Communication. For your application, I wonder if Big Data would help. It is a variant of IPC, but with bigger data buffer.

    Rex
  • 0 in reply to Rex Chang
    Intellectual 650 points

    Hi Rex,
    Our main scenario for DSP usage is very frequent processing of small data chunks.
    Thus my main question is - what is the fastest method to activate some DSP task (from arm cortex a15) to start processing the data?
    The data delivery itself is another question, sorry for non clear question.

  • 0 in reply to Sergey Danilov
    TI__Guru 50170 points
    Hi, Sergey,

    MessageQ goes through kernel context and interrupts DSP through IPCGR to notify DSP. So, the latency will be the kernel processing which is in tens of usec. The messageQ is a secure and fastest available mechanism TI developed, unless the user space application writes to the share memory and interrupts the DSP. What latency are you expecting for your application?

    Rex
  • 0 in reply to Rex Chang
    Intellectual 650 points
    Thanks!
    tens of usec will probably work nice in case if it will be possible to send an arm-to-dsp messages using a non blocking call through some kind of queue .
    So, if the latency is 50usec, then, for example, 100 messages sent one after another with 10usec period will pass in (100 x 10usec) + 50usec, rather than 100 x (10usec + 30usec)
    I hope my explanation is not very cryptic =)

    We need to make about 200-300 "calls" to DSP every 1.5 ms.
    In a very simplified way it looks like we are constantly reading some data, for example from SATA disk, in a Linux task that wakes up every ~1.5 ms, and this task should pass this data to the DSP in small chunks for processing (about 200-300 chunks)
    So it would be perfect to organize the processing as a pipeline
  • 0 in reply to Sergey Danilov
    TI__Guru 50170 points
    Hi, Sergey,

    The latency is in the kernel context which applies to every message. If the messages are sent from user space as I mentioned in my earlier post, and DSP gets interrupt, it will be like your calculation. Instead of the kernel latency, it is the latency of copying to memory.

    Rex
  • 0 in reply to Rex Chang
    Intellectual 650 points
    Hi Rex,
    Sorry, I'm really struggling to clearly understand your message.

    Could you please describe this part of your message in more details.
    - "If the messages are sent from user space as I mentioned in my earlier post, and DSP gets interrupt, it will be like your calculation. Instead of the kernel latency, it is the latency of copying to memory. "
    I reviewed the info at processors.wiki.ti.com/.../Processor-sdk-MultiWay-of-ARM-DSP-Communication and unfortunately I can't find a way how to interrupt a DSP form a linux user space application (without a latency)
  • 0 in reply to Sergey Danilov
    TI__Guru 50170 points
    Hi, Sergey,

    User space application, I meant, to write the application without using IPC. The application copies the data to share memory and trigger interrupt to DSP to process it. In that way, the messages don't go through kernel context.

    Rex
  • 0 in reply to Rex Chang
    Intellectual 650 points
    Hi Rex,
    Thank you very much
    BTW - may be you know - if there is some high level API for a IPCGR interrupt usage on linux side?
    I've fond this topic at the moment e2e.ti.com/.../503640
    but probably I can use some part of IPC framework just for enabling/triggering the interrupt?
    Thanks!
  • 0 in reply to Sergey Danilov
    TI__Guru 50170 points
    Hi, Sergey,

    AM57x devices don't have IPCGRx registers. It uses Mailbox event interrupt. The interrupt is the input to DSP_INTC. Please refer to Chapter 19 Mailbox in AM572x TRM, and Chapter 5.3 DSP SS Functional Description.

    Rex
  • 0 in reply to Rex Chang
    Intellectual 650 points

    Hi Rex,
    Am I understanding correctly that there is no any code example or c/c++ framework for this purpose (interrupt a DSP core from linux app without any additional latency)?

    Sorry for asking it again, but I can't get a clear answer and it seems strange the whole IPC framework don't have a function for DSP interruption form an arm user space app without other complicated additions (and added latency) I believe that it is pretty common task when linux app needs to wake up a DSP (ti-rtos) task

  • 0 in reply to Sergey Danilov
    TI__Guru 50170 points

    Hi, Sergey,

    User space applications are beyond the support scope on this forum. You may want to refer to kernel mailbox and see if you can trigger the interrupt by accessing the mailbox registers from user space.

    Rex