clock link AMC-to-RTM

[jordens]

2016-11-11 google hangouts consensus item:

For stand-alone operation (in a minimal enclosure or on the bench), it's useful and convenient to not have to provide a phase locked 100 MHz clock on the minimal rf backplane or the RTM frontpanel but to be able to use the recovered and jitter-cleaned RTIO clock to drive the clock tree on the RTM.

Therefore, the one output of the SI5324 synth/jitter cleaner on the AMC that goes to FPGA general purpose should go into a fan-out and then into an SMA that can be connected to another SMA on the RTM to feed the HMC830. This obviously assumes that there is no backplane that's in the way of the SMA cable.

[sbourdeauducq]

Can't the FPGA do that clock fanout? Or are you worried about noise?

[jordens]

Having the fpga do the fanout was deemed too noisy.

[hartytp]

@jordens Can you remind me why we can't use the SI5324 on the RTM for this.

[jordens]

That's one level of FPGA plus serial link plus FPGA plus SI5324 noisier. But fine by me if the jitter is still good enough. I forgot that we had that thing there as well.

[jordens]

And I would like to seize this opportunity to point out again that this desire to squeeze so many channels into this has lead to a big and otherwise unnecessary increase in complexity, delays, and mission creep.

[hartytp]

"might as well be hanged for a sheep as a lamb"... presumably, once we've been through one set of fibre-cdr-SI324, the added jitter from going through it all a second time will only be ~3dB, which isn't likely to be significant.

IHMO, this is a reasonable price to pay for reducing the amount of AMC-RTM wiring -- if we actually cared about the noise in this clock path, then it'd be better to use a lower-noise component than the SI5324...

@jordens what frequency are SI_CLK_OUT_1/SI_CLK_OUT_2? Which one should we use as the 100MHz reference for the HMC830?

[sbourdeauducq]

Note that the SI5324 on the RTM side might operate at a submultiple of the RTIO clock, or even asynchronously to the RTIO clock in the first gateware implementations.

[hartytp]

@sbourdeauducq Okay, would you prefer to use the AMC SI5324 then, and route the recovered 100MHz clock over the AMC-RTM connector? If so, which output from the AMC SI5324 would you like to route to the RTM?

[jordens]

@hartytp I don't see how that's a significant simplification. It's adding a fan-out on the AMC and routing one signal over the connector versus adding a fan-out on the RTM and routing it there. The frequencies will be dictated by the RTM-AMC data link clocking. We want both available to the FPGAs.

[hartytp]

@jordens It's not a significant simplification, just a minor convenience: it seems sensible not to route a signal over the AMC<=> RTM connector if we are already generating it on the RTM. But, if there's a reason to prefer to use the SI5234 on the AMC then go for it.

Can you confirm which output (1/2) from which SI5324 (AMC/RTM) you want to be used as the 100MHz source in CDR mode, please?

[jordens]

The ones going to the fabric. SI_CLK_OUT2 on the RTM or SI_CLK_OUT1 on the AMC in 1.0rc1. With fan-outs.

[hartytp]

Any preference over RTM/AMC (or, are they equivalent as far as you're concerned)?

[jordens]

Doesn't make much of a difference to me. @sbourdeauducq should weigh in regarding the likelihood of actually spitting out 100 MHz on either. AFAICT the frequency doesn't need to be 100 MHz because the HMC830 can cope.

[hartytp]

@jordens True, the HMC830's N- and R-dividers are 19-bit and 14-bit respectively, so this is unlikely to be a problem for any vaguely sensible SI5234 frequency.

In that case, I propose the following:

• We don't alter the AMC or add any new AMC <-> RTM connections for the recovered clock
• We add a fanout buffer on the RTM SI5234's SI_CLK_OUT2 output
• We route one output of this fanout buffer to a clock mux, whose other input is the backplane/front-panel 100MHz reference (on the current version of the schematic, this corresponds to the ADCLK948 output that routes to OSCIN on the HMC7044)
• This signal goes through a balun (TCM2-43X+) for differential to single-ended conversion and then to the HMC830 reference input.
• The HMC830's output goes through an ADCLK948 or similar clock mux, whose other input is the clock mezzanine output. The output of this mux goes into the HMC7043 input.

Objections?

[sbourdeauducq]

AFAICT for our purposes we can always arrange the gateware for the AMC-RTM link clock to be derived from the same oscillator as the RTIO clock. We can remove the fanout buffer, disconnect CLK_OUT2 from the FPGA and use it exclusively for driving the HMC830. The reasons I wanted a Si5324 to GCLK connection are 1) the IBUFDS_GTE2 has a rather wide and vague skew specification 2) the connection inside the FPGA between the transceiver and fabric parts of the die seems to be noisy. As the RTM FPGA is not involved in high precision timing, this is unimportant here.

[hartytp]

@sbourdeauducq ACK. Modified proposal is then:

• We don't alter the AMC or add any new AMC <-> RTM connections for the recovered clock
• Disconnect RTM SI5234's SI_CLK_OUT2 output from the RTM FPGA
• Route RTM SI5234 CLK_OUT2 to a clock mux, whose other input is the backplane/front-panel 100MHz reference (on the current version of the schematic, this corresponds to the ADCLK948 output that routes to OSCIN on the HMC7044) -This signal goes through a balun (TCM2-43X+) for differential to single-ended conversion and then to the HMC830 reference input.
• The HMC830's output goes through an ADCLK948 or similar clock mux, whose other input is the clock mezzanine output. The output of this mux goes into the HMC7043 input.

[hartytp]

To make life easier for @gkasprow, I'll close this issue and raise a new summary issue...