Code Optimization 101 Help?

MikeH

Other Parts Discussed in Thread: OMAP-L138

I am beginning the long journey of attempting to optimize my audio compression algorithm for real-time operation. Currently it does NOT appear that it is able to run fast enough for my application. I am seeking the guidance of the optimization ghurus on this forum.
========================================
Test configuration:
Logic PD Experimenter with OMAP-L138 SOM
CCS4 4.1.3.00034, DSP/BIOS 5.41.02.14
========================================
I successfully implemented (with a *lot* of help from the ghurus of EDMA and McASP) a ping-pong buffered EDMA3 transfer of 48000 sample/sec 16-bit stereo audio in I2S format to/from the McASP, which is then sent to/from the on-board AIC3106 audio codec. As a temporary alorithm test for the C6748, I am merely copying the input buffer to the output buffer. This works well in real-time and I have accurately benchmarked the DMA transfer time of the audio samples which arrive at a rate of 96000 samples/second. I transfer 512 total samples during the DMA transfer, so that the time my algorithm can consume is 5.3mS (512/96000). I have benchmarked this time using DSP/BIOS STS functions and gethtime() and verified that the CPU cycles between DMA transfers is ~1,600,000, which works out to 5.3mS/(1/300MHz) with a 300MHz CPU clock.

Unfortunately, when I remove the test alogorithm and insert the actual audio compression algorithm, all hell breaks loose. CCS4 consistently crashes with differing error messages (some are posted HERE), and sometimes hangs requiring a task manager kill.

I have determined that I can compile in either Debug or Release, with full symbolc debugging ON (-g), and optmization off (blank), and the code will run, but the audio is very distotred and CCS4 typically crashes sooner or later. I have insterted gethtime() before and after the encoder and decoder. When the code is actually running the encode time is typically around 960,000 cycles, and the decode around 750,000 cycles, which unfortunately is just over 100% CPU utilization.

However, if I try some rudimentary optimization by EITHER turning on optimization (any value other than blank), OR turning off symbolic debugging (no -g), the system either crashes, hangs, or stops giving statistics. The same thing happens if I comment out the decode portion of the algorithm in an attempt to reduce the processing time of the algorithm.

I am currently stumped and frustrated with the constant crashing, illogical outcome of my optimization attempts, and lack of DSP/BIOS statistics when the code actually runs.

I have read a great deal about code optimization techniques, including the Ti Wiki and this very nice presentation (http://processors.wiki.ti.com/images/6/6e/C64p_cgt_optimization.pdf), but cannot seem to get past the CCS4 crashes, hangs, and lack of statistics.

Can someone give me some pointers for things that may be more obivous to the more experienced programmers?

Thx

MikeH

over 14 years ago

0 Steven Tuttle over 14 years ago

Intellectual 820 points

Mike,

I am not familiar with DSPBios applications, so I won't be much help in that dept.

You might want to try bumping up the memory allocated to your stack - it just might be running out of stack space.

I don't know if DSPBios requires a heap, but that also could be running out of memory, and causing weird behaviors.

Steve

0 Brad Griffis over 14 years ago in reply to Steven Tuttle

TI__Guru*** 125430 points

First, even more important than compiler options can be cache configuration. How do you have L1 and L2 cache controllers configured and have you enabled the appropriate MAR bits for external memory? See this wiki article for some more details:

http://processors.wiki.ti.com/index.php?title=Enabling_64x%2B_Cache

There's a great app note related to optimizing code:

Hand-Tuning Loops and Control Code on the TMS320C6000

You might also look at some of the new tools such as this one:

http://processors.wiki.ti.com/index.php/Program_Cache_Layout

Good luck! Let us know how it goes.

Brad

0 Lopi over 14 years ago in reply to Brad Griffis

Intellectual 470 points

Mike,

Are you using the EDMA3 LLD? I found that with my project on the c6747 that the EDMA3 driver code was too bloated. When I added my own processing code the EDMA3 ended up in SDRAM. Then the DSP spent too much time swapping the EDMA3 code into program memory (ex for transfer completion ISR). Just programming the EDMA3 registers directly worked better for me.

Good luck,

Lori

0 MikeH over 14 years ago in reply to Steven Tuttle

Guru 15580 points

Steve,

Thanks for the thoughts. Unfortunately, I have tried doubling and quadrupling the stack with no improvements.

I have also allocated heaps in a couple of sectons of memory. One is for my algorithm (dynamic assignments) and the other is for anything else that needs one.

Thx,

MikeH

0 MikeH over 14 years ago in reply to Brad Griffis

Guru 15580 points

Brad,

Cached and MAR'd.

Thanks for the pointer to the reference material.

MikeH

0 MikeH over 14 years ago in reply to Lopi

Guru 15580 points

Lopi,

Yes, I am using EDMA3 LLD from the TTO LLD Workshop example. I don't really have a "bloat" concern (yet). My concern is that my algorithm takes too long to process the incoming audio. The EDMA3 is working autonomously and not consuming any CPU cycles during the period of interest, so I don't really think going away from LLD will help my issue.

I have a hunch that the problem lies in the fact the the algorithm keeps getting stepped on by more incoming data while it's still trying to process what's already arrived.

Thanks for your thoughts.

MikeH

0 MikeH over 14 years ago in reply to MikeH

Guru 15580 points

After struggling with this issue for the past week, I upgraded CCS4 to version 4.2 (was using 4.1.3.0034) and everything started working as expected. I can now compile without symbolic debuggin (turned off -g) and turn on aggressive optimization (3) and my code runs at 30% utilization! This is great! So now I have a fully working real-time audio compression system using ping-pong buffers and EDMA3 at 30% CPU utilization.

Thanks to all for the assistance.

MikeH

Processors

Processors forum

Code Optimization 101 Help?