• 0
Sign in to follow this  
subasheee

Frequecny resolution of FFT is decided by FFT clock frequency ?

Question

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

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

@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

Share this post


Link to post
Share on other sites
  • 0
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

Share this post


Link to post
Share on other sites
  • 0
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

 

Untitled.jpg

Share this post


Link to post
Share on other sites
  • 0

@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

Share this post


Link to post
Share on other sites
  • 0
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

Share this post


Link to post
Share on other sites
  • 0

@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

Share this post


Link to post
Share on other sites
  • 0

@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.

Edited by zygot

Share this post


Link to post
Share on other sites
  • 0

@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

Share this post


Link to post
Share on other sites
  • 0
22 hours ago, subasheee said:

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)

@D@n,

Yeah, I have to admit that I missed this post. I think that there are several issues here to deal with. Out of curiosity I decided to look at the FFT IP datasheet.

Tvalid is not a clock but a data valid input that tells the core when the input data samples are valid. I'm not sure how to interpret the poster's comments as to what exactly is the intended meaning. There's no Tvalid as a clock and there's no Tvalid clock duty cycle. There's just data and a signal indicating when the data is valid.

As to clocks never use logic derived signals as clocks and expect Vivado to resolve the timing. This is true for schematic entry, VHDL, Verilog or any other way you might convey your design to Vivado. As to taking data sampled by one clock and using it with another clock then you have to use proper domain crossing techniques. As to control signals, like Dvalid, they have to be synchronous with the clock where they are used. If they are derived in one clock domain and used in another clock domain then you have to use proper domain crossing techniques. Also the delay in the logic that defines these control signals has to be shorter than the sum of the clock period, setup time and hold times. (I know that the last sentence seems obvious but unless you constrain the design properly don't expect Vivado to place you logic to meet timing. That's for designs with single clock domains. Take some time to figure out what happens if a control signal is derived in a 100 MHz clock domain and used in a 10 MHz clock domain.... ). Vivado tools are smart but they don't have ESP; feed them insufficient or bad rules and they will give you insufficient and bad results.

It's entirely possible to have the DCM create a clock with a duty cycle that isn't 50% but there rarely is a reason to do so and the timing can become more difficult to achieve.

Edited by zygot

Share this post


Link to post
Share on other sites
  • 0

I'm assuming that @subasheee is trying to do streaming rather than burst FFT analysis. I haven't read enough to understand how the core handles "frames" of streamed data but for sure the user needs to read and understand PG109. I always get nervous when using some else's IP that handles the details "behind the curtain" and doesn't explain the consequences... which is why I generally prefer to create my own IP. Admittedly, I haven't tried coding an FFT in logic. Well, a long long time ago I did work on an FFT implemented in ECL logic... but that was a long long time ago...

Edited by zygot

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this