Problems FFT IP CORE v 9.0

[mohamed shffat]

Hello  everyone , my regrades .  

I wanna ask something about the FFT IP CORE on the vivado , i'm really confused ! Here i'm trying to implement a real time FFT core on my Artix 7 FPGA board , but the results are looks very strange . My design contains first an XADC with a 427 KSPS sampling rate for a cos wave signal at the input , after the XADC i'm storing the data in a FIFO memory with 1024 depth , after that i'm inserting the data to an FFT core but the results in the output don't look as a spectrum and there's alot of noise which i couldn't handle it , i attached the results in picture below , the parameters of my all design are : 

- Cos wave with a 200 KHZ as an input for the XADC . 

- XADC continuous sampling with single channel Vp - Vn , and with a sampling rate 427 KSPS . 

- FIFO memory block with a 16 bit width of the input and the output data , and with a 1024 depth . 

- FFT real time mode , 1024 points , Fixed point , Scaled , and truncation rounding . 

- Target clock freq 100 MHZ and target data throughput 100 MSPS . 

- The width for the FFT is 16 bit for each real and imaginary parts at the input and output . 

- Phase factor with 16 bits width , and the architecture is Pipelined , streaming I/O .

The output of this core is as shown below in the pic , notice that i got this results with a 100mv cos amplitude , the 1 v amplitude or above gives a full noised signal such as the 2nd pic . I just exported the data with the ILA debugging core then simulated it on the MATLAB .

I'm wondering what's the error or the mistake in the design and how can i fix all of that to get a clear spectrum , if you can please help me as fast as possible . 

Sorry for this long message . 

Thanks for evertything . 

My greetings 

[D@n]

Wow, that really looks like a fun problem!    I've always loved debugging FFT's.  (No, seriously!  You can find my own FFT core here.)  One of the things that makes FFT's so fun to debug is that they are such black boxes.  It's hard to see what's going on inside them, even when you have all the internals to them at your finger tips--such as I did.  You sort of need to learn to choose good input/test waveforms (sine waves and impulses are wonderful choices), and watch what happens.

Then ... you look at the output.  What does the output tell you?  Your two outputs above tell different stories.  The first one looks like the output of a complex FFT, with a complex sine wave input.  To my knowledge, the XADC doesn't produce anything complex ... are you using a real or complex FFT?  The first output you have also suggests that you have something other than your sine wave going into your FFT---something that's changing slowly (together with something changing faster), but that has almost a random component to it.  Then your second FFT, looking so drastically different suggests that the amplitude is doing something ... nonlinear.  All of these tell you things.

As a wildcard guess, did you reverse your bit order going into the core?  Or are you placing values into the core (or not) when it's not ready for them?  For example, the XADC can only go as fast as 1Msps, but you are running at 100MHz  ... are you dealing with the non-samples appropriately?  i.e., how are you handling those clocks where you don't have new valid data?  Both on the input as well as the output of your core ...?

While a lot of your discussion above discussed numerical precision, somehow ... I just don't think that's your problem at this point. 

Sorry, enough of the wild guesses.  Let's move back to sound engineering principles ...

I've also used the Xilinx FFT core before, and I trust that it works.  If you are really worried about it, you can always use the core I mentioned above as an alternate, although ... experience and intuition suggests that Xilinx FFT will be good enough.  So, let's figure out what's going on with your design.

Starting at the top ... You've got at least four systems in your design above and you are testing them as a whole: 1) an external signal generator, 2) your XADC, 3) your FFT, and 4) ... whatever you are doing/using to produce and read a result.  Any one or multiple of these systems may be in error.  The first goal of any engineering endeavour is to split up the various blocks and prove that each works individually. There are several ways of doing this, mostly dependent upon your confidence in the other systems that form a part of your design.  (Even if you have such confidence, you should be able to do these tests--I usually keep `define'd code around for this purpose, at least until I know things work.)

1. Let's prove step #4 works.  Remove steps #1-3 from your design, and place a counter into your design.  Do you get a counter out?  Add a portion step #2 back into your design, so that you only count up when a sample is present.  Are you getting doubled or missing counter values?  Replace the FFT synch signal with your own synthetically made signal.  (I forget the name of this -- you know, the one that tells you that you are looking at FFT bin 0?)  We're only doing this because we've removed the FFT from the design.... can you grab FFT output frames when you want them as necessary?
2. Now, let's look at the FFT input.  Can you generate a sine wave digitally, skipping the external signal generator, XADC, and FFT, and then verify that it looks like an appropriate sine wave?  Can you adjust the frequency of the sine wave, the amplitude, etc., does it still look right?  Make sure you test the full amplitude of your sine wave, from one bit all the way up to 16 bits.  Use MATLAB/Octave or whatever, and perform FFT's of this output.  Does it look good?  Do histograms of the output.  Are all the bits in place like they should be?  Repeat (as necessary) at the speed of values coming out of your XADC--making sure you only get valid values out when you should be seeing valid values out.
3. Incidentally, my favourite way to do this is to place individual samples into the FFT, chosen and selected by the host computer.  Sure, the data rate is poor, the FFT isn't being tested at its full speed, that USB/UART interface is painfully slow, etc., but there are a lot of bugs you can work out by doing this.  Indeed, when I last needed to debug an FFT, I used the USB UART to write values to an internal bus within the FPGA.  Then, when the last value of any complex pair was written, I'd clock the FFT once and read the outputs using roughly the same interface.  This includes reading and verifying the signaling wires too.
4. Only at this point are you ready to test your FFT.  Place this synthetic signal into your FFT.  You know exactly what it is from the previous step, right?  So then you know exactly what the FFT output should look like.  Does it look right?  If so, your FFT is working and the problem lies somewhere else in your design.
5. Now, connect your signal generator and XADC to your output recorder, bypassing the FFT.  Are you getting a sine wave out of the XADC like you are expecting?  If not, its not the FFTs fault.  Make certain you keep track of when values are valid, though, such as when the XADC clock is taking place, etc.
6. If everything to this point passes, then your FFT (and indeed your whole system) should work.

You do realize that the fundamental assumption in all debugging, that there is only one bug in any design, is rarely true, right?    Your goal is to remove as many possible sources of error/bugs as possible to get down to the one that is giving you the hassle.

I hope this helps.  Let us know what you discover!

Dan

 

[D@n]

Here's a link to a post that discusses more about what is required to debug an FFT component on an FPGA, and specifically to what I was trying to describe above.

Dan

[OscarBarajas]

You and your blog are saving my life right now. I sincerely appreciate that you took the time to do this.

[Kenny]

On 5/30/2017 at 1:06 AM, D@n said:

Here's a link to a post that discusses more about what is required to debug an FFT component on an FPGA, and specifically to what I was trying to describe above.

Dan

Hi Dan! A couple of years late on this one. I'm not new to FFT, but am new to FPGA hardware (and required software) for actually performing an FFT (or even an IFFT). I see IFFT core software in that github link you kindly provided.

I'd like to just try my hand at using an FPGA board for performing an FFT --- even the most basic of FFT. Could you or someone point me in the right direction about entry-level FPGA boards that I could buy from Digilent that can make use of your FFT core for carrying out an FFT?

Also - I had been thinking about how the set of sequence data (for which the FFT is to be applied to) is transferred from (eg. a computer) to a memory area for which the FPGA board can apply the FFT. Do such FPGA boards involve their own system-on-chip operating system that communicates with a computer - in order to do some data transfer, such as serial communications transfer? So all the sequence data must be transferred from the computer (via serial or parallel communications) to the FPGA board, and the FFT core system then carries out the FFT. And then finally, some more communications activity is required to transfer the results back to the computer (for somebody to then look at the results, and do some plots/graphing), right?

I purchased from digilent an ARTY s7-25 board and also an ARTY S7-50 board. I have only just recently purchased these boards - for learning and verilog programming purposes only. Would either of these boards be capable of doing FFT ?

Thanks Dan!

[D@n]

@Kenny,

Any entry level board can and will do an FFT--the real question is how much of an FFT do you want to do.  I've done FFT's on an Artix-7 35T, so you should be okay with the S7-50.  That said, size and complexity are tightly coupled with both the size of the FFT and the precision of the bits within it.

If you want an example, this FFT Demo was built using Digilent's Nexys Video board.  It works by reading data from an external Pmod MIC3 microphone, filtering the data, windowing it, FFT'ing it, taking the log of the magnitude, and then writing it to memory.  The memory is then treated as a framebuffer and used to display a scrolling raster via an HDMI output.  Optional software will make the raster scroll in simulation window (also provided, tested on Ubuntu).

Dan

[Kenny]

@D@n --- Hi Dan! Greatly appreciated your help for letting me know that any entry level board can/will do an FFT. I didn't know where to start before. You've definitely gone out of your way to point me in the right direction - both by letting me know that FFT is possible with my two ARTY boards, and for pointing out that FFT Demo with the Nexys Video board. I just looked it up a moment ago --- sku 410-316. I'm going to order one of those (today)! I had always wanted for a long time to work towards knowing how to use an FPGA board just to do an FFT --- at any speed - even slow speed. I didn't know where to start - not knowing what board to get to even begin. Thanks for your time and help Dan. Once again - genuinely appreciated!

[D@n]

@Kenny,

If you are an FPGA beginner, then ... I would start somewhere else.  I would recommend starting by learning how to debug FPGA designs.

The problem with FPGA development is that, unlike software, you have little to no insight into what's going on within the FPGA.  There are a couple keys to success:

1. Being able to insure your design works as intended before placing it onto the FPGA.  Simulation and formal methods work wonders for this task.  Unlike debugging on hardware, both of these approaches to debugging offer you the ability to investigate every wire/signal/connection within your design for bugs.  If you are unfamiliar with these tools, then I would recommend my own tutorial on the topic.
2. Being able to debug your design once it gets to hardware.  This should be a last resort since its so painful to do, but it is a needed resort.  To do this, it helps to be able to give the hardware commands and see responses.  It helps to be able to get traces from within the design showing how it is (or isn't) working.  I discuss this sort of thing at length on my blog under the topic of the "debugging bus (links to articles here)", although others have used Xilinx's ILA + MicroBlaze for some of these tasks.

Either way, welcome to the journey!

Dan

[Kenny]

On 11/7/2019 at 11:02 PM, D@n said:

@Kenny,

If you are an FPGA beginner, then ... I would start somewhere else.  I would recommend starting by learning how to debug FPGA designs

Either way, welcome to the journey!

Dan

@D@n ---- thanks Dan! Just before your last post, I was already looking at your tutorial site and bookmarked the link - in preparation to work through those tutorials! It is a great tutorial site. I'm definitely going to be following your teachings from there. I've been looking at the nice details there, so I'm already one of your students. Greatly appreciated! I totally agree that learning to debug FPGA will be hugely beneficial. I will definitely enjoy working through the tutorial, and read your blogs too. Thanks again D@n! Once again - much appreciated!