TMS320F28375D: CLA slow compared to FPU

Thanks much!

Hi!

Thank you for your answer above.

I was testing my code and realized some other reasons why it was being slower. I am using arrays a lot (that hold floats) and noticed the CLA runs slower than/same speed as the FPU when

1) I use variables as indexes.

Ex:

Uint16 i,x;

i = 0;

x = array1[i] + array2[i];

array1[] and array2[] are float32 globals and initialized in my main.c

2) Setting a value of an array location

Ex:

Uint16 i;

i = 0;

result[i]= 23.3 + 90.9;

result[] is also a float32 global that is initialized in my main.c

I was wondering if I need to change something for the CLA to run faster? I know if I hardcode the array positions the CLA is faster, but my code needs to use a variable index.

Hi Casey,

I am reaching out to the experts and will let you know any suggestions once I head back from the team.

Thanks,

Ashwini

Hi!

Found one more oddity(?)

3)

when I compare floats("<","<=", ">", ">=") whether from an array or constant, the CLA is slower. (When I compare using "=" or "!=" they are about the same speed).

Ex:

//time: FPU - 40ns; CLA - 60ns

Uint16 x;

if(1.2 < 2.3){

   x = 5;

}

Ex2:

//array was initialized as a global in main as array[3] = {1.2, 3.4, 5.6}

//time: FPU - 0.08μs; CLA - 0.1μs

Uint16 x;

if(array[0] < 2.3){

   x = 5;

}

Thanks!

Hi Casey,

Thanks, I will share this with the team as well.

Can you let me know the compiler version and optimization level being used?

Regards,

Ashwini

Hi!

Compiler: TI v20.2.1.LTS

Optimization Level: off

Speed vs Size trad-offs: 2

Floating point mode: strict

Casey,

Just wanted to let you know that Ashwini is out of the office for a few days, I'll make sure some others have eyes on this post but worst case you can expect a reply by next Thursday the 5th when she is back in the office.

Best,

Matthew

Casey-

When you do a compare such as < or >, the processor has to compute the difference of the argument and evaluate the remainder.  The checking for equality, = or !=, it can be done faster with a bitwise compare.  this might explain the difference.

Hi Casey,

Sorry for the later reply. I gave the 2 examples you posted (reposted below again for reference) a try on CLA and C28 and I did not see a significant difference in the cycle count for the code generated for CLA and C28. Can you post the assembly generated for CLA and let me know how you are benchmarking the CLA?

Ex:

//time: FPU - 40ns; CLA - 60ns

Uint16 x;

if(1.2 < 2.3){

   x = 5;

}

Ex2:

//array was initialized as a global in main as array[3] = {1.2, 3.4, 5.6}

//time: FPU - 0.08μs; CLA - 0.1μs

Uint16 x;

if(array[0] < 2.3){

   x = 5;

}

Thanks,

Ashwini

Hi!

To time the CLA and FPU/C28 code, I used GPIO breakout pins and a logic analyzer to time it. Running it at the same time or separately made no noticeable difference in time.

//in gpio.c
void InitGpio(void)
{
    GpioCtrlRegs.GPBCSEL2.all = 0x00010000 //GPIODAT/SET/CLEAR/TOGGLE reg. master
    GpioCtrlRegs.GPBDIR1bit.GPIO39 = 1;
    GpioDataRegs.GPBSET.bit.GPIO39 = 1;
    GpioCtrlRegs.GPBDIR.bit.GPIO44 = 1;
    GpioDataRegs.GPBSET.bit.GPIO44 = 0;
}

//in ClaTasks_C.cla
//have a ADC trigger this task once in a while
interrupt void ClaTask1 (void)
{
    GpioDataRegs.GPBSET.bit.GPIO44 = 1;
    Uint16 x;
    x = 0;
    if(1.2 < 2.3){
        x = 5;
    }
    GpioDataRegs.GPBCLEAR.bit.GPIO44 = 1;
}

//in test.c
//gets called in main function loop
void sampleFunction (void)
{
    GpioDataRegs.GPBSET.bit.GPIO39 = 1;
    Uint16 x;
    x = 0;
    if(1.2 < 2.3){
        x = 5;
    }
    GpioDataRegs.GPBCLEAR.bit.GPIO39 = 1;
}

Here is the assembly code for the section:

22 GpioDataRegs.GPBSET.bit.GPIO44 = 1;
Cla1Task1(), c:
0000a60a: 78410000 MMOVIZ MR1, #0x0
0000a60c: 75807F0A MMOVZ16 MR0, @0x7f0a
0000a60e: 78811000 MMOVXI MR1, #0x1000
0000a610: 7C800004 MOR32 MR0, MR1, MR0
0000a612: 75C07F0A MMOV16 @0x7f0a, MR0
24 x = 0;
0000a614: 78400000 MMOVIZ MR0, #0x0
0000a616: 75C08000 MMOV16 @0x8000, MR0
26 x = 5;
0000a618: 78400000 MMOVIZ MR0, #0x0
0000a61a: 78800005 MMOVXI MR0, #0x5
0000a61c: 75C08000 MMOV16 @0x8000, MR0
28 GpioDataRegs.GPBCLEAR.bit.GPIO44 = 1;
0000a61e: 78410000 MMOVIZ MR1, #0x0
0000a620: 78811000 MMOVXI MR1, #0x1000
0000a622: 75807F0C MMOVZ16 MR0, @0x7f0c
0000a624: 7C800004 MOR32 MR0, MR1, MR0
0000a626: 75C07F0C MMOV16 @0x7f0c, MR0
29 }

Also, sorry if you're still testing but did you have a chance to try out my other 2 findings mentioned above:

1) I use variables as indexes.

Ex:

Uint16 i,x;

i = 0;

x = array1[i] + array2[i];

array1[] and array2[] are float32 globals and initialized in my main.c

2) Setting a value of an array location

Ex:

Uint16 i;

i = 0;

result[i]= 23.3 + 90.9;

result[] is also a float32 global that is initialized in my main.c

The part you answered in your most recent response is only my point #3.

Hi Casey,

Thanks for posting the assembly. I will take a look and get back to you tomorrow. Upon a brief look it appears that the GPIO write at the end of the function could be adding to the overhead.

I would recommend using the method mentioned in the link below where the EPWM is used to measure the execution in clock cycles instead. By looking at the assembly the clock cycles can be adjusted to account for EPWM read overhead to get exact cycles. That will be easier to compare with similar profiling on C28 side using same EPWM or CPU timer0.

https://software-dl.ti.com/C2000/docs/cla_software_dev_guide/faq.html#how-can-i-measure-the-duration-of-a-task

Thanks,
Ashwini