Why not (re)flash Urukul? It's not very difficult, and if you are buying bare boards from Technosystem you should be expected to perform this sort of operation. If you buy a system from M-Labs, all Urukul are flashed and tested at the system level (among other things).
On the other hand, supporting and maintaining support for different Urukul gateware versions in the driver significantly increases complexity and potentially comes with a performance hit.
Note that this error may also occur if the Urukul wasn't flashed at all or if the communication with Kasli breaks down for any reason. If you want to avoid dealing with this sort of problem yourself, you can order a fully assembled crate.

Some things are unclear. Foremost, does the latest Urukul CPLD support all version of the Urukul hardware? Also, the relationship between the following is unclear.

• Urukul hardware version
• coredevice_generic.schema.json "hw_rev"
• https://github.com/quartiq/urukul/tags tag version number
• artiq/coredevice/Urukul.py proto_rev

Why not (re)flash Urukul? It's not very difficult

There are several competing factors here.

• We all would like to see updates to Urukul CPLD that fix bug and add features.
• Updating Urukul firmware is invasive for an experiment as it requires disconnecting cables, removal from crate, flashing, reverse. This is a bit of a chore for labs with many Urukul boards and is disruptive.
• It's reasonable to deprecate support quite outdated versions of CPLD.
• There ought to be a mechanism for supporting more than one version of CPLD else many uses have to flash many boards with each CPLD version bump.

In my lab we have Urukul hardware versions 1.1, 1.2, 1.3 and 1.4. It's no problem at this stage to update the CPLD to the latest. But due to questions above we've held back so far.

Foremost, does the latest Urukul CPLD support all version of the Urukul hardware?

Urukul 1.4 moved to a larger CPLD, so the CPLD gateware itself is not compatible across those Urukul versions. But the CPLD gateware versions that support Urukul <1.4 and >=1.4 use a compatible protocol on the EEM side.

And to be more precise about CPLD versions:

• CPLD version 1.3.1 (Hydra) supports hardware v1.3. It might also support v1.2 and v1.1 but this needs review, I have not touched those old versions for a while.
• CPLD version 1.4.0 (Hydra) and master (Hydra) support hardware v1.4 and v1.5.

Those CPLD versions are compatible with the current ARTIQ drivers (5/6/7).

@jordens what is the compatibility of "CPLD version 1.3.1" with hardware v1.1 and v1.2?

Is the plan that patches and updates for hardware v1.1 (v1.2,v1.3) will be maintained on the CPLD 1.3.x release series?

@sbourdeauducq Please review my edit to the wiki.

But the CPLD gateware versions that support Urukul <1.4 and >=1.4 use a compatible protocol on the EEM side.

@sbourdeauducq Is this a convoluted way of saying that all hardware versions of Urukul use a compatible protocol on the EEM side? Or that there was a breaking change in how the EEM was used with the release of hardware v1.4?

Also, please reopen this Issue.

@jbqubit I don't think that's been explored. Please investigate and report back.

@sbourdeauducq Is this a convoluted way of saying that all hardware versions of Urukul use a compatible protocol on the EEM side? Or that there was a breaking change in how the EEM was used with the release of hardware v1.4?

With CPLD versions 1.3.1 and 1.4.0 on hardware v1.3/v1.4/v1.5 the EEM protocol is compatible, yes.
I'm not sure about the older hardware versions, someone would have to study the hardware schematics and CPLD source code to decisively answer that.

I don't think that's been explored. Please investigate and report back.

The whole point of paying professional software and gateware developers such as QUARTIQ is to reduce the complexity encountered by end users in building quantum control systems. From my end it looks like QUARTIQ accepted funding to develop and extend the Urukul CPLD but couldn't be bothered to test it on production hardware, document the hardware-CPLD compatibility matrix or document changes.

WTF? You must be out of your mind! There is exactly zero funding to serve your capricious requests.

WTF? You must be out of your mind!

I think you misunderstand @jordens. My comment points to work that ought to have been done under past contracts but was overlooked by QUARTIQ.

Urukul 1.4 moved to a larger CPLD, so the CPLD gateware itself is not compatible across those Urukul versions.

In reading up on the changes between v1.3 and v1.4 it's not clear to me what the breaking hardware changes were made with respect to the CPLD. Hardware v1.4 was a rollup of some analog component level problems -- the FPGA IC was not changed. It's not clear why a "larger CPLD" necessitates breaking support for v1.2 and v1.3.

From the hardware side Technosystem was quite accommodating in applying hardware patch2019 to make v1.2 and v1.3 work fine from an RF perspective. So there's many of us who have hardware of this vintage that works fine with previous versions of ARTIQ.

Since it can be hard to follow the core elements of this Issue here's a recap.

• QUARTIQ made many changes to CPLD but never bothered to consider support for any but the latest roll of the hardware

• ARTIQ was changed to support only the latest version of the CPLD

• Many copies of perfectly functional Urukul hardware in the hands of users no longer works with ARTIQ master

I'm sorry to say this so bluntly but you have got absolutely no clue. Certainly not about any contracts QUARTIQ accepted, certainly not about "what ought to have been done", certainly not about the technical aspects, what works and what doesn't, and certainly not about who did what and who's "accommodating". How would you know? None of this makes any sense. Please stop peddling your bullshit here and go somewhere else.

To provide perspective for anyone seeing this exchange and wondering how this affects them: We are fully supporting our customers and have several users who understand how open source works and who have been using e.g. the first Urukul v1.0 prototype continuously until today and with current versions of ARTIQ.

e.g. the first Urukul v1.0 prototype continuously until today and with current versions of ARTIQ.

That's great! So what's the hardware-CPLD compatibility matrix look like?

Right now ARTIQ master requires proto_rev =0x08.

Many copies of perfectly functional Urukul hardware in the hands of users no longer works with ARTIQ master

That's not correct - all old hardware (e.g. KC705, Urukul 1.0, Kasli 1.0, even Novogorny) can still run on current ARTIQ. But it's rare enough (e.g. Urukul 1.0, 1.1 and 1.2 altogether are perhaps 1% of the global fleet) that I don't know every detail off the top of my head about what is required to get it to work, and it's simpler (for me at least) to just RTFS when there's a problem. Schematics and source code of old versions remain archived and accessible.

Which hardware version is your problematic card anyway? And did you consider the other possible causes for this error message?

We are using v1.0-v1.5 in the same setup and with ARTIQ master; the pre-1.3 hardware can just be flashed with the 1.3 firmware. In v1.4, the CPLD model was changed, so compatibility ranges are 1.0-1.3 and 1.4-1.5, for both of which a proto_rev 0x8 firmware exists.

I've confirmed that Urukul hardware v1.0-1.4 works with gateware v1.3.1. The wiki is updated to reflect this.

https://github.com/sinara-hw/Urukul/wiki/Firmware