Gateware Mismatch Error

JBLYONS

I am running into issues with our kasli crate as I attempted to update to a later version of Artiq. I eventually get a
gateware and firmware mismatch error, specifically with ARTIQ 8.0+unknown.beta, which I believe is causing issues when running experiments as our Urukul now displays red LEDs. To resolve this, I attempted to rebuild the gateware and reflash our kasli crate, but noted that for whatever reason, the nix develop environment defaults to v8.0+unknown.beta, despite the main nix profile being in Artiq v8.9. Thus, I am unable to generate the appropriate gateware for our kasli crate.

I am not sure if I am completely missing something as I have reinstalled from scratch multiple times, and attempted to update the flake files. I am unsure of how to get nix develop to register as Artiq v8.9.

Alternatively, I installed ARTIQ directly to nix, and attempted to run the gateware generation command from there.

I went ahead and installed the python packaging module directly to the nix environment, but I still receive the ModuleNotFoundError. When I install packaging again, nix states that 'packaging' was installed successfully.

Thanks for any insight.

architeuthis

The gateware+firmware mismatch warning is only a warning. It checks for a mismatch of the version numbers given by the firmware and software respectively, not for any actual incompatibility between them. If your gateware was generated from the same version as the software you are using, they are almost certainly perfectly compatible and your Urukul issue likely has a different source.

That said, using the boards shell, e.g. nix develop .#boards will generate gateware with the current precise version number rather than "unknown/beta". (Note that it also won't add the current source to your PYTHONPATH, but work from the most recent git commmit -- hence being able to use the precise version number.)

JBLYONS

Hm, unfortunately, nix develop .#boards was unable to fix the issue.

In regard to the Urukul with red LEDs, I am not sure on how to troubleshoot if it is not an issue with the gateware I generated. Essentially, I generated a new device_db.py file and gateware to update our Kasli crate with SUServo mode and checked to ensure the DIP switches are in the correct location. I am also able to successfully run:

artiq_sinara_tester -o suservos

This executes fine, but my Urukul does not output a signal to measure with a spectrum analyzer. I presume this is tied to the red LEDs.

Any opinions would be appreciated. As an aside which may or may not be important, when briefly looking over our .json file, I did note that when changing our prior device_db.py file to account for SUServo mode, I may have flipped the port numbers for the Urukul? Is this significant? Ultimately, as I completely new to this, I am not sure on how the physical connections correspond to the .json file or where I can even look to verify physical connections inside our Kasli crate are connected appropriately.

Thanks for helping clear my confusion.

architeuthis

JBLYONS

re: .#boards; ah, I didn't realize this, but evidently unknown is still defaulted to if your Git tree is dirty. Again, though, this is almost certainly not the root of the problem.

As an aside which may or may not be important, when briefly looking over our .json file, I did note that when changing our prior device_db.py file to account for SUServo mode, I may have flipped the port numbers for the Urukul?

Yes, the port numbers given in the system description are significant, they must be the physical EEM ports used. If there's still any doubt they are in fact labeled on the Kasli PCB:

i.e. EXT0, EXT1, EXT2, etc.

JBLYONS

I was able to fix the physical ports and represent that in the .json file. I regenerated all the files and reflashed the kasli crate, but still have red LEDs on my Urukul. I did notice that there is a 'critical warning' when generating gateware.

I presume this is not typical behavior?

Furthermore, when I restart up the Kasli Crate, the Urukuls boot up with red LEDs. However, when I run a check with:

artiq_sinara_tester -o suservos

the Urukuls DO turn green. I am still unable to read the output off of a spectrum analyzer though.

Thanks for your thoughts. @architeuthis

architeuthis

JBLYONS

I presume this is not typical behavior?

Not necessarily. Vivado notoriously produces a lot of warnings even for perfectly good builds. AFAICT the log you post is one of the handful of 'critical' warnings that's in fact standard for every ARTIQ build.

You might want to post the system description JSON you're using. Can you confirm that SUServo was working as desired before you upgraded (with ARTIQ-7, presumably?)

JBLYONS

Did some more testing and realized we had a faulty cable and spectrum analyzer. After subbing new equipment, I was able to clearly read a 10 MHz signal from the Urukul Channels.

Now, there is only one more issue I am encountering when running a basic SUServo experiment:

I looked around the various MLab-Forums to pull some basic code to run SUServo, but each piece of example code breaks down for us:

This same error persists across each example and is tied to this line:

self.suservo0.cpld0.set_att()

I have tried to explicitly address the error by replacing cpld0 with cplds but trigger more errors. I am unsure of the what the root issue actually is, and where the appropriate documentation is to read up on the attributes associated with suservo0. For context, this is our lab's first time working with SUServo which prompted us to flash the kasli crate and update our system to Artiq 8.

Thanks so much for all of your assistance so far and for any additional insight you might have! @architeuthis

JBLYONS

Update: I found the answer to my own question. I read through the git repositories and noted the change to 'cplds' in the suservo, Artiq 8, repository. The entire system is now up and running as expected.

Thanks again for your help!