> That sounds reasonable. What about using LVDS and two male SMA > connectors, e.g.: > http://www.digikey.com/product- > detail/en/CONSMA013.031/CONSMA013.031-ND/1577227 > soldered on the back of the LTC6957 PCB? They would serve both as a short > electrical connection and mechanical mount. I suppose that the > LTC6957 PCB will be very small (so it can be reasonably designed not to bump > into parts of the KC705 or the FMC cards) and has no other connectors on the > back.
Sounds good, although for mechanical compatibility it might be better to use two extremely short (<1") SMA cables, since the axial misalignment tolerances on SMA are not very forgiving. We can test it out and see how it goes. > > The 3.3V LVCMOS DDS sync signal would be sent to a TI CDCLVC1112 1:12 > > LVCMOS clock fanout (http://www.ti.com/product/cdclvc1112) located > > very close to the FMC connector, which would then fan out the sync > > signal with one output channel dedicated to each DDS's SYNC_IN pin via > > an analog switch. This way the sync signal is always point-to-point > > (nothing shared on a bus), so loading (and corresponding slow > > rise/fall times) should not be an issue for the FPGA output. The > > additive jitter of this part is extremely low (~100 > > fs) so we will be limited by jitter due to the rise times from the > > FPGA. > > That CDCLVC1112 also has slow rise times, but it seems that it's unavoidable > with LVCMOS. An AND gate instead of the analog switch would also work. > Skew does not matter for SYNC_IN, as the FPGA will scan its timing until it > receives an aligned SYNC_CLK. Skew does matter, however, for SYNC_CLK. 3.3V LVCMOS just always has a slower rise time -- this is a consequence of the much higher voltages involved. So for a given slew rate that a driver can produce, you'll get a faster rise time for something like LVDS (where the swing is hundreds of mV) than for something that needs to swing by several volts. And this is (one of) the reasons people don't use 3.3 LVCMOS for high-speed signaling :) > > As to the question of returning the SYNC_CLK signal to the FPGA, I had > > been talking about using an analog switch to pass the SYNC_CLK to the > > FPGA using a shared bus (with a chip-select pin to determine the state > > of the switch). > > All SYNC_CLKs need to be matched (ideally to less than a SYSCLK cycle) so > that the FPGA can properly detect when they are aligned, and a shared bus > will not achieve that. This is not necessarily required, I had thought. What we need is to repeatably set the phase relationships of all the different SYNC_CLKs to within less than a SYSCLK cycle, and we need the SYNC_CLK phases to be such that we can meet the IO_UPDATE setup and hold time criteria for all DDS boards at the same time, but this does not necessarily imply that the SYNC_CLKs are aligned either at the FPGA or at the DDS cards themselves. In fact, one might consider the situation were you want the SYNC_CLK of a more distant DDS to lag behind that of a nearer DDS, which would give more headroom for the IO_UPDATE setup time by accounting for the propagation delay of the IO_UPDATE pulse down the shared bus. Are there limitations on the IDELAY/ODELAY range that make this problematic? My vision for a synchronization had been as follows: 1) Enable the sync feature on one DDS and turn on the analog switch on SYNC_IN. 2) Send a SYNC_IN pulse from the FPGA to the clock fanout, which is then received by the DDS with the enabled syncing (others do not receive it due to analog switch on their cards being off). 3) Sweep the ODELAY from the FPGA while monitoring the phase of the returned SYNC_CLK from that DDS, stopping when the SYNC_CLK is stable with the correct phase. 4) Disable the sync feature on the DDS. 5) Repeat for all other DDS chips. The "correct phase" in 3) can be established in one of several ways: a) use a readback loop in hardware to connect the FPGA to the DDS board and back again, measure round-trip time, divide by two to estimate propagation delay, and use this to figure out the desired phase relationship. b) set up a system where you can look at the SYNC_CLK pulses over matched-length coax cables using a fast oscilloscope. Run the FPGA ODELAY syncing sequence until these are aligned as desired, then figure out the phase relationship of the SYNC_CLK signals at the FPGA and have it remember this phase relationship for all future syncing. The board-to-board variations in propagation times should be low enough that this would work if we measured it once and then used those values for all FMC daughter cards. Once the SYNC_CLK is fixed, we just would need to check periodically (before and after each experiment, for example) to make sure that the phases of each SYNC_CLK are where we want them to be. > What about using a multiplexer with matched trace lengths to each DDS? > It seems a bit difficult however to find a multiplexer that has at the same > time a large number of inputs (so we don't have the part-to-part skew > problem), low skew between the inputs, and LVCMOS or LVDS support. The > SY100E164 would be good, except it's old 5V ECL which requires inconvenient > supply voltages (and LVCMOS->ECL translators again seem to have the part- > to-part skew problem). Let me know if you find something. This seems more difficult, but I will look into it if need be. Again, the part-to-part skew is what kills us every time. > Routing each SYNC_CLK to the FPGA with matched trace lengths all the way is > also an option. Using one IDELAY and one IOB register per input (all clocked > from the same network) should result in low skew. This approach would cost us too many pins on the FMC connector, unfortunately...we need to multiplex the SYNC_CLK signals or else multiplex the chip select signals. It seems that most folks want to keep the chip select signals separate so we can change multiple DDSs simultaneously, something that cannot be done in the current system. Seems not worth giving up this feature. Daniel _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
