On 01/03/2015 06:47 AM, Slichter, Daniel H. wrote: >> 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.
That would be unterminated (on-die 50 ohm termination is only supported for VCCO <= 1.8V) so there can be signal integrity issues at long cable lengths. What about adding to the FMC backplane a connector that is properly designed for high speed differential signaling, e.g. SATA? The impedance is the same as LVDS so standard SATA cables can be used. Then add a LVCMOS33 translator; the only unmatched length becomes the traces between the translator and the FPGA which are shorter than typical cables and do not depend on a particular lab setup. > 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. My experience with Spartan-6 is that it doesn't like signals lingering between the logic high and logic low thresholds, so I was thinking that adding a fast LVDS comparator such as the ADCMP604 near each DDS chip could improve things. But we would have to take into account the comparators' part-to-part skew, which isn't specified by ADI (they only give a "typical" propagation delay value), and this is another rabbit hole. > 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, we can give it a try. Let's hope that all the resulting jitter is Gaussian so we can do an average on the FPGA to get to the actual timing of incoming SYNC_CLK transitions. What's the plan for acceptable signal integrity on the long traces that go across the backplane? >> 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. At each DDS chip, IO_UPDATE must be stable for at least 2ns before each SYNC_CLK rising edge (AD9914 datasheet p.6 "IO_UPDATE Pin Setup Time to SYNC_CLK"). We must have enough control on the timing to achieve this. Sébastien _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
