DSPRelated.com
Forums

Code and data organization and memory optimization

Started by William C Bonner March 21, 2007
I have a project running on a 6713 processor, with a megabyte of
external sram. I am not running the TI BIOS. I'm running Code Composer
Studio 3.1.23.

My code, data, and stack is larger than 256k, so I have been running
with the cache enabled, reducing the available internal ram on the DSP
to 192k. The cache is configured to run on my entire external memory range.

I have set things up with some code and data explicitly declared to run
from the internal ram (including having the stack internal) and other
code and data simply declared to fit in either internal or external,
depending on the linker's choice.

I have been manually eking out some speed improvements by picking
particular functions to be located in internal ram.

Is there a way in code composer studio to run a call graph to see which
functions are called in a run of the program, and what functions I may
improve the response time by moving them to the more precious ram?

I suppose understanding the cache efficiency is enough work for me to
get a doctoral degree in itself.

Thanks for any help.. Wim.
Sorry to respond to my own post so quickly, but I wanted to add that I'm
linking with the following libraries beyond my own. csl6713, dsp67x,
fastmath67x, and rts6700. Also, I've got stuff in my linker command file
forcing some of that into internal ram. (I was having problems with my
code when these were not in internal ram, and I have no idea why.)

.iram > L2RAM
{
-lrts6700.lib (.far)
-lcsl6713.lib (.far)
-lfastmath67x.lib
}
William C Bonner wrote:
> I have a project running on a 6713 processor, with a megabyte of
> external sram. I am not running the TI BIOS. I'm running Code Composer
> Studio 3.1.23.
>
> My code, data, and stack is larger than 256k, so I have been running
> with the cache enabled, reducing the available internal ram on the DSP
> to 192k. The cache is configured to run on my entire external memory range.
>
> I have set things up with some code and data explicitly declared to run
> from the internal ram (including having the stack internal) and other
> code and data simply declared to fit in either internal or external,
> depending on the linker's choice.
>
> I have been manually eking out some speed improvements by picking
> particular functions to be located in internal ram.
>
> Is there a way in code composer studio to run a call graph to see which
> functions are called in a run of the program, and what functions I may
> improve the response time by moving them to the more precious ram?
>
> I suppose understanding the cache efficiency is enough work for me to
> get a doctoral degree in itself.
>
> Thanks for any help.. Wim.
>
>
> Subject: Code and data organization and memory optimization
> Posted by: "William C Bonner" w...@wimsworld.com wbonner
> Date: Wed Mar 21, 2007 9:11 am ((PDT))
>
> Is there a way in code composer studio to run a call graph to see which
> functions are called in a run of the program, and what functions I may
> improve the response time by moving them to the more precious ram?

Hi Willaim,

The only method that I know of that seem to be what you are asking about
is the CCS's profiler session: Profiler->Start new session.

The call stack stack window (but no profile info) is View->Call stack.

As a general rule I would assume (am I whong here?) that the RMS algorithm
from scheduling might be applicable here: the most frequently called
code sections are allocated to the faster RAM.

Rgds,

Andrew
Andrew Nesterov wrote:
>> Subject: Code and data organization and memory optimization
>> Posted by: "William C Bonner" w...@wimsworld.com wbonner
>> Date: Wed Mar 21, 2007 9:11 am ((PDT))
>>
>> Is there a way in code composer studio to run a call graph to see which
>> functions are called in a run of the program, and what functions I may
>> improve the response time by moving them to the more precious ram?
>>
> The only method that I know of that seem to be what you are asking about
> is the CCS's profiler session: Profiler->Start new session.
>
> The call stack stack window (but no profile info) is View->Call stack.
>
> As a general rule I would assume (am I whong here?) that the RMS algorithm
> from scheduling might be applicable here: the most frequently called
> code sections are allocated to the faster RAM.
>
Thanks.

I'm not familiar with the RMS term, but I think part of what I'm looking
for is a specific way of optimizing the library functions that I call in
my time critical code into the fast ram, while leaving the library calls
that I use during boot up or textual output / event generation stage in
slower ram, optimized by the cache controller itself.

I use the call stack view on a regular basis in my windows debugging
because it verifies the call path of how I got to a particular
breakpoint. The code in my DSP is straightforward enough that I
generally already know the call stack, but I sometimes use that view on
the DSP as well.

Wim.