Hi guys,
I am not sure if our experience is relevant.
It was with totally different hardware, we had a lot of sync problems.
The culprit was our technician who was testing computer monitors on the
next table.
Particularly LVDS signals are vulnerable, with a small common-mode voltage
the line receivers lock to one state. Very good grounding and shielding
help.
Easy to test, just trigger an modern oscilloscope AFTER the line receiver
for extra long cycles on the clock line. Or extra short, if there is
ringing.
Cheers,
Jouko
--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do
more of what works. If it works big, others quickly copy it. Then you do
something else. The trick is to do something else."
On Mon, 26 Nov 2012, Dan Werthimer wrote:
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 iterationsin 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/
