sayma v2.0: implement new synchronisation scheme

[hartytp]

We now have a proven scheme for board-board synchronisation:

• either change the PLL for one which can provide the required range of DAC clock frequencies with deterministic phase relative to the reference clock, or add some means of using the FPGA to measure the dac clock phase so we can reset the divider until the phase is correct. Edit: maybe do both so we have a fallback plan e.g: route the reference clock to a cc pin on the RTM FPGA, and route the DAC clock to a differential input (but make sure we use one with sensible IDELAYs). Do a DAC clock eye scan and reset the DAC dividers (toggle between two values) until we achieve the correct phase
• Pick output on the RTM FPGA to be the SYSREF source (I'm assuming that we are happy to use a global SYSREF signal rather than having independent ones per DAC)
• add a FF that retimes the FPGA SYSREF onto the reference clock to remove jitter. This must be a fast, low-jitter flip flop. In my demo, I'm using a MC100EP31
• the FF D input (FPGA SYSREF) can be a simple LVCMOS signal, since it doesn't need to be that fast or low-jitter so there's no need to make it differential. I'm matching LVCMOS to the FF LVPECL input with a simple potential divider. NB this signal should be DC coupled from the FPGA to the FF
• the FF clock can be either SE or differential, depending on what's most convenient (I'm using an AC coupled SE signal and using an RC network to match to LVPECL)
• FF output to digital delay line
• I'm using NB6l295M which is LVPECL, but there's also a CML version if that's easier
• one FF output can drive both delay line inputs without issue, both should be DC coupled (again, add required RC network to match and terminate)
• Delay line SPI (SCLK, MOSI, EN, LOAD) driven by RTM FPGA
• delay line outputs connect to DAC sysref inputs these should be DC coupled and terminated. NB we need an RC network to match to the required 600mV common-mode input voltage. Add 0R pads that can be used for AC-coupling capacitors in the SYSREF inputs in case we decide to use that later
• remove HMC7043 + JESD ADCs (no clock source for them anymore and, in any case, there doesn't seem to be a use case for them now that the AFE will have LVDS ADCs)
• @sbourdeauducq is there any need to route the DAC/ADC SYNC lines over the AMC<->RTM connector, or can they just go to the RTM FPGA? One option would be to route these lines to the RTM FPGA and then add some LVCMOS GPIO between the RTM and AMC FPGAs. That gives users choice in how/whether these signals are connected
• Remove the SYSREF signals from the AMC FPGA (again, just route some GPIO to the RTM FPGA and let the users decide its functionality in gateware)
• decide how to clock the AMC transceivers. This is a bit tricky given the constraints involved. @sbourdeauducq should probably decide how to do this

How does that all sound??

[sbourdeauducq]

@sbourdeauducq is there any need to route the DAC/ADC SYNC lines over the AMC<->RTM connector, or can they just go to the RTM FPGA?

The ADCs will be stripped. The DAC sync lines (FF) should be driven by the AMC FPGA to reduce dependency on DRTIO.

[dhslichter]

the FF D input (FPGA SYSREF) can be a simple LVCMOS signal, since it doesn't need to be that fast or low-jitter so there's no need to make it differential. I'm matching LVCMOS to the FF LVPECL input with a simple potential divider. NB this signal should be DC coupled from the FPGA to the FF

Does this not raise potential issues if the rise/fall times or the output jitter becomes comparable to the DAC clock period (~400 ps at max clock rate)? It seems to me that we can tolerate a lot of jitter, and not-great rise/fall times, but to run at the max clock rate we still need to pay some attention to these things, and it might be better (i.e. more margin for error) to use a higher-performance differential signal from SYSREF from FPGA. Is there a downside/problem with doing this? If not, I would advocate for it, just in case it makes a difference for robustness...

[hartytp]

@dhslichter no. The FF retimes the FPGA signal onto the 150MHz ref clk, so the FPGA SYSREF just needs to meet S/H w.r.t. the 150MHz clock. The FF SYSREF output needs to meet S/H at 2.4GHz, which is why we chose a FF with jitter in the single-digit ps...

[dhslichter]

@hartytp ack, sorry about the confusion, proceed :)

[gkasprow]

@hartytp any preference in selection of the fanout chip?

[hartytp]

Which fanout? The fanout for the reference that feeds the main PLL?

As a rule, any fanout that is in the critical path that provides the DAC clock should be a low noise one like an ADCLK. Anything that is only involved in the SYSREF path can be a LVDS one (jitter must be much lower than 100ps).

[gkasprow]

I mean the one that splits HMC830 to DACs. I assume we can leave theADCLK948 as it is now.

[hartytp]

@gkasprow let's double check that the DACs can actually handle LVPECL clock signals. I don't think we need a mux here, and we only need two outputs, so an ADCLK925 is probably more appropriate than an ADCLK948.

[gkasprow]

@hartytp ADCLK948 costs nearly the same as ADCLK925, but it has mux and we can route both HMC830 and ADF4356 and have ability to choose which one to use by software. And we already use ADCLK948 in the design.

[hartytp]

ADCLK948 costs nearly the same as ADCLK925 And we already use ADCLK948 in the design.

Okay. I don't really like using the ADCLK948 as a 2-output fanout by my objections are mainly cosmetic (to much board area, looks odd on the schematic to have so many unused outputs). Agreed, it's worth saving a BOM line, so let's use the ADCLK948.

but it has mux and we can route both HMC830

True.

• [x] Please can you add a pair of MMCX/UFL connectors that can be swapped in (solder jumpers) for the HMC830 to inject an external DAC clock for debugging. Let's make those the default population option, and keep the HMC830 as a fallback
• [x] Please make sure that the HMC830 power lines are disabled by default -- I don't want noise from the HMC830 coupling through the switch when it's off