mirny: Unstable initialization with MUXOUT not low/too high errors

[thomasfire]

Quite often while testing the Mirny, MUXOUT too high/not low errors occur. From the observations:

1. Often, but still able to use (50% - 70% failure rate) - at CLK freqs >12MHz (including 125MHz mmcx source)
2. Almost all the time (>90% failure rate) - at CLK from 10 to 12 MHz.

System: ARTIQ-7

Testing steps:

{
  "target": "kasli",
  "min_artiq_version": "7.0",
  "variant": "mirny_test",
  "hw_rev": "v2.0",
  "base": "standalone",
  "core_addr": "192.168.1.42",
  "peripherals": [
  {
      "type": "urukul",
      "dds": "ad9910",
      "ports": [0],
      "clk_sel": 2
    },
  	{
            "type": "mirny",
            "almazny": false,
            "ports": [1],
            "refclk": 10e6,
            "clk_sel": "sma"
        }
  ]
}

DDS script:

from artiq.experiment import *

class DDSPhase(EnvExperiment):
    def build(self):
        self.setattr_device("core")
        self.rf0 = self.get_device("urukul0_ch0")

    @kernel
    def run(self):
        self.core.reset()
        self.rf0.cpld.init()
        
        attt = 16.0

        self.rf0.init()
        self.rf0.set_att(attt)

        freq = 10 * MHz

        self.rf0.set(freq, phase=0.)
        self.rf0.cfg_sw(True)

After running DDS script, I ran artiq_sinara_tester -o mirnies a few times.

[sbourdeauducq]

Are the PLL parameters within datasheet specs?

[sbourdeauducq]

@thomasfire What does "MUXOUT too high" mean? It's a digital signal.
What's the exact error message?

[Spaqin]

The check is done in ADF5356.init(), before any frequencies are set.

Toggling the MUXOUT around doesn't make particular sense to me - I see it's used to check if there is actually a working Mirny on the other side, but does not indicate PLL lock, just that the ADF5356 is able perform the MUX switch.

At a glance, maybe this could be solved by starting init() function with a sync(), to ensure that the MUX logic is set to 3.3v before we change the MUX itself; then only updating the 4th register, instead of every single one, also cutting down initialization time.

[sbourdeauducq]

Toggling the MUXOUT around doesn't make particular sense to

It does make sense, especially with this test failing right now. Otherwise we can't tell if the PLL is not locking or if the MUXOUT readout is not working for some reason.