Urukul/AD9910: phase accumulator reset upon profile change?

airwoodix

Hello,

is it a feature of the AD9910 to always clear the DDS phase accumulator upon profile change, even if CFR1[13] is cleared?

Considering the example below:

when run as given, phase tracking between the channels work (i.e. the phase difference between dds0 and dds1 is always 0);
with line 23 uncommented (i.e. forcing a profile change after the call to dds1.set_mu()) the phase difference between dds0 and dds1 is stable across repetitions of the experiment but is not 0 in general (and depends on the frequency). While the datasheet documents that changing profiles loads the register values, this profile change should not reset the phase accumulator since set_mu() clears CFR1[13] before returning;
adding a delay before switching profiles (line 27) allows tuning the phase between the two outputs, thus hinting towards a phase accumulator reset upon profile change (also the frequency dependence goes in that direction)
the relative phase is also 0 for frequencies that are multiples of 50 MHz: this is probably pure coincidence
asserting IO_UPDATE explicitly after the call to set_mu() (to load the cleared CFR1 register) doesn't help.

Is this behavior documented in the AD9910 datasheet? or is this a known bug?
Thanks!

from artiq.experiment import *
from artiq.coredevice import ad9910


class ProfileSwitch(EnvExperiment):
    def build(self):
        self.setattr_device("core")

        # Urukul v1.3 => use different boards because
        # PROFILE[2:0] is shared between channels
        self.dds0 = self.get_device("urukul0_ch0")
        self.dds1 = self.get_device("urukul1_ch0")

        self.trg = self.get_device("ttl4")

        self.ftw = self.dds0.frequency_to_ftw(125.0 * MHz)

    @kernel
    def run(self):
        self.core.reset()
        self.init_dds()

        # self.dds1.cpld.set_profile(2)
        self.dds1.set_mu(self.ftw, profile=0, phase_mode=ad9910.PHASE_MODE_TRACKING)

        # self.dds1.cpld.io_update.pulse_mu(8)
        # delay_mu(128 * 2)
        self.dds1.cpld.set_profile(0)

        self.dds0.set_mu(self.ftw, phase_mode=ad9910.PHASE_MODE_TRACKING)

        with parallel:
            self.trg.pulse_mu(400)
            self.dds1.sw.on()
            self.dds0.sw.on()

    @kernel
    def init_dds(self):
        for dds in [self.dds0, self.dds1]:
            dds.cpld.init()
            dds.init()
            dds.sw.off()
            dds.set_att_mu(180)

rjo

Could you elaborate what your mental model of the chip is at the different code steps and what should happen vs does in fact happen? I have a hard time diff-ing mine and yours 😉
Also the line numbers aren't available immediately.
In general I suspect that changing profiles around set_mu may not result in what is expected for PHASE_TRACKING and even ABSOLUTE. Since set_mu() clears the shared accu but sets the profile-specific offset, the ensuing phase evolution depends on the the trajectory through the profiles and is not phase-tracking profile-specific virtual oscillators. I think the following statement is correct: set_mu PHASE_TRACKING and ABSOLUTE modes will only have the respective behavior iff the affected profile is active at that time. set_profile will generally not do PHASE_TRACKING or ABSOLUTE changes as defined (unless you fiddle with CFR1[13]). Is that what you are after?
One thing to keep in mind: Are we certain that the PROFILE pins meet S/H w.r.t. SYNC_CLK. Unlike IO_UPDATE they go through the CPLD and are not delay-tuned.

airwoodix

Thanks for the feedback!

Could you elaborate what your mental model of the chip is at the different code steps and what should happen vs does in fact happen? I have a hard time diff-ing mine and yours 😉
Also the line numbers aren't available immediately.

Sorry about that. I think that we understood the issue. Here's the incorrect code again, slightly refactored, for reference:

from artiq.experiment import *
from artiq.coredevice import ad9910


class ProfileSwitch(EnvExperiment):
    def build(self):
        self.setattr_device("core")

        # Urukul v1.3 => use different boards because
        # PROFILE[2:0] is shared between channels
        self.dds0 = self.get_device("urukul0_ch0")
        self.dds1 = self.get_device("urukul2_ch0")

        self.trg = self.get_device("ttl4")

        self.ftw = self.dds0.frequency_to_ftw(123.2 * MHz)

    @kernel
    def run(self):
        self.core.reset()
        self.init_dds()

        self.do()

        with parallel:
            self.trg.pulse_mu(400)
            self.dds1.sw.on()
            self.dds0.sw.on()

    @kernel
    def init_dds(self):
        for dds in [self.dds0, self.dds1]:
            dds.cpld.init()
            dds.init()
            dds.sw.off()
            dds.set_att_mu(180)

    @kernel
    def do(self):
        self.dds1.cpld.set_profile(1)
        self.dds1.set_mu(self.ftw, phase_mode=ad9910.PHASE_MODE_TRACKING)
        self.dds1.cpld.set_profile(0)

        self.dds0.set_mu(self.ftw, phase_mode=ad9910.PHASE_MODE_TRACKING)

Changing to the following works:

@kernel
def do(self):
    self.dds1.set_mu(self.ftw, profile=1)
    self.dds1.cpld.set_profile(1)
    self.dds1.set_mu(self.ftw, phase_mode=ad9910.PHASE_MODE_TRACKING)
    self.dds1.cpld.set_profile(0)

    self.dds0.set_mu(self.ftw, phase_mode=ad9910.PHASE_MODE_TRACKING)

A plausible explanation goes as: the phase accumulator only runs if there's a non-0 FTW loaded in the DDS core (otherwise, the SYSCLK-clocked flip-flop just shifts 0s all the time), which is not the case on profile 1 in the incorrect code above. The situation is therefore equivalent to having a phase accumulator reset upon the change to profile 0. The fix is effective only if one sets the same FTW for both profile 0 and profile 1, which relates to your comment about tracking profile-specific virtual oscillators. Does this make sense?

One thing to keep in mind: Are we certain that the PROFILE pins meet S/H w.r.t. SYNC_CLK. Unlike IO_UPDATE they go through the CPLD and are not delay-tuned.

Good point. Originally, the idea was that it shouldn't matter since there're no new values being loaded from the I/O registers, but this is indeed wrong since this also triggers loading new values into the DDS core. Is that correct?

rjo

If PROFILE doesn't meet S/H then a transition from 0 to 3 can be sampled as 0, 0, 3 or as 0, 1, 3, or as 0, 2, 3, or as 0, 3, 3 in three successive SYNC_CLK cycles. That results in in different phase accumulator values.

airwoodix

Thanks. This makes sense but should be unproblematic if the FTW for all the profiles visited is the same, shouldn't it?

rjo

Yes. But e.g. if the phase offset word is different the phase will glitch in different ways