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.

Problems with C64x+ DSPLIB IFFT function

I am having an issue with the DSP_ifft16x16 function that I'm hoping someone can please help me with.  I am using the C6455 in little endian, C64x+ dsplib version 3.0.0.8. 

I'm trying to do a simple 256 point FFT/IFFT test to basically get back the original data.  The input data is all real values with no imaginary component. It has the first 64 values equal to 32+0j, (ie. x_16x16  = [32 0  32 0 32 0...etc] and the rest is zero padded.

Twiddle factors for the FFT and IFFT are generated with:
gen_twiddle_fft16x16(wfft_16x16, FFT_SIZE);
gen_twiddle_ifft16x16(wifft_16x16, FFT_SIZE);

The FFT function works as expected. FFT is called and the results are the same as Matlab:
DSP_fft16x16(wfft_16x16, FFT_SIZE, x_16x16, y_16x16);

IFFT is then called with:
DSP_ifft16x16(wifft_16x16, FFT_SIZE, y_16x16, xout_16x16);

The values of xout is about 4 times greater than x (ie. x = 32, xout = ~1024), which is expected due to the scaling.  However, instead of getting 64 real values of ~1024, I get some values that are negated. (ie. real(xout) = 1023, 1028, -1022, 1030, 1026, -1023, etc)

Does anyone know why I would get negative values instead of the expected positive 64 real values? I'm using separate twiddle factors for the IFFT and I don't think I'm having a scaling issue here.  Thank you very much in advance for any help provided.

  • There appears to be a problem in the original example code that comes with DSPLIB ver 3.0.0.8 for 16x16 IFFT.

    In your code, if you change gen_twiddle_ifft16x16(wifft_16x16, FFT_SIZE) to gen_twiddle_ifft16x16_sa(wifft_16x16, FFT_SIZE), your problem should be fixed.  The following are what I got for the first 64 complex samples of IFFT output in the order of Real, Imag, Real, Imag with the same kind of input as you have for FFT.

    128 1 130 5 129 3 133 8
    130 2 128 0 128 0 131 4
    128 2 127 2 130 1 131 2
    128 3 129 3 129 -1 131 1
    127 0 129 1 128 2 127 3
    131 1 128 1 129 1 128 2
    127 1 126 1 128 0 127 1
    128 1 131 2 129 2 128 1
    126 1 127 0 126 0 130 3
    126 3 130 -2 127 3 126 1
    127 0 126 1 129 0 127 -1
    127 1 127 0 128 0 129 -1
    128 1 128 -1 125 0 125 -1
    124 -1 131 0 128 0 126 -1
    127 0 128 0 129 4 129 1
    124 2 127 -2 125 2 127 -1

  • That did the trick!  Thank you very much!!!

  • When should (and shouldn't) the "_sa" version be used?  gen_twiddle_ifft16x16() has Big and Little Endian versions, whereas gen_twiddle_ifft16x16_sa() does not.

     

  • On further investigation, gen_twiddle_ifft16x16_sa() appears identical to the _LITTLE_ENDIAN version of gen_twiddle_ifft16x16().

    And does the "_sa" have some link with "serial assembly (SA) implementation" (phrase spotted at "http://processors.wiki.ti.com/index.php?title=FFT_Implementation_With_No_Data_Scaling")?  Does this count as a clue in TI's "Guess he Acronym" game?  Does this mean that the C code in DSP_ifft16x16.c is just indicative of the algorithm used and the library contains hand-coded linear assembly?

  • Hi Tim,

    Yes, SA means serial assembly, or linear assembly:

    http://www.ti.com/ww/cn/uprogram/share/ppt/c6000/Chapter7.ppt

    The  gen_twiddle_ifft16x16 function is used to generate the twiddle factors for the ifft. This function is used in the example test file DSP_ifft16x16_d.c that measures performance. There is no linear assembly implementation for this function, the function was repeated in the code with "_sa" at the and to have a consistent function name to be used by the testing file when testing the linear assembly version. I understand that could be confusing. I hope my explanation helps.