Configuring Cache in DSP BIOS v6

Hi Arun,

Thank you for your reply. That is indeed an interesting and relevant example. In the mean while we've enabled the cache without use of the module using:

#include <cslr_cache.h>

init_cache()

{

int i;

CSL_CacheRegs *CacheRegs;

CacheRegs = (CSL_CacheRegs*)0x01840000;

/* Invalidate L1I and L1D */

CacheRegs->L2CFG = CacheRegs->L2CFG | 0x300;

    /* Clean L2 */

    CacheRegs->L2WBINV = 0x1;

/* Enable Maximal L1P/D cache */

CacheRegs->L1PCFG = 0x7;

CacheRegs->L1DCFG = 0x7;

/* Enable 256k L2 cache */

CacheRegs->L2CFG = CacheRegs->L2CFG | 0x4;

for(i=224;i<239;i++)

CacheRegs->MAR[i] = 0x1;

}

Hi Tom,

If you have the CSL, thats an easier way to do it too. Good luck with your project :)

Regards,

Arun

Auppu,

In the demo project you mention the cfg file indeed contains:

var Cache       =   xdc.useModule('ti.sysbios.family.c64p.Cache');

Cache.MAR224_255 = 0x0000000f;

Is that sufficient to enable the caches? How do I know that my caches are enabled now, and that the L2 cache size is e.g., 256k?

Kind regards

Tom,

- the MAR registers enable only cacheability for the external memory (DDR2). If L2 cache or L1 cache are turned off, the performance will still be slow when running out of DDR2


- to have the MAR range really cached, you will need to have L2 cache / L1 cache active. You found a way to enable it with CSL, and there was a suggestion on how to configure this in BIOS.

note that after reset L2 is all SRAM (see datasheet page 96) so this needs to be changed as desired


- the L1 cache configurations will have also default (reset) values which might be changed by the ROM bootloader - you can check in the bootloader user guide what the status will be, see table 21

Again, the application code will need to modify them as desired after the bootloader stage


- pay attention that the linker command file for your application will need to be coherent with the final configuration, i.e. it is forbidden to allocate code / data in memory sections (like in L2) that are successively reconfigured as cache. If you do this the program would likely behave in an unpredictable way and crash immediately

- the megamodule (C64x+) cache user guide has information on what to take care of in terms of cache / buffer management in relation to different scenarios, when having L2 cache active with DDR buffers and concurrent DMA transfers

This applies mainly to external memory ranges since internal cache coherency between L2 Ram and L1P/L1D is quite completely maintained by the megamodule itself in hw by snooping the cache activity (please check the user guide for the details and the exceptions, mainly for L1P)


- also make sure to read carefully the bootloader user guide as at reset some parts of the L2 internal ram for core zero need to be reserved to the bootloader internal use.  If I recall well you can also "reuse" this apparently "lost" memory after boot by declaring it as a union, and putting there an uninitialized section, if desired, or some other data which you page / copy in with the application - see the assembly language tools user guide for the details, there should be an example of doing this (sorry I don't remember the exact section, it's about the linker command file setup)

Hope this helps clarifying.