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.

AM2754-Q1: Limitation on NFFT i.e., FFT length/size in FFTLIB

Part Number: AM2754-Q1
Other Parts Discussed in Thread: FFTLIB

Tool/software:

Hello Team,

I had created a wrapper for C7x optimized FFT computation based on the Real-to-Complex kernel FFTLIB_fft1d_i32f_c32fc_o32fc for running C7x_0 based applications. While testing for various FFT lengths, it is observed that for N=32, we get a return of 4 (FFTLIB_ERR_INVALID_DIMENSION). Inspecting the kernel source code i.e., freertos_sdk_am275x_11_00_00_16/source/fftlib/src/fft_c7x/FFTLIB_fft1d_i32f_c32fc_o32fc/c71/FFTLIB_fft1d_i32f_c32fc_o32fc_ci.cpp, I see that in the FFTLIB_fft1d_i32fc_c32fc_o32fc_checkParams() function, there is a condition (with comment):


   
else if (bufParamsX->dim_x < 64 * 2) { /* Minimum number of points is 64 */
      status = FFTLIB_ERR_INVALID_DIMENSION;
      }

So, I would like to:
  1. confirm that, as per the source code, clearly, my FFT lengths of N=32 is not supported (but couldn't find this information in the FFTLIB documentation) for the C7x optimized implementation. Right? It seems the test cases for the FFTLIB_fft1d_i32f_c32fc_o32fc kernel driver seems to not include N=32 as well.
  2. know why the check for dim_x is for NFFT * 2? Are we expected to store bufParamsData.dim_x as NFFT * 2 as well? I had followed the test driver freertos_sdk_am275x_11_00_00_16/source/fftlib/test/fft_c7x/FFTLIB_fft1d_i32f_c32fc_o32fc/FFTLIB_fft1d_i32f_c32fc_o32fc_d.c for my FFT wrapper and it seems to set bufParamsData.dim_x as NFFT. Am I right to follow

I would really appreciate if the above queries are answered for a clearer understanding of the FFTLIB.

Regards,
Sreekanth

  • Hi Sreekanth,

    confirm that, as per the source code, clearly, my FFT lengths of N=32 is not supported (but couldn't find this information in the FFTLIB documentation) for the C7x optimized implementation

    Yes, that's right. The optimised version doesn't support fft length of N=32 and the lib falls to natural C implementation for the lengths less than 64. This is done because smaller than 64 length doesn't gain anything performance-wise due to ineffiicient use of Streaming Engine.

  • know why the check for dim_x is for NFFT * 2? Are we expected to store bufParamsData.dim_x as NFFT * 2 as well? I had followed the test driver freertos_sdk_am275x_11_00_00_16/source/fftlib/test/fft_c7x/FFTLIB_fft1d_i32f_c32fc_o32fc/FFTLIB_fft1d_i32f_c32fc_o32fc_d.c for my FFT wrapper and it seems to set bufParamsData.dim_x as NFFT. Am I right to follow

    You are right to follow the FFTLIB_fft1d_i32f_c32fc_o32fc_d.c for your wrapper implementation. The complex numbers are stored in interleaved order in the output buffer i.e.(real1, imag1, real2, imag2,...), hence the need for NFFT * 2. For the input, you  don't need the dim_x to be NFFT * 2.

    Thanks,

    Shreyansh

  • Hi Shreyansh,

    Thanks for the response. Is there a document which I can refer to that captures details like these? Couldn't find these in the library docs. Some information on FFT lengths that are supported by the library explicitly stated would be of great help.

    Regards,

    Sreekanth

  • Hi Sreekanth,

    Thanks for the response. Is there a document which I can refer to that captures details like these?

    I am not aware of any document that captures this. I have discussed it with the team internally, and the plan is to include such information in the user guide document in future releases.
    Thanks,
    Shreyansh