hi tim,

the casper fft's are maximized to handle high bandwidths with
low resource utilization, but they are not optimized for low latency,
as astronomers use them in streaming applications where latency
is not important.

there are other FFT architectures - some 512 input FFT's can
convert from time domain to frequency domain in 9 clocks (but they use a lot
of resources).  i can point you to these architectures if you want...

you might try the xilinx FFT, or you can configure the casper FFT for
8, 16 or 32 parallel inputs.   it sounds like your adc produces 4 samples
per FPGA clock (you are sampling at 512 MHz and your FPGA is running
at 128 MHz).   if you employ a CASPER FFT with 8 inputs instead of 4,
and ground every other input, then the latency will be cut in half.
if you use a CASPER FFT with 16 inputs, and ground three inputs,
then connect an adc input, connecting every fourth input, then the latency
will be but
down by a factor of four.   if you use a casper FFT with 32 inputs, then
the latency
will be cut down by a factor of eight.


best wishes,

dan



On Fri, May 2, 2014 at 10:11 AM, Madden, Timothy J. <tmad...@aps.anl.gov>wrote:

>  Folks
>
>
> I am trying to use a complex fft (the green FFT block) for a spectrum
> analyzer application.
>
>
> I would like to use a 512 point FFT to compute on read time data. I need
> the FFT to compute in less than 512 samples. I am using 4 taps in the
> input, and running the FPGA at 128MHz. In this case, the FFT needs to
> finish in 128 clocks or less. In this way I can have two FFTs running in
> real time and not miss data.  I am usign a pfb_fir before the FFT.
>
> I can't get the FFT to compute in less than 512 clocks, which translates
> into 2048 samples. I tried removing the reorder block, and still no luck.
>
> Is there documentation on how many clocks it takes an fft block to
> compute?
>
>
> Also, if we supply ONE and only ONE sync pulse, should the fft block
> compute indefinately? My simulink seems to require a series of sync pulses
> to get the FFt to work more than once.
>
>
> Tim Madden
>
>

Reply via email to