Phase ambiguity in Urukul

FabianS

Hi everyone,
I am trying to get an Urukul up and running. Works fine so far, but I have a problem with the determinism of the device. Below is the full example I put together. It generates a pulse with the Urukul and a DIO at the same time. The phase mode is set to absolute, so I would expect the phase to be deterministic relative to the DIO signal.
When I use an oscilloscope and trigger on the DIO's TTL output I can see two different phase offsets. The distance between the two signal types is always approximately 1.5ns, independent of the frequency of phase value I generate with the Urukul. Can someone explain this behaviour and maybe suggest a solution?

from artiq.coredevice.ad9910 import PHASE_MODE_ABSOLUTE, PHASE_MODE_CONTINUOUS, PHASE_MODE_TRACKING

class Urukul_Frequency_Pulse(EnvExperiment):
    """Urukul Single Frequency Pulse"""
    def build(self):
        self.setattr_device("core")
        self.setattr_device("urukul0_ch1")
        self.setattr_device("ttl0")
        

    @kernel
    def run(self):
        self.core.reset()
        self.urukul0_ch1.cpld.init()
        self.urukul0_ch1.init()
        delay(100*ms)
        self.urukul0_ch1.set_att(1.0)
 
        while True:
            self.urukul0_ch1.set(frequency = 100*MHz, amplitude = 0.8, phase = 0.0, phase_mode = PHASE_MODE_ABSOLUTE)
            self.urukul0_ch1.sw.on()
            self.ttl0.on()
            delay(1*ms)
            self.urukul0_ch1.sw.off()
            self.ttl0.off()
            delay(1*ms)`

FabianS

OK, I found out a small thing: It works - sometimes. When I add an extra delay after the first delay in the endless loop with delay_mu(), I can make it work if I choose the correct values. Interestingly the state of "working" and "not working" switches every 8 mu. So I guess there is something wrong in the FPGA/CPLD code?

rjo

Did you set up your Urkul for synchronization in your variant definition, and did you perform the initial delay seed calibration?

E.g. https://git.m-labs.hk/M-Labs/sinara-systems/src/branch/master/luh2.json#L23
and e.g. use artiq_sinara_tester to set the delay seeds.

FabianS

Thanks for the hint. Long story short: I don't understand the synchronization architecture of the Urukul. Any hint would be welcome, otherwise I will, again, waste days trying to figure it out on my own by looking at schematics, datasheets, and source code (there seems to be no documentation describing the architecture, just a bunch of variables without explanation how they are linked together).

rjo

To understand how the DDS chip synchronization works there is no substitute to reading the chip datasheet. It would be redundant to replicate that information. I'm not aware of an alternative.

The core of the problem is twofold: to synchronize SYNC_CLK, accurate and deterministic generation of SYNC_IN pulses to meet S/H to (DDS) SYS_CLK This requires tuning starting from a seed value that stored either in EEPROM or given in the device db.
Additionally the IO_UPDATE pulses need to be placed deterministically to meed (DDS) SYNC_CLK S/H.

FabianS

OK, I read the datasheet, but that does not explain how the sinara-hw/sw interacts with the DDS. I don't even know what question to ask. One starter may be: It seems like I will need a TTLClockGen. The manual says, that I cannot use a regular TTL channel for that. What are regular TTL channels and which ones are the ones I need? Is this an extra hardware?

sb10q

FabianS The manual says, that I cannot use a regular TTL channel for that.

Where?

ln4

FabianS One starter may be: It seems like I will need a TTLClockGen. The manual says, that I cannot use a regular TTL channel for that. What are regular TTL channels and which ones are the ones I need? Is this an extra hardware?

Sorry to ask after almost 3 years,do you finally solve the problem or find something else useful? I seem to have similar problem about synchronization of Urukul

rjo

You don't say what you did to get to where you are now. Which system is this?
Usually you only need to do what I referenced (https://forum.m-labs.hk/d/228-phase-ambiguity-in-urukul/3) and you are done. The rest happens behind the scenes.

FabianS

rjo You don't say what you did to get to where you are now. Which system is this?
Usually you only need to do what I referenced (https://forum.m-labs.hk/d/228-phase-ambiguity-in-urukul/3) and you are done. The rest happens behind the scenes.

Custom system. I did not see your edit yet. I will give that a try, I have not seen this option anywhere in the manual...

sb10q Where?

In
https://m-labs.hk/artiq/manual/core_drivers_reference.html#artiq.coredevice.ttl.TTLClockGen
it reads:

This should be used with TTL channels that have a clock generator built into the gateware (not compatible with regular TTL channels).

jonasmanthey

Can I reproduce this without having a TTL card? I have a Kasli, Urukul, Zotino and Fastino card.

rjo

Sure. This also shows up as deterministic carrier-envelope phase between the Urukul RF switch TTL (envelope) and the RF phase (carrier).

sb10q

Ok, but TTLClockGen has nothing to do with Urukul synchronization.

rjo

Ok, but TTLClockGen has nothing to do with Urukul synchronization.

TTLClockGen is the component that implements Urukul synchronization.

This should be used with TTL channels that have a clock generator built into the gateware (not compatible with regular TTL channels).

A misunderstanding. "This" meaning the coredevice driver that's documented here, "channel" referring to the gateware PHY. They both don't refer to the hardware.