I have been digging around on this one.
http://hax4.blogspot.co.uk/2010_02_01_archive.html Advises:
Quote:
"ARM has provided a folder under RVDS 4.0 installation path that contains the assembly code for FFT, which covers almost all the FFT scenarios, including the odd ones like radix = 3 (Can radix be 3 for FFT?). It supports both V4 and V5TE instruction set.
However it would be useful only if you know how to set it up. For some reason, ARM did not do a good job to document this assembly code. And it took me a while to sort it out :
(1) First of all, you need to determine the FFT length and the data format you are gonna use. Assume you are gonna use 16 bit complex number and N = 1024
For 16 bit complex number, each point should be like:
typedef struct { INT16 x, y; } comp16;
(2) Goto "C:\Program Files\ARM\RVDS\Examples\4.0\77\windows\fft_v5te", open the file fft_main.s under "fft_asm" folder, at the end of the file, you will find a bunch of "GENERATE_FFT_FUNCTION", which are macros to generate correspondent FFT functions for different scenarios. Only keep the one that fits your needs and comment out the rest. If will save you significant amount of memory space by doing do.
(3) Now you need to determine the function name for your FFT scenario. The assembly would generate your FFT function name in the following naming convention:
FFT_$radix.$direction.$qname.$intype.$outpos.$pres cale
For example, if your FFT is radix = 4, forward, 16 bit integer, different in/out buffer, no pre-scaling, your FFT function would be "FFT_4EFQ14". Please refer to fft_mac.h under "fft_asm" folder for detail of the parameter definition.
So your FFT function would be something like:
typedef int fFFT16(comp16 *input, comp16 *output, int N);
extern fFFT16 FFT_4EFQ14;
......
FFT_4EFQ14 (input_buffer, output_buffer, 1024); // actual FFT operation
(4) Also you need to generate the twiddle table for your FFT. Use gcc or VC++ to open the file gentable.c under "tables" folder, compile and run it. It will prompt you for the parameters regarding your FFT scenario, and generate a file like t_01024_4.c for you (depending on the parameters, the file name might be different). If you have a FFT with odd radix or length, you might also need to have the "t_rad.c" file.
Open the twiddle table you've just generated, only keep the table you that fits your FFT scenario and remove the rest. The table bears the name like t_QxxS_radix or t_QxxR_radix. Here the S and R have something to do with "coeforder", whose definition can be found in fft_mac.h as well. For our 1024 point, 16 bit FFT case, if the ARM architecture is no less than version 5, it should be R. So we should keep the table "t_Q14R_4" only.
Now put all the files together (all the files under "fft_asm" folder, plus the twiddle table you've generated) and you are good to go!
There is no doubt that those who composed this piece of FFT code are artful engineers. However, I do have a few notes on how the test program was written. After all the convoluted test set up in the testfft.c provided by ARM, I don't see how these "enum" type would help in any meaningful way. Correct me if I am wrong, but my understanding is that those "enum" types are mostly for the test program itself. Sadly the example test only gives out tests for floating format. I couldn't find any example that shows how to use 16 bit fixed-point.
Also the way function name is provided is kind sneaky. Although it is very clever to do this in assembly, such practice could really use some good documents."
|
I will follow up on this.
Thanks