> 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
