Agreed. The coefficient interpolator, however, could get substantial savings beyond that, even, and could be applicable to many things besides PFBs.
On Mon, Jan 21, 2013 at 3:36 PM, Dan Werthimer <[email protected]>wrote: > > hi aaron, > > if you use xilinx brams for coefficients, they can be configured as dual > port memories, > so you can get the PFB reverse and forward coefficients both at the same > time, > from the same memory, almost for free, without any memory size penalty > over single port, > > dan > > > > > On Mon, Jan 21, 2013 at 3:18 PM, Aaron Parsons < > [email protected]> wrote: > >> You guys probably appreciate this already, but although the coefficients >> in the PFB FIR are generally symmetric around the center tap, the upper and >> lower taps use these coefficients in reverse order from one another. In >> order to take advantage of the symmetry, you'll have to use dual-port ROMs >> that support two different addresses (one counting up and one counting >> down). In the original core I wrote, I instead just shared coefficients >> between the real and imaginary components. This was an easy factor of 2 >> savings. After that first factor of two, we found it was kind of >> diminishing returns... >> >> Another thought could be a small BRAM with a linear interpolator between >> addresses. This would be a block with a wide range of uses, and could >> easily cut the size of the PFB coefficients by an order of magnitude. The >> (hamming/hanning) window and the sinc that the PFB uses for its >> coefficients are smooth functions, making all the fine subdivisions for >> N>32 samples rather unnecessary. >> >> On Mon, Jan 21, 2013 at 2:56 PM, Dan Werthimer <[email protected]>wrote: >> >>> >>> >>> 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 >>>> >>> >>> >> >> >> -- >> Aaron Parsons >> 510-306-4322 >> Hearst Field Annex B54, UCB >> > > -- Aaron Parsons 510-306-4322 Hearst Field Annex B54, UCB
