C5515 Optimization considerations

Andreas,

So here are some suggestions to try and achieve your goals.

1) Make sure you have set the clock to run at its maximum rate.

2) If you have large functions you may be able to help the optimizer if you can create local blocks and declare variables closer to where they are used and limit their scope as much as possible.

3) Always look at the assembler code produced (using the mixed mode display or the dissassembly window) and ask yourself if it is reasonable or seems to contain redundant operations.  Sometimes you will need to contort your code with some rather difficult to read constructs to get the most out of the optimizer.

4) Take advantage of the intrinsic functions especially if you are concerned about over/under flow as the DSP can perform saturation management for you.  These also give you another way to insert assembly language instructions into your code without haveing to go completely to assembly.  The good part about using the intrinsics is that the compiler understands them better than a simple asm statement which allows the optimizer to get involved for further improvements.

5) Layout your variables carefully (especially any arrays or matricies) to utilize the dual access RAM to its fullest extent.  The architecture of the DSP has many busses for the movement of data in/out of the processor and properly managing these (via variable placement) can significantly speed up your code as the processor pipeline will stall less.

6) Minimize access to I/O space and off chip memory/components.  These paths will cause the processor to stall more often as they are slower mechanisms.  In general, make as many accesses to these spaces via DMA or by using shadow variables (especially in I/O space when configuring peripherals on the fly).

7) Use one channel of the DMA for setting up other DMA's.  You do this by setting up the register configurations in structures located in memory somewhere.  Then write a small function which takes a DMA reference and a pointer to one of these structures and inserts it into the DMA source address and then kick off the DMA.  The DMA will load the configuration structure data into the appropraite DMA channel while the processor can do other preparations.  Then all you need to do is start it when you are ready.  Do this because accessing the I/O is a slow process and consumes multiple cycles which can cause pipe line stalls unnecessarily.  Be careful though, if you expect to port this code to another 55xx processor, not all of them can access the DMA I/O space.  This will work for the 5515 processor.

As for your direct questions...

- GPIO is all managed by CPU. Is there a better way to handle such kind of data acquisition? I saw that SPI is handled by CPU as well... If not, what's the best way to do data acquisition and input filter algorithm independently from the rest of the algorithm? I'm currently using Timer HWIs to execute GPIO receive code. It's okay. But when I put the filter algorithm inside the the HWI, USB requests are blocked which slows down my Target-Host transfer. How would you "organize" those HWIs?

This is certainly a place where you want to take a look at the assembly produced for your code.  The context save and restore code for an ISR can vary but some things just force a complete context save which can be time consuming if you are poping in and out of an ISR quite frequently.  In general, the optimizer will attempt to only save those registers that need saving on entrance to an ISR but if the ISR is large or calls functions in another object, where the optimizer cannot see the register allocations, then it simply will do a complete context save just in case.  If you must use ISR code, your best bet is to do as little as possible in there like read the GPIO and store it in a buffer and return.  Then use a semaphore to tell the baseline code to work on the data as a set instead of a piece at a time.  Even better, you can set up a DMA to read the GPIO and put the data into the buffer.  You will still need to operate on the data using your filter but doing it in the largest chunks possible usually saves time.  A DMA for the SPI os also a good choice for similar reasons.  The idea is to let the DMA do the mundane work while your code does the stuff the DMA cannot.  Also, the GPIO (and all IO space in the processor) has a minimum 5 cycle access time so if your doing this with the processor you are spinning your wheels for a significant amount of time here.

- if I do #pragma MUST_ITERATE .. (how) can I be sure that the code is pipelined or executed in parallel

The MUST_ITERATE pragma does nothing to guarantee parallel opcodes will be generated.  All it does is tell the compiler that the loop will iterate at least once.  This provides the optimizer the information to remove a pretest (for the times if the loop is never executed) and also can clear the path for the optimizer to generate looping structures using DSP instructions which support looping thus making the code smaller and faster.  You should look into the UNROLL pragma as this can further optimize speed by limiting the number of iterations a loop must iterate through which will reduce the looping overhead.  For example, if your code is looping over 5 machine instructions and you have to do a comparison and branch to determine if the loop is complete, then 2 out of the 7 instructions are overhead.  Using the UNROLL pragma you can tell the compiler it would be ok to unroll the loop once thus only having to iterate half as many times.  Now 2 out of 12 instructions are overhead so you have faster execution at the expense of 5 additional instructions.  Without these pragmas, the optimizer must make more pessimistic assumptions which generally result in more generated code and slower execution.

- I have several "element-wise" matrix operations like subtract matrix A from B etc. What is better (see the following exemplary pseudo-code)?

for (i...N)
C[i] = A[i] - B[i]
end
for (i...N)
D[i] = k*C[i]
end
... and many other operations to follow...

OR

for (i...N)
C[i] = A[i] - B[i]
D[i] = k*C[i]
... and many other operations to follow...
end

Generally, the second case will generate faster tighter code but if you put too much inside the loops you can confuse the optimizer and lose some of the benifit.  A happy medium is usully the case, it also depends on the dependency of operations.  For example, if I have 4 arrays (a, b, c, d) and I need to perform the operations of a += b and c += d, then these operations are essentially independent of each other so they can use your second style for loop with a high probability that parallel instructions will be generated.  If the operations were instead to be b += c - d and a += b, then the second assignment is dependent upon the first.  In this case it is unlikely you will get parallelism if you implement these two operations in the for loop so they operate on the same index at the same time.  Instead, if you perform the second operations first iteration before entering the loop and inside the loop perform the operations such that the second operation is always an index ahead of the first, then parallelism can apply.  You just need to do the final iteration on the first operation after the loop.

- w.r.t. to memory operations. I'm currently using memcpy for copy and memset for setting to zero. I imagine that I could get much better performance if I'd use DMA for memory copy. What about setting to zero? What's the best performing method? Doing it manually in a loop?

The DSP is a pretty good device, if you are merely moving data and not performing any operations on it, the DMA may not be significantly faster than the code.  However, the big advantage here is that you can do something else in code while the DMA is moving data around for you.  So if you don't have to wait for the DMA to finish before you can go onto another task, using the DMA is always a plus.  You can use the DMA to set a constant value too.  Just setup the source address to not increment, only the destination address does and then point the source address to a variable where you have placed the initialization value.  If you have a repeating pattern, you can set the DMA to place that pattern as well, effectively a nested for loop implementation.  Also, since the processor operates fastest when accessing the internal memories, you can use the DMA to transfer data between external memory and internal memory saving all that time for your processor to be doing better things.  So my answer is definitely yes, if you can use a DMA then use it!

- and then there's the #pragma DATA_ALIGN ... what impact does it have on the C5515? First, I've seen that for example on the OMAP-L137   DATA_ALIGN (x,128)   is preferable for caching. But why is it DATA_ALIGN (x, 8) on the C5515?

The DATA_ALIGN pragma is never needed per se', however, there are several situations where it can be useful.  If you use and extternal SDRAM, you can align your structures to minimize the number of page commands needed to send across the bus.  Most external memory will be slower than theinternal memory and if the data is layed out so it crosses a 32 bit boundary it can cause additional access to memory thus slowing things down.  The fact that code space is measured in bytes and data space is measrued in words can require an alignment of 2 for constants.  I don't know off hand the reason for the alignment of 8 but I am also not familiar with the development board you are using so I cannot comment as to the validity of it.

You may not need to go all the way to assembly to complete what you want to do.  You can intermix C and assembly quite easily.  The Optimizing compiler guide can show you how.  In this case, you should only need to code in assembly those functions which you cannot get the optimizer to do a decent job at.  Some of the matrix operations may benifit from this as many of them can take advantage of the multiply-accumulate instructions of the DSP.

Hope this has helped,

Jim