---------- Forwarded message ---------- From: Robert Jördens <jord...@gmail.com> Date: Wed, Oct 29, 2014 at 11:01 PM Subject: Re: [ARTIQ] TTL/DDS breakout meeting report To: "Slichter, Daniel H." <daniel.slich...@nist.gov>
On Wed, Oct 29, 2014 at 1:29 PM, Slichter, Daniel H. <daniel.slich...@nist.gov> wrote: > 2. We are planning to implement DDS synchronization among all the DDS > chips and feed back their SYNC_CLK to the FPGA, allowing us to ensure that > setup times are met when performing DDS updates (IO_UPDATE aka FUD). Can > the RTIO core + SoC currently handle this behavior? This would entail > synchronizing the IO_UPDATE output to the SYNC_CLK input, with a fixed but > programmable delay – perhaps most simply done by synchronizing the start > time of the experiment to an edge of the SYNC_CLK input to the FPGA. Could > this be handled in the same way that the mains triggering is handled? We > would also want some sort of timeout and error handling protocol in the case > that the SYNC_CLK signal is not present. I think it would be sufficient to > wait 10 us for a SYNC_CLK edge and then just start the experiment, but > raising a flag so the user knows the SYNC_CLK was absent. You need to treat each DDS individually. Quoting AD: "If you need to run faster than 2.5 GHz, then the AD9914 cannot be synchronized reliably/repeatably. We excluded the synchronization section from the data sheet to avoid the issue where users try to synchronize at higher speeds and find that it isn't working." If you go for a slower clock, you can take the ad9915 and implement correct synchronization as in its datasheet. For the ad9858, synchronization will not work with the current pcb because (at least) of the divide-by-2 ambiguity. -- Robert Jordens. -- Robert Jordens. _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
