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]

@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

[jean]

5 minutes ago, D@n said:

Wide FFTs?  If it requires tearing apart the Cooley-Tukey algorithm ...

Thanks sir for you help.  I dont undestand very well you question. For me I use IFFT of size 2048 cloked to 30.72 MHz, I choose a pipelined, streaming architecture, I use a scale factor to avoid ovrflow. The other IP is dds compiler cloked at 245.76 MHz generate a sin cos running at 30.72 MHz.  I am very grateful

[D@n]

I think I answered that above already.

Dan

[jean]

3 minutes ago, D@n said:

I think I answered that above already.

Dan

@D@n

sir I appreciate you if you can explain please me a little more even for a sentence, how I  can do, I should use this IFFT xilinx. I use a CDC between these two IP, please any idea of you can be a solution for me.

[jean]

11 hours ago, D@n said:

I think I answered that above already.

Dan

@D@n please sir can you give more details how can I do this, even for a sentence. thanks

[jean]

17 hours ago, D@n 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

@D@n

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.

[D@n]

@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

 

[jean]

45 minutes ago, D@n 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

[D@n]

1 hour ago, D@n said:

Wide FFTs?  If it requires tearing apart the Cooley-Tukey algorithm ...

Dan

[D@n]

@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

[D@n]

@jean,

Your typical FFT accepts one sample at a time.  If you are operating at a 245 Msps rate, but then downclock that rate to something lower--say 50Msps, then each clock period will need to convey five samples.  You would then need to place five samples into the FFT per clock cycle.  Few FFTs can handle this.  Building an FFT that can handle five input samples at once is non trivial.  I've done it to build an FFT that can handle two incoming samples at once, so I know some of what is involved.  It's doable, but it will take some significant work.  If you go this road, you will either need to hire some (expensive) help, or dig into how the Cooley Tukey Fast Fourier Transform works in order to replace and re-implement pieces of it.

Your language above, however, is quite confusing.  You are generating a 30MHz signal at 245 Msps, but then want to process this signal at 30MHz?  Wouldn't that violate the Nyquist sampling theorem?

You may need to go back to the drawing board and rethink what it is you wish to do from the beginning.  What you are asking to do is not trivial.  It is doable if you know what you are doing, but judging by your questions I'm not sure you are ready to dive into a problem this complex.  My worry is that I will just spend hour after hour coaching you through the minute details of doing something like this and ... I have better (paid) uses for my time.

Dan

[jean]

22 minutes ago, D@n said:

@jean,

Your typical FFT accepts one sample at a time.  If you are operating at a 245 Msps rate, but then downclock that rate to something lower--say 50Msps, then each clock period will need to convey five samples.  You would then need to place five samples into the FFT per clock cycle.  Few FFTs can handle this.  Building an FFT that can handle five input samples at once is non trivial.  I've done it to build an FFT that can handle two incoming samples at once, so I know some of what is involved.  It's doable, but it will take some significant work.  If you go this road, you will either need to hire some (expensive) help, or dig into how the Cooley Tukey Fast Fourier Transform works in order to replace and re-implement pieces of it.

Your language above, however, is quite confusing.  You are generating a 30MHz signal at 245 Msps, but then want to process this signal at 30MHz?  Wouldn't that violate the Nyquist sampling theorem?

You may need to go back to the drawing board and rethink what it is you wish to do from the beginning.  What you are asking to do is not trivial.  It is doable if you know what you are doing, but judging by your questions I'm not sure you are ready to dive into a problem this complex.  My worry is that I will just spend hour after hour coaching you through the minute details of doing something like this and ... I have better (paid) uses for my time.

Dan

@D@n  sorry for all my questions but why you told me that I vialote the nyquist sampling theorem 

[D@n]

@jean,

Do you know what the Nyquist sampling theorem is?

Dan

[zygot]

2 hours ago, D@n said:

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

As a generalization I agree. The double clocked synchronizer is common practice but not necessarily robust enough for all applications. Really this topic can get quite complicated. As for dual clock FIFO flags there are known timing uncertainties and usually you can avoid them in a system approach.

I'm in total agreement with @D@nwho, if I'm reading him correctly, is suggesting that adding complexity to a complicated design approach is asking for more issues ( more difficult issues as well ) to figure out and resolve than anyone really wants to face. Elegant alternatives to complicated solutions are generally better and where one ends up at the end. A lot of general concepts seem workable until you start using them in physical implementation.

My advice is to figure out a system level approach that has easier implementation requirements.

[jean]

2 hours ago, D@n said:

@jean,

Do you know what the Nyquist sampling theorem is?

Dan

@D@n the sampling frequency should be grater than fmax*2. Or the sampling frequency of fft is 30.72 MHz and my input signal sin cos is 30.72 MHz. 

I did not think about this criteria. If I want to resolve this problem, I should have a sine cos more the 2*30.72MHz

[jean]

On 10/9/2020 at 4:48 PM, D@n said:

@jean,

You may need to go back to the drawing board and rethink what it is you wish to do from the beginning.  

Dan

@D@nHi Sir, apologize for my different questions. I started again from the beginning, I clocked my different IPs to the same clock (30 MHz).

Configuration of DDS compiler:

System clock frequency=30 MHz, phase width=12, phase data= 64.

Using this configuration, the dds generates a 0.4675 MHz sine cos

Configuration of IFFT target clock frequency=30 MHz, target data throughput=30 MSPS.

When I try to compute a small IFFT of (8,16,32) of the generated signal from the dds compiler, the result of computation is correct compared to Matlab.

The problem is when I increase the size of IFFT (64,128, 256,1024), I have incorrect results. I don’t know why? Or I respected the Nyquist theorem (0.4675 MHZ< sampling frequency of IFFT/2=30/2=15). I cannot properly configure my dds to compute an IFFT of size 2048 ? I noticied by increasing the size of the FFT, I should further decrease output signal from the dds which correspond to the input data of the IFFT. I dont know why? A priori there is something I cannot understand. I am very grateful if you can respond me. Please sir have any clarification. Thanks.

[jean]

On 10/9/2020 at 5:13 PM, jean said:

Your typical FFT accepts one sample at a time.  If you are operating at a 245 Msps rate, but then downclock that rate to something lower--say 50Msps, then each clock period will need to convey five samples

@D@n Dear sirs, 

I have a somewhat stipulated question but I cannot understand it. please any clarification in my this example or any example I don't know why the data rate of each IP depends on its clock, the sample rate also depends on the clock. If an IP is cloked at 30 MHz it buad rate is 30Mbit/s if it is cloked to 245MHz baud rate is clocked to 245 Mbit/s. the sampling frequency is dependent on clock

[jean]

1 minute ago, D@n 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.

[jean]

51 minutes ago, D@n 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

@D@nThank 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

 

[D@n]

@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

[jean]

39 minutes ago, jean said:

@D@nplease 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

 

[jean]

On 3/9/2018 at 3: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

@D@n @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 

[jean]

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

 

[zygot]

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

[zygot]

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.