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: https://github.com/sinara-hw/EEM_FMC_Carrier/discussions/3#discussion-3449874

[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?