thanks glenn,
the trick of using a small number of coefficients
for a large transform should work. we've done
million point transforms using only 1024 integer
coefficients; the results come out very close to a floating point
full coefficient computation. perhaps something is
broken in the design, probably in the way the coefficients are selected.
as you point out, the quick fix is to use all the coefficients,
(if one has enough block ram), but we should try to figure
out what the design problem is,
for users implementing large FFT's that are block ram limited.
if i recall correctly,
the fft coefficients are stored in bit scrambled order,
so if one wants to pick a nearby coefficient from the rom based look up
tables, one should throw away the most significant address bits in
the coefficient counter, not the least significant address bits.
perhaps this is the problem??
dan
G Jones wrote:
Dan,
This sounds to me like the behavior I see with long transforms with the
maximum coefficient depth setting, where the block tries to use the
trick of storing only rounded roots of unity for the last stages. I
can't look into it in detail right now, but I recommend looking under
the masks to find that parameter and setting it so that the value is
greater than the number of stages in the transform to see if that fixes it.
Glenn
On Thu, Aug 27, 2009 at 5:16 PM, Dan Werthimer <[email protected]
<mailto:[email protected]>> wrote:
dear casper collaborators,
can anybody please advise ron on his question
appended below about problems with 32K point
wideband real transforms??
ron - does your 32K wideband real FFT work
correctly in simulation?
we've build instruments doing 32K complex transforms,
but these FFT's are complex (not real),
and they are biplex (not wideband), so this is
probably not a very useful data point.
best wishes,
dan
[email protected] wrote:
...
We have problems taking the Real Sampled Wide-band FFT
(fft_wideband_real) from 16kpt to 32kpt. It works fine at 16k
with 8bit and 10bit sampled data input and we have adequate chip
resources and we don't believe it is timing issue.
At 32kpt we have considerable unwanted spectra. Has anyone used
this with SP block with this number of complex channels? We
suspect a fault with SP block?
Ron Beresford
/Systems Engineer ASKAP/SKA /
/CSIRO Australia Telescope National Facility/
/Vimiera & Pembroke Rds/
/Marsfield NSW Australia 2122/
/Ph 61-2-9372-4315/
/Fx 61-2-9372-4310/
/Mob 0428 294 711/
www.atnf.csiro.au <http://www.atnf.csiro.au>
<http://www.atnf.csiro.au/>
This email is Australian made of entirely 100% recycled words.
Please dispose of it thoughtfully.
