Hi Jason, If the ibobs are clocked synchronously (as in Richard's setup), how could the internal syncs be out of alignment (after proper triggering on a 1pps?).
As I understand it, once you trigger on the 1pps the two ibob internal syncs should be perfectly aligned, both in cycle number and time (subject to some possible glitch)? - Andrew On 8/28/09 2:23 AM, "Jason Manley" <[email protected]> wrote: > 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 >
