Hi Glenn: I updated casper library last week. I found the 32K FFT could not generate right output even I modified the max coefficient depth to 13 which helps me fix this problem last time.
16K FFT is all right. Any suggestions? Thanks a lot. Wa n ________________________________ From: G Jones [mailto:glenn.calt...@gmail.com] Sent: Tuesday, 1 September 2009 9:28 AM To: Cheng, Wan (ATNF, Marsfield) Cc: d...@ssl.berkeley.edu; Beresford, Ron (ATNF, Marsfield); casper@lists.berkeley.edu Subject: Re: [casper] ROACH progress. I found this to be the case as well. I believe that the technique should work, but there is some bug in the implementation currently. Glenn On Mon, Aug 31, 2009 at 4:24 PM, <wan.ch...@csiro.au> wrote: Hi Dan: The problem is fixed by using all the coefficients. And I also check the size of coefficient of different size FFT. I found FFT size(bits number) is always equal or smaller than the coefficient size. So I guess the coefficients are not picked up correctly in Casper design? Any idea? Wan -----Original Message----- From: Dan Werthimer [mailto:d...@ssl.berkeley.edu<mailto:d...@ssl.berkeley.edu>] Sent: Friday, 28 August 2009 10:51 AM To: G Jones Cc: Beresford, Ron (ATNF, Marsfield); casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> Subject: Re: [casper] ROACH progress. 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 > <d...@ssl.berkeley.edu<mailto:d...@ssl.berkeley.edu> > <mailto:d...@ssl.berkeley.edu<mailto:d...@ssl.berkeley.edu>>> 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 > > > > ron.beresf...@csiro.au 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> > <http://www.atnf.csiro.au/> > > This email is Australian made of entirely 100% recycled words. > > Please dispose of it thoughtfully. > > > > >
