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.

TMS320C6678: Enabling Prefetch for MSMC memory in OpenMP runtime... Should be disabled ?

Part Number: TMS320C6678

Hello, 

I`ve run my eyes through the C667x OpenMP runtime and noticed that the runtime enables the prefetch feature for MSMC memory which is configured as cache.

C:\ti\openmp_dsp_c667x_2_06_02_01_debug\packages\ti\runtime\ompbios\OpenMP.c

void __TI_omp_reset_rtsc_mode(void)
{
    // Cache configured via ti_sysbios_family_c66_Cache_Module_startup using
    // sizes specified in Platform.xdc
    //__TI_omp_configure_caches();

    /* OMP runtime requires a portion of MSMCSRAM to be non-cached. Since it is 
     * not possible to disable caching in the MSMCSRAM address range, we need a 
     * 2 step process:
     * 1. Map a portion of MSMCSRAM into a range that can be marked as
     *    non-cached. This is done using the MPAX register
     * 2. Annotate the mapped section as non-cached using the appropriate
     *    MAR register for that memory range
     * All accesses to MSMCSRAM through the mapped address range will not
     * be cached.
     */
    if (OpenMP_hasMsmc)
    {
       __TI_setMPAX(OpenMP_mpaxForMsmcMapping, 
                    OpenMP_msmcNoCacheVirtualBase, 
                    OpenMP_msmcNoCachePhysicalBase, 0x10 /* 128 KB */);
       __TI_omp_disable_caching(OpenMP_msmcNoCacheVirtualBase, 
                                OpenMP_msmcNoCacheVirtualSize);

       /* Enable Caching for MSMCSRAM */
       __TI_omp_enable_caching(OpenMP_msmcBase, OpenMP_msmcSize);
    }
    else
    {
       __TI_omp_disable_caching(OpenMP_ddrNoCacheBase, OpenMP_ddrNoCacheSize);
    }

    /* Enable caching for DDR */
    __TI_omp_enable_caching(OpenMP_ddrBase,  OpenMP_ddrSize);
}

And __TI_omp_enable_caching function in C:\ti\openmp_dsp_c667x_2_06_02_01_debug\packages\ti\runtime\openmp\src\omp_init.c looks like:

void __TI_omp_enable_caching(unsigned int start, unsigned int length)
{
tomp_setMAR(start, length, CACHE_PC|CACHE_PFX|CACHE_WTE);
}

I feel Prefetch should be disabled for MSMC memory because of Errata Advisory 28. It says like this for the workaround:

Software must disable the PFX bits in the MARs for address ranges 0x0C000000 – 0x0FFFFFFF corresponding to cacheable data (MARs can be written to only in supervisor mode. The PFX bit for MARs 12-15 which define attributes for 0x0C000000 – 0x0FFFFFFF is set to 1 by default). This will disable pre-fetching for accesses to those addresses, while still allowing those accesses to be cached in L1D. If pre-fetching for MSMC SRAM and other memory spaces is desired, it can still be done provided they are remapped to a space other than 0x0C00 0000 – 0x0FFF FFFF within the MPAX registers (the remapped MSMC will act as shared level 3 memory and will be cacheable in L1D and L2). The L2 cache must remain on and set to a cache size greater than zero, and must not be frozen when accessing pre-fetchable data, otherwise XMC will apply the previously described L1D-specific behavior for the data prefetcher and subject the system to the same issue.

So, I`ve suggested the customer who is actually using OpenMP runtime to rebuild it with the following customization:

1. Add the following function:

void __TI_omp_enable_caching_withoutPFX(unsigned int start, unsigned int length)
{
tomp_setMAR(start, length, CACHE_PC|CACHE_WTE);
}

2. And replace the existing code with it:

void __TI_omp_reset_rtsc_mode(void)
{
    // Cache configured via ti_sysbios_family_c66_Cache_Module_startup using
    // sizes specified in Platform.xdc
    //__TI_omp_configure_caches();

    /* OMP runtime requires a portion of MSMCSRAM to be non-cached. Since it is 
     * not possible to disable caching in the MSMCSRAM address range, we need a 
     * 2 step process:
     * 1. Map a portion of MSMCSRAM into a range that can be marked as
     *    non-cached. This is done using the MPAX register
     * 2. Annotate the mapped section as non-cached using the appropriate
     *    MAR register for that memory range
     * All accesses to MSMCSRAM through the mapped address range will not
     * be cached.
     */
    if (OpenMP_hasMsmc)
    {
       __TI_setMPAX(OpenMP_mpaxForMsmcMapping, 
                    OpenMP_msmcNoCacheVirtualBase, 
                    OpenMP_msmcNoCachePhysicalBase, 0x10 /* 128 KB */);
       __TI_omp_disable_caching(OpenMP_msmcNoCacheVirtualBase, 
                                OpenMP_msmcNoCacheVirtualSize);

       /* Enable Caching for MSMCSRAM */
//       __TI_omp_enable_caching(OpenMP_msmcBase, OpenMP_msmcSize);
       __TI_omp_enable_caching_withoutPFX(OpenMP_msmcBase, OpenMP_msmcSize);
    }
    else
    {
       __TI_omp_disable_caching(OpenMP_ddrNoCacheBase, OpenMP_ddrNoCacheSize);
    }

    /* Enable caching for DDR */
    __TI_omp_enable_caching(OpenMP_ddrBase,  OpenMP_ddrSize);
}

Do you agree with this customization ? If yes, please consider updating the OpenMP runtime in the future release.

Best Regard,
NK

  • Hi Naoki,

    This is an interesting point. We will review the code and then get back to you.

    Thanks,
    Garrett
  • Naoki,

    From C6678 datasheet,

    2.3.1 MSMC SRAM

    MSMC SRAM can serve as a Shared Level 2 or Level 3 memory:

    • Shared Level 2 memory—The MSMC memory is cacheable by L1D and L1P

    caches; L2 will not cache requests to MSMC SRAM.

    • Shared Level 3 memory—The MSMC memory is not directly cacheable at the L2,

    but is cacheable in L1D and L1P. However, if it is remapped to an external address

    using the address-extension capabilities in the C66x CorePac MPAX, the MSMC

    memory can be cached as a shared L3 memory both in the L1 and L2 caches. To

    achieve this, the caching must be enabled in MAR registers (using MAR.PC bit)

    for the remapped region.

    And as explained in the thread

    MSMC RAM – typically used as shared level 2 memory . Errata is saying that pre-fetch must be disabled or MSMC must be configured as shared level 3 memory. Expect that the performance will be better with pre-fetch disabled.

    The OpenMP case falls into the category - MSMC is configured as shared level 3 memory, so errata 28 should not be applicable.

    Regards,
    Garrett

  • Hello Garrett,

    Thanks for your reply. 

    OpenMP runtime has 2 memory segments originated from the MSMC SRAM. The one is for non-cacheable SRAM (It is actually a part of MSMC memory but it is remapped to some known address range by MPAX and then the cache disabled by the related MAR configuration). The other is pure MSMC SRAM and it is configured as cacheable and pre-fetchable in the runtime.

    Here is the related code in C:\ti\openmp_dsp_c667x_2_06_02_01\packages\ti\runtime\ompbios\OpenMP.c

    if (OpenMP_hasMsmc)
    {
    __TI_setMPAX(OpenMP_mpaxForMsmcMapping,
    OpenMP_msmcNoCacheVirtualBase,
    OpenMP_msmcNoCachePhysicalBase, 0x10 /* 128 KB */);
    __TI_omp_disable_caching(OpenMP_msmcNoCacheVirtualBase,
    OpenMP_msmcNoCacheVirtualSize);

    /* Enable Caching for MSMCSRAM */
     __TI_omp_enable_caching(OpenMP_msmcBase, OpenMP_msmcSize);
    }
    else
    {
    __TI_omp_disable_caching(OpenMP_ddrNoCacheBase, OpenMP_ddrNoCacheSize);
    }

    So, i still think the cacheable and pre-fetchable MSMC SRAM should be regarded as level 2 memory and the advisory should be taken care. What do you think ?

    Best Regards,
    NK

  • Hello Garrett,

    Happy new year! Well, do you have any further suggestions on this ?
  • Hi Naoki,

    Thanks! I mis-understood your points in previous post, thought the code you posted is to enable the cache at some point for the OpenMP_msmcNoCacheVirtualBase().

    It looks like the errata advisory 28 was not applied to the OpenMP runtime. I have create a JIRA to track this internally.

    Regards,
    Garrett
  • Hello Garrett,

    Thank you for issuing the ticket for fixing the issue. Meanwhile, I would suggest the customers to modify the runtime by themselves.
    I close the thread now.

    Best Regards,
    NK