• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 681 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.

code in c6472 shared memory

SNBANIK
Intellectual 645 points


I have couple of questions regarding code organization in c6472

 1. Since c6472 has a shared L2 SRAM of size 768Kbytes and each core has 608Kbytes of its own L2 SRAM/Cache, Is there a way of building my code such that I have all my common signal/image processing modules reside in the shared L2 (and hence single copy) while individual executive (with the functions that actually calls these underlying common modules) reside in individual core L2?

This way I reduce overall code size (do not replicate common code) and also making individual core code size small enough that it makes it possible to think of putting them in L2 memory. Of course the signal processing modules have to be re-entrant.

 2. The other question is regarding L1P - what are the tradeoffs of using part of L1P as Cache versus all of it as Cache. I understand the tradeoffs in general, what I am looking for is what has been other people's experience of splitting L1P into Cache and SRAM and what is a general rule of thumb. We have currently setup entire L1P as cache in 645x based product.

Thanks

Somnath

 

  • 0
    TI__Mastermind 30825 points

    1.) Yes, you can map common functions into the SL2 portions of the memory map by defining them to be in sections mapped to the SL2 memory space.  Any code that calls those routines will access them via the SL2 if that's where the function resides.  These routines will be cached by the L1P Cache when accessed if it's enabled.

    2.) The trade off going All Cache in L1P vs partial Cache / partial SRAM in L1P is very system dependent.  If you have a lot of code and task switching between functions, a smaller cache is going to have a greater impact on performance (significantly more thrashing) than a larger cache.   You would have to way the benefits of going partial cache / partial SRAM and probably would only seriously consider it if you really have a critical set of tasks that are going to be used the vast majority of the time and can accept the potential increase in cache thrashing for the rest of the routines.   In which case these routines with it being all cache may have resulted in greater cache thrashing, then separating them out.  Utilizing cache analysis tools within CCS and setting it up both ways may be able to help you understand which is the best way for your system.

    Best Regards,

    Chad

  • 0 in reply to Chad Courtney
    TI__Expert 3795 points

    Hi Somnath,

    Yes you can make any of your modules reside in SL2 by defining sections for them in the linker command file. 

    For example, you can say

     

    MEMORY {

       CACHE_L1P   : origin = 0xe00000,    len = 0x8000

       CACHE_L1D   : origin = 0xf00000,    len = 0x8000

       DDR2        : origin = 0xe0000000,  len = 0x10000000

       LL2RAM      : origin = 0x800000,    len = 0x98000

       SL2RAM      : origin = 0x200000,    len = 0xc0000

    }

     

     

    SECTIONS {

            .bss:     {} > LL2RAM

           .mem:  {} > LL2RAM

           .bios:    {} > SL2RAM
            .data:    {} > SL2RAM
            .pinit:   {} > SL2RAM
            .text:    {} > SL2RAM
            .cinit:    {} > SL2RAM
     }

     

     

  • 0 in reply to auppu6547
    Intellectual 645 points

    Thanks for your replies so far.

    What is stil not clear to me is -- since every core is built separately, how do I ensure that the linker generates same address for each of those cores (for the common modules).

    And how does the loader know not to load the common modules separately for each core that is it loads only once.

     

  • 0 in reply to SNBANIK
    TI__Expert 3795 points

    Hi,

    For the common modules, the linker will essentially put these in a specific memory location defined in SL2. Even if the loader is loading the same modules again in the SL2, you need not worry since its loading it to the SAME physical memory location. So, there is no chance of duplication of SL2 data. 

    Regards,

    Arun

  • 0 in reply to auppu6547
    Intellectual 515 points

    Hi,

    By putting the .text section in SL2, I am observing some strange behavior. It will take the user to press "GO" (F8) twice before the program was able to start. In addition, the PC will remain unchanged and rest at the same address line of main() after the first "GO" (F8)button was issued.

    The behavior was observed using the Hello world example in CCSV4 with the only modification of the configuration file by adding the following lines to expliciitly force the text section in the SL2 memory.

    Program.sectMap[".bss"] = "LL2RAM";  
    Program.sectMap[".mem"] = "LL2RAM"; 
    Program.sectMap[".bios"] = "SL2RAM";
    Program.sectMap[".data"] = "SL2RAM";
    Program.sectMap[".pinit"] = "SL2RAM";
    Program.sectMap[".text"] = "SL2RAM";
    Program.sectMap[".cinit"] = "SL2RAM";

    I am using the following version of target content to build the Hello World RTSC example

    Code Composer Studio: 4.2.1.00004

    Code Generation Tools: V7.0.4

    Inter-processor Communication: 1.21.02.23

    SYS/BIOS: 6.30.03.46

    XDC Tools: 3.20.06.81

    RTSC target: ti.targets.C64P

    RTSC Platform: ti.platforms.evm6472

    RTSC Build-Profile: whole_program

     

     

    Thanks much,

     

    Dominic

     

     

  • 0 in reply to Dominic Wu
    Intellectual 290 points

    I would like to be in the email chain of this topic.  Thanks.

  • 0 in reply to Louis Leung
    TI__Intellectual 835 points

    We have been able to reproduce the issue reported by Dominic. Disabling auto run to main in debugger options seems to address this issue.

    In CCS v4.2 auto run can be disabled two ways:

    1) Under Tools > Debugger Options > Generic Debugger Options > Auto Run Options
        CAUTION: In the current version of CCSv4 (4.2) this applies to only selected core. You have to repeat this for all cores.

    OR

    2) Under Window >  Preferences ... > CCS > Debug >  Debugger Options > Generic > Auto Run Options
       This will be a global setting

    You will have to restart Debug session for this change in setting to take effect.

    Thanks to Piyush and Ki-Soo for working with me on this issue.

    Rama

  • 0 in reply to Rama
    Intellectual 515 points

    The suggested method is working. Thanks a lot for your help, I appreciate it.

    Dominic