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/
