Placing snap blocks on separate ibobs will not be a definitive test,
but would certainly be helpful. You would have to trigger them from
the external 1PPS, which is not guaranteed to be perfectly aligned
across boards after the first arm-trigger-sync operation (you may
jitter by one or two clocks). Bear this in mind when interpreting the
two captures... that the values could be out by up to 2 counts.
Triggering the snap blocks off the internally-generated sync pulses
would defeat the purpose entirely, since the syncs would force the
local counters to trigger the snap blocks at the same values even if
they don't occur at the same time.
Jason
On 28 Aug 2009, at 11:10, Andrew Siemion wrote:
Hi Richard,
Did you add snap blocks to the counters prior to the xaui links,
triggered on a sync, to ensure that the ibobs are indeed synchronized?
- Andrew
On 8/28/09 2:02 AM, "Richard Armstrong"
<[email protected]> wrote:
Dear CASPERites,
I've been trying for some time to synchronise two XAUI streams from
two separate IBOB boards in a BEE2 board. I've not met with much
success. I'd be really grateful any ideas or help from anyone who
may have experience with this, or perhaps a better general
understanding of the issues I'm encountering.
The test system I've got is as follows: I'm clocking my IBOBs
synchronously and aligning them with a 1PPS input. Each IBOB has a
31-bit counter which is reset off a 'sync' pulse. The sync pulse is
generated by a circuit that is aligned with the 1PPS signal. I'm
sending the counter value multiplexed with the sync in a demux-by-2
XAUI block to the BEE2. At the BEE2, I'm testing the alignment of
the counters.
In my mind, as long as the ibob data rate is low enough, the XAUI
interface should provide complete clock-domain isolation. That is,
the bee2 should be able to be clocked at any rate, including a
lower rate than the ibob (provided, again that the data transfer
rate is low enough).
Worryingly, and unexpectedly, I find the counter values way out of
alignment, and perhaps worse than this, there seems to be jitter on
the difference between the counter values from cycle to cycle.
Andrew and Peter helped me out for a couple of days on their way to
Paris. We corrected some of the design errors (namely, selecting
demux-by-2 for 32-bit data), made sure the ibob clock was running
slower than the bee2 clock, and changed the length of the sync
pulse. However, we were unable to resolve the fundamental issues.
This week I've been trying to clock the BEE2 off an IBOB-generated
clock with an LVTTL-to-LVPECL clock driver. I changed the BEE2
design and changed a jumper to select user-clock on the BEE2 board.
Unfortunately, this doesn't seem to help much (although, I could be
doing it wrong) and I'm finding with this scheme that the BEE2 has
the tendancy to kill the running process after a few seconds to
minutes.
I know many of the more experienced CASPERites advise asynchronous
designs for this reason. However, I'm pretty sure someone else must
have disregarded this advice (or perhaps discovered this advice) by
pursuing XAUI synchronisation. Were these same issues seen? What's
the best clocking scheme in practice (fully synchronous or
downstream boards clcoked faster)? Does anyone have any ideas on
jitter?
Thanks,
Richard
