hi danny and ryan, i suspect if you are only doing small FFT's and PFB FIR's, 1K points or so, then BRAM isn't likely to be the limiting resource, so you might as well store all the coefficients with high precision.
but for long transforms, perhaps >4K points or so, then BRAM's might be in short supply, and then one could consider storing fewer coefficients (and also taking advantage of sin/cos and mirror symmetries, which don't degrade SNR at all). for any length FFT or PFB/FIR, even millions of points, if you store 1K coefficients with at least at least 10 bit precision, then the SNR will only be degraded slightly. quantization error analysis is nicely written up in memo #1, at https://casper.berkeley.edu/wiki/Memos best wishes, dan On Mon, Jan 21, 2013 at 4:33 AM, Danny Price <[email protected]> wrote: > Hey Jason, > > Rewinding the thread a bit: > > On Fri, Jan 4, 2013 at 7:39 AM, Jason Manley <[email protected]> wrote: > >> Andrew and I have also spoken about symmetrical co-efficients in the >> pfb_fir and I'd very much like to see this done. We recently added the >> option to share co-efficient generators across multiple inputs, which has >> helped a lot for designs with multiple ADCs. It seems to me that bigger >> designs are going to be BRAM limited (FFT BRAM requirements scale >> linearly), so we need to optimise cores to go light on this resource. >> > > Agreed that BRAM is in general more precious than compute. In addition to > using symmetrical coefficients, it might be worth looking at generating > coefficients. I did some tests this morning with a simple moving average > filter to turn 256 BRAM coefficients into 1024 (see attached model file), > and it looks pretty promising: errors are a max of about 2.5%. > > Coupling this with symmetric coefficients could cut coefficient storage to > 1/8th, at the cost of a few extra adders for the interpolation filter. > Thoughts? > > Cheers > Danny >
