Hi David, Traditionally, the CASPER libraries are much better at processing data many times the rate of the FPGA rather than the other way around. So while your suggestion of reusing multipliers is of course a good one, it's generally not well implemented in the CASPER libraries. You might consider using Xilinx filters for the PFB_FIR section (perhaps) followed by CASPER FFTs. The FFTs could be shared amongst many lower bandwidth signals by sending one frame of data at a time through the FFT.
You can estimate the resource usage by drilling down into the blocks (look under mask) and manually counting. Or you can make a couple test designs, count the resources (planahead is convenient for doing this) and the figure out how it's scaling. Good to check this against your estimate to make sure it's doing things the way you expect. Most blocks have an option to explicitly use DSP48s or general logic for the implementation. Glenn On Mon, Jun 10, 2013 at 12:07 PM, David Saroff <[email protected]> wrote: > Short of compiling a design, can the resource usage of a PFB yellow block > be seen? > > If the data rate is some submultiple of the FPGA clock, say 50 MSPS and > 200 MHz is there a natural way to share resources? > > The question's context: > 38 dipole antennae of the focal plane array for the green bank telescope. > Signal from each of the 38 is sampled at 50 MSPS, digitized to 12 bits. > What frequency resolution fits on a virtex-6? That is what is the number > of taps P and fft bins n that will fit? > > Count multipliers as dsp48 blocks. > > 2000/38 =~ 50 dsp48 blocks per signal. That doesn't seem like enough. If > there is a way to resource share, is there a factor of 200MHz/50MHz = 4 > available ideally? Then it looks more like 4 * 50 = 200 dsp48's per > channel. That still doesn't seem like enough. > > What about a sample rate of 2.5 MHz? Then the potential reuse multiplier > is 200MHz/2.5MHz = 80 and the number of multiplies per channel is a more > comfortable 80 * 50 = 4000 The bandwidth is less for the 2.5 MSPS vrs 50 > MSPS, by a factor of 1/20th. That makes fewer fft bins n necessary, so > might the advantage of lower sampling rates and narrower band widths be > quadratic? > > Summary > 1)when we parametrize a PFB, can we conveniently see how many dsp48s and > slices, etc it requires? > > 2)if a PFB receives samples slower than the system clock, is there a way > to share it between channels? > > some embarrassment for the beginner's questions. > > > >
