PLL Timeout

[samhile]

I cannot get a PLL lock with a new v1.3 Urukul using clk_sel=2 (MMCX), nor with clk_sel=0 (internal XO)

This board is successfully locking using clk_sel=1 and a 125MHz signal applied to the front SMA.

When I have an MMCX cable applied, I can probe the clock signal from Kasli on the reverse side of the Urukul board, so I'm confident the clock is arriving on the board.

I've seen comments that others have working v1.3 Urukul boards, so should I assume I have a faulty board? Any suggestions?

``

[sbourdeauducq]

What ARTIQ version?

[jordens]

And what urukul cpld firmware version?

[tballance]

We have been having this issue with a v1.3 recently too. Probing the board, the MMCX_OSCn_SEL never goes high after configuration, even though the CPLD is fully functioning in other regards.

CPLD reports proto_rev version 8, though looking at the code it doesn't seem to distinguish between v1.2 and v1.3 versions. My guess is that the board was flashed with the 1.2 code.

Any other thoughts on this? Our next step is to flash in the 1.3 jed.

If possible, it would be useful to have another field in the CPLD config registers to reflect the minor version so that these problems are easier to identify in the future.

[sbourdeauducq]

@tballance @samhile There is a known bug that has been introduced, and fixed, recently in the ARTIQ software that causes this symptom. So, check your ARTIQ versions.

[tballance]

@sbourdeauducq Thanks. I can't check the commits we were using right now, but IIRC this was present on release-4 as well. Could you link to the ARTIQ commit that fixed the issue (I can't figure out which one it is)?

[sbourdeauducq]

https://github.com/m-labs/artiq/commit/91e375ce6acd6b626b1040abefd1af7c1cdb9d63

[tballance]

@sbourdeauducq Thanks, but I don't think that will solve our problem. This commit has to do with the AD9910, whereas our problem is a lot more basic: Our CPLD does not seem to drive MMCX_OSCn_SEL high when we instruct it to, so the clock never gets past the mux. I think there are two possible causes for our observation: a) our kernel code is out of date and is not setting the second bit of CLK_SEL b) out CPLD is flashed with an old version of the code

Unfortunately I can't check the artiq version we were using right now, but I guess a) is most likely our cause, and may be @samhile's cause too. Will update when tested.

[mfe5003]

@sbourdeauducq Hi, this is following up on @tballance's comment. We are on release 4 with different versions of the software and gateware. Looking at the diff I don't think this should be a problem. https://github.com/m-labs/artiq/compare/0ec01790fe8c75730bb534756804a16189b0d25f...5b2e7cb7f38b7fe4f6711ca3e3ab9c338f34466a

$ artiq_run dds_test.py
WARNING:artiq.coredevice.comm_kernel:Mismatch between gateware (4.0+25.g5b2e7cb7) and software (4.0+21.g0ec01790) versions

The clock select changes in artiq/coredevice/urukul.py appear in my local repo, so unless there were further changes made or I am missing something, it is looking like:

b) out CPLD is flashed with an old version of the code

is the cause. The fix will require some time since I don't have a programmer right now, but I can try switching to one of the other oscillators.

[samhile]

@sbourdeauducq I am working with ARTIQ release-4 (commit 1555fcf4 from 23 Jan, after the fix you're talking about). Gateware is compiled from 1555fcf4 too.

@jordens As for the CPLD version, it looks to me like 8

    u_status = self.urukul0_cpld.sta_read()
    print('SW',urukul_sta_rf_sw(u_status))
    print('SMP',urukul_sta_smp_err(u_status))
    print('PLL',urukul_sta_pll_lock(u_status))
    print('IFC',urukul_sta_ifc_mode(u_status))
    print('PROTO',urukul_sta_proto_rev(u_status))

this outputs:

    INFO:worker(2141,urukul_test.py):print:SW 0
    INFO:worker(2141,urukul_test.py):print:SMP 0
    INFO:worker(2141,urukul_test.py):print:PLL 0
    INFO:worker(2141,urukul_test.py):print:IFC 5
    INFO:worker(2141,urukul_test.py):print:PROTO 8

[samhile]

ah, hang on - 91e375ce isn't on the release-4 branch

[jordens]

@samhile If you didn't flash, configure and test that board yourself, you'll want to check with whoever you bought it from or just redo the flashing configuring and testing yourself.

[samhile]

@jordens are you saying that proto_rev 8 is not correct for the v1.3 board? Its a recent order from Technosystem. Can you point me to instructions on how to flash and configure the CPLD?

[jordens]

Technosystem makes boards. They don't contribute or participate directly. https://github.com/quartiq/urukul is the CPLD code.