Hi,

On 01/06/2015 04:43 AM, Slichter, Daniel H. wrote:
> Is there an on-die 100-ohm differential termination for LVDS signals 
> at VCCO = 2.5V?

Yes.

> Either way, it's actually a physically shorter distance from the SMA
> connector to the FPGA (~5 cm) than from the FMC connector to the
> FPGA, so if we have to use LVCMOS to drive the clock we're still
> better using the SMA connector, if we ensure that the LTC6957 chip is
> attached directly to the board (no long cables).  In addition, at
> these frequencies I would imagine we could get away with an LVDS
> signal that is differential on the clock driver board, goes to two
> extremely short SMA cables to the SMA connectors on the KC705, and
> then comes back (the traces on the KC705 are 100 ohm differential 
> from the FPGA until right next to the SMA connectors).

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.

>>> 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,
> 
> What do you mean by signals "lingering" in this particular instance? 
> Slow rise/fall times?

Slow rise/fall times received by the FPGA. Internal FPGA signals couple
to them and cause jitter, and in extreme cases glitches even if the
signal is monotonic at the FPGA pad (this won't happen here).

> 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.

> 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.

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.

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.

Sébastien
_______________________________________________
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Reply via email to