agreed. anybody already have, or want to develop, a coefficient interpolator?
dan On Mon, Jan 21, 2013 at 3:44 PM, Aaron Parsons <apars...@astron.berkeley.edu > wrote: > 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 <d...@ssl.berkeley.edu>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 < >> apars...@astron.berkeley.edu> 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 <d...@ssl.berkeley.edu>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 >>>> <d...@thetelegraphic.com>wrote: >>>> >>>>> Hey Jason, >>>>> >>>>> Rewinding the thread a bit: >>>>> >>>>> On Fri, Jan 4, 2013 at 7:39 AM, Jason Manley <jman...@ska.ac.za>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 >
