TMS320F28075: #2614-D Use --fp_mode=relaxed to enable TMU hardware support for sin.

Leela,

F2807x has the TMU, so you should definitely use that and not the FPUFastRTS library. The FPUFastRTS library is meant to be used where the TMU is not available. The TMU is significantly faster than the FPUFastRTS library. Both the TMU and FPUFastRTS result in some loss of accuracy, which is why the "relaxed" mode is needed to enable the TMU instructions.

Now coming to the specific issues you're facing:

- Increased timing with "relaxed" mode. This clearly means the TMU instructions aren't getting used where they should be. Have you tried looking at the generated disassembly for your code?

- The compiler should automatically replace the sin/cos calls with the corresponding TMU calls, assuming you're using 32b floating point calls. Which calls do you have in your code?

- I can't say offline why your FPUFastRTS function calls aren't returning correct results.

Thanks,

Sira

Hi Sira,

Thank you for your response. I am referring to sprueo2b.pdf and it says fastRTS library is faster. Am I missing something?
 

Thanks,

Leela

Hi Sira,

Per your suggestion, I removed fastRTS library from the project and set the "--fp_mode=relaxed". Below is the assembly code. You can notice that it has TMU instructions,  but still the timing is more than the timing with standard library's sin and cos functions running from RAM. Could you please suggest?

Thanks,

Leela

Hi,

The document you are referring here was written way before the chips with TMU were developed. So this fragment applies only to older chips, without TMU.

Regards,
Andy

Hi Andy,

Thank you for your response. That clarifies why I should not use fastRTS library. 

would you be able to answer my question related to TMU timings?

Thanks,

Leela

Leela,
first I noticed that you are using very old compiler version - 6.4.6. Have you tried the newest one? 
And second: do you have all the optimizations turned on? 
It is difficult to say something about timing, I need to know how you are measuring the time here. And a code snippet would be helpful.

Regards,
Andy

Andy,

Changing compiler version or optimizations are big risk looking at the current status of the project. I am comparing the two methods ( running sin,cos functions of standard library from RAM &  "--fp_mode=relaxed" while keeping compiler version and optimizations same. do you think that is not an appropriate comparison?

Here is my code and looking at the delta in a scope.

1. "--fp_mode=strict"

2. "--fp_mode=relaxed"

Thanks,

Leela

signal is inverted in the scope

I understand your concerns about upgrading the compiler, but I'm also aware of the numerous bugs that were present in old versions and fixed later.
I'm worring that pairing the newest generation chip and such old compiler may be not a good idea, basically because the compiler may not be fully aware of the capability of the chip and the optimization may be worse.
You can always install the new compiler and compile the fragment of code just to compare the assembly outputs of both compilers.
Can you also post here the assembly output of the code above? Including the gpio set and clear instructions?
Is the code executing from flash or ram? What is you cpu frequency and flash timings if executing from flash?

Regards,
Andy

Sorry for the comment about the newest generation chip - the TMS320F28075 is not the newest generation of c28x chips.
Anyway, the newer compiler may generate more efficient code.

Andy

is there a way to run "__relaxed_sin" and "__relaxed_cos" function calls from RAM? Challenge is I cannot find those functions in .map file

Yes, you can place selected functions from a library in RAM.
But if the function is inlined then the parent function have to be placed in RAM. This can be accomplished with simple pragma CODE_SECTION with the function name.
Placing selected routines from rts library have to be done in the linker cmd file.

Regards,
Andy

Andy,

Parent function is already running from RAM and I believe "__relaxed_sin" and "__relaxed_cos" are inlined. so "__relaxed_sin" and "__relaxed_cos" are already running from RAM then. Interesting that time is more than standard library functions. 

Any idea why would sincos function from rts2800_fpu32_fast_supplement.lib report '1' and '1' for both sin and cos for any theta while running standalone. they report appropriate values while running from debugger

Thanks,

Leela

It's funny, I've just commented some other topic and that could apply here as well.

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1162796/tms320f28377d-running-rts2800_fpu-strcmp-function-from-ram-returns-bad-result/4376856#4376856

If the sincos uses some constants from OTP ROM or FLASH it may be the problem of memory security.
Please check if your ram section where you keep your functions belongs to the 'secure' category.

Regards,
Andy

Andy,

I would like you to double check my linker file and see if you find any issues. i do memcpy of fpumathtables during the initialization. 

===================================

MEMORY
{
PAGE 0 : /* Program Memory */
/* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
/* BEGIN is used for the "boot to Flash" bootloader mode */

BEGIN : origin = 0x084000, length = 0x000002
RAMM0 : origin = 0x000122, length = 0x0002DE
RAMD0 : origin = 0x00B000, length = 0x000800
RAMLS0 : origin = 0x008000, length = 0x002000
RESET : origin = 0x3FFFC0, length = 0x000002

/* Flash sectors */
FLASHA : origin = 0x080000, length = 0x002000 /* on-chip Flash */
FLASHB : origin = 0x082000, length = 0x002000 /* on-chip Flash */
FLASHC : origin = 0x084002, length = 0x001FFE /* on-chip Flash */
FLASHD : origin = 0x086000, length = 0x002000 /* on-chip Flash */
FLASHE : origin = 0x088000, length = 0x008000 /* on-chip Flash */
/*FLASHF : origin = 0x090000, length = 0x008000 /* on-chip Flash */
FLASHG : origin = 0x098000, length = 0x008000 /* on-chip Flash */
FLASHH : origin = 0x0A0000, length = 0x008000 /* on-chip Flash */
FLASHI : origin = 0x0A8000, length = 0x008000 /* on-chip Flash */
FLASHJ : origin = 0x0B0000, length = 0x008000 /* on-chip Flash */
FLASHK : origin = 0x0B8000, length = 0x002000 /* on-chip Flash */
FLASHL : origin = 0x0BA000, length = 0x002000 /* on-chip Flash */
FLASHM : origin = 0x0BC000, length = 0x002000 /* on-chip Flash */
FLASHN : origin = 0x0BE000, length = 0x002000 /* on-chip Flash */

PAGE 1 : /* Data Memory */
/* Memory (RAM/FLASH) blocks can be moved to PAGE0 for program allocation */

BOOT_RSVD : origin = 0x000002, length = 0x000120 /* Part of M0, BOOT rom will use this for stack */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAMD1 : origin = 0x00B800, length = 0x000800

RAMLS5 : origin = 0x00A800, length = 0x000800

RAMGS0 : origin = 0x00C000, length = 0x008000
FLASHF : origin = 0x090000, length = 0x008000 /* on-chip Flash */
}

SECTIONS
{
/* Allocate program areas: */
.cinit : > FLASHD PAGE = 0, ALIGN(4)
.pinit : > FLASHD, PAGE = 0, ALIGN(4)
.text : >> FLASHC | FLASHD PAGE = 0, ALIGN(4)
codestart : > BEGIN PAGE = 0, ALIGN(4)

GROUP
{
ramfuncs
{
-l F021_API_F2837xD_FPU32.lib
-l rts2800_fpu32_fast_supplement.lib<sincos_f32.obj>(.text) // load sincos function to ram
}
}
LOAD = FLASHD,
RUN = RAMLS0 ,
LOAD_START(_RamfuncsLoadStart),
LOAD_SIZE(_RamfuncsLoadSize),
LOAD_END(_RamfuncsLoadEnd),
RUN_START(_RamfuncsRunStart),
RUN_SIZE(_RamfuncsRunSize),
RUN_END(_RamfuncsRunEnd),
PAGE = 0, ALIGN(4)

FPUmathTables : LOAD = FLASHF,
RUN = RAMGS0,
RUN_START(_FPUmathTablesRunStart),
LOAD_START(_FPUmathTablesLoadStart),
LOAD_SIZE(_FPUmathTablesLoadSize),
PAGE = 1

/* Allocate uninitalized data sections: */
.stack : > RAMM1 PAGE = 1
.ebss : >> RAMLS5 | RAMGS0 PAGE = 1
.esysmem : > RAMLS5 PAGE = 1

/* Initalized sections go in Flash */
.econst : > FLASHD PAGE = 0, ALIGN(4)
.switch : > FLASHD PAGE = 0, ALIGN(4)

.reset : > RESET, PAGE = 0, TYPE = DSECT /* not used, */

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Thanks,

Leela

Leela,

the linker file looks ok to me. The ramfuncs are copied to the LSRAM which is secure. The code executed from secure memory should have access to both secure and unsecure memories. The FPUTables are in GSRAM, which is unsecure, but like I said, it shouldn't be a problem.
I'm out of ideas.
But anyway, I would try to use TMU, because it should be about 3x faster than sincos from rts2800_fpu32_fast_supplement.

Regards,
Andy

Andy,

TMU is definitely increasing the time. I am not sure why. How can I see the assembly code of sincos function? I can only see below references in the assembly code. Any idea?

LCR       #_sincos  

.global _sincos

Thanks,

Leela

You can view the assembly code of sincos in the library folder in C2000Ware - the source files are included.
The second method is while debugging, open the Dissasembly window in CCS, and then you can step through the assembly code.

Regards,
Andy

Andy,

Thank you for pointing me to the library folder in C2000Ware. That helps. But, can i see the assembly code generated in my project for sincos function? Challenge is it works while debugging mode. Problem is only when running in standalone mode.

Thanks,

Leela

The code in Dissasembly window should be no different in debug or standalone. When assembly stepping you can see the exact instructions of your code, see addresses, etc. You can post here some screenshots of the assembly code.
Of course you can do the same for TMU solution.

Andy

That's great.
But did you try the TMU solution? Because I doubt if the sincos is faster then TMU - the cycles given in the documentation of fast supplement library and the TMU cycles given in the datasheet suggests that the TMU should be about 3x faster.

I encourage you to give it a try.

Regards,
Andy

Andy,

As I shared timings earlier, TMU timings is more than rts2800_fpu32.lib

Here are the numbers again..

TMU = 3.1usec

rts2800_fpu32.lib = 2.7usec

rts2800_fpu32_fast_supplement.lib = 0.4usec

Thanks,

Leela

If that's the case then something is wrong. You should check the generated assembly for TMU.
It definitely should be faster than both libs.

Regards,
Andy