• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 961 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DSP_fft16x16 input changes

John Samuels
Prodigy 50 points

Hello,

I am currently working on a dm6437 and am getting acquainted with DSPLIB (downloaded here: http://www.ti.com/tool/sprc265). 

Here's my problem: the input to functions DSP_fft16x16 (and 16x32/32x32) changes after making the call. I thought the result was stored separately and the input should be intact. Am I wrong? 
  • 0
    TI__Mastermind 35645 points

    Hi,

    Thanks for your post.

    I think, there is a common challenge which is seen that the input data is not correctly scaled when using the FFT kernel. Kindly refer the below e2e posts:

    https://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/83082/286930#pi317334=1

    https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/276316

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question

    -------------------------------------------------------------------------------------------------------

  • 0 in reply to Sivaraj Kuppuraj
    Prodigy 50 points

    Hi Sivaraj,

    I'm running fft_example.c within the DSPLIB download. Are you saying the provided example doesn't do proper scaling of the input data?

    I see that it's mentioned in page 2-4 of www.ti.com/.../sprueb8b.pdf that to prevent overflow we must scale by 2^(log2(nx)). Well, when I set x_16x16 to be a 0 Hz sine wave (ie, DC component) with no phase offset (imaginary component is 0), the real values of the wave default to 128. I scaled that down to 8, and I'm still getting the input vector x_16x16 to change. Am I missing something?

    UPDATE: Even when I scale down the twiddle factors the input array changes after the call.

  • 0 in reply to John Samuels
    TI__Genius 12805 points

    John

    I do not have access to the location of the code that you specified so I am not sure what library you use, but I looked at our standard dsplib C64p library, and I looked at the assembly source code function DSP_fft16x16_sa.sa (you can see it in directory \dsplib_c64p\packages\ti\dsplib\src\DSP_fft16x16\c64P where you download the library.  Look at the code in lines 87-148 and it is clear that this is in place algorithm.

    The comment on lines 219-221 states the following:

        The fft() code shown here performs the bulk of the computation     *
    *       in place. However, because digit-reversal cannot be performed      *
    *       in-place, the final result is written to a separate array, y[].    *

    So this is mainly in place function. No wonder the input vector has been changed.

    Best Regards

    Ran