Are the operations disrupted during a re-write of the configuration registers?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Are the operations disrupted during a re-write of the configuration registers?
I take it you mean re-writing identical registers twice? Let me know if you meant something else.
Sometimes, yes, re-writing the same set of registers can be disruptive.
If you re-write R0 with FCAL_EN set to 1, the frequency calibration routine will be retriggered. This can obviously be disruptive to the output frequency since it discards the current calibration data and starts over from scratch. Unless you need to recalibrate the VCO, FCAL_EN should be set to 0 when writing R0.
If you have MASH_SEED_EN=1, re-writing the MASH_SEED register adds the value written to the accumulator, which can result in an updated phase offset. If MASH_SEED_EN=0, this is inapplicable; if MASH_SEED_EN=1 and MASH_SEED is instead written as 0, nothing will be added to the phase offset accumulator, so the phase offset won't change.
I'd have to check in the lab to be certain, but I think re-writing the same divider values or re-writing VCO_PHASE_SYNC doesn't reset the dividers, so phase and frequency are not disrupted. Re-writing different values (including re-writing the old values after SEUs change the bits) will reset the divider phase, so the device may need to be re-synchronized. There are some cases where a phase reset will never be observed regardless (category 1 SYNC); the concern is potentially with category 2 SYNC or category 3 SYNC, where the output is not an integer multiple of the input. If precise input-to-output phase sync or phase offset control isn't required, and if the SYSREF divider isn't used, then there's no concern in direct VCO mode outputs (since the VCO frequency will not change quickly enough to respond to the momentary divider resets), but channel divider outputs might be disrupted - again, I'd have to check.