Process ADC data, moved by DMA, using CMSIS DSP: what's the right way?

Hi,

I did not follow the entire subject bu since my name is quoted here, I thought I would take a look !

Regarding speed comparison and optimization issues, can you tell which compiler you are using with which options ?

I you link with CMSIS_DSP library which is most likely built with ARM compiler (5, 6 ?) with high optimizations. Your code may not be comparable in terms of speed if built let's say with GCC !

If I caught your need properly, you need to detect min and max over a buffer of 12-bits signed integers ?

Can you show your computation code ?

First of all, I'll talk about what's (in theory) slow about your shift operations.

Normally, the compiler should figure this out by itself, but if you've turned off optimizing, it's not going to happen.

*pSrc = (*pSrc) << shiftBits;
*pSrc = (*pSrc) >> shiftBits;

We don't need to go down to the assembly-level.

This is what happens in unoptimized code:

1: Read a value from memory

2: Shift a value by n positions

3: Store a value in memory

4: Read a value from memory

5: Shift a value by n positions

6: Store a value in memory

Reading a value from memory require 2 clock cycles.

Shifting the value to the left or right requires 1 clock cycle.

Storing the value requires 1 clock cycle.

If the code is not optimized by the compiler, then the code can be improved by removing step 3 and step 4.

As I can not see the full loop, I can't give a full suggestion on optimizing; except from what I've written earlier.

My earlier suggestion adapted to shifting:

void ...(...)
{
     register int32_t        i;     /* index */
     register uint32_t       *d;    /* destination */


     d = &((int32_t *)pSrc)[i];     /* (destination seems to be the same as source) */
     i = -length;                   /* convert length of array to a negative index */
     do
     {
          d[i] = (d[i] << shiftCount) >> shiftCount;
     }
     while(++i);                    /* increment index and keep going until i wraps to 0 */
}

In other words: do not split up the shift in several 'stages', it might make an impact performance, as the code could grow.

If the code is build as I planned, it would result in something like this:

     adds.n   r0,r0,r1,lsl#2     /* point d to end of array */
     rsbs.n   r2,r1              /* index = -length */
loop:
     ldr.n    r0,[r1,r2]         /* [2] get 12-bit ADC value */
     sbfx.w   r0,r0,#0,#12       /* [1] sign-extend it to 32 bits */
     str.n    r0,[r1,r2]         /* [1] store the sign-extended result */
     adds.n   r2,r2,#4           /* [1] increment index */
     bne.n    loop               /* [1/1+P] go round loop until index wraps to 0 */

The numbers in square brackets are how many clock-cycles I expect the code to spend.

The last one has the format [branch not taken/branch taken], where P is 'prefetch'; P is a value between 1 and 3 (normally 1).

That means if your code runs from SRAM, then per sample, it should cost 7 clock cycles if P is 1.

We'll add an extra clock cycle, so we won't be disappointed .. Dividing 204MHz by 8 clock cycles allow us to process 25 million samples per second.

However! You also need to remember that the DSP needs to process the data.

In addition to using the above loop, I recommend changing the optimization level.

If I understand correctly, LPCXpresso is using gcc, and if that's the case, then it's easy for me to tell you how to change the optimization level:

In case you're able to run your gcc from the command-line, try this:

arm-none-eabi-gcc --help=optimizers

-It will give you a long list of optimization options, but the following is the important one: -O<number>.

Normally I use -Os (for size optimization), but that's not what you want in this case!

-Ofast is another way of saying you want fast code; here's the description: "Optimize for speed disregarding exact standards compliance".

From what I can see on NXP's web-site, you need to specify the setting inside the IDE; here's where they say it is:

Project -> Properties -> C/C++ Build -> Settings -> Tool Settings -> MCU C Compiler -> Optimization -> Optimization Level

I recommend first trying -O3

I usually write my own code in a way, so that even when optimization is disabled, the code is almost just as efficient.

The most important thing you can do is to get the optimization working; it should improve performance very much; especially if the compiler unrolls loops (unrolling means more operations per branch - or less branches per operation; have your pick).

Hi Thibaut, indeed I thought that since I'm evaluating your code it was proper to link your blog! And of course any hint from you would be welcomed.
Actually I tried to reply to your questions in the section below trying to merge your answer with Jen's one.

If I caught your need properly, you need to detect min and max over a buffer of 12-bits signed integers ?

That's right!
And I believe that your implementation while save me a lot of computational time: I quoted the code in the answer below.

Line 19, 20, 36 and 37 looks very wrong to me.

To me, it seems you're doing the same job twice.

Eg. after 8 iterations, the values you've already sign-extended, will be sign-extended again.

I could be wrong, but I better mention it; are you sure that they're doing what you want ?

(I would remove them completely)

About the 'prefetch' on branches (P):

Prefetch only happens when necessary. It's not really something you're in control of (especially not when using C code).

-But it may be 3 the first time the branch jumps back in the loop and then 1 from that point on.

If an interrupt happens while you're inside the loop, P might become 3 again.

But as you see, this is something that's rare, so I think you can assume the value 1.

RAM usage looks great. There's plenty for placing code in SRAM in a section that does not collide with the DMA.

As far as I can tell, the DMA buffer is somewhere in RamLoc128.

That means you can pick any of the other ram locations (I'd suggest one of the AHB sections) for the code.

Now, I just don't know which address RamLoc128 is.

(I particularly like that NXP measure 0 Bytes in GB).

About Optimization:

Line 19, 20, 36 and 37 looks very wrong to me. [...]
are you sure that they're doing what you want ?

Unfortunately no, I'm not: the purpose of those lines is to point to the 2nd value of the pair that is being processed by Thibaut's function and sign-extend that value!
I tried to figure out how much I needed to move my pointer to get the next-sample address by looking at the samples' address trough the debugger, maybe I was wrong?

so I think you can assume the value 1

That's ok for now, won't thinker with it.

Today I did some tests using the -O3 optimization level for my project and the result is great (using thibaut's function with no sign extension): the elapsed time for 128 sample is roughly 18us  compared to the 160 without optimization!
Fun fact: compiling the CMSIS DSP with -O2 gives slight better performance than using -O3! (updated the old post)

Speaking of the Memory Layout:

RAM usage looks great. There's plenty for placing code in SRAM in a section that does not collide with the DMA.

As far as I can tell, the DMA buffer is somewhere in RamLoc128.

Yes, I completely agree: as I can see in LPCXpresso project's properties RamLock128 starts @ 0x10000000 (you can look for it in the picture posted my recap).

That means you can pick any of the other ram locations

Next step on this front I'll try to do: understand how I can do this.

It's great to hear about the optimization results.

abet wrote:

Today I did some tests using the -O3 optimization level for my project and the result is great (using thibaut's function with no sign extension): the elapsed time for 128 sample is roughly 18us  compared to the 160 without optimization!

Fun fact: compiling the CMSIS DSP with -O2 gives slight better performance than using -O3! (updated the old post)

The -O2 is a great observation. This might be connected to that -O3 most likely unrolls the loops more than -O2.

If that's the case, it means that fetching the code from SPIFI slows down (I'm only guessing here).

If it's possible for you to link to a binary version of a pre-compiled CMSIS DSP library, try that.

I know that the people who have developed the DSP library have spent very much time on optimizing it; like that was the most important thing in thw World for them,.

-So if a precompiled library exists and you can link directly to that, then you'll most likely get the best performance regarding the DSP library.

Regarding the sign extension, there is a very simple way to do it : change the scale of your data !

If I understood properly, your sample buffer holds 16-bits values in which 12 lowest significant bits are the ADC output value in 2-s complement and I expect you have 4x 0-bit in front (bits 15-12).

I would symbolize this sample pair like that : sample n (0x0SA1), sample n+1 (0x0SA2)

When you use *__SIMD32(pSrc), it loads a register with both samples (0x0SA20SA1), then you just need to shift left by 4 bits to have 0xSA20SA10 which is a pair of signed 16-bits values !

I you need to keep your samples for further computations, you can write back to memory with this new scale.

This would give something like :

uint32_t SearchMinMax16_DSP(int16_t* pSrc, int32_t pSize)  
{  
    uint32_t data, min, max;  
    int16_t data16;  
  
    /* max variable will hold two max : one on each 16-bits half 
     * same thing for min 
     */  
  
    /* Load two first samples in one 32-bit access */  
    data = *__SIMD32(pSrc);
    /* put significant bits on bits 15-4 instead of 11-0 on each halfword */
    data <<= 4;

    /* Write back to memory to have useable 16-bits samples, increment source pointer by a pair of samples */
    *__SIMD32(pSrc)++ = data;

    /* Initialize Min and Max to these first samples */  
    min = data;  
    max = data;  
    /* decrement sample count */  
    pSize-=2;  
  
    /* Loop as long as there remains at least two samples */  
    while (pSize > 1)  
    {    
  
        /* Load next two samples in a single access */  
        data = *__SIMD32(pSrc);
        /* put significant bits on bits 15-4 instead of 11-0 on each halfword */
        data <<= 4;

        /* Write back to memory to have useable 16-bits samples, increment source pointer by a pair of samples */
        *__SIMD32(pSrc)++ = data;

        /* Parallel comparison of max and new samples */  
        (void)__SSUB16(max, data);  
        /* Select max on each 16-bits half */  
        max = __SEL(max, data);  
        /* Parallel comparison of new samples and min */  
        (void)__SSUB16(data, min);  
        /* Select min on each 16-bits half */  
        min = __SEL(min, data);  
  
        pSize-=2;  
    }  
    /* Now we have maximum on even samples on low halfword of max 
     * and maximum on odd samples on high halfword */  
    /* look for max between halfwords 1 & 0 by comparing on low halfword */  
    (void)__SSUB16(max, max >> 16);  
    /* Select max on low 16-bits */  
    max = __SEL(max, max >> 16);  
  
    /* look for min between halfwords 1 & 0 by comparing on low halfword */  
    (void)__SSUB16(min >> 16, min);  
    /* Select min on low 16-bits */  
    min = __SEL(min, min >> 16);  
  
    /* Test if odd number of samples */  
    if (pSize > 0)  
    {  
        data16 = *pSrc;  
        /* put significant bits on bits 15-4 instead of 11-0 on low halfword */
        data16 <<= 4;
        /* Write back to memory to have useable 16-bits sample */
        *pSrc = data16;

        /* look for max between on low halfwords */  
        (void)__SSUB16(max, data16);  
        /* Select max on low 16-bits */  
        max = __SEL(max, data16);  
  
        /* look for min on low halfword */  
        (void)__SSUB16(data16, min);  
        /* Select min on low 16-bits */  
        min = __SEL(min, data16);  
    }  
  
    /* Pack result : Min on Low halfword, Max on High halfword */  
    return __PKHBT(min, max, 16); /* PKHBT documentation */  
}  

With proper optimization options, I expect this to be quite efficient.

Yes, this is quite efficient!

It might be possible to gain 2 extra clock cycles per iteration by further unrolling, eg. processing four 16-bit samples at a time.

-It requires reading the vaiues contiguously.

Eg. if the two load instructions are next to eachother, then a clock cycle will be saved.

Another clock cycle is saved on the branch, we're saving.

Explained in detail; this sequence will save 2 clock-cycles:

load : load: process : process : store : store : branch

This sequence will only save one clock-cycle:

load : process : store : load : process : store : branch

(the end of the while loop represents the branch)

Each time the unrolling doubles, 2 clock cycles are saved until there are not enough free registers.

If we keep the DMA buffer's size divisible by 16 or a higher power of two, we do not need the 'cleanup' for the remaining values.

That would make the code a little simpler and easier to maintain.

RAM usage looks great. There's plenty for placing code in SRAM in a section that does not collide with the DMA.

As far as I can tell, the DMA buffer is somewhere in RamLoc128.

That means you can pick any of the other ram locations (I'd suggest one of the AHB sections) for the code.

Now, I just don't know which address RamLoc128 is.

Jens, if code will be run in SRAM the location should be at 0x10000000, the start of RamLoc128. It should be the data space and DMA buffer that must be relocated. This is because RamLoc128 (starting from 0x10000000) is the area where the bootloader copies and executes the image from SPIFI (and other external source) when not executing in place.

(I particularly like that NXP measure 0 Bytes in GB).

From your post above:

    I needed to add the SPIFI Flash in order to use the Link2 as evaluation board (as described here: Introduction to Programming the NXP LPC4370 MCU Using the      LPCxpresso Tools and Using Two LPC-Link2 Boards and here: Using an LPC-Link2 as an LPC4370 evaluation board | NXP Community

Using the LPC-Link2 with SPIFI Flash as the boot source is described in those two pages. What Jens is recommending is to execute from SRAM for the code to run faster. This means that you will add SPIFI Flash but program execution should not be directly from that location. The code from Flash should be copied to SRAM and executed there.

Yes, I completely agree: as I can see in LPCXpresso project's properties RamLock128 starts @ 0x10000000 (you can look for it in the picture posted my recap).

Next step on this front I'll try to do: understand how I can do this.

From my reply to Jens, the code should be run from 0x10000000, the start of RamLoc128. It should be the data space and DMA buffer that must be relocated.

Regarding the sign extension, there is a very simple way to do it : change the scale of your data !

Before Andrea posted what he is doing with the samples, this is not an advisable trick. Now that finding the minimum and maximum values seems the only task to be done, left-shift/change of scale is a simple but effective way of sign extension.

For this project, writing a custom function for searching the minimum and maximum values rather than using the CMSIS functions is more advantageous. This is because the input samples need to be sign-extended first and the search for minimum and maximum values can be combined in a single function.

... I know I asked info about floating point conversion so, I would be happy to give the correct answer to Goodwin cause his insight is great, but then I'd need to open up a new post to continue the interesting optimization discussion.

Please, let me know if a way is better than the other and what I should do, I really don't want to take advantage of anyone.

The floating point conversion did not solve your problem. I just thought it might help if we try to find a better way of converting the samples to floating-point format. You can mark one of Jens' or thibaut's reply as the correct answer since they provided high-caliber codes and tips on optimization. It's more than enough that you are very responsive and you acknowledged the effort of those who reply.

If you are planning to have expanded discussion regarding optimization, especially new question(s), it will be better if you open a new discussion about it.

In this project I need to use the ADCHS to sample gaussian-shaped impulsive signals like these:

I only have very very little knowledge about ionizing-radiations but I think signed data format is unwieldy for the type of signal you are processing. Perhaps the quantity you are measuring is somehow associated with energy. Anyhow it's quite unusual to use negative values for gaussian-shaped signal like this.

Yesterday there was an important update to the project and a collegue was able to tell me that we need at least 40 samples (or 128 on the entire 10us duration) per spike, so this acquisition can't be slower than roughly 1.25 Msps.

(Note that I still hope to be able to perform a 40Msps acquisition and understand how to get out the most from this micro, since this would open a whole set of possibilities for the applications of my project)

If you can use an unsigned data type for the samples I speculate that you can still gain improvement in processing speed. This is because you might be able to use the data from the DMA buffer directly, no need for sign extension. You can configure the ADC for offset binary format, pack 2 samples per word, and have bits 31 to 28 and 15 to 12 read as 0. In that case the maximum value will be the one closest to 4095 and the minimum value will be the one closest to 0. As can be seen from the plot there are only peaks and valleys there is no trench.