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 >
