Help with altera FFT

I think my FFT is working in general for analog audio input. I have increased the FFT resolution from 256 points to 512 points, however, I don't seem to notice much difference in the output.

Also, how come for some frequency inputs, I get one pretty clean spike, but for other frequency inputs, the spike fans out at the bottom, with two or more spikes in adjacent bins and/or the amplitude fluctuates a little? My input is always one constant sine wave. For example, at 1335Hz, the spike is very sharp and good, but at 1260Hz, I get two spikes at about 4 bins apart and their magnitudes fluctuate just a little.

To be of any help can you tell me about:

your sampling frequency (of sinusoid)

your fft sampling frequency

do you use real and imaginary fft inputs and real/imaginary fft outputs

how then do you combine real and imaginary into one signal

your DAC sampling frequency(and do you correct for sinc distortion, see a today's post on that)

How do you visualise spectrum? is it commercial spectrum analyser and do you have positive negative sides of spectrum?

Here's my setup...

Everything that I am using is on the DE2 board which has a Cyclone II

I'm using the WM8731 CODEC chip on the DE2 board configured as the ADC.

My input source is a fix frequency sine wave going through the line in on the DE2 to the ADC.

I've configured the WM8731 with a sampling frequency is 8000Hz. According to the WM8731 doc, this setup requires a MCLK frequency of 18.432MHz. However, the PLL Megawizard can only produce a 18.75MHz clock. I don't know how this slight difference in the clock speed will affect the sampling frequency and everything else.

The clock to the FFT is generated based on the 18.75MHz clock as follows:

...

elsif (CLK_18_4MHZ = '1' and CLK_18_4MHZ'event) then -- this is the 18.75MHz clock

-- ReferenceClk / (SampleRate*2)-1 = 1151 = 10001111111

-- 18432000Hz / (8000Hz*2)-1

if (LRCK_1X_DIV >= "10001111111") then

LRCK_1X_DIV <= (others => '0');

FFT_clock <= not FFT_clock;

else

LRCK_1X_DIV <= LRCK_1X_DIV + 1;

end if;

The FFT is setup with a 256-point streaming architecture. Both the data and twiddle precision are 16 bits.

The digitzed signal from the ADC is connected to just the real input of the FFT.

For the FFT output...

I am scaling the real and imaginary FFT output using the exponent according to the scaling algorithm in the FFT doc. After the scaling, I apply the equation

sqrt(I^2 + Q^2)

So the FFT input signal is 16 bits and the final output after the equation is 29 bits.

I have a 256 x 29 bit dual-port RAM to store the 256 output values from the FFT. I can then read from the RAM to see what the magnitude is for a certain frequency bin.

Finally, I have a VGA controller that reads from the RAM and plots the values from the 256 locations as bars on the monitor.

Again, all the components that I have mentioned are implemented on the Cyclone II FPGA on the DE2 board.

I don't know what is the sinc distortion so I guess I am not correcting it. Where is your post on it? What is the sinc distortion? My codec is used as an ADC and not as a DAC, so what is this DAC sampling frequency that you are referring to?

For a start. Don't worry about my comments on DAC as you are not using it, instead you are outputting to monitor.

The first issue I can say is that ref clk difference is trivial for your test purpose (but will have some effect on the hearing of audio if you pass your frequencies to human).

second: Is there any reason why you use double Fs (8000*2) for your fft?

since data is sampled at 8k by ADC then you should run fft at that data rate unless altera fft requires you double the speed of internal fft operation. Even then the fft input and output should run at 8k otherwise you will introduce major error.

third: how did you do your sqrt(I^2 + Q^2)? was it in DSP builder?

fourth: in your fft scaling do you take account of bit-growth.

fourth: why use 29 bits for result when your data is just 16 bits, it looks excessive, you can truncate it down to 16 bits(not important now)

Hi,

I think my conclusion on your fft clk is not right. You are dividing it into 8KHz, fair enough. I wonder why not use the same 8 clk of ADC for your fft, may be it is not connected in hardware.

So generally your design looks ok in principle. You can simplify it by removing sqrt if you want. Just add squred values to get power instead of amplitude.

As such your fft result covers 0 ~ 1 i.e starts as positive from 0 ~ .5 then negative mirror image from -.5 ~ 0

0 means 0 frequency, .5 means Fs/2 = 4KHz.

so you can label your frequency axis from 0 ~ 4 then -4 to 0

You should see two lines on either side. These two should be equal if yur input is connected to real fft only. for example if your input frequency = 2Khz

then the lines should be at +2 on your frequency axis.

I am still not sure what is your ADC actual Fs. If we assume it is 8k

while your fft clk = 18750/(1152*2) = 8.138... this is a big difference

--- Quote Start ---

I think my conclusion on your fft clk is not right. You are dividing it into 8KHz, fair enough. I wonder why not use the same 8 clk of ADC for your fft, may be it is not connected in hardware.

I am still not sure what is your ADC actual Fs. If we assume it is 8k

while your fft clk = 18750/(1152*2) = 8.138... this is a big difference

--- Quote End ---

The 8kHz signal is generated internally in the CODEC chip given the Master clock input of

18.432MHz, and I don't think this 8kHz clock is available to the outside. 18432/(1152*2) = 8. So theorectically, my FFT clock is 8kHz. However, as noted above, my actual clock input is 18.75 and not 18.432, therefore my actual FFT clock is 8.138!

--- Quote Start ---

How did you do your sqrt(I^2 + Q^2)?

You can simplify it by removing sqrt if you want. Just add squred values to get power instead of amplitude.

--- Quote End ---

I am using the Altera megafunctions for doing the sqrt and square, so this is easy.

--- Quote Start ---

fourth: in your fft scaling do you take account of bit-growth.

fourth: why use 29 bits for result when your data is just 16 bits, it looks excessive, you can truncate it down to 16 bits(not important now)

--- Quote End ---

According to the Altera FFT doc on the exponent scaling, 29 bits is the resulting output bit width for my FFT setup. However, I am only passing bits 19:12 to the monitor.

--- Quote Start ---

As such your fft result covers 0 ~ 1 i.e starts as positive from 0 ~ .5 then negative mirror image from -.5 ~ 0

0 means 0 frequency, .5 means Fs/2 = 4KHz.

so you can label your frequency axis from 0 ~ 4 then -4 to 0

You should see two lines on either side. These two should be equal if yur input is connected to real fft only. for example if your input frequency = 2Khz

then the lines should be at +2 on your frequency axis.

--- Quote End ---

Yes, I do see the two mirror image lines on either side.

So it seems like that my problems stem from the fact that my master clock is not exactly 18.432MHz?

none of the pictures you posted look alright to me. I was expecting two symmetrical lines (well apart) and more towards the edges than the centre.

your frequencies are close to 1 Khz so the lines should be close to location +1 out of x axis from 0 to 4, -4 to 0:

......|.....................................|.....

0....1....2....3....4....-3.....-2....-1....0

if you centre the fft on dc(which I guess you don't) it becomes:

......................|...........|..................

-4....-3....-2....-1....0....1.....2.....3....4

your truncation of 29 bits by taking bit 19:12 is not clear to me.

You should be taking the value from MSBs. unless they are "dead" bits i.e. never used by result(indicating low input swing or bad design)

your ADC Fs and FFT Fs must be identical, preferably same clock line, else the two clocks must be equal , related and locked to each other.

In any case of data and clk acquired from outside then I will use that same clk and I will also check for any timing problems at the io registers which is not normally part of fpga timing report.

edit:

Your picture indicate some high frequencies near 4KH and this is maximum for your fft, possibly due to some flipping of data.

another issue that popped up now is the way you display on the monitor. You must latch your fft output while refrshing the monitor otherwise a free running fft will not give identical block data unless you work hard to do that