Frequecny resolution of FFT is decided by FFT clock frequency ?

[subasheee]

Hi,

I am am able to compute the FFT using IP core block available in Vivado 2017. However, whatever is the sample rate of input signal to FFT IPcore, the frequency resolution of the FFT is fixed by clock frequency of the FFT. Example

Frequency resolution  = sampling frequency/number of samples

DDS compiler generates sinusoidal frequency 976.56Hz at a clock freq of 1MHz,therefore the sample rate is 1Ms/s. this signal is given as input to the FFT IPcore 9.0 which is clocked at 5MHz with number of samples as 65536. therefore,

Expected frequency resolution = 1MHz/65536, however, measured frequency resolution  =5MHz/65536 in Behavioral simulation (Vivado 2017)

It does not matter what is the clock frequency of DDS compiler, the frequency resolution of the FFT remains at 5MHz/65536. But, in reality the frequency resolution is fixed by sample rate of input signals and the buffer size of FFT.

So, my question is, why in FPGA the frequency resolution is fixed by the clock frequency of FFT rather than sample rate of the input signal.

Help is much appreciated.

 

Regards,

Subash

[D@n]

@zygot,

I don't think the FFT is the issue at this point.

I think the issue is running one clock at fs1 into one component, and another clock at fs2 into another component.  The problem was then "fixed" by making both components run at fs1, but ... by making the ready line come from a clock generator with a 10% duty cycle?  This was the part I was hoping you might comment on.  I have no experience doing this, and it concerns me that there might be some sleeping dragons lying in this road.

In Verilog this would be *very* easy to handle.  I'd be running everything at the system clock rate, which would be 82MHz (for the DDR3 SDRAM) or higher and then adjusting the "valid" signals to handle the rates.  Easy.  Using this "simple" GUI method, the logic items that should be simple aren't nearly as apparent to me.  As one engineer stated, "there's no way to take the training wheels off."  As a result, the simple logic construct I just mentiond is ... beyond my experience to instruct (via the GUI), and the alternative @subasheee has chosen (a clock with a 10% duty cycle, rather than logic)... concerns me.

Dan

[zygot]

@D@n,

Well, I've been struggling to decide if I want to tangle with this one. I've not used the FFT IP from Xilinx so I'm not familiar with either the IP or the documentation. I've always thought of the resolution of an FFT as the number of bins. @subasheee seems to understand this:

On 3/8/2018 at 11:29 AM, subasheee said:

Frequency resolution  = sampling frequency/number of samples

But then there's this:

On 3/8/2018 at 11:29 AM, subasheee said:

Expected frequency resolution = 1MHz/65536, however, measured frequency resolution  =5MHz/65536

I'm not sure why the poster expects the FFT resolution to be relative to the DDS sampling rate. I suspect that the user has some unreasonable expectation that he can create data samples in one IP ( i.e. the DDS ) with Fs1 and run an FFT using another IP at Fs2 and that Vivado will resolve the difference in sampling rates. A question that I have is this: has the user properly notified Vivado of the frequencies of all of the clocks in the project constraints file?

A problem with the GUI flow and using someone else's IP is that the user can fooled into thinking that they don't have to pay attention to the details just as much as if they were  implementing a design using their own IP. Anyone using someone else's IP has to read the documentation carefully. Xilinx IP generally provides enough information to use their IP if you already understand the theory behind what the IP accomplishes.  The block diagram flow suggests a simplicity that doesn't exist. Once all of the signal are connected the user still has to take care of the details. I don't suspect any metastability issues here but I certainly suspect clocking and design issues.

[D@n]

@zygot,

Any suggestions on how I should respond to @subasheee here?

I think @subasheee is trapped within the graphical design approach to building an FFT based processing engine, and thus struggling with the lack of expressiveness in the graphical language, and ... unaware of the metastability pitfalls that attach themselves to the approach mentioned above.

Dan

[subasheee]

19 hours ago, D@n said:

@subasheee,

It's kind of hard to tell from here, as you haven't actually shared any of your logic above.  The devil is clearly hidden in the details you haven't shared.

I am rather concerned, though, that you've said you've clocked your FFT at a different rate from your DDS.   Both should be clocked with the same system clock (100MHz or so).  Your samples should *never* need to cross from one clock domain from another.  Use the valid signals instead to indicate which clock actually has valid data within it.

Dan

HI @D@n

 Thanks for the reply. After few simulations, i figured out that the frequency of Tvalid should be same as input signal sample rate (as you have suggested) and the pulse width of Tvalid should be same as the width of clock pulses to the FFT IP-core.

For eg: FFT clock at 1MHz, input signal at 10kHz, Tvalid should be clocked at 10kHz at 1% duty (ON for 1us and OFF for 0.1ms-1us)

Regards,
Subash

[D@n]

@subasheee,

It's kind of hard to tell from here, as you haven't actually shared any of your logic above.  The devil is clearly hidden in the details you haven't shared.

I am rather concerned, though, that you've said you've clocked your FFT at a different rate from your DDS.   Both should be clocked with the same system clock (100MHz or so).  Your samples should *never* need to cross from one clock domain from another.  Use the valid signals instead to indicate which clock actually has valid data within it.

Dan

[subasheee]

On 3/9/2018 at 10:16 AM, D@n said:

@subasheee,

Sure!  Only accept inputs at the sample rate.  Check out the valid line at the input to the FFT, and *only* set that line high once per sample.

Dan

Hi @D@n,

 

I tried clocking the s_axis_data_tvalid of FFT IPcore at the same frequency as that of the sampling frequency of input signal. The frequency resolution does changes but not as that of the input signal. I simulated two scenarios

1.      DDS complier generates 61Hz sine signal at a sample rate of 1MHz, it is down sampled to 10kHz then given as input to the FFT IP core clocked at 1MHz. FFT buffer=16384. In this case,

 

Actual frequency resolution(supposed to be)=10kHz/16384,

Frequency resolution with FFT IPcore clocked at 1MHz=1Mhz/16384

Frequency resolution with FFT IPcore clocked at 1MHz and Tvalid clocked at 10kHz=500kHz/16384

2.      DDS complier generates 61Hz sine signal at a sample rate of 1MHz, it is down sampled to 10kHz then given as input to the FFT IP core clocked at 100kHz. FFT buffer=16384. In this case,

 

Actual frequency resolution(supposed to be)=10kHz/16384,

Frequency resolution with FFT IPcore clocked at 100kHz=100khz/16384

Frequency resolution with FFT IPcore clocked at 100kHz and Tvalid clocked at 10kHz=50kHz/16384

 

So, I am not able to figure out, why the sampling frequency of FFT IP core is half of the clock frequency, if the Tvalid is clocked at the sample rate of input signal to the FFT IP core.

 

I have attached the simulation results for your reference. The details of the signals are as follows

INP_CLK          -->Clock input to the FFT IP core, 100kHz

ACT_SINE       -->Input signal to FFT IP core sample at 10kHz

SQUARE_OUT-->FFT output-magnitude axis

TUSER_delay  -->FFT output-frequency axis

TVALID              -->FFT output valid signal

 

Regards,

Subash

 

[subasheee]

7 hours ago, D@n said:

@subasheee,

Because you are accepting inputs to your core at your clock frequency and not your sample frequency.

Dan

Dear @D@n

Yes, you are correct. But, FFT has only single clock. If i make the clock frequency of FFT as the sampling frequency  of input signal then then the FFT computation time increases significantly for low sample rate input signal (eg: 5kSps). Unlike FIFO blocks, FFT does not have two separate clocks for input and output, so that i have flexibility to read, process and write at different clock frequencies.
Is there any solution to just read the signal at lower sample rate but carry out FFT processing and writing at high clock frequencies ?

Regards,

Subash

[D@n]

@subasheee,

Because you are accepting inputs to your core at your clock frequency and not your sample frequency.

Dan