• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 582 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.

Where Cache (and Memory Settings in General) are done best?

Joern
Genius 3055 points
Other Parts Discussed in Thread: SYSBIOS

Hi, I'm using now the current EZSDK 5.05. Within my codec server's .cfg file I've set this:

var Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
Cache.MAR0_31    = 0xffffffff;
Cache.MAR32_63   = 0xffffffff;
Cache.MAR64_95   = 0xffffffff;
Cache.MAR96_127  = 0xffffffff;
Cache.MAR128_159 = 0xffffffff;
Cache.MAR160_191 = 0xffffffff;
Cache.MAR192_223 = 0xffffffff;
Cache.MAR224_255 = 0xffffffff;
Cache.initSize.l1pSize = Cache.L1Size_32K;
Cache.initSize.l1dSize = Cache.L1Size_32K;
Cache.initSize.l2Size  = Cache.L2Size_256K;

which for me to a significantly faster codec execution. All seems to run so far, but there always was this warning from the build process:

clarify this warning: ti.sysbios.family.c64p.Cache:
"/somewhere/ti-ezsdk_dm814x-evm_5_05_01_04/component-sources/bios_6_33_05_46/packages/ti/sysbios/family/c64p/Cache.xs",
line 486: ti.sysbios.family.c64p.Cache : Cache settings were changed
in user configuration. User configuration options will override
platform settings. Check your memory map to make sure that Cache does
not conflict with your L1/L2 memory placement. To avoid conflicts
between L1/L2 memory and cache, we recommended specifying cache sizes
along with memory sizes in a platform package.  

So far, so good - it sounds understandable for me that it was a better idea to configure the L1/L2 memory placement and the L1/L2 sizes a one same place, to avoid conflicts. I saw several threads here regarding to a wizard component of the CCS, but I use EZSDK, and I wanted to change the needed stuff by hand.

The platform description for DM8148 and it's CPU components seems somewhat widespreaded to me - is there any overview where to find what? And, more in common, where actually the best place would be for memory settings for my platform in general?

Thanks in advance,
Joern.

  • 0
    TI__Mastermind 26780 points

    Joern,

    I looked at this a bit and see why you are getting that warning, and have been discussing this with some other members of the SYS/BIOS team. 

    Personally, I think you should be able to change the cache size settings without getting that warning. The memory and cache size defaults for the platform are defined in the platform’s Platform.xdc file.  As long as you are making non-conflicting choices for the different cache sizes, to override what is in the Platform.xdc file, I think you can continue to use that platform and don’t need to create a new one.  

    I'll continue to discuss this internally, proposing to remove that warning in a future release.  I’ll post back to this thread if there is something I’m missing, and the recommendation is different…

    Scott

  • 0 in reply to ScottG
    Genius 3055 points

    Scott,

    thanks for this clarification - so I'll continue, in spite of the warning, to enable the whole L2 cache for use on DSP side. Because it so significantly increases the execution speed for my DSP side implementation.

    But I do that with ducked head, because I'd feel better if actually I saw a possibility to have an overview over all possibly concurrent settings.

    Of course I myself are somewhat sure that I didn't place anything into the L2 RAM using it as internal RAM. But how to know if nowhere else this is done by a component's settings?

    Isn't there a reason why the Platform.xdc sets the default size of L2 cache to zero?

    By the way, all the comfort provided through the XDCtools until now for me has a dark side, too: because of multiple includes and always the possibility to override some setting it seems difficult to me to keep track of holding this conflict-free.

    Best regards,
    Joern.

  • 0 in reply to Joern
    TI__Mastermind 26780 points

    Joern,

    I looked and didn’t find any graphical views or files that show a good summary of contributions from different components.  I will ask around to see if there is something I’m not aware of, and post back if I find something.

    One slight consolation is that what is shown in the graphical tool and the program’s map file is the aggregate of all contributions from the different components.  So, inspecting at those levels shows the end result of the configuration and build with the different components.

    I don’t know why the default L2 size is zero.  For some apps this may be preferred (to have some local fast RAM), but for others (like yours) there will be a big performance boost with it configured as cache.

    And to your last point, I understand what you are saying as far as limited visibility.  On the bright side though, there is indeed a *lot* of error checking going on behind the scenes to detect obvious conflicts, to warn, or prevent a build.  

    Scott

  • 0 in reply to ScottG
    Genius 3055 points

    Scott,

    thanks for the hint to the program's map file - that helps a lot (if I trust in that information ;-)) - the display of graphical tools I don't see, I don't use the CCS... or are there other tools, independently on the CSS, which I've overlooked?

    The bright side of XDCtools I'll be better able to see when some day all EZSDK components are controlled by that and so use the same settings. But I can't wait. Currently f.e. we have heavy issues to solve because the firmware loader has it's very own memory settings. Also f.e., I am still fighting against some feeble optimization settings coming from anywhere back to my components, like --optimize_with_debug, maybe this is intentionally, but if, where is that then documented?

    I tell you this just as examples, these points go far behind of the scope of this thread, and if I don't find already given answers or find the solutions by myself, of course then I'll open new threads.

    Thanks again,
    Joern.