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.

OMAP-L138 LCDK, DSPLIB DSPF_sp_cfftr2_dit with Inverse

Other Parts Discussed in Thread: OMAP-L138

When using the assembly-optimized dsplib library on the OMAP-L138 LCDK, I encounter a quirk with subsequent calls to DSPF_sp_cfftr2_dit and DSPF_sp_icfftr2_dif. The API states that the twiddle factors should be bit-reversed; however upon performing this action to both the transform and inverse twiddle factors, there is distortion present in an N=32 sized transform. If the twiddle factors are passed non-bit-reversed in back-to-back transform/inverse calls, this distortion is not present. Why might this be the case? Code snippet is as follows, for context:

FFT operations within ISR:

    // Extract data (complex) from input framebuffer
    for (i=0; i < BUFFER_COUNT; i++) {
    	// Populate input sample arrays
    	inpLcpx[2*i] = Left[i];
    	inpLcpx[2*i+1] = 0.0;
    	inpRcpx[2*i] = Right[i];
    	inpRcpx[2*i+1] = 0.0;
    }

    // Calculate FFT using call to optimized-assembly DSPF_sp_cffrt2_dit
    DSPF_sp_cfftr2_dit(inpLcpx, twiddle, BUFFER_COUNT);
    DSPF_sp_cfftr2_dit(inpRcpx, twiddle, BUFFER_COUNT);

    // Calculate IFFT using call to optimized-assembly DSPF_sp_icfftr2_dif
    DSPF_sp_icfftr2_dif(inpLcpx, twiddleInv, BUFFER_COUNT);
    DSPF_sp_icfftr2_dif(inpRcpx, twiddleInv, BUFFER_COUNT);

    // Then pack real data into output framebuffer
Twiddle factors are generated as follows. Call is to method defined within ISR, from main:
void twidInit()
{
	int i=0;
	float a = 2.0f*PI/BUFFER_COUNT;
	for (i=0; i < BUFFER_COUNT; i+=2) {
    	     // Populate twiddle factors
             twiddle[i] = cosf(-(i/2)*a);
             twiddle[i+1] = -sinf(-(i/2)*a);
             twiddleInv[i] = cosf((i/2)*a);
             twiddleInv[i+1] = -sinf(-(i/2)*a);
	}

}

 
  • 7026.fft_eg.zipHi Max,

    I suspect the problem is caused by the twiddle factors you're using.

    The API documentation for DSPF_sp_cfftr2_dit() states the following:
    The imaginary coefficients of w are negated as {cos(d*0), sin(d*0), cos(d*1), sin(d*1) ...} as opposed to the normal sequence of {cos(d*0), -sin(d*0), cos(d*1), -sin(d*1) ...} where d = 2*PI/n.

    This isn't explicitly stated in the API documentation for DSPF_sp_icfftr2_dif(). However, the unit test drivers for both kernels use twiddles that following this convention.

    I wrote a test program to see if I could identify any problems with these kernels when they're called back-to-back. I experimented with different types of input signals, including real sinusoids, complex exponentials, and uniformly distributed random numbers. I wasn't able to find any problems for N=32 or N=256. I've attached my test program and the matlab scripts I used for generating the test input vectors.

    Could you try the twiddles in the unit test drivers for the kernels and see if this resolves the problem?

    Thanks and regards,

    Frank

  • Could I asked a question that what the "kernels" means in the dsplib. I am using the code demenstration of DSPF_sp_ifftSPxSP_d.c which shows that the "kernel_size " are not able to be found, and I deleted it. The code is successfully complied but with incorrected results. 

    There is another question that sometimes one programme containing the code "include <DSPF_sp_ifftSPxSP.c>" is right but the error of "con't find the file" appears when using another CCS(5.3) platform.

    Thank you very much!