Hi all,
I am porting a codec to ADSP BF533.I am using visualDSP++ 4.0 (december
updated) and EZ-kit lite. I want to reduce cycle count for processing each
frame.Now my cache is enabled and all code and data is placed in external
memory. Now if I move my frequently used modules from internal memory to
external memory oycle count is increasing.This is explained below:
The problem is that I have defined USECACHE macro :
#define USE_CACHE 1//not using MEM_L1_CODE_CACHE space
and cache is enabled using :
int __cplb_ctrl= CPLB_ENABLE_ICPLBS | CPLB_ENABLE_ICACHE |
CPLB_ENABLE_DCPLBS | CPLB_ENABLE_DCACHE | CPLB_ENABLE_DCACHE;
Now I have all my code mapped to SDRAM0 by the following:
program_ram
{
INPUT_SECTION_ALIGN(4)
INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
noncache_code))
INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
} >MEM_SDRAM0
Now suppose I am getting X no. of cycles/frame with this configuration
___________________________________________________________________________
Now I map the frequently routines to internal memory and rest to external by
the following in .ldf file:
//map critical routines to MEM_L1_CODE
program_critical
{
INPUT_SECTIONS( fft3_fx.doj(program) fft9_fx.doj(program)
basicop2.doj(program))
} >MEM_L1_CODE
//map all other to external memory
program_ram
{
INPUT_SECTION_ALIGN(4)
INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
noncache_code))
INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
} >MEM_SDRAM0
If this gives Y no. of cycles then Y>X.
The cycle count should decrease when movinf routines to internal i.e. it
should be Y
Can anybody tell me what could be the possible reason for this behaviour and
what could be the solution.
regards
chandresh
09891020212
--
After all, we are not children. It's time we planned our life
????increasing cycle count????
Started by ●March 31, 2006
Reply by ●March 31, 20062006-03-31
This is a tough call....
You might have to do a deeper analysis of individual functions...
Can you explain waht exactly the objects fft3_fx, fft9_fx and basicop2
contain?
(1) What is the cache configuration? Is all the SDRAM configured as
cacheable? Then what does the object "noncache_code" correspond to?
(2) After remapping some of the objects to internal memory, have you
verified the map file to see what mapping have changed (what functions have
been moved from external memory to internal memory)? Is there any
possibility that with new modifications some thing has been moved from
internal to external memory (?)... Just verify this using MAP file.
(3) Is there any difference in where the data is being mapped in two cases?
(4) You might have to do a profiling of individual functions and see which
functions are taking more execution time after remap... This might help
you... Specially you might like to know if the increased cycle count is
because of the code section which still reside in external memory or is it
because of the functions which have been moved to internal memory....
Regards,
Kunal
On 3/31/06, chandresh wrote:
> Hi all,
>
> I am porting a codec to ADSP BF533.I am using visualDSP++ 4.0 (december
> updated) and EZ-kit lite. I want to reduce cycle count for processing each
> frame.Now my cache is enabled and all code and data is placed in external
> memory. Now if I move my frequently used modules from internal memory to
> external memory oycle count is increasing.This is explained below:
>
> The problem is that I have defined USECACHE macro :
> #define USE_CACHE 1//not using MEM_L1_CODE_CACHE space
> and cache is enabled using :
> int __cplb_ctrl= CPLB_ENABLE_ICPLBS | CPLB_ENABLE_ICACHE |
> CPLB_ENABLE_DCPLBS | CPLB_ENABLE_DCACHE | CPLB_ENABLE_DCACHE;
>
> Now I have all my code mapped to SDRAM0 by the following:
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
> noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
> Now suppose I am getting X no. of cycles/frame with this configuration
> ___________________________________________________________________________
>
> Now I map the frequently routines to internal memory and rest to external
> by the following in .ldf file:
> //map critical routines to MEM_L1_CODE
> program_critical
> {
> INPUT_SECTIONS( fft3_fx.doj(program) fft9_fx.doj(program)
> basicop2.doj(program))
> } >MEM_L1_CODE
> //map all other to external memory
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
> noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
> If this gives Y no. of cycles then Y>X.
> The cycle count should decrease when movinf routines to internal i.e. it
> should be Y >
> Can anybody tell me what could be the possible reason for this behaviour
> and what could be the solution.
> regards
> chandresh
> 09891020212
> --
> After all, we are not children. It's time we planned our life
>
> ------------------------------
>
--
That which does not kill, makes us stronger
You might have to do a deeper analysis of individual functions...
Can you explain waht exactly the objects fft3_fx, fft9_fx and basicop2
contain?
(1) What is the cache configuration? Is all the SDRAM configured as
cacheable? Then what does the object "noncache_code" correspond to?
(2) After remapping some of the objects to internal memory, have you
verified the map file to see what mapping have changed (what functions have
been moved from external memory to internal memory)? Is there any
possibility that with new modifications some thing has been moved from
internal to external memory (?)... Just verify this using MAP file.
(3) Is there any difference in where the data is being mapped in two cases?
(4) You might have to do a profiling of individual functions and see which
functions are taking more execution time after remap... This might help
you... Specially you might like to know if the increased cycle count is
because of the code section which still reside in external memory or is it
because of the functions which have been moved to internal memory....
Regards,
Kunal
On 3/31/06, chandresh wrote:
> Hi all,
>
> I am porting a codec to ADSP BF533.I am using visualDSP++ 4.0 (december
> updated) and EZ-kit lite. I want to reduce cycle count for processing each
> frame.Now my cache is enabled and all code and data is placed in external
> memory. Now if I move my frequently used modules from internal memory to
> external memory oycle count is increasing.This is explained below:
>
> The problem is that I have defined USECACHE macro :
> #define USE_CACHE 1//not using MEM_L1_CODE_CACHE space
> and cache is enabled using :
> int __cplb_ctrl= CPLB_ENABLE_ICPLBS | CPLB_ENABLE_ICACHE |
> CPLB_ENABLE_DCPLBS | CPLB_ENABLE_DCACHE | CPLB_ENABLE_DCACHE;
>
> Now I have all my code mapped to SDRAM0 by the following:
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
> noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
> Now suppose I am getting X no. of cycles/frame with this configuration
> ___________________________________________________________________________
>
> Now I map the frequently routines to internal memory and rest to external
> by the following in .ldf file:
> //map critical routines to MEM_L1_CODE
> program_critical
> {
> INPUT_SECTIONS( fft3_fx.doj(program) fft9_fx.doj(program)
> basicop2.doj(program))
> } >MEM_L1_CODE
> //map all other to external memory
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
> noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
> If this gives Y no. of cycles then Y>X.
> The cycle count should decrease when movinf routines to internal i.e. it
> should be Y >
> Can anybody tell me what could be the possible reason for this behaviour
> and what could be the solution.
> regards
> chandresh
> 09891020212
> --
> After all, we are not children. It's time we planned our life
>
> ------------------------------
>
--
That which does not kill, makes us stronger
Reply by ●April 3, 20062006-04-03
chandresh,
>> Now if I move my frequently used modules from internal memory to external memory oycle count is increasing.
Is this not expected?
When you have code or data in external memory it takes more cycles to access them. Hence the cycle count increases. Move the less frequently used code in the external memory & more frequently used code to internal memory .
On Fri, 31 Mar 2006 chandresh wrote :
> Hi all,
>
>I am porting a codec to ADSP BF533.I am using visualDSP++ 4.0 (december
>updated) and EZ-kit lite. I want to reduce cycle count for processing each
>frame.Now my cache is enabled and all code and data is placed in external
>memory. Now if I move my frequently used modules from internal memory to
>external memory oycle count is increasing.This is explained below:
>
> The problem is that I have defined USECACHE macro :
>#define USE_CACHE 1//not using MEM_L1_CODE_CACHE space
>and cache is enabled using :
>int __cplb_ctrl= CPLB_ENABLE_ICPLBS | CPLB_ENABLE_ICACHE |
>CPLB_ENABLE_DCPLBS | CPLB_ENABLE_DCACHE | CPLB_ENABLE_DCACHE;
>
>Now I have all my code mapped to SDRAM0 by the following:
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
>noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
>Now suppose I am getting X no. of cycles/frame with this configuration
>___________________________________________________________________________
>Now I map the frequently routines to internal memory and rest to external by
>the following in .ldf file:
>//map critical routines to MEM_L1_CODE
> program_critical
> {
> INPUT_SECTIONS( fft3_fx.doj(program) fft9_fx.doj(program)
> basicop2.doj(program))
> } >MEM_L1_CODE
>//map all other to external memory
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
>noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
>If this gives Y no. of cycles then Y>X.
>The cycle count should decrease when movinf routines to internal i.e. it
>should be Y >
>Can anybody tell me what could be the possible reason for this behaviour and
>what could be the solution.
>regards
>chandresh
>09891020212
>--
>After all, we are not children. It's time we planned our life
>> Now if I move my frequently used modules from internal memory to external memory oycle count is increasing.
Is this not expected?
When you have code or data in external memory it takes more cycles to access them. Hence the cycle count increases. Move the less frequently used code in the external memory & more frequently used code to internal memory .
On Fri, 31 Mar 2006 chandresh wrote :
> Hi all,
>
>I am porting a codec to ADSP BF533.I am using visualDSP++ 4.0 (december
>updated) and EZ-kit lite. I want to reduce cycle count for processing each
>frame.Now my cache is enabled and all code and data is placed in external
>memory. Now if I move my frequently used modules from internal memory to
>external memory oycle count is increasing.This is explained below:
>
> The problem is that I have defined USECACHE macro :
>#define USE_CACHE 1//not using MEM_L1_CODE_CACHE space
>and cache is enabled using :
>int __cplb_ctrl= CPLB_ENABLE_ICPLBS | CPLB_ENABLE_ICACHE |
>CPLB_ENABLE_DCPLBS | CPLB_ENABLE_DCACHE | CPLB_ENABLE_DCACHE;
>
>Now I have all my code mapped to SDRAM0 by the following:
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
>noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
>Now suppose I am getting X no. of cycles/frame with this configuration
>___________________________________________________________________________
>Now I map the frequently routines to internal memory and rest to external by
>the following in .ldf file:
>//map critical routines to MEM_L1_CODE
> program_critical
> {
> INPUT_SECTIONS( fft3_fx.doj(program) fft9_fx.doj(program)
> basicop2.doj(program))
> } >MEM_L1_CODE
>//map all other to external memory
> program_ram
> {
> INPUT_SECTION_ALIGN(4)
> INPUT_SECTIONS( $OBJECTS(L1_code) $LIBRARIES(L1_code))
> INPUT_SECTIONS( $OBJECTS(cplb_code) $LIBRARIES(cplb_code))
> INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
> INPUT_SECTIONS( $OBJECTS(noncache_code) $LIBRARIES
>noncache_code))
> INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
> } >MEM_SDRAM0
>
>If this gives Y no. of cycles then Y>X.
>The cycle count should decrease when movinf routines to internal i.e. it
>should be Y >
>Can anybody tell me what could be the possible reason for this behaviour and
>what could be the solution.
>regards
>chandresh
>09891020212
>--
>After all, we are not children. It's time we planned our life
