On 01/08/2015 07:17 AM, Slichter, Daniel H. wrote: >> The phase of that distant DDS will also be off by roughly the >> propagation delay. > > See above; this is not an issue because we don't really care about > the absolute phase difference between DDS chips at the plane of the > DDS outputs, just that this phase difference is fixed and returned to > the same value by the SYNC process.
Well, synchronizing them to one SYSCLK provides an elegant solution to this problem and that of meeting setup times on all chips, at the cost of having another skew-matched layout for the distribution buffer to flip-flop lines. As I believe you can add more layers to the backplane in the worst case, the difficulty sounds reasonable. If the SYSCLK-perfect approach fails for some reason (such as part-to-part skew on SYNCLK within the DDS chips), we can fall back on the "fixed phase difference" solution. Other advantages of the SYSCLK-perfect synchronization is that the DDS hardware becomes fully interchangeable without phase differences from one box to the next, and testing that the sychronization actually works can be done with a straightforward observation of the SYNCLKs or the outputs on a multi-channel fast scope. Actually, it might be better to connect the analog output of the DDS to a flip-flop instead of or in addition to SYNCLK. This way, the above-mentioned part-to-part skew on SYNCLK within the DDS chips is out of the equation (and it should be negligible for the setup times), and we can re-use the flip-flop for unit tests of driver functionality such as different phase modes. The main problem is that the system will need to output waveforms during synchronization. On 01/08/2015 08:07 AM, Slichter, Daniel H. wrote: > Originally the motivation for using this FMC backplane/DDS riser > scheme was that it required minimal modification of an existing > design. Now that we are trying to do the DDS synchronization using > the FPGA and traces on the backplane as well, it's getting a bit more > involved. However, I don't think the level of complexity approaches > what might be necessary if we move to a COTS crate architecture like > MicroTCA for the DDS's, where it would probably be necessary to have > a distributed RTIO core and an FPGA on each card to handle > communications, which run over gigabit Ethernet or PCIe in those > standards. Yes, connecting a rack to the KC705 would be complicated, mechanically and electrically. Sébastien _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
