• 0
mohamed shffat

Problems FFT IP CORE v 9.0


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 

1st image.jpg2nd image.jpg

Share this post

Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0

Wow, that really looks like a fun problem!  :D  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?  :P  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!



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