Xilinx FFT core's IFFT function not working? Dun Xilinx TEST their cores before releasing them?

Hi,
   has anybody used the FFT v4.1 core from Xilinx Core generator
before to do IFFT?
This is the scenario:
- I am using this config of the FFT core with the selected
configurations
   -pipelined, streaming
   -unscaled. input wave is 24 bits. output is 34 bits. coefficients
also 24 bits input

1) I use matlab to generate 24 bit complex waveform and save it into
text file
2) I run my testbench in modelsim (simulation). the testbench reads in
the text file of complex waveforms generated in (1). It is then fed
through the xilinx core generated FFT. This generates an FFT result.
(I have verified this output in matlab. It seems to be working fine.)

3) the FFT result is fed into another instantation of the same core.
this time, the core is configured to do IFFT by clearing the fwd_inv
signal (. Also, because the FFT core accepts a maximum input bus width
of 24 bits, I truncate the output from previous FFT from 34 bits to 24
bits before feeding into the IFFT core.
4) in theory, the normalised input and output waveform results should
be the same. I see some alarming results.

a) the output of the IFFT shows the first 7 samples of constant value.
This will result in some kind of phase shift. The output of the
simulation is piped into a text file. I read it into matlab and do my
analysis. In addition, viewing of the complex output waveform in
modelsim waveform viewer in analog step also confirms this. :(


Huh? Is that normal? Have i missed out something here? If not, isnt it
appalling? dun xilinx test their IP cores before releasing them?
Ridiculous right?


Chris

On Jul 25, 9:49=A0am, chrisde...@gmail.com wrote:
> 2) I run my testbench in modelsim (simulation). the testbench reads in
> the text file of complex waveforms generated in (1). It is then fed
> through the xilinx core generated FFT. This generates an FFT result.
> (I have verified this output in matlab. It seems to be working fine.)

Are you sure that you have got the correct timing between the first
input data word and the other FFT core control inputs?
For example, you have to assert the Start input a few cycles before
you put the first data word on the input data bus of the core. Have a
careful look at the timing diagram for pipelined streaming mode in the
Xilinx FFT data sheet to make sure you have the timing correct in your
simulation.
I have used this core in almost the same configuration you describe
with no problems.

-T

Hi,
   I have checked. the first input sample is fed in when index for xn
is 3. I have followed the timing.
   But i found something further. The problem is due to the FFT
result.

 Did you do this the last time?
1) generate 24 bit number
2) feed into the FFT
3) the 34 bit result which you obtain in VHDL testbench is piped into
a text file. afterward, you IFFT the result in matlab

the waveform you get  in (3) is generated  against the initial
generated waveform fed into FFT described in step (1). in addition, i
found the waveform generated here is also as described in the previous
email with the leading 7 sampes roughly the same value.
also, the final waveform for both real and complex portions is one
time sample delayed to the original input sample.

possibly that this is due to quantization errors?

thanks again.
Chris


On Jul 25, 11:53=A0am, Tom <tom.der...@gmail.com> wrote:
> On Jul 25, 9:49=A0am, chrisde...@gmail.com wrote:
>
> > 2) I run my testbench in modelsim (simulation). the testbench reads in
> > the text file of complex waveforms generated in (1). It is then fed
> > through the xilinx core generated FFT. This generates an FFT result.
> > (I have verified this output in matlab. It seems to be working fine.)
>
> Are you sure that you have got the correct timing between the first
> input data word and the other FFT core control inputs?
> For example, you have to assert the Start input a few cycles before
> you put the first data word on the input data bus of the core. Have a
> careful look at the timing diagram for pipelined streaming mode in the
> Xilinx FFT data sheet to make sure you have the timing correct in your
> simulation.
> I have used this core in almost the same configuration you describe
> with no problems.
>
> -T

Hi

> =A0 =A0I have checked. the first input sample is fed in when index for xn
> is 3.

No it isn't... the first input sample should be time aligned to when
xn_index is 0.
This occurs a few cycles (3 or so? i forget) after you assert Start
high.

>  Did you do this the last time?

No I haven't done what you said because I implemented in actual
hardware, with real ADC (although double-checked against a digitially
synthesized waveform), real data buffers on input and output, feeding
output of the FFT out of the FPGA into a PC where it was post-
processed in Matlab. I found no such problems that you report. I used
the streaming core with various values of N (points), 24-bit for
input, output and twiddles.

I think the problems you seem to have found are unlikely to be related
to quantization error... more likely a timing/simulation problem. It
is extremely unlikely this bug exists in the hardware core itself,
since it is used very widely in many applications. It is just about
possible that it is a bug existing in the simulation files used by
Modelsim. However, to be honest, it is much more likely it is due to
something in your own implementation of the simulation testbench, or
misunderstanding of the timing requirements for the core.

Not sure I can assist you much more, if you are really stuck then open
a Webcase with Xilinx and send them the simulation files you are
using. One other thing - do check whether your scaling schedule is
appropriate, and also whether you are expecting output in natural or
bit/byte reversed order. Finally check you have not accidently enabled
"cyclic prefix" (intended for use with OFDM transmitters), if you are
using v5 of the core.

-T