Hi Jack, I finally got hold of this issue.
The problem was in the pfb_fir_generic block. After replacing it, the fft output was as expected. Cheers, Amit On 06-Nov-15 5:04 PM, Jack Hickish wrote: > Hi Amit, > > I've hastily fixed that error regarding bram latency -- it's pushed to > the master casper branch at https://github.com/casper-astro/mlib_devel.git > > You should be able to cherry pick that commit into your repository, but > I recommend just using the casper-astro master branch rather than the > SMA branch you're currently working with. The SMA code was merged into > casper-astro more recently than the commit you are currently at anyway. > > As for your spectra, I'd suggest seeing if the problem persists with the > latest casper-astro master branch and then investigating further from there. > > Cheers, > Jack > > > On Fri, 6 Nov 2015 at 11:14 Amit Bansod <[email protected] > <mailto:[email protected]>> wrote: > > Dear All, > > I am trying to extract 1 channel/band using PFB/FFT (pfb_fir_generic & > fft_wideband_real blocks from casper library) and I am getting > inconsistent result from a 64 channel PFB/FFT. > > I also found that the for 64 channel FFT, the fft_wideband_real block > breaks at fft_wideband_real/fft_biplex_real_4x/bi_real_unscr_4x/delay0 > (or ../bi_real_unscr_4x/delay1) for BRAM latency > 2. Can this be also a > cause for concern ? > > I have enclosed the plots of the same band for the 64 & 128 channel > FFTs. The BW of 1 band is 12.5 MHz for 128 channels and 25 MHz for 64 > channels FFT. > > The design has ASIAA 5g ADCs with fpga running at 200 MHz and same noise > source is feeding both ADCs. > > I am using the sma-wideband repository with commit : ecab6f5 > > > Regards, > Amit Bansod >
