> On 01/01/2015 01:21 AM, Slichter, Daniel H. wrote:
> > For the RTIO clocking, I'm currently planning to put a 2.5V LVDS clock
> > on the USER_CLK_P/USER_CLK_N SMA connectors directly on the
> > KC705 board (goes to an MRCC pair in I/O Bank 15, pins L25 and K25).
> 
> I'm not very confident about this technique (and high speed LVDS signals on
> two separate SMA connectors in general). The differential impedance will
> not match the LVDS requirements on long sections of the transmission line.

Another option is to use a single-ended 2.5V LVCMOS clock on the USER_CLK_P SMA 
connector, this can be accomplished with a different variant of the same 
LTC6957 chip, again with very low jitter.  Our only constraint is that we need 
to use VCCO=2.5 V because Bank 15 is used to interface with other chips on the 
KC705 which constrain us.  

> What about those:
> http://www.digikey.com/product-detail/en/HMC363S8GE/1127-1028-1-
> ND/3452169
> 
> I haven't checked the jitter performance (including long-term skew
> drift) and the datasheet I found is lacking, but at first glance this
> $21 chip can divide by 8 from DC to 12GHz. Then the FPGA can divide by
> another 3 to reach 24. There are evaluation boards available for ~$300.

I looked at these Hittite chips previously and they are definitely a 
possibility if people would like to use them.  The phase noise performance may 
not be quite as good as the Wenzel parts we are planning to use but it may not 
matter in the end at that level for our purposes.  In any event, with the 
current plan each experiment is free to choose the method by which they 
generate the RTIO clock and the DDS SYSCLK (and the frequencies used for each), 
and all they need to do is provide a sine wave at each frequency with 
sufficient power.  I don't think it makes sense to try to integrate this into 
the FMC backplane since then it locks people in more.

> > The edge timing at the SYNC_IN pin is probably the main limitation
> > there.
> 
> Edge timing with the ODELAY is very precise, but it can be drowned in jitter.
> Gaussian jitter would "just" make the process more random.

I think this should hopefully not present too much of an issue, again we just 
resync until it works.  Above 3 GHz all bets are off for deterministic syncing 
anyway...

 
> > For the DDS clocking, Raghu has done some experiments to see how long
> > the DDS SYNC_CLKs maintain synchronization if they are not constantly
> > receiving synchronization pulses (both at 2.5 GHz and 3 GHz SYSCLK),
> > and it seems they have a tendency to lose lock with each other at
> > around 1, 2, or 3 hours after synchronization.
> 
> That's suspicious. I would expect the DDS divider to operate synchronously to
> SYSCLK, and so SYNCLK should not significantly drift once locked unless the
> DDS chips miss clock transitions or register spurious ones. If that's the 
> case,
> the problem would adversely affect phase coherence as well.
> 
> What does ADI tech support say about this? How large/fast was the drift?
> Was it continuous, or did it happen in discrete steps of e.g. one SYSCLK
> period? Was the chip operating well within specs - good power supply
> voltages, no ground bounce, good SYSCLK signal integrity?

There is no drift to speak of (at least, not that is meaningful given our 
measurement setup); the loss of lock occurs as a discrete jump, usually of 2 
SYSCLK cycles (in either direction).  I haven't talked to Analog Devices about 
this, but they might be able to shed some light on it.  As far as I know, 
everything is operating well within spec, and we are using two demo boards from 
AD so there shouldn't be issues with our board design at fault here.  

Agreed that this affects phase coherence, thus my suggestion of a feature to 
check the SYNC_CLK phase before and after an experiment and raise a flag if it 
has shifted by more than half a SYSCLK period (to allow for some inevitable 
jitter in the SYNC_CLK signal to the FPGA).  

> A 300ps rise time is large when syncing at 3.5GHz, and differential signaling
> does sound like a better option. (Unfortunately, HP banks are not available
> on the FMC...)

Correct, but this is the rise time that is available from the DDS chips 
themselves on their SYNC_OUT for example.  In general it's going to be hard to 
get a rise time that is much faster out of 3.3V LVCMOS, which is what we need 
to interface with the SYNC_IN pin of the DDS chips.  

> I think that level translators on the data bus should be fine, especially as 
> the
> register readback performance does not matter. In regular operation (as
> opposed to debugging DDS communication issues), we are only writing to the
> DDS chips and data lines are driven by the FPGA all the time.
>
> TMDS (which is supported at 3.3V VCCO for outputs) may also be an option

I'd rather not deal with level translators if they are not necessary, although 
your point is well taken that we don't need the utmost speed for the readback.  
However, even if we send the DDS sync signals over LVDS they will still need to 
be converted to 3.3V LVCMOS at some point, and then I think we are right back 
where we started in terms of rise times and resulting jitter.  The fact that it 
seems to work fine at up to 3 GHz SYSCLK with our current setup all in LVCMOS 
makes me feel that all this craziness to make one LVDS line for the syncing 
isn't really worth it.

> Ok. This does not take into account the differences in pin input capacitances,
> but we may be able to neglect or model them.

What we care about is not necessarily the absolute phase of SYNC_CLK from DDS 
to DDS (as long as they are sufficiently aligned that the I/O update window can 
be met for all DDS chips simultaneously), but rather the repeatability.  This 
will not be affected by pin capacitances since those are fixed for each DDS 
card.  As long as the FPGA sets up the SYNC_CLK of each DDS to the same phase 
relative to the RTIO clock (to within < 0.5 SYSCLK cycles) each time, we're 
good.  
 
Happy New Year!
Daniel

_______________________________________________
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Reply via email to