Hello, I am looking for some guidance in trying to get a Mirny v1.0 (Board v1.0rc5 with ADF5356) working using the newly updated code from Airwoodix that was recently incorporated into artiq beta.

Firmware has been compiled using the latest artiq version following manual, with updated json defined as shown in https://github.com/m-labs/artiq/pull/1563 (and #1561).

My board is v1.0 so I have set clk_sel = 2 for (MMCX) and refclk=125e6 as it is being clocked from the Kasli (following schematic and documentation here https://github.com/m-labs/artiq/issues/1559).

After flashing the Kasli with the new gateware, I then flashed the mirny with the CPLD code from https://github.com/quartiq/mirny

To test the code, I have used the TestMirny.py example from https://github.com/m-labs/artiq/pull/1530. After power cycling the Kasli this runs with no errors but no output. Resubmitting the experiment a few times and it then starts failing at self.ch.init() with ValueError: MUXOUT not high. The RF Switch on ch0 is working (light goes green) but the red PLL Lock light is always lit (suggesting it is not locking).

Has anyone had success getting this working on a v1.0 with ADF5356? Any suggestions for debugging appreciated. Do I need to explicitly set the state of the CLK_DIV pin on the CPLD for example on the v1.0 boards?

This looks like an instance of #1560 which is hopefully fixed by #1596. Without applying the patch, you should be able to work around the issue by calling channel.sync() instead of the init (this is effectively a blind init with proper register init).

Your procedure otherwise looks fine to me. The clk_div pins defaults to high-Z (divide-by-1) which should work fine. If you want to avoid synthesizing the CPLD bitstream, you can download it from the M-Labs build server: mirny.jed

Thanks for this - I still get the MUXOUT error even using the patched code without BLIND=True using both CLK_SEL=0 and 2, but I will check the output tomorrow when I get access to a frequency counter and see if that is updating. I will also try flashing the .jed from the M-Labs build incase that makes it work.

Using the example code from Sebastian (example #3 here https://forum.m-labs.hk/d/109-mirny-coding-examples) I did at least get 144ish MHz output so the boards must be alive at any rate!

Just to be sure: is the "patched code" the one from the pull request? If not, could you try with it?

I'm sorry, I forgot that the workaround I gave doesn't do the job: the registers are not fully initialized in the current code (charge pump bleed current needs to be set as well, see PR) so sync() alone is not sufficient.

  • jdp replied to this.

    airwoodix yes I am using your updated code, and have installed it into a new local env for testing. I have Mirny CH0 on a frequency counter (currently stuck working remotely) and this did not clear the MUXOUT error, I have been running with Blind=True to bypass this.

    I think there might be something else wrong here on my board: I can always read and write from the CPLD, and the registers have the right numbers in but the resulting behaviour is not always reproducible (the red LEDs are a bit random) but when I see an output of e.g. 148 MHz (achieved using Sebastian's example #3 mentioned above) I cannot control the RF switch using self.ch.sw.on(), but if I write to reg2 of the cpld then I can turn things on and off that way, but not always. It is almost as if the outputs are latching, which is similar to the issue described for the CLK_DIV pin.

    I need to check using the m-labs mirny.jed incase my build has an error so I will get back to you early next week once these things have been checked.

      and this did not clear the MUXOUT error

      Did you cycle power before trying the patched code? I'd systematically do this to avoid having the ADF5356 in an uncontrolled state and getting confusing results. I'm looking forward to the outcome with the new mirny.jed build.

      What do you expect from the "new mirny.jed"? Nothin has changed since the latest released version (0.2.4), right?

        rjo making sure there are no build errors. Very unlikely though, I agree.

          rjo I also agree it is unlikely to change, but want to make sure I haven't wasted anyones time with a bad build. Given others have got the ADF3536 working with this code, hard to see what the issue might be unless the clock divider (for example) on v1.0 boards is not behaving as expected. I will get the board scoped out tomorrow and try and see if I can check this, but if you have any experience or ideas I am open to suggestions

            @airwoodix Success: I have a solution. Using CLK_SEL=1 (external SMA) and running a 125 MHz from the neighbouring DDS board the mirny behaves as excepted - I can control the frequency on each channel and the RF switches work reliably.

            Using CLK_SEL=0 or 2 (Internal OSC or MCX) fails, even when trying the mlabs mirny.jed. Looking at the schematics for v1.0rc5, it looks like there is an issue in the clock chain as the MCX and OSC are combined on a Si53340, then fed into input CLK0 of Si53312. As even with the SMA input connected to the board the initialisation only works with CLK_SEL=1, the Si53312 looks to be operating and IN_SEL0 driving the right output. I am guessing IC17 is the culprit, as both of the other clock modes work.

            I tried playing around with the CPLD initialisation to toggle through different chip-select values as the initial testing of v1.0 showed the clk_select was not driving low (https://github.com/sinara-hw/mirny/issues/7#issuecomment-479927215) but this didn't solve the problem. For now, I am happy to run using the external SMA clock so thanks very much for the help.

              jdp Great! Thanks for the feedback. I unfortunately can't reproduce your issue with the clock selection, it works with all sources on the v1.0 board I have here.
              Do you confirm that #1596 fixes #1560 for you?

              • jdp replied to this.

                  airwoodix Yes I confirm that using the patched code #1596 I can initialise the channels first time after a power up without requiring additional calls to the sync() command