Using SU Servo mode and freestanding Urukul in the same experiment

aquinn

We are trying to write an experiment that generates outputs from an SUServo-mode Urukul (Urukul 0) and a non-SUServo-mode Urukul (Urukul 2). However, when we try to initialize both in the same experiment, we get the error below during compilation:

root:While compiling <repository>\depreciated_experiments\urukul_test_orig.py <synthesized>:1:1-1:62: error: host object has an attribute 'io_update' of type <instance artiq.coredevice.urukul._RegIOUpdate { __objectid__: numpy.int32 }>, which is different from previously inferred type <instance artiq.coredevice.ttl.TTLOut { __objectid__: numpy.int32 }> for the same attribute '<artiq.coredevice.urukul.CPLD object at 0x00000170AF7DB648>' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <repository>\depreciated_experiments\urukul_test_orig.py:50:1: note: expanded from here def run(self): ^

The minimal code required to reproduce this error is shown below

class UrukulTestMinimal(EnvExperiment):
    def build(self):
        self.setattr_device("core")
        self.setattr_device("urukul0_cpld")
        self.setattr_device("suservo0")
        self.setattr_device("urukul2_cpld")
    
    @kernel
    def run(self):
        self.core.reset()
        self.urukul2_cpld.init()
        self.suservo0.init()

It looks like this is a known issue with using two Urukuls in different configurations (issue #1207 on the ARTIQ GitHub) and one that doesn't have a general solution yet. Has anyone else run into a similar issue in their own experiments, and if so, what kinds of workarounds did you use?

Edit: We got in touch with a group that's worked around this problem, and they let us know that one solution is to run SUServo from a separate experiment class (called SUServoControl in the code below) which inherits from a main class that the standalone Urukul is controlled from (UrukulControl). An attempt at making code like this is shown below, but unfortunately, running SUServoControl produces the same error as above. It's not immediately clear to me what the issue is.

class UrukulControl(EnvExperiment):
    def build(self):
        self.setattr_device("core")
    
        self.setattr_device("urukul2_cpld")
        self.setattr_device("urukul2_ch0")
    
        self.setattr_device("urukul0_cpld")
        self.setattr_device("suservo0")
        self.setattr_device("suservo0_ch0")

    @kernel
    def urukul_init(self):
        self.urukul2_cpld.init()
        self.urukul2_ch0.init()
    
    @kernel
    def run(self):
        # prepare core
        self.core.reset()
    
        # initialize Urukul CPLD and DDS
        self.urukul_init()

        # initialize suservo
        self.suservo_init() 
    
class SUServoControl(UrukulDummy):
    @kernel
    def suservo_init(self):
        self.suservo0.init()
        self.suservo0.set_config(enable=1)

aquinn

We got in touch with a group that's worked around this problem, and they let us know that one solution is to run SUServo from a separate experiment class (called SUServoControl in the code below) which inherits from a main class that the standalone Urukul is controlled from (UrukulControl). An attempt at making code like this is shown below, but unfortunately, running SUServoControl produces the same error as above. It's not immediately clear to me what the issue is.

class UrukulControl(EnvExperiment):
    def build(self):
        self.setattr_device("core")
    
        self.setattr_device("urukul2_cpld")
        self.setattr_device("urukul2_ch0")

        self.setattr_device("urukul0_cpld")
        self.setattr_device("suservo0")
        self.setattr_device("suservo0_ch0")

    @kernel
    def urukul_init(self):
        self.urukul2_cpld.init()
        self.urukul2_ch0.init()

    @kernel
    def run(self):
        # prepare core
        self.core.reset()

        # initialize Urukul CPLD and DDS
        self.urukul_init()

        # initialize suservo
        self.suservo_init() 

class SUServoControl(UrukulDummy):
    @kernel
    def suservo_init(self):
        self.suservo0.init()
        self.suservo0.set_config(enable=1)

aquinn

Workaround!

From further communication with the same group: To prevent the initialization error described above, the SUServo CPLD and DDS devices need to initialize from different classes than the freestanding Urukul CPLD and DDS initialize from. Here are instructions on how to set this up.

To make the SUServo devices and Urukul devices initialize from different classes, you can set up a dummy package in your ARTIQ environment. I called this package "artiq_workaround." I put a single file in this package, artiq_workaround.py, which defines classes that inherit from the ARTIQ CPLD and DDS classes but are otherwise empty. The full contents of this file are

from artiq.coredevice import urukul, ad9910

class CPLD(urukul.CPLD):
    pass

class AD9910(ad9910.AD9910):
    pass

I then changed the "module" arguments in our device_db.py file for the SUSurvo Urukul devices so that, rather than initializing from the ARTIQ code, they initialize from the classes in this new package, e.g.

device_db["urukul0_cpld"] = {
    "type": "local",
    "module": "artiq_workaround.artiq_workaround",
    "class": "CPLD",
    "arguments": {
        "spi_device": "spi_urukul0",
        "refclk": 125000000.0,
        "clk_sel": 2
    }
}

Once this change was made to the device_db.py entries for all SUServo CPLDs and DDS, we could run experiments that used SUServo-mode and freestanding Urukul together without issue.

sb10q

FYI, the new compiler NAC3 (hopefully released early next year for Linux) should not require this kind of workaround.

dreens

Nice seeing this in-use code, thanks.

I am considering using my sampler in suservo mode. Am I understanding correctly from what I've read here and on github that the SU Servo must constitute a link between two urukuls and one sampler? Or is it possible to only link half the channels of a sampler with one urukul?

Relatedly, does suservo give me the capability to use RF amplitude on a single AOM to adjust output power to meet a setpoint, while still giving me the capability to arbitrarily turn the AOM on/off or change its frequency? What I have in mind would be to take a DDS controlling say a doppler cooling AOM, and use suservo to not only turn doppler on/off or change between cool or detect frequencies, but also adjust amplitude to desired values concurrently.

Thanks,
Dave