• 0

Frequecny resolution of FFT is decided by FFT clock frequency ?


Go to solution Solved by [email protected],

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

Link to post
Share on other sites

Recommended Posts

  • 0
7 hours ago, [email protected] said:

@subasheee,

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

Dan

Dear @[email protected]

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

Link to post
Share on other sites
  • 0
On 3/9/2018 at 10:16 AM, [email protected] 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 @[email protected],

 

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

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

Link to post
Share on other sites
  • 0
19 hours ago, [email protected] 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 @[email protected]

 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

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

Link to post
Share on other sites
  • 0

@[email protected],

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

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)

@[email protected],

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
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
Link to post
Share on other sites
  • 0
On 3/10/2018 at 5:42 PM, subasheee said:

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

 

 

Hi, please, I have the same problem, DDS compiler at IFFT are not clocked in the same clock. Please can you explain me How did you clocked the s_axis_data_tvalid at the same freqeuncy as the sampling frequency

 

Link to post
Share on other sites
  • 0
On 3/9/2018 at 3:16 AM, [email protected] 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

@[email protected] @subasheee please can explain me how I can I resolve this problem, I have the same issue, dds compiler and IFFT are not clocked to the same freqeuncy.  How to set the input tvalid of IFFT. It is not a clock to connect it to the output of clock wizard for example 

Edited by jean
Link to post
Share on other sites
  • 0
39 minutes ago, jean said:

@[email protected]please sir can you explain me how I can I resolve this same problem, I have the same issue, dds compiler and IFFT are not clocked to the same freqeuncy.  How to set the input tvalid of IFFT high or it is not a clock. I am very grateful for you

 

Link to post
Share on other sites
  • 0

@jean,

You can only cross clock domains using specific solutions.  I recently wrote an article about how to move words across clock domains.  That's not particularly that fast, and perhaps not what I'd recommend for any DSP work.  If you need something similar or closer to full speed (rather than 1/6th speed), you'll need to use an asynchronous FIFO.

Bottom line:

  1. Clock domain crossing is a hassle.  Avoid it if you can.
  2. If not, then I think you need to get your hands dirty.

Dan

Link to post
Share on other sites
  • 0
51 minutes ago, [email protected] said:

@jean,

You can only cross clock domains using specific solutions.  I recently wrote an article about how to move words across clock domains.  That's not particularly that fast, and perhaps not what I'd recommend for any DSP work.  If you need something similar or closer to full speed (rather than 1/6th speed), you'll need to use an asynchronous FIFO.

Bottom line:

  1. Clock domain crossing is a hassle.  Avoid it if you can.
  2. If not, then I think you need to get your hands dirty.

Dan

@[email protected]Thank you sir for your reply. On my part, dds compiler uses a clock frequency 245.76 MHz generate a sine cos running at 30.72 MHz. The IFFT should running with an input clock 30.72 MHz.  What do you think sir  I'm use cdc or I'm trying to use your FIFO?  Todays, I understood that I had a problem of changing the clock domain when I make these IP in differnts clock, I have incorrect result, I have the same results only when I use the same clock input

 

Link to post
Share on other sites
  • 0
1 minute ago, [email protected] said:

@jean,

Sorry, I forgot your two clock rates.

That's a more complicated problem than I can answer on a forum.  The last time I needed to build something like that, I built my own FFT implementation.  Your task is doable, but not trivial.

Dan

Thanks sir, just can you tell me if I use a clock crossing doamin between these two IP can resole the problem or it's not enough thanks you.

Link to post
Share on other sites
  • 0
17 hours ago, [email protected] said:

@jean,

You can only cross clock domains using specific solutions.  I recently wrote an article about how to move words across clock domains.  That's not particularly that fast, and perhaps not what I'd recommend for any DSP work.  If you need something similar or closer to full speed (rather than 1/6th speed), you'll need to use an asynchronous FIFO.

Bottom line:

  1. Clock domain crossing is a hassle.  Avoid it if you can.
  2. If not, then I think you need to get your hands dirty.

Dan

@[email protected]

What do you think sir if I use this IP AXI Clock Converter connects one AXI memory-mapped master to one AXI memory-mapped slave operating in a different clock domain. Thanks.

Link to post
Share on other sites
  • 0

@jean,

There are three general methods for crossing clock domains.  The first is a 2-flip-flop synchronizer.  The second is a word synchronizer, built using a 2FF synchronizer to handle the flags, and the third is an asynchronous FIFO (others in this forum would call it a multi-synchronous FIFO).

Neither of these methods solves the problem of handling data at a rate that doesn't fit the lowest rate of the system.  For that you will need a multiplexer to create larger words of data containing multiple sample clocks of data within them.  The further challenge will be getting an FFT or DDS or whatever to operate on such multi-sample words.  It's doable, but not trivial.  The DDS solution is probably something a beginner could accomplish.  Wide FFTs?  If it requires tearing apart the Cooley-Tukey algorithm, then I'd be looking for a strong compensation before diving into that problem and even stronger compensation before helping someone else dive into it.  The good news is others have done it--but you'll have to do some digging to find them and their algorithms.  Beware that any algorithms you find may (or may not) apply to your situation.

Bottom line: You've got some challenging engineering ahead of you, and I'm not able to do it for you on this forum.

Dan

 

Link to post
Share on other sites
  • 0
45 minutes ago, [email protected] said:

@jean,

There are three general methods for crossing clock domains.  The first is a 2-flip-flop synchronizer.  The second is a word synchronizer, built using a 2FF synchronizer to handle the flags, and the third is an asynchronous FIFO (others in this forum would call it a multi-synchronous FIFO).

  solves the problem of handling data at a rate that doesn't fit the lowest rate of the system.  For that you will need a multiplexer to create larger words of data containing multiple sample clocks of data within them.  The further challenge will be getting an FFT or DDS or whatever to operate on such multi-sample words.  It's doable, but not trivial.  The DDS solution is probably something a beginner could accomplish.  Wide FFTs?  If it requires tearing apart the Cooley-Tukey algorithm, then I'd be looking for a strong compensation before diving into that problem and even stronger compensation before helping someone else dive into it.  The good news is others have done it--but you'll have to do some digging to find them and their algorithms.  Beware that any algorithms you find may (or may not) apply to your situation.

Bottom line: You've got some challenging engineering ahead of you, and I'm not able to do it for you on this forum.

Dan

 

Thanks for you reply sir. In my case, I am using an IFFT of size 2048.  I think that a serial to parallel converter with a cdc. The other probelm how can IFFT computes this new data

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