TMS320F280039C-Q1: CPU cannot finish the calculation in 33.33us interrupt in PFC control

Hi,

Our expert on this topic is out of office for two weeks. Is it ok to wait for his return? 

Thanks,

Ben Collier

Hi Ben

I think the expert might be Sira? it is ok, I have some workaround, such as reduce some "if- else-" branch, but still need expert help to look into the root cause.

I will follow up latter.

Thanks

Joe

Yes, and ok sounds good. 

Hi Ben

Seems that Sira backs to office, could you please help to re-assign the E2E thread to him?

Thanks

Joe

Hi Joe,

What optimization level is specified for the project?

Have you checked whether the divisions on the C28x side are using the TMU?

The C28x should be faster than (or as fast as) the CLA for the operations you have described.

Can they share the code?

Thanks,

Sira

Hi Sira

Sorry for the delay, I do not have F280039 LP for now, but I do the following test with F280049 LP:

The Basic projects are : timer_ex1_cputimers and cla_sin,

The optimization level setting is shown below:

Test 1: In the project "timer_ex1_cputimers" I add below statement to calculate 512 and use CPU TIMER0 to record the time:

// for (i = 0; i<10; i++)
// {

for (j = 0; j<512; j++)
{
sinf(test_input[j]);

}

//}

Test result 1:

17984 cycles are needed for 512 times sinf() calculation in CPU.

179456 cycles are needed for 5120 times sinf() calculation in CPU.

Test 2: In the project "cla_sin" the same statement is added in CLAtask1, the CPUTimer_startTimer() is added before Cla1ForceTask1andWait() and CPUTimer_stopTimer() is added behind WAITSTEP:

Test result 2:

8011 cycles are needed for 512 times sinf() calculation in CLA.

77416 cycles are needed for 5120 times sinf() calculation in CLA.

Test 3: In the project "cla_sin" I use the statement below in CLAtask1, the CPUTimer_startTimer() is added before CLA_forceTasks() and CPUTimer_stopTimer() is added in the first line of cla1Isr1() :

// for (i = 0; i<10; i++)
// {

for (j = 0; j<512; j++)
{
x = i+j;
//CLAsin(test_input[j]);
}
// }

Test result 3:

10319 cycles are needed for 512 times + calculation in CLA.

102791 cycles are needed for 5120 times + calculation in CLA. (CPU do this with 77010 cycles)

The test shows that sinf runs faster in CLA than in CPU.

My question can be narrow down to how to improve the CPU running efficiency for sinf?

Thanks

Joe

Joe,

Looking at your optimization settings, fp_mode = relaxed which is goog. However, the optimization level (--opt_level) is off. This prevents TMU instructions from being generated. Please change it to 2 atleast. 

Thanks,

Sira

Hi Sira

Thanks for your guidance, I changed the optimization level (--opt_level) to 2, that helps me reduce the CPU time consumption dramatically.

Test result: 97485 timer0 cycles for 5120 sinf calculation with --opt level 2, (179456 with --opt level off)

But the compiler ignores my test code at first, and it becomes normal after I add "volatile" before variable claim. So I think if customer changes the --opt level to 2 directly in the mature project, they may find their program performance changed to the unexpected state. 

Support needs:

Could you please help to suggest where users need to check when change --opt level from off to 2?

Or can user do not set the --opt level for the whole project, just for the ISR?

Thanks

Joe

Hi Sira

Thanks for your reply, I changed the benchmark code according to your guidance, finally I can see the 5120 sinf consume 71782 timer0 counts in CPU and 77416 timer0 counts in CLA, that's align with :

Sira Rao80 said:

The C28x should be faster than (or as fast as) the CLA for the operations you have described.

Best regards

Joe

Hi Sira

One more question:

Sira Rao80 said:

the optimization level (--opt_level) is off. This prevents TMU instructions from being generated. Please change it to 2 atleast. 

Is there any guidance for this? I cannot find the exact statement in SPRU514Z 3.1 and 3.16 that --opt_level off prevent the TMU instructions from being generated.

Thanks

Joe 

Joe,

Agreed, this is not mentioned. Can you take a look at your code and check whether TMU instructions are generated with optimization off.

Thanks,

Sira

Hi Sira

Sorry for the delay, Seem in both --opt_level off and --opt_level 2, the TMU function __relaxed_sinf is called and there is no large differences in disassembly view?

--opt_level off                                                                 --opt_level 2

Thanks

Joe

Joe,

That confirms it then. TMU instructions are still generated with Optimization OFF, as long as fp_mode = relaxed. But enabling optimizations helps with performance on the rest of the code.

Thanks,

Sira

Hi Sira

It is strange that there is large cycle differences with --opt level 2 and --opt level off, but any way I will try a single sinf() calculation again to see the time cost.

Joe Ji said:

Test result: 97485 timer0 cycles for 5120 sinf calculation with --opt level 2, (179456 with --opt level off)

Thanks

Joe