hi ricardo, there still might be a bug with 2^27 sync period??? a 2^27 period is so long, you might not notice a very rare occasional error in the spectra. you'd have to check the spectrum right after the sync pulse propagates through...
best wishes, dan On Mon, Nov 26, 2012 at 7:20 AM, Ricardo Finger <[email protected]> wrote: > Hello Dan and Andrew, > > Thanks for your replies. > > Yes, my sync period is a multiple of Nacc· PFB FIR taps · LCM(reorder > orders) · FFT Size / Simultaneous inputs. > > The order of the fft_unscrambler is 9 and the biblex unscramblers have > order 2, so I have a pulse sync of Nacc*4*LCM(2,2,9)*4096/8 = Nacc*36864. I > have tried Nacc=128,256 and 512 with no success. > > Thanks for the tips on debugging technics. I will implement the test data > as you suggest. > I did went through compiling with casper mlib_devel using less slices. The > 36864 minimum periode still doesnt work to me, but a 2**27 sync pulse > periode seems to work... i don't know why, since 2**27 is not a multiple of > 36864... This suggest I may have a bug after the FFT block. > At least I have something working while I gather more knowledge on sync > stuff! > > Cheers, > > Ricardo > > > On Sat, Nov 24, 2012 at 7:45 PM, Dan Werthimer <[email protected]>wrote: > >> >> hi ricardo, >> >> have you reviewed the memo on sync pulse minimum period? >> it's at: >> https://casper.berkeley.edu/memos/sync_memo_v1.pdf >> >> in particular, have you checked the number of iterations >> in the FFT reorder block? >> >> is your sync period a multiple of: >> >> Sync period = Naccumulations · PFB FIR taps · LCM(reorder orders) · >> FFT Size Simultaneous inputs >> >> >> best wishes, >> >> dan >> >> On Fri, Nov 23, 2012 at 11:25 PM, Andrew Martens <[email protected]>wrote: >> >>> Hi Ricardo >>> >>> > I am trying to build a 2-pol spectrometer in a ROACH 1. I started with >>> > the Casper mlib_devel PFB+FFT but I ran out of slices so I swap the >>> > PFB for the one used at VEGAS (taken from the monroe_library_latest) >>> > on the git repo. >>> >>> Just to let you know in case you didn't that there are various parameter >>> options for the fft and pfb_fir that allow you to trade off usage of one >>> resource for another (e.g You can force the adders in the fft butterfly >>> to be implemented in DSP48Es rather than in slices. You can also force >>> delays and coefficients at fft stages to be implemented in BRAMs instead >>> of slices). >>> >>> > The model compiled but I am having problems with synchronization. The >>> > zero channel jumps around every time I run the bof (It can be >>> > anywhere). >>> >>> To debug this, you may want to try the following; >>> * Make a new design >>> * Make 4 counters, the first one starting from 0, the second from 1 etc. >>> Make the step size 4, and make them increment to 2^N-4, 2^N-3, 2^N-2, >>> 2^N-1 (where N is the size of your FFT). >>> * Copy all the logic (accumulator etc) after the FFT in your design to >>> your new design >>> * Make the counters the real and imaginary part of the input to your >>> logic. >>> * Make a sync generator that outputs a sync exactly every accumulation >>> (e.g 2**12/4*512). >>> * If you simulate with this, or compile it and run it on the FPGA, you >>> should be able to check if everything after the FFT works correctly as >>> you can work out exactly what the output should be. This should help >>> tell you where the problem is. >>> >>> We often build these types of tests into our designs (if there is logic >>> available). We have blocks that generate test data (TVGs or test vector >>> generators) in the data path with a multiplexor allowing us to use real >>> data or the test data. This allows us to verify parts of our design and >>> help isolate bugs. It seems that you don't have much logic available >>> though, so that is why making a separate design with only part of your >>> design would be easier (quicker to compile with no chance of running out >>> of space). >>> >>> Good luck and regards >>> Andrew >>> >>> >>> >>> >>> >>> >>> >> > > > -- > Ricardo Finger Camus > Electrical Engineer > Astronomy Department > University of Chile > Of: 56(2)9771122 > Casilla 36-D, Santiago. > http://www.das.uchile.cl/lab_mwl/ >
