• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 917 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 SysLink a zero-copy driver

Ketan_Patel
Intellectual 975 points
Other Parts Discussed in Thread: SYSBIOS

From Customer: 

Is SysLink a zero-copy driver – in other words, does SysLink copy the buffer once and pass the pointers to the application, or is the buffer copied multiple times as it traverses the IPC across layers?

  • 0
    TI__Genius 12025 points

    Ketan Patel,

    In most cases, SysLink is a zero-copy driver. However, it does depend on the device and which module is being used. Most devices supported by SysLink have shared memory accessible to all processors. Most transport layers are implemented as zero-copy. For example, MessageQ, ListMP, RingIO, etc. typically use a zero-copy implementation.

    For a precise answer, please find out what device and module the customer is using.

    Also, be aware that cache maintenance is often an overlooked performance cost. If the customer is trying to do performance analysis, the cache configuration/usage will play a large role.

    ~Ramsey

  • 0 in reply to Ramsey
    TI__Intellectual 975 points

    Ramsey,

    The device is the DM8148.

  • 0 in reply to Ketan_Patel
    TI__Genius 12025 points

    Ketan Patel,

    For the DM8148, the default SysLink implementation is zero-copy for MessageQ, ListMP, RingIO.

    ~Ramsey

  • 0 in reply to Ramsey
    TI__Intellectual 975 points

    Ramsey:

    In follow on to your cache management question:

     

    "We want not to have Caching Enabled for the Shared Region so that the data will be written immediately to DDR.

    Does SysLink and SysBios allow us to configure the certain Memory Block to be not Cached on DM8148 device ?

    We need to do this from both A8 and C674x modules."

    -Ketan Patel

  • 0 in reply to Ketan_Patel
    TI__Genius 12025 points

    Ketan,

    Yes, this is possible. When using SysLink on the ARM (Cortex-A8), by default all shared regions are mapped as non-cached. So, you don't need to do anything there. On the DSP, by default all shared regions are cached. So, you need to configure the shared region as non-cached. Have a look at the ex02_messageq example (download the latest SysLink release, look in examples folder). This example maps both SR_0 and SR_1 as non-cached. Here are some notes.

    1. The DSP MAR bits control the cache property of memory. Each bit controls a 16 MB block, so you must align your shared regions on 16 MB boundaries.

    /*  configure external memory cache property
     *
     *  8000_0000 - 9FFF_FFFF  2000_0000  ( 512 MB) Cache.MAR128_159
     *  --------------------------------------------------------------------------
     *  8000_0000 - 8DFF_FFFF   E00_0000  ( 224 MB) --------  don't care
     *  8E00_0000 - 8E00_FFFF     1_0000  (  64 KB) SR_0      no-cache      MAR142
     *  8E01_0000 - 8EFF_FFFF    FF_0000  ( ~15 MB) --------  no-cache      MAR142
     *  8F00_0000 - 8FFF_FFFF   100_0000  (  16 MB) DSP_PROG  cache enable  MAR143
     *  9000_0000 - 9FFF_FFFF  1000_0000  ( 256 MB) --------  don't care
     */
    Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
    Cache.MAR128_159 = 0x00008000;  /* xxxx xxxx xxxx xxxx 10xx xxxx xxxx xxxx */

    2. The shared region configuration must reflect the MAR configuration, it does *not* control the cache setting. Make sure to configure your shared region to match the MAR configuration.

    /* configure SharedRegion #0 (IPC) */
    var SR0Mem = Program.cpu.memoryMap["SR_0"];

    SharedRegion.setEntryMeta(0,
        new SharedRegion.Entry({
            name:           "SR0",
            base:           SR0Mem.base,
            len:            SR0Mem.len,
            ownerProcId:    MultiProc.getIdMeta("HOST"),
            cacheEnable:    false,
            isValid:        true
        })
    );

    3. Look in Dsp.cfg and config.bld for more details.

    ~Ramsey

  • 0 in reply to Ramsey
    TI__Intellectual 975 points

    Ramsey,

    Thank you for your help!!!

  • 0 in reply to Ramsey
    Prodigy 150 points

    Ramsey:

    We tried this setting on the DM8148 device and it did not work, the memory is still cached and we need to invalidate it in order to ARM to see the value DDR.

    We are using SYSBIOS 6.32.xxxx, not sure if cache function has known issues.

    I notice the latest version is 6.34 now, not sure if we need to upgrade.

    Did you test this on 6.34 and DM1848?

    regards

    --Zhigang

  • 0 in reply to Zhigang Liu
    TI__Genius 12025 points

    Zhigang,

    Yes, we have tested this on DM8148 using SYS/BIOS 6.33.05.46 with SysLink 2.20.01.18. We have also been using this with older releases. You can look at the release notes for previous releases of SysLink at the Target Content web page. You don't need to upgrade your SYS/BIOS, but there is no harm in doing so.

    So you are running on the DSP? And the ARM cannot see the data land in external memory (DDR) until the DSP performs a cache write-back operation? (You probably don't want to do a cache invalidate). It must be a MAR configuration issue because this is the only module which controls the cache-ability of memory as seen by the DSP. Remember that each MAR bit controls 16 MB of space. Be sure to place your data and code in different 16 MB sections.

    The MAR bits are documented in the TMS320C674x DSP Megamodule, Section 4.4.4.

    ~Ramsey

  • 0 in reply to Ramsey
    Prodigy 150 points

    Ramsey:

    Thanks for the info.

    In fact, we did the test in CCS, we can see that, with MAR settings, L2 Cache is disabled for the share region.

    But L1D still is enabled.

    This can be easily verify in CCS since it has 3 check boxes for memory browser to enable/disable cache view.

    Plus, in the DSP cache document, MAR registers is under L2 Cache section, so I think it controls only L2, not L1.

    Do you know any way can control both cache settings?

    Since on ARM side, the MMU setting can control both L1 and L2 cache without any problem.

    regards

    --Zhigang

  • 0 in reply to Zhigang Liu
    TI__Genius 12025 points

    Zhigang,

    The MAR bits should indeed turn off both L1 and L2 caching of external memory. Note: the MAR bit must be zero to disable caching. Would you attach your generated map file and generated cfg.xml file. They will be in the package/cfg folder where you configured the DSP executable.

    There is a possibility that some code which runs very early in the boot process might have pulled these addresses into the L1 cache (before the MAR bits were initialized). By the time you get to main(), the MAR bits will have been initialized. You could call CACHE_wbInvAll() in main(). This should safely clear out the cache, and from then on the memory should not get cached again.

    ~Ramsey

  • 0 in reply to Ramsey
    Prodigy 150 points

    Ramsey:

    You are right, MAR bits is working now for both L1D and L2.

    Thanks for your help.

    --Zhigang