Hi, Happy new year to all!
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 would be > to use a PLO at the DDS SYSCLK frequency and then employ a 24x > divider, which would give better phase noise performance at the RTIO > clock frequency, but a) I don't think the PLO is the limit on the > RTIO clock phase noise, and b) the divider system is more expensive > and would require purchase orders. 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. > For the Magtrap experiment, we will clock the RTIO core at 100 MHz > and the DDS chips at 2.4 GHz -- this is optimal in terms of where the > DDS spurs are located with respect to the Mg+ transition frequencies. > For other experiments, people may use higher frequencies. Above 3 > GHz we haven't been able to get the DDS clocks to sync reliably, > though. This may work better with the FPGA-based syncing because > even if the process is a bit random, you can just send individual > SYNC pulses until the SYNC_CLK phase is as desired and then stop. Agreed. > 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. > 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? > The current DDS sync design I envision involves using one 3.3V LVCMOS > line from the FPGA to send a synchronization signal, which will go to > a 1:12 LVCMOS clock distribution chip on the FMC backplane. > Unfortunately we cannot use LVDS because all the available I/O banks > need to run at a 3.3V VCCO in order to talk to the interface logic of > the DDS chips (e.g. the parallel bus etc). Using 2.5V LVCMOS to > drive 3.3V inputs degrades our noise margin to basically zero, which > given our desire for >100 MHz bus speeds doesn't seem like a sensible > tradeoff. Putting level translators in will be a nightmare in terms > of introducing skew and latency, especially for bidirectional > signals. I don't think that using LVCMOS instead of LVDS will make a > big difference, though, as the 3.3V LVCMOS rise times (based on IBIS) > are ~300-400 ps, 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...) 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, but receiving it can be difficult as most chips come with built-in HDMI circuitry. It is possible in some cases to do it with a regular LVDS input and a few passive components; for example see the attached schematics which worked fine at several hundred Mbps. But it sounds trickier than using the level translators and 2.5V VCCO. At 3.3V, on-die termination of LVDS inputs is also not supported by the FPGA. > Each output from the clock distribution chip will be dedicated to one > DDS. On the DDS cards themselves, there will be an analog switch > which allows the clocking signal to be either passed through to the > DDS SYNC_IN or blocked (SYNC_IN pulled low after the switch), > depending on a DDS chip select signal. The same analog switch will > use another channel to pass the DDS SYNC_CLK back to the FPGA for > monitoring. It will also have two more channels that are connected > together right next to the DDS, so that the FPGA can send pulses and > measure a round-trip time from FPGA inputs to DDS and back for > deskewing if needed. Ok. This does not take into account the differences in pin input capacitances, but we may be able to neglect or model them. > I am making provision on the DDS cards themselves to do the > hardware-only syncing using the SYNC_OUT/SYNC_IN method if preferred > for some reason, so that can be a backup option. Agreed. This should make the design easier to reuse, as porting the FPGA clock synchronization mechanism is tricky if the FPGA does not have luxurious IODELAYs like the K7. I guess other groups may also be interested in a nice FMC DDS system. Best, Sébastien
vmixext-20121010.pdf
Description: Adobe PDF document
_______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
