TMS320F280049C: Looking for proper linker cmd file for fft example code

Hello Omer,

Thank you for your answers, and thanks for correcting me about the memory size. I thought it counted as bytes instead of 16-bit words.

When one imports a fresh project example, the cmd linker file looks like you showed above, and under project properties (General), the linker command file setting also points to the one you showed. This file 

But, this linker file does not list all the RAM available in my part .
   

However, as soon as I change away from the generic part to select my proper part (C280049C), the linker file goes away.

I assume I should use the linker file for my specific part, but then modify the cmd file for the FFT buffer alignment.

So, there are a few questions.

1) Which added statements are needed to make use of full RAM space? Just the ALIGN steps?

2) The FFT routines say the input buffer must be "aligned" for proper function, but the routine description claims it swaps input/output buffers for the various stages of the FFT, so shouldn't BOTH input & output buffers be "aligned"? Since I will have multiple buffers for inputs/outputs/intermediate processing (see next statements below), do all have to be "aligned" or just the initial input buffer to FFT?

3) Please correct any incorrect assumptions.
- input data is 1024-pt real data, so planning following steps:
- read in 1024-pts real data
- setup FFT structure, hnd_cfft, for 512-pt
- 512-pt CFFT_f32t(hnd_cfft);
- 512-pt CFFT_f32_unpack(hnd_cfft);
- 512-pt (or 1024-pts ?) RFFT_f32_mag_TMU0() (still trying to figure out which it needs, real or complex)
- 512-pt CFFT_f32_phase_TMU0()
- additional freq domain processing
- CFFT_f32_pack() (in preparation for ICFFT)
- 512-pt ICFFT(hnd_cfft);
- now I expect to get 1024-pt real data out (or after some additional steps?)

thanks, Dan
p.s. If a call would be more efficient way to handle this, you can reach me at +1-719-359-5352 or email me your contact to dan.staver@tavetech.com

Hello Dan,

To simplify, when you choose a new linker file it selects this new linker file as the one to set up the memory (hence modifying it in project properties makes the project ignore the previous .cmd file). I'm not sure why you're not modifying the existing linker file and adding in the memory configuration for the rest of the RAM, there should be no issue in doing this I would think.

To address your questions:

1. I believe everything in the MEMORY{} section of the .cmd file is needed for initializing the RAM sections, I'm not sure if this is what you mean by the ALIGN steps
2. Yes, all buffers are required to be aligned (given 1 pair of input/output buffer, they can be stored sequentially to be aligned properly if the input buffer is already aligned)
3. A few points on this:
   1. CFFT has its own magnitude function with TMU0, is there a reason that you're unpacking the CFFT to use the RFFT_f32_mag_TMU0?
   2. The rest of your assumptions look fine, although I'm unsure about sampling 1024 real data points if you're only doing a 512-point CFFT.
      1. If you were using a device with more memory you could instead use the RFFT to do the FFT and process the phase/magnitude, and then use the CFFT to convert back to the time domain (there is some additional processing required to go from RFFT to CFFT for the arrays).

Best regards,

Omer Amir

I think I have now figured out the linker file with no issues there. 

Now, for my FFT questions. Many TI documents say it is computationally preferential to do N-point FFT for 2N-point real data, then do an unwrap after, so not sure why you say not to unwrap? See example project "c2000\C2000Ware_4_03_00_00\libraries\dsp\FPU\c28\examples\fft\dsp_rfft.c", where they have 256-point real but call 128-point complex FFT.

(line-63) #define TEST_SIZE       (256U)
(line-107) CFFT_f32_setFFTSize(hnd_cfft, (FFT_SIZE >> 1));  // so they're setting up to do 128-point complex FFT
(line-112) CFFT_f32t(hnd_cfft);                             // do 128-point FFT here
(line-122) CFFT_f32_unpack(hnd_cfft);                       // now they explicitly call unwrap here so NOT built-in, no????

The document for this "CFFT_f32t" says it swaps input and output buffers for each stage so you check for final output buffer before subsequent processing.

5.4.2.18 void CFFT_f32t (CFFT_F32_STRUCT_Handle hndCFFT_F32)
This routine computes the 32-bit floating-point FFT for an N-pt (N = 2n; n = 5 : 10) complex
input. This function will reorder the input in bit-reversed format before proceeding with the FFT.
The routine uses two buffers in ping-pong fashion i.e. after each FFT stage the output and input
buffers become the input and output buffers respectively for the next stage. The CFFT_F32 object
uses two pointers, CurrentInPtr and CurrentOutPtr to keep track of the switching. The user can
determine the address of the final output by looking at the CurrentOutPtr.

Yet, in the actual "fpu_cfft.h" file contradicts this:
    C:\ti\c2000\C2000Ware_4_03_00_00\libraries\dsp\FPU\c28\include\fpu32\fpu_cfft.h

extern void CFFT_f32t(CFFT_F32_STRUCT_Handle hndCFFT_F32);
//! \brief Complex Fast Fourier Transform (In-Place) using a Pre Generated
//! Twiddle Factor Table
//!
//! This routine computes the 32-bit floating-point FFT for an N-pt
//! (\f$ N = 2^{n}, n = 5 : 10\f$) complex input. The routine performs its
//! computation in-place, i.e. it uses a single buffer as both input and output
// for each FFT stage.
//! \param hndCFFT_F32 Pointer to the CFFT_F32 object
//! \attention
//! -# This function does not reorder the input in bit-reversed format before
//! proceeding with the FFT. It assumes the user has already bit reversed the
//! input by calling CFFT_f32_brev() prior to calling this function
//! -# The routine requires a single buffer of size 2N (32-bit float), for
//! computation; the buffer must be aligned to a memory address of 4N words
//! (16-bit).

Which is correct? Is there an FFT-expert who can help?

Hello Daniel,

Daniel Staver said:

Many TI documents say it is computationally preferential to do N-point FFT for 2N-point real data, then do an unwrap after, so not sure why you say not to unwrap?

I did not say you should not use the unpack function, I was just confused why you were using it. It looked like you were using it just to use the RFFT magnitude function, but if you were following the provided example then that's fine.

Daniel Staver said:

Yet, in the actual "fpu_cfft.h" file contradicts this:

I believe you are looking at the incorrect comments for the CFFT_f32t function description in the header file. I double-checked, and the comments relating to each function are directly above the function's declaration (no space between the comments and function declaration). These are the comments for the CFFT_f32t function:

//! \brief Complex Fast Fourier Transform using a Pre Generated Twiddle
//! Factor Table
//!
//! This routine computes the 32-bit floating-point FFT for an N-pt
//! (\f$ N = 2^{n}, n = 5 : 10\f$) complex input. This function will reorder
//! the input in bit-reversed format before proceeding with the FFT. The
//! routine uses two buffers in ping-pong fashion i.e. after each FFT stage the
//! output and input buffers become the input and output buffers respectively
//! for the next stage. The CFFT_F32 object uses two pointers, CurrentInPtr
//! and CurrentOutPtr to keep track of the switching. The user can determine
//! the address of the final output by looking at the CurrentOutPtr.
//! \param hndCFFT_F32 Pointer to the CFFT_F32 object
//! \attention
//! -# The routine requires the use of two buffers, each of size 2N (32-bit
//! float), for computation; the input buffer must be aligned to a memory
//! address of 4N words (16-bit). Refer to the CFFT linker command file to see
//! an example of this.
//! -# If alignment is not possible the user can use the alternative, albeit
//! slower, function CFFT_f32ut
//! \warning This function is not re-entrant as it uses global variables to
//! store certain parameters
//!
//! <table>
//! <caption id="multi_row">Performance Data</caption>
//! <tr><th> Samples <th> Cycles 
//! <tr><td> 64      <td> 2334
//! <tr><td> 128     <td> 5032
//! <tr><td> 256     <td> 11026
//! <tr><td> 512     <td> 24250
//! <tr><td> 1024    <td> 53220
//! </table>
//
extern void CFFT_f32t(CFFT_F32_STRUCT_Handle hndCFFT_F32);

The comments you are citing from the fpu_cfft.h file seem to be for the CFFT_f32it function, which is why they are inconsistent.

Best regards,

Omer Amir