01-29-2019 08:58 AM
Currently the Xilinx FFT IP allows the use of natural order for both input and output, or natural order for input and bit-reversed order for output, but not bit-reversed order for input and natural order for output.
There is an answer record from 2015 stating that it is in the roadmap of the 2016 release, and there is a question about this in the forum from 2017 where a Xilinx employee mentionned that is is on the roadmap.
Is it possible to have an update on this ? Is it really planned to be implemented, and if yes when ?
This is an important feature, because if convolution or correlation wants to be computed by means of FFT, having bit-reversed order for both input and output allows a significant saving in memory and an appreciable reduction of the latency.
02-17-2019 05:59 PM
You are correct that current FFT does not support bit-reversed order for input and natural order for output. I don't see a roadmap for this feature, who is the customer asking for this feature?
02-18-2019 04:43 AM
At one time, I had looked into accepted bit-reversed inputs into my own FFT core. The utility of this is straight forward. If you want to take an input, FFT it, convolve it with something via a point-by-point multiply on the output, and then inverse FFT the result: it makes sense to get rid of the extra bit-reversal stage(s). They really aren't required. If the output of the first FFT left the result in a bit reversed order, the multiplies (convolution) could be done in the same order, and the the inverse FFT could be done without requiring a second bit reversal stage.
In my case, the bit-reversal uses block RAM and very little logic, so I could see this becoming useful if block RAM were tight.
I got far enough along in the process to realize that I'd need to implement two separate types of butterflies: decimation in time and decimation in frequency. One is appropriate for starting with natural order and ending with a bit reversed order, the other is appropriate for starting with a bit-reversed order and ending with the natural order. (I'd have to look up which one is which.)
This may be the reason Xilinx has not (yet) chosen to implement both FFT modes.