Zotino initialisation

Ana

Hi,

We are testing out our system with a few simple scripts and have run into an inconsistency when initialising the Zotino. Depending on where in the code we initialise the channel, we either get an RTIO underflow error or not.

I have included the code below. When we initialise the zotino before the DDS channels (exactly as in the code below), it executes with no errors. When we initialise the Zotino after the DDS channels (commented out with a note), we get an RTIO underflow error, and adding additional delays immediately before/after doesn't help.

Does this have anything to do with clashes in the FIFO buffer lanes? If that is the case, then shouldn't the error happen regardless of whether we initialise the Zotino before or after the DDS channels?

import sys

from artiq.experiment import *



class ConstantValues2(EnvExperiment):
    def build(self):
        self.setattr_device("core")
        self.setattr_device("urukul0_cpld")
        self.setattr_device("zotino0")
        self.dds0 = self.get_device("urukul0_ch0")
        self.dds1 = self.get_device("urukul0_ch1")
        self.dds2 = self.get_device("urukul0_ch2")
        self.dds3 = self.get_device("urukul0_ch3")
        self.dds4 = self.get_device("urukul1_ch0")
        self.dds5 = self.get_device("urukul1_ch1")

        self.dummy = self.get_device("ttl6")
        self.cameratrigger = self.get_device("ttl4")
        self.coolshutter = self.get_device("ttl8")
        self.probeshutter = self.get_device("ttl9")
        self.eomshutter = self.get_device("ttl10")
        self.motcoiltrigger = self.get_device("ttl7")

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

        self.zotino0.init()  # initialises zotino0 - works

        self.dds0.cpld.init()
        self.dds0.init()
        self.dds0.set_att(0.0)

        self.dds1.cpld.init()
        self.dds1.init()
        self.dds1.set_att(0.0)
        
        self.dds2.cpld.init()
        self.dds2.init()
        self.dds2.set_att(0.0)
        
        self.dds3.cpld.init()
        self.dds3.init()
        self.dds3.set_att(0.0)
        
        self.dds4.cpld.init()
        self.dds4.init()
        self.dds4.set_att(0.0)
        
        self.dds5.cpld.init()
        self.dds5.init()
        self.dds5.set_att(0.0)

        # self.zotino0.init()  # initialises zotino0 - doesn't work

        self.dds0.set(80 * MHz, amplitude=0.32)
        self.dds1.set(103 * MHz, amplitude=0.42)
        self.dds2.set(80 * MHz, amplitude=0.32)
        self.dds3.set(226.5 * MHz, amplitude=0.31)
        self.dds4.set(234 * MHz, amplitude=0.30)
        self.dds5.set(110 * MHz, amplitude=0.45)

        self.dds0.sw.on()
        self.dds1.sw.on()
        self.dds2.sw.on()
        self.dds3.sw.on()
        self.dds4.sw.on()
        self.dds5.sw.on()

        delay(200 * us)

rjo

It depends on where the RTIO underflow is hit.
Please paste the error as well.

rjo

Also note that you don't need to cpld.init() for each channel. Just once per Urukul.

Ana

Also note that you don't need to cpld.init() for each channel. Just once per Urukul.

Noted!

Here is the error message:

$ artiq_run repository/constant_values2.py
Core Device Traceback (most recent call last):
  File "repository/constant_values2.py", line 58, in __modinit__ (RA=+0x1298)
    self.dds0.set(80 * MHz, amplitude=0.32)  # 0.32
  File "<artiq>\coredevice/ad9910.py", line 715, in ... artiq.coredevice.ad9910.AD9910.set<artiq.coredevice.ad9910.AD9910>(...) (RA=+0x23f8)
    return self.pow_to_turns(self.set_mu(
  File "<artiq>\coredevice/ad9910.py", line 522, in ... artiq.coredevice.ad9910.AD9910.set_mu<artiq.coredevice.ad9910.AD9910>(...) (inlined)
    self.write64(_AD9910_REG_PROFILE0 + profile,
  File "<artiq>\coredevice/ad9910.py", line 312, in ... artiq.coredevice.ad9910.AD9910.write64<artiq.coredevice.ad9910.AD9910>(...) (inlined)
    self.bus.set_config_mu(urukul.SPI_CONFIG, 8,
  File "<artiq>\coredevice/spi2.py", line 169, in ... artiq.coredevice.spi2.SPIMaster.set_config_mu<artiq.coredevice.spi2.SPIMaster>(...) (inlined)
    rtio_output((self.channel << 8) | SPI_CONFIG_ADDR, flags |
  File "ksupport/rtio.rs", line 67, column 14, in (Rust function)
    <unknown>
                 ^
artiq.coredevice.exceptions.RTIOUnderflow(0): RTIO underflow at 2147548731944 mu, channel 32, slack -120752 mu
Traceback (most recent call last):
  File "C:\Users\Atomionics\.conda\envs\artiq\Scripts\artiq_run-script.py", line 9, in <module>
    sys.exit(main())
  File "C:\Users\Atomionics\.conda\envs\artiq\lib\site-packages\artiq\frontend\artiq_run.py", line 225, in main
    return run(with_file=True)
  File "C:\Users\Atomionics\.conda\envs\artiq\lib\site-packages\artiq\frontend\artiq_run.py", line 211, in run
    raise exn
  File "C:\Users\Atomionics\.conda\envs\artiq\lib\site-packages\artiq\frontend\artiq_run.py", line 204, in run
    exp_inst.run()
  File "C:\Users\Atomionics\.conda\envs\artiq\lib\site-packages\artiq\language\core.py", line 54, in run_on_core
    return getattr(self, arg).run(run_on_core, ((self,) + k_args), k_kwargs)
  File "C:\Users\Atomionics\.conda\envs\artiq\lib\site-packages\artiq\coredevice\core.py", line 137, in run
    self.comm.serve(embedding_map, symbolizer, demangler)
  File "C:\Users\Atomionics\.conda\envs\artiq\lib\site-packages\artiq\coredevice\comm_kernel.py", line 641, in serve
    self._serve_exception(embedding_map, symbolizer, demangler)
  File "C:\Users\Atomionics\.conda\envs\artiq\lib\site-packages\artiq\coredevice\comm_kernel.py", line 633, in _serve_exception
    raise python_exn
artiq.coredevice.exceptions.RTIOUnderflow: RTIO underflow at 2147548731944 mu, channel 32, slack -120752 mu

Channel 32 corresponds to this in the device database:

device_db["ttl_zotino0_ldac"] = {
    "type": "local",
    "module": "artiq.coredevice.ttl",
    "class": "TTLOut",
    "arguments": {"channel": 0x000032}
}

I'm quite new to Artiq and Sinara, so still trying to get the hang of things.

rjo

0x32 is not 32.

The problem is the marginal and busy configuration of all DDS and switches within a short time. Depending on the placement of your zotino0.init() the compiler and memory subsystem will do different things to the DDS configuration sequence and some results of that compilation are slightly slower than others. Just adding a bit of slack between or around the DDS configuration and switch settings should help.
You can also analyze this comprehensively with the coreanalyzer tool which would show you the slack.

Ana

rjo
I see. Thanks for your help!