• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 101 subscribers
  • Views 5728 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.

Is there example(s) how to use shared memory as a heap between ARM(Linux) and DSP (BIOS) on TCI6638K2K

Vesa Peltonen
Intellectual 525 points

Hi all,

I want to achieve the following:

To have a section in MSMC shared memory that will act like a heap, that both ARM(running Linux)  and DSP (running SYS-BIOS) can access it. Currently only ARM needs to do allocations from that heap. The allocation size will vary.

(I've IPC/MessageQ communication already in place between ARM and DSP where I can pass the pointer to allocate memory to the DSP for data processing.)

Is there any examples/documents that can point me how to do this? 

There is some code in the image processing demo where DDR3 is used to share data between ARM and DPSs, but in my case the amount of date is smaller, and I assume  that the shared memory would be much faster than to use DDR3?

Thanks a lot!

  • 0
    Intellectual 525 points

    Just noticed that the "DDR heap" allocation/de-allocation in the image processing demo is done by doing message roundtrip to DSP twice.

    1. ARM sends IPC message to DSP with requested size and alingment

    2. DSP allocates the memory from heap and returns the address in IPC message

    *** data is processed by using another messageQ ***

    3. ARM send another message to DSP to free the allocated memory (step #2)

    Is this the correct way to do this? Looks for me quite complicated.

  • 0 in reply to Vesa Peltonen
    TI__Mastermind 45025 points

    Hi Vesa Peltonen,

    I need some more information in order to better help you.

    Are you using the MCSDK?  If so, which version?  Also, please list your versions of IPC and SYS/BIOS.

    Vesa Peltonen said:
    Just noticed that the "DDR heap" allocation/de-allocation in the image processing demo

    Can you please tell me more about this demo?  Which software product does it come from?

    Steve

  • 0 in reply to Steven Connell
    TI__Mastermind 45025 points

    Also, I wanted to point you to this thread which seems similar to your question:

    http://e2e.ti.com/support/embedded/bios/f/355/t/291105.aspx

    Steve

  • 0 in reply to Steven Connell
    Intellectual 525 points

    Hi Steve, others,

    I'm using MCSDK 3.0.1.12, IPC 3.0.2.26 and BIOS 6.35.4.50.

    The image processing demo I'm referring to is the one which comes with the MCSDK, located here:
    mcsdk_bios_3_00_01_12/demos/image_processing/ipc/evmtci6638k2k/

    The demo is explaned on this wiki page. The variant that I'm looking at is the keystone 2 one. http://processors.wiki.ti.com/index.php/MCSDK_Image_Processing_Demonstration_Guide 

    My application architecture is quite simple. The host (ARM in this case) is giving jobs to do for each DSP one at the time. I've that in place already by using IPC/MEssageQ on both Linux and BIOS.

    What I'm missing is the using the MSMC shared memory to share data between ARM and DPS efficiently. This data is too big to be put inside IPC messages.  This is marked in the below image with red.

  • 0 in reply to Vesa Peltonen
    TI__Intellectual 2745 points

    Vesa:

    I think the msgcom APIs might be extremely beneficial for this application.  The function calls are very similar to MessageQ but it can take advantage of MSMC when communicating between ARM-DSP (though by default it uses DDR, it is configurable in application).

    I have not tried using it in conjunction with MessageQ however, that would be interesting.  I'm attaching an example which does bi-directional communication between ARM-DSP, as well as a guide briefly explaining how to use/run it.

    One concern with using msgcom though...Do all the DSPs have to communicate back to the ARM (bidirectional)?  Or are they purely slaves that receive data.  Currently there is a software limitation on the number of msgcom channels that can be created - will be changed in next release.  You would maybe have to do some clever scheme, such as passing all data from ARM to DSP0, then using MessageQ or some regular IPC method to share this data to other DSPs.

    I hope this helps, I really think msgcom is a good way to go to solve your issue.

    Sincerely,

    John Demery

    Msgcom Example For Forum.zip
  • 0 in reply to John Demery
    Intellectual 525 points

    Thanks John for this input!

    I'll give a look into msgcom implementation with respect to shared memory usage.

    I've another question:

    I noticed that messageQ round-trip for ARM-DSP-ARM without any processing takes about 100 usec (TCI6638).  Do you know if this is "regular" overhead? Do you know if msgcom is faster? What are the transport layers used in both cases?

    Thank you!

    -vesa

  • 0 in reply to Vesa Peltonen
    TI__Intellectual 2745 points

    Vesa:

    Msgcom should be faster, it utilizes the Multicore Navigator as a transport which should result in the lowest round trip time.  I am currently trying to confirm what MessageQ uses when communicating between ARM and DSP and will get back to you when I am certain.

    I hope this helps Vesa!

    Sincerely,

    John Demery

  • 0 in reply to John Demery
    Intellectual 525 points

    Hi all,

    Where I can find any bench-marking figures for ARM-DSP communication with both MessageQ and MsgCom implementations?

    I've manage to get both of them working, but the round-trip times are huge. I suspect that there might be something wrong in my test code:

    • MessageQ ARM-DSP-ARM roundtrip takes about 100 micro seconds.
    • MsgCom ARM-DSP-ARM takes about 800 usec with polling and 2000 usecs with blocking call. 

    (I tested DSP-DSP communication and the times were around 20 usecs). 

    Thanks for any input on this!

  • 0 in reply to Vesa Peltonen
    TI__Intellectual 2745 points

    Vesa:

    IPC benchmarks are located here: http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Inter-Processor_Communication_.28IPC.29. though I think it only has DSP to DSP

    Msgcom benchmarks are not available yet but you could modify the unit tests found in the syslib directory to gather that information. 

    If you could post your sample code that would be helpful!

    Sincerely,

    John Demery

  • 0 in reply to Vesa Peltonen
    TI__Intellectual 1840 points

    You might want to look at Linux Utils/CMEM package provided as a part of MCSDK 3.x package (please see release notes from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/4_00_00_06/exports/linuxutils_4_00_00_06/linuxutils_4_00_00_06_ReleaseNotes.html). You can configure different pools of memory and manage them from ARM. You can also get physical pointer of the allocation and pass it to DSP. I think it will fit to your usecase.

    Regards

    Sajesh

  • 0 in reply to John Demery
    Intellectual 550 points

    Hello John,


    I need your help please,


    Im trying to re-compile this code you uploaded, for the DSP side, but Im having to many problems in different areas.

    Most of problems I think already manage to solve them, but by now Im having some linking issues I cannot solve.

    undefined                          first referenced                                                                                                    
      symbol                                in file                                                                                                         
     ---------                          ----------------                                                                                                    
     Netfp_setupCascadingFailInfo       /scratch/jimenez/CSS2/syslib_3_00_00_04/packages/ti/runtime/netfp/lib/K2/ti.runtime.netfp.ae66<netfp_cascading.oe66>


     Netfp_setupFailInfo                /scratch/jimenez/CSS2/syslib_3_00_00_04/packages/ti/runtime/netfp/lib/K2                /ti.runtime.netfp.ae66<netfp_cascading.oe66>


     queueRingMultipleProcessWriterTask         ./main_core0.obj                                                                                                    
     writerControlTask                                             ./main_core0.obj            

    error #10234-D: unresolved symbols remain
    error #10010: errors encountered during linking; "Core0_msgCom_tmdxevm6638lxe_UnittestProject_little.out" not built

    The linker.cmd has these (and obviously more) includes:

    -l"/scratch/jimenez/CSS2/syslib_3_00_00_04/packages/ti/runtime/netfp/lib/K2/ti.runtime.netfp.ae66"

    -l"/scratch/jimenez/CSS2/pdk_keystone2_3_00_03_15/packages/ti/csl/lib/k2h/c66/ti.csl.ae66"

    and also, I already include the same libraries in the File Search Path of the C6000 Linker configuration.

    Im using:

         -- CCS 5.5.0.00077

        -- IPC 3.0.4.29

        -- PDK_Keystone2 3.0.3.15

        -- NDK 2.22.2.16

        -- SA LLD 2.0.2.00

        -- SYS/BIOS 6.37.1.24

        -- System Analyzer 1.4.0.06

        -- SysLib  3.0.0.04

        -- XDAIS 7.21.1.07

    With the RTSC configurarion target as follows:


    TARGET: ti.targets.elf.C66

    Platform: ti.platforms.evmTCI6638K2K

    Could you please tell me how to fix those undefined symbols? I would be very thankful if you could.

    Regards,

    Ronny