Husky sampling clock phase is not consistent.

[jpcrypt]

The relative phase between the target clock and the ADC sampling clock phase is not always consistent when scope.clock.adc_mul is changed, or when the frequency of scope.clock.clkgen_src is changed.

Running scope.clock.pll.recal() and re-setting scope.clock.clkgen_src appears to resolve the problem but more testing is needed.

[jpcrypt]

The issue is hard to explain without getting into details about PLL operation. However, when scope.clock.clkgen_src = 'system', the issue can only occur if you had a non-zero scope.clock.adc_phase. For most users, this means that this is a non-issue (and you can stop reading right here). None of our labs or demos use scope.clock.adc_phase, and only our CW305 notebooks use scope.clock.clkgen_src = 'extclk'.

For the scope.clock.clkgen_src = 'extclk' case, see #499 and #501.

For the scope.clock.clkgen_src = 'system' and scope.clock.adc_phase != 0 case, read on:
To understand the root issue here, you need to know that when scope.clock.clkgen_src = 'system', Husky uses a discrete PLL chip to generate both the target frequency and the ADC sampling frequency.

When the user sets scope.clock.adc_mul we must update the ADC clock accordingly; we were trying to do this without touching the target clock if at all possible (e.g. not have it drop out and require a target reset).

This was well-intentioned, but it meant that for a given set of [target frequency, ADC frequency], you could end up with a different set of PLL settings depending on the sequence of scope.clock settings that you set on the way to setting your final [target frequency, ADC frequency].

Where this becomes a problem is when scope.clock.adc_phase is non-zero, because the way that adc_phase is (was) defined meant that the actual phase depended on those PLL parameters. So, for a fixed scope.clock.adc_phase value, different PLL parameters = different actual ADC phase. That is the issue here.

The fix involves setting the PLL parameters deterministically, so that any given set of [target frequency, ADC frequency] will always results in the same PLL settings. This means that changing scope.clock.adc_mul will now be more likely to drop the target clock (you get a warning if this happens); you may need to reset the target as a result.

At the same time, we're also changing the scope.clock.adc_phase API so that it specifies the ADC phase as a percentage of the target clock phase, rather than a dimensionless number which must be interpreted with PLL parameters.