There are three bugs we know of in the FFT.
The first one (the biggest one) involves the twiddle coefficients and
matlab's understanding of "i" and "j" as sqrt(-1) for complex numbers.
This one's been fixed and should be checked-in. See earlier emails for
details.
The second bug is a little more subtle and is probably the one you're
describing here. It comes about when you use a 3-multiplier twiddle
coef block and a portion of the data path performs a rounding on the
number but the other part of the path doesn't. This results in
crosstalk like you describe. You can temporarily sidestep this problem
by choosing "optimise for logic" in the FFT mask parameter which will
then use the 4-multiplier twiddle cores. Of course this assumes you
have multipliers to spare.
The third bug involves rounding of the coefficients in the ROMs where
-1 can be represented in a Fix_18_17 number but +1 can't. We haven't
yet done simulations to figure out exactly how this affects the data.
But we have noticed that it affects the imaginary part and the real
part differently.
Andrew Martens is working on bugs 2 and 3 at the moment. He'll
hopefully have fixes and some other mods to the FFTs available next
week.
Jason
On 23 Jun 2010, at 23:36, Jonathan Landon wrote:
Jason --
Dave MacMahon tells me he's been working with you to get your
updated FFT blocks into the git repository and that there were a
couple bugs still to be fixed in blocks relating to the FFT. I'm
excited to try out the new FFT because its brokenness could explain
why my PAPER crosstalk tests are so puzzling (crosstalk seems to be
independent of physical distance between ADC inputs so I'm
suspicious of a digital bug). Is the most up-to-date version now in
the CASPER library?
Jonathan
