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 > > > > > > >
