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.

DMA Cache Invalidate and Cache Flush

Other Parts Discussed in Thread: OMAP-L138

Hi

I have a buffer that is 15MB created using CMEM. I used DMA to transfer data from SRAM to the buffer for processing.

I did a data check by transferring 6MB of data. In the first transfer of the 6MB, the data is transferred successfully but in the second transfer of the 6MB, I realized that there are some inconsistencies occurring randomly around 2-3Mb.

I referenced some EDMA examples and tried the EDMA3_CacheFlush and EDMA3_CacheInvalidate.

The process takes time because of the flushing and invalidating 15MB each time after transferring 65500 bytes of data. For example to fill the 15MB of data, i will need to invalidate and flush for 240 times. Then, I tried replace the length by some values and somehow I manage to get the inconsistencies to go away but it still takes time to complete the process.

I am not sure if I require to flush the cache or invalidate the cache or what is the proper way to do so if I require flushing and invalidating. Somewhere is wrong but I am not sure.

Please assist.

Thanks...

  • Hi,

    Thanks for your post.

    Make sure you read this one:

    TMS320C621x/C671x DSP Two-Level Internal Memory Reference Guide

    http://www.ti.com/lit/spru609

    L2 cache only helps you if you have program/data in external memory.  If you can turn the L2 cache entirely off (which will give you more space as SRAM) and fit all your code/data in L2 then that will be the best performance.  Otherwise you'll have to do some system level testing/analysis to determine the best tradeoff of cache vs SRAM and which code/data should be put in external memory

    None of the c6000 devices use a write through cache.  All of our caches are "write back" caches.  Please review the definitions in Section 2 of the Two Level Internal Memory Reference Guide.  Along those lines please also see the definition of "snoop" as that is the means by which coherence is maintained for the L2 SRAM.  Read Section 8.2 "EDMA Coherence in L2 SRAM Example"

    Also, please check the below wiki for your reference:

    http://processors.wiki.ti.com/index.php/Cache_Management

    Thanks & regards,

    Sivaraj K

    ------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question

    -------------------------------------------------------------------------------------------------------

  • Hi Sivaraj

    I would like to turn the L2 Cache off totally and use all of it as SRAM.

    There's a tci file that loads the configuration.

    I have attached the file (evmOMAPL137

    /* 
     * Copyright (c) 2010, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     * 
     */
    /*
     * Setup platform-specific memory map:
     */
    var mem_ext = [
    {
        comment:    "DDRALGHEAP: off-chip memory for dynamic algmem allocation",
        name:       "DDRALGHEAP",
        base:       0xC3000000,
        len:        0x01000000,
        space:      "code/data"
    },
    {
        comment:    "SDRAM: off-chip memory for application code and data",
        name:       "SDRAM",
        base:       0xC2C00000,
        len:        0x00300000,
        space:      "code/data"
    },
    {
        comment:    "DSPLINK: off-chip memory reserved for DSPLINK code and data",
        name:       "DSPLINKMEM",
        base:       0xC2F01000,
        len:        0x00100000 - 0x1000,
        space:      "code/data"
    },
    {
        comment:    "RESET_VECTOR: off-chip memory for the reset vector table",
        name:       "RESET_VECTOR",
        base:       0xC2F00000,
        len:        0x00001000,
        space:      "code/data"
    },
    ];
    
    
    /*
     *  Internal memory partitioning for evmDM6446
     *
     *  On the left in the diagram below is the layout of internal memory
     *  available on DM6446 for data caching and as RAM; on the right is the
     *  diagram showing how this configuration file partitions the available
     *  64k+80k of memory. (The 32K for program cache is not affected by this
     *  configuration.) Please find more specifics on how the configuration is
     *  done further below.
     *
     *
     *  Physical internal memory on DM6446     Default partitioning in this .tcf
     *
     *              |//////////|                           |//////////|
     *  0x11800000  +----------+               0x11800000  +----------+
     *              | L2Cache  |                           |          |
     *              |  and/or  | 64k                       | L2 Cache | 64k
     *              |  IRAM    |                           |          |
     *              |          |                           |          |
     *  0x11810000  +----------+               0x11810000  +----------+
     *              |//////////|                           |//////////|
     *              :          :                           :          :
     *              |//////////|                           |//////////|
     *  0x11F04000  +----------+               0x11F04000  +----------+
     *              |          |                           |          |
     *              | L1DSRAM  | 48k                       | L1DSRAM  |
     *              |          |                           |          | 64k
     *  0x11F10000  +- - - - - +                           |          |
     *              |L1Cache or| 32k                       +- - - - - +
     *              |more L1DSR|               0x11F14000  | L1 cache | 16k
     *  0x11F18000  +----------+               0x11F18000  +----------+
     *              |//////////|                           |//////////|
     */
    
    /*
     *  Configure L1D Cache and L1DSRAM segment: l1DMode
     *
     *  OMAP3530 device has 48KB of physical memory at 0x10F04000 available
     *  as internal RAM, called the "L1DSRAM" segment in BIOS, and it has
     *  another adjacent 32KB at 0x10F10000 that can either be used entirely
     *  for L1D cache, or split between L1D cache and more internal memory.
     *
     *  The 80KB segment (48KB + 32KB) starts at 0x10F04000. When powered on,
     *  the device uses the upper 32K for L1D cache entirely, so BIOS by default
     *  defines the L1DSRAM segment to be 48KB long and does not change the cache.
     *
     *  We can change the default behavior, by shrinking the L1D cache and adding
     *  the extra space to L1DSRAM. We can set the L1D cache to be 32K (the default)
     *  or 16K, 8K, 4K, or 0K. The corresponding L1DSRAM sizes then are 48K (the
     *  default), or 64K, 72K, 76K, or 80K.
     *
     *  The L1DSRAM segment always starts at 0x10F04000.
     *
     *  Configure L2 Cache memory settings: l2Mode
     *
     *  This value indicates how the physical internal memory of size 64KB
     *  starting at 0x10800000 will be split between L2 cache and a
     *  general-purpose internal memory segment IRAM.
     *
     *  The options for l2Mode are:
     *
     *  "0k"  -- IRAM    : start = 0x10800000, len = 64KB
     *           L2 Cache: none
     *  "32k" -- IRAM    : start = 0x10800000, len = 32KB
     *           L2 Cache: start = 0x10808000, len = 32KB
     *  "64k" -- IRAM    : none
     *           L2 Cache: start = 0x10800000, len = 64KB
     */
    
    var device_regs = {
        l1PMode: "32k",
        l1DMode: "16k",
        l2Mode: "128k"
    };
    
    var params = {
        clockRate: 300,
        catalogName: "ti.catalog.c6000",
        deviceName: "L137",
        regs: device_regs,
        mem: mem_ext
    };
    
    /*
     * Now customize the generic platform with parameters specified above.
     */
    utils.loadPlatform("ti.platforms.generic", params);
    
    /*  ===========================================================================
     *  Enable heaps and tasks
     *  ===========================================================================
     */
    bios.enableMemoryHeaps(prog);
    bios.enableTskManager(prog);
    
    /*  ===========================================================================
     *  Create heaps in memory segments that are to have heap
     *  ===========================================================================
     */
    bios.SDRAM.createHeap = true;
    bios.SDRAM.heapSize   = 0x20000; // 128K
    
    /* set for use in all.tcf */
    var platformSeg = bios.SDRAM;
    
    bios.DDRALGHEAP.createHeap = true;
    bios.DDRALGHEAP.heapSize   = bios.DDRALGHEAP.len;
    
    /*
     * The setting of L1DSRAM.len is to work around a problem in the BIOS 5
     * bios_6747.tci file.  TODO - remove when that (SDOCM00051331) is fixed.
     */
    bios.L1DSRAM.len       = 0x4000;
    
    bios.L1DSRAM.createHeap       = true;
    bios.L1DSRAM.enableHeapLabel  = true;
    bios.L1DSRAM["heapLabel"]     = prog.extern("L1DHEAP");
    bios.L1DSRAM.heapSize     = bios.L1DSRAM.len;  // all of L1DSRAM for this heap
    
    bios.IRAM.createHeap       = true;
    bios.IRAM.enableHeapLabel  = true;
    bios.IRAM["heapLabel"]     = prog.extern("L2HEAP");
    bios.IRAM.heapSize     = 0x20000;  // half of IRAM's 256K for this heap
    
    bios.L3_CBA_RAM.createHeap       = true;
    bios.L3_CBA_RAM.enableHeapLabel  = true;
    bios.L3_CBA_RAM["heapLabel"]     = prog.extern("L3_CBA_RAM_HEAP");
    bios.L3_CBA_RAM.heapSize     = 0x10000;  // half of L3's 128K for this heap
    
    /*  ===========================================================================
     *  GBL
     *  ===========================================================================
     */
    /* set MAR register to cache shared internal memory 0x80000000-0x80FFFFFF */
    bios.GBL.C64PLUSMAR128to159 = 0x00000001;
    
    /* set MAR register to cache external memory 0xC0000000-0xC3FFFFFF */
    bios.GBL.C64PLUSMAR192to223 = 0x0000000f;
    
    /*
     *  @(#) ti.sdo.ce.examples.servers.all_codecs; 1, 0, 0,261; 12-2-2010 21:23:34; /db/atree/library/trees/ce/ce-r11x/src/ xlibrary
    
     */
    
    
    ).

    Under device_reg I changed the l2Mode: "128k" to l2Mode: "0k".

    1. Does this mean that I have reduce the l2cache size from 128k to 0k?

    2. When I check the technical documents, the OMAP-l138 has 256kb l2cache and 128kb of shared RAM. In this case of 128k, is this the shared ram or the l2cache?

    var device_regs = {

       l1PMode: "32k",

       l1DMode: "16k",

       l2Mode: "128k"

    };

    3. Does this also mean that I have access the l2Cache as SRAM already?

  • Dear John,
    It seems 128KiB as cache and other 128KiB as RAM configured.


    I would like to turn the L2 Cache off totally and use all of it as SRAM.

    Then try to use like below.

    var device_regs = {

    l1PMode: "32k",

    l1DMode: "16k",

    l2Mode: "0k"

    };

    Refer this.
    /
    *
    * The options for l2Mode are:
    *
    * "0k" -- IRAM : start = 0x10800000, len = 64KB
    * L2 Cache: none
    * "32k" -- IRAM : start = 0x10800000, len = 32KB
    * L2 Cache: start = 0x10808000, len = 32KB
    * "64k" -- IRAM : none
    * L2 Cache: start = 0x10800000, len = 64KB
    */
  • Hi

    Thanks for your response.
    I tried the method you suggested and the caching issue is resolved for me.

    I have another question which is the starting address where I can actually use that caching part like an SRAM.
    So that means at start = 0x10800000, i have 128Kb worth of space where I can use to store some struct information or something.
    Is that right?

    Thanks again.
  • Dear John,

    I have another question which is the starting address where I can actually use that caching part like an SRAM.
    So that means at start = 0x10800000, i have 128Kb worth of space where I can use to store some struct information or something.
    Is that right?

    Yes.
    Please refer to the following DSP mega module user guide.
    www.ti.com.cn/.../sprufk5a.pdf
  • Hi

    I refer to the www.ti.com/.../omap-l138.pdf at page 24 and the address is at 0x1180 0000 (DSP L2 RAM).

    Thanks for the response and assistance.

    Regards,
    John
  • Thanks John for your update.