• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 435 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5994: LEA FFT slower than expected

Fred P
Expert 2235 points

Part Number: MSP430FR5994
Other Parts Discussed in Thread: ENERGYTRACE

I did some bechmark on the real FFT call msp_fft_fixed_q15().

I get results much higher than what is expected from SLAA698B. The scores I get are even higher than what is expected from complex fft calls.

From table 7, I was expecting:
N=64 -> 913 cycles
N=128 -> 1766
N=256 -> 3568

What I get is:
N=64: ~4000
N=128: ~5500
N=256: ~7500

I also have a quite wide variation for N=256, ranging from 6320 to 8000 cycles. N=128 varies less and N=64 is pretty stable.

Referring to table 1, my scores are much faster than without LEA and tracing the code reveals a wait on LEA interrupt flag at some point. So LEA does look alive (but not well?).

However, EnergyTrace does not show any LEA activity...

What can be going on here?

Regards,

Frederic

  • 0
    TI__Mastermind 26375 points

    Hi Frederic, I guess that LEA FFT is slower than expected because LEA is disable. Please refer to: https://e2e.ti.com/blogs_/b/process/archive/2017/10/16/visualizing-the-performance-of-the-low-energy-accelerator

  • 0 in reply to Xiaodong LI
    Expert 2235 points

    I feel you read through my post a little fast.

    If LEA was disabled, it would be waaaay slower, around 50k-100k cycles as shown in your link.  I am nowhere near that score.

    I also traced the code into the lib and LEA is definitely enabled since it waits on LEA interrupt flag.  If it was disabled, I would end up in the extensive math, which are well grayed out by CCS, instead of msp_lea_enterLPM().  Or I would at least get wrong results and a very low cycle count if LEA was not doing its job.  It is not the case.

    As for EnergyTrace++ not showing LEA activity might be related to its 1kHz sampling rate over Spy-by-wire.  Sampling may well fall in between LEA activity.

    So it looks like LEA works, doesn't it?  Do you have some other way to assert LEA operation?

    That being said, I believe I understand why I get slower performance than expected.

    I gathered better benchmarking statistics and noticed a key element: difference between expected and measured cycle counts is "constant".

    There is some variability but if I stick to the mode, difference is constant.  Moreover, the mode is the minimum value.

    I would blame that on some system interrupts delaying the call to msp_benchmarkStop().

    However, Real FFT is running barely faster than complex FFT at N=256, and actually a bit slower at N=128 and N=64.  I believe this is related to the to code overhead required by the real FFT calling msp_split_q15().  That is not taken into account by Table 7.

    It appears the benefit of real FFT over complex FFT happens with N>256.

**Attention** This is a public forum