I think what must be happening is even though your iBOB and BEE2 are
running on the same clock, the XAUI links have independent 156.25 MHz
clocks, so even though the same data rate is going in as coming out,
the data is available at the other end of the link at slightly
different times, so they drift in and out of sync. Although it seems
like this would require two different clocks on the BEE2 end, so maybe
this would be solved if you ensure that the pair of XAUI links you use
is clocked from the same BREF oscillator. (I think that's 0 and 2 or 1
and 3 but I can't remember right now).

Perhaps you can solve your problem as simply as not allowing reads from the
XAUI until after say 32 clocks from when the iBOB begins transmitting,
to allow the buffers to fill up a little.

Glenn

On 7/21/08, Jason Ray <j...@nrao.edu> wrote:
> All,
>
>  As some of you may know, Randy & I have been working on getting reliable
> data transmission across the inter-chip connections on the BEE2.  We managed
> to get that working reliably and have moved on to the next problem that has
> reared its ugly head.
>
>  Once we got back to the point of looking at spectra again, we soon noticed
> that we are occasionally getting spurs, on the odd harmonics of our clock
> freq +/- the input frequency.  That is, if our input frequency is 51Mhz,
> we'll see a spike at 51MHz, 149MHz, 251MHz, 549MHz, and 651MHz.  Our iBOB is
> using ADC_CLK which we have set to 800MHz, the iBOB provides the clock to
> the BEE2 usr_clk2x input.
>
>  Further investigation revealed that our two XAUI links (from the same iBOB)
> are getting out of sync.  The eight samples from the ADC are transmitted to
> the BEE2 over XAUI... four samples on XAUI0 and the other four samples on
> XAUI1.  Once they arrive at the BEE2, they are sometimes out of sync.  Its
> hard to explain in an email, but if we look at the received sample values
> (in BRAMs) we can discern the sine wave, but with discontinuities as if the
> samples are scrambled.  We have seen the sync & unsync condition come & go
> over periods of a half hour or so, so maybe there's some sort of clock
> drifting going on...?
>
>  We verified the unsync condition by generating various test patterns in the
> iBOB.  If we transmit all 1's on one clock and all 0's on the next, the two
> are out of sync at the BEE2.  If we transmit all A's, then all 5's, the two
> are generally in sync but we have seen it go out of sync, but not as often.
> We also transmitted a 32-bit counter value across the two XAUIs and have
> seen it go sync and unsync.
>
>  Has anyone ever experienced this?  Or are there any suggestions?  I
> attached a pdf of our iBOB sampler design.  At the BEE2, we simply slice
> apart the incoming XAUI data and shove it in BRAMs.
>
>  Thanks in advance!
>  Jason
>
>

Reply via email to