Long TTL pulse behavior, TTL stays high

jpagett

I came across this while trying to switch a DDS on and off with a long duty cycle (1 second). However, I have identified that the problem is ultimately with TTLs in general.

When a TTL is turned on, it seems that there is some maximum time after which the TTL no longer responds to future commands.

The minimal example which reproduces this behavior is as follows.

from artiq.experiment import *

class TestTTL(EnvExperiment):

    def build(self):
        self.core = self.get_device("core")
        self.ttl = self.get_device("ttl5")

    @kernel
    def run(self):

        self.core.reset()
        print(self.N)
        self.core.break_realtime()

        for _ in range(5):
            self.ttl.on()
            delay(1*s)
            self.ttl.off()
            delay(1*s)

I do not know if this is a general behavior common to other crates, since I only have the one to test on.

I am using artiq release 7, gateware version 7.8123.3038639.

Please advise if anyone knows why this behavior might be happening, and if there is anything we can do to avoid it.

esavkin

Hi jpagett , I have just tested your code at ARTIQ 7 and 8 versions, and even added a 10 seconds to the ttl.on()'s delay:

from artiq.experiment import *
class TestTTL(EnvExperiment):
    def build(self):
        self.core = self.get_device("core")
        self.ttl = self.get_device("ttl5")
    @kernel
    def run(self):
        self.core.reset()
        self.core.break_realtime()
        for _ in range(10):
            self.ttl.on()
            delay(10 * s)
            self.ttl.off()
            delay(1 * s)
            print("hello")

After running this code, I see 10 hello in console instantly, and ten ten-seconds pulses on the oscilloscope. Also, I was able to interrupt it by running another length pulses.

When a TTL is turned on, it seems that there is some maximum time after which the TTL no longer responds to future commands.

So I am bit confused by what did you mean by this.

jpagett

esavkin

My bad re the self.N, I forgot to remove it from an earlier version before posting.

esavkin When a TTL is turned on, it seems that there is some maximum time after which the TTL no longer responds to future commands.

So I am bit confused by what did you mean by this.

This is a heuristic description of what I'm seeing. When I run the above, my TTL channel goes high and stays high even if when I call ttl.off(). It seems that this only happens after waiting a long period after turning that channel on.

This occurs on multiple channels on our crate, and we saw similar "sticking" behavior one that I was able to test on from another group, though the occurrence was less consistent.

Thank you for testing this for us. If it turns out to be just a problem with our crate, this is in some sense a better conclusion.

jpagett

Perhaps relevant -- our crate has a Kasli 2.0.

esavkin

jpagett Well, I've also tested it with a Kasli 2.0 and DIO-SMA v1.3m, though it was a configuration with one TTL card only, I doubt that would make a significant difference.
We'll try to test against different configurations (and different cards) and see if the problem occurs.

jpagett

The core analyzer logs for the above experiment (this time run on a different TTL channel on a different DIO-SMA v1.3m card):

Log channel: 47
DDS one-hot: True
OutputMessage(channel=15, timestamp=64833016901496, rtio_counter=64833016779352, address=0, data=1)
OutputMessage(channel=15, timestamp=64834016901496, rtio_counter=64833016796240, address=0, data=0)
OutputMessage(channel=15, timestamp=64835016901496, rtio_counter=64833016799816, address=0, data=1)
OutputMessage(channel=15, timestamp=64836016901496, rtio_counter=64833016804248, address=0, data=0)
OutputMessage(channel=15, timestamp=64837016901496, rtio_counter=64833016807176, address=0, data=1)
OutputMessage(channel=15, timestamp=64838016901496, rtio_counter=64833016810440, address=0, data=0)
OutputMessage(channel=15, timestamp=64839016901496, rtio_counter=64833016813528, address=0, data=1)
OutputMessage(channel=15, timestamp=64840016901496, rtio_counter=64833016816640, address=0, data=0)
OutputMessage(channel=15, timestamp=64841016901496, rtio_counter=64833016819648, address=0, data=1)
OutputMessage(channel=15, timestamp=64842016901496, rtio_counter=64833016823176, address=0, data=0)
StoppedMessage(rtio_counter=64836041979152)

It seems that everything is in order re the RTIO log.

sb10q

Sounds unlikely that it would be a one-off problem with a crate. This behavior is controlled by the internals of the FPGA. A shotgun approach of trying different random configurations is unlikely to turn up anything.

@jpagett Do you have a better or more detailed repro? Are you aware of the "seamless handover" feature of ARTIQ, which may be a source of confusion here?

jpagett

I meant to update here after discovering the issue -- only getting around to it now.

The problem was entirely user error. My idle kernel included a core.reset(), which was clearing the buffer before the ttl.off() timestamp came up. For now I've just removed my idle kernel, and the issue is resolved.