LMK04832: LMK04832: Help getting synchronized clock outputs and SYSREFs in multi-LMK04832 setup

With SYNC_DISSYSREF set, you are preventing the SYSREF divider from being reset when the SYNC event is triggered. This is what you want for a configuration where you have a common 6MHz reference being distributed and the SYSREF divider is fed back in zero-delay mode. Because you have R=1 and N=1 at PLL1, this should guarantee a deterministic, repeatable phase relationship between the reference input and the SYSREF. You have the same divider values and digital delay values on all 132MHz clocks and on all 6MHz SYSREFs, they are using the same formats, etc. At least this much looks unobjectionably correct.

Am I correct in understanding that "not just a relative offset" means the measurement of the phase error is slightly different for each SYNC (potentially by a random amount), but nominally close to correct? The suggestions below assume this is what you mean, I'll revisit if you meant something else.

I'd also like to know what input tone you're trying to measure with the ADC, so I can quantify what "a few degrees" error is in absolute terms - for instance, if you're measuring a 10MHz tone, a one-degree variation is around 280ps, so even one degree of error could constitute setup issues; but if you're measuring a 3GHz tone, now a one-degree variation is less than 1ps, which is getting into difficult-to-debug device architecture issues. It would further be helpful to know what level of accuracy you are expecting.

For now, here's some sources of skew that can show up between devices:

• The datasheet makes note of the clock skew between different clock pairs, which would be a constant offset on a per-device basis. This may contribute to some static offset, but not changing offset like what I think you're describing. It's worth considering in the future, if possible, using clocks in the same clock group for better skew matching; better yet, if you can use both clocks in a pair as device clocks, and route the SYSREFs from other outputs. You have a lot of flexibility on SYSREF timing with the local analog delay, so it's better to aim for the closest match on the device clocks that you can achieve.
• If the devices are at different temperatures or have significantly different supply voltages (a few %), these could result in variations at the phase detector timing of PLL1, which would affect the input-to-output phase. The relative drift across temperature is on the order of 1ps/°C, though there's also some variation in that number (maybe ±0.5ps/°C) as a function of process variation. I'm not sure about supply voltage variation, but keep in mind that unlike PLL2, PLL1 phase detector runs directly off of the 3.3V PLL1 supply, so it is particularly susceptible to noise or voltage variation. Variation at the charge pump changes the timing relationship of the inputs at the phase detector by ± a few picoseconds.
• Note that the temperature differences can apply across long cabling setups as well. We've had customers try to route clocks across a few meters of cabling at drastically different temperatures, resulting in tens of picoseconds of timing error. This is especially problematic when multiple assemblies are involved, since there can be significant temperature gradients across a chassis or system.
• Sometimes programming sequence can affect results. Every time the LSB of the PLL2_N is programmed, a recalibration of the internal VCO is triggered, which substitutes the value of the PLL2_N_CAL divider temporarily (to eliminate some uncertainties with PLL2_N and feedback mux). As a result, if the PLL2_N_CAL and the PLL2_PRE_PD are not properly set before the LSB of the N-divider is programmed, the calibration can fail and arbitrary coefficients will be selected. This can result in significant mismatch between the VCO operating VTUNE voltages, which looks like different timings at the phase detector - I've seen tens of picoseconds of variation caused by programming sequence errors. I think in some ways the nested configuration should be resistant to this, since the latency through the PLL2 loop to OSCIN is sort of irrelevant anyway and the PLL1 VCXO phase shifts to compensate it, but this can cause other issues, like...
• We have seen some effect from different VCXO phases in nested zero-delay configurations, maybe a few picoseconds between runs. We're not yet sure exactly what's responsible, but the operating theory is that the VCXO phase results in deterministic spurs at certain intervals, which has an average effect of altering the overall input-to-output phase relationship by a few picoseconds in a somewhat-deterministic pattern. You could test for this by stepping your SYSREF dynamic digital delay one step forward at a time, though note that there is a datasheet note about how to configure dynamic delay for SYSREF and it's somewhat particular. You'd step one device's SYSREF divider forward one VCO step at a time, and check if the phase error between the ADCs shifts with it. Keep in mind that shifting the SYSREF divider phase doesn't actually change the input-to-output phase relationship, because that's guaranteed by the zero-delay configuration; but it does change the 132MHz phase offset, so you might want to also step those outputs along with the SYSREF to ensure everything stays nominally in-phase to the same VCO cycle. Likewise, this changes the input-to-VCXO and output-to-VCXO phase relationship, which moves the timing of the VCO in a way that might minimize spurs or timing impacts. I suspect a PLL2_R divider reset could also help if timed to force a deterministic phase at the VCXO, though I'm not sure how well it would work with the OSCIN multiplier enabled.