clocking and DRTIO

[dhslichter]

@sbourdeauducq are you currently planning to implement DRTIO over EEM for this carrier card? If so, should we be copying part/all of the clock cleaning/recovery circuitry used on e.g. Kasli and reproduce that here? The cards on the FMC daughterboard will likely need high-quality clocks, and it would be nice to be able to use a DRTIO-derived clock instead of an external clock to achieve this.

See also discussion: #3 (comment)

[sbourdeauducq]

DRTIO over EEM does not have a CDR, so the noise will be less (it would be similar to HDMI signaling). The clock will be transmitted on a EEM LVDS pair and not recovered from the data. It would still go through relatively noisy FPGA fabric though (including on-chip MMCMs/PLLs for phase shift), so it all depends how much of a clock quality is required.

There's the option of having another clock connection that does not go through FPGAs, like we do with the MMCX cables on Urukul/Mirny. But we would need to be able to adjust its phase at the receiver to align it with the data; are there practical low-noise chips for doing that?

Otherwise yes we could go for a WRPLL-style jitter filter, but note that it is not finished currently (ping @hartytp @cjbe).

[sbourdeauducq]

Or we can maybe avoid this with some clock/data delay calibration that is stored e.g. in a EEPROM or the device database to keep skew reproducible.

[dhslichter]

For Shuttler we need a decent clock but it will only be ~100-150 MHz so the requirements are a bit less stringent than for Urukul at 1 GHz. However, it probably makes sense to be able to have an Urukul/Mirny-quality clock on the carrier board because FMC cards will likely include things like high-sample-rate ADCs or DACs where this is important. MMCX from a Kasli would be suitable, but I don't know about the phase alignment circuitry -- how is this done right now with Urukul?

[sbourdeauducq]

With a calibration and storage in EEPROM.

[gkasprow]

Shuttler has Silabs Si549 clock generator; it also accepts low jitter clock via MCX connector as well as from dedicated FMC clock pair which is routed to the Carrier clock distribution chip which takes external/MCX/backplane clock and routes it to FMC and FPGA.
So once we connect low jitter clock from Kasli, we can run all Shuttler boards from it.
We can also PLL-lock the Silabs oscillator which sits on Shuttler FMC which would further reduce the noise.

[sbourdeauducq]

We can also PLL-lock the Silabs oscillator which sits on Shuttler FMC which would further reduce the noise.

This needs WRPLL-style circuitry (another Silabs oscillator) and finishing the WRPLL code.

[dhslichter]

Without seeing schematics here, are there phase determinism issues with this arrangement?

[sbourdeauducq]

A simple option (if it works reliably across VT): We can use the MMCX as main and low-jitter clock, then have 2x4x625Mbps DRTIO signals on the EEM connector synchronous to the MMCX clock, with data delays that are fixed after a calibration. Calibration must be repeated when changing MMCX or EEM cables. At 625Mbps my guess is there should be enough timing margin for VT effects afterwards.
Straightforward delay calibration can be implemented with oversampling at 1250Msps on the receiver side.
This all can be done with just the FPGA and no PLL chips or other special hardware support.