• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 678 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.

MAR bits on EVM OMAP L137!

Atmapuri
Intellectual 510 points

Hi!

I specified the 64P L2CFG Mode to use 256kBytes of memory for cache using DSP/BIOS on the user interface displayed when double clicking the BIOS configuration file which was added to the project. There is also a need to specify MAR bits. According the gel file, the shared RAM starts at 0x80000000 and the SDRAM starts at 0xC0000000. The shared RAM address is described as CPU internal RAM, by the DSP/BIOS. I will not be using the ARM so I am wondering about the meaning of "shared RAM". Would it be correct to set MAR bits 192-233 to 0x0000000f in order to enable the CPU cache for the 64MBytes of SDRAM properly?

Thanks!
Atmapuri

 

  • 0
    TI__Mastermind 24340 points

    Atmapuri said:
    I specified the 64P L2CFG Mode to use 256kBytes of memory for cache using DSP/BIOS on the user interface displayed when double clicking the BIOS configuration file which was added to the project. There is also a need to specify MAR bits.

     Please see chapter 4 of:

    http://www-s.ti.com/sc/techlit/SPRUFK5

    And related pages: 

    http://tiexpressdsp.com/index.php/Enabling_64x%2B_Cache#Don.27t_forget_the_MAR_bits.21

    http://wiki.davincidsp.com/index.php/C6747_Audio_Example_cache_configuration

     

    Atmapuri said:
    According the gel file, the shared RAM starts at 0x80000000 and the SDRAM starts at 0xC0000000. The shared RAM address is described as CPU internal RAM, by the DSP/BIOS. I will not be using the ARM so I am wondering about the meaning of "shared RAM".

    The shared RAM is the internal memory that can be accessed both by the ARM and the DSP. So you can use it if you are going to use the DSP only. See datasheet page 4:

    "Although the DSP L2 is accessible by ARM and other hosts in the system, an additional 128KB RAM shared memory is available for use by other hosts without affecting DSP performance."

    see also page 8.

    Atmapuri said:
    Would it be correct to set MAR bits 192-233 to 0x0000000f in order to enable the CPU cache for the 64MBytes of SDRAM properly?

    Yes, please see section 4.4.4 of the:

    http://www-s.ti.com/sc/techlit/SPRUFK5

    and:

    http://wiki.davincidsp.com/index.php/C6747_Audio_Example_cache_configuration

  • 0 in reply to Mariana
    Intellectual 510 points

    Hi!

    There are various subsystems of DSP/BIOS which rely on IRAM. If CPU Cache size is set to 256Kbytes, I guess all references of IRAM have to be modified to SDRAM. Are there some hidden side effects of setting IRAM to zero? Like utterly poor performance of certain type of code or similar? On desktop computers, the CPU cache does a pretty good job. Is there code which absolutely requires to reside within IRAM and thus prevents it from being set to zero? For me it would not matter, if the code would run 10% slower, if in return all the vars could be declared without #pragma and no need to worry about their size too much.I tried setting IRAM to zero but get error when trying to save the DSP/BIOS configuration file:

    js: "./HelloBIOSTest.tcf", line 14: MEM segment CACHE_L2: overlaps with another segment or cache configuration.
    MEM segment IRAM: overlaps with another segment or cache configuration.

    Although there is no actual overlap because the IRAM section length is zero and section also can not be deleted.

    Thanks!
    Atmapuri

  • 0 in reply to Atmapuri
    TI__Mastermind 18130 points

    If you intend to use the entire range of L2 RAM as cache, you will need to make sure that your BIOS config does not try to place anything in this memory range. Unfortunately this means going through and modifying things by hand.

    In general, if everything located in external memory remains in the L2 cache your system will run just as fast as if it were located in the L2 RAM; however, this rarely happens for anything but the smallest programs, so you will see some performance hits. It is impossible to predict how much slower the code will run as a whole without knowing more about it, but if you are smart with your alignments and such you can minimalize this hit very significantly.

    Atmapuri said:
    js: "./HelloBIOSTest.tcf", line 14: MEM segment CACHE_L2: overlaps with another segment or cache configuration.
    MEM segment IRAM: overlaps with another segment or cache configuration.

    Although there is no actual overlap because the IRAM section length is zero and section also can not be deleted.

    The reason it cannot be deleted is likely because you have something trying to place a structure inside the L2 RAM. After you clean this up as mentioned above you should be able to remove it.