Reset/initialization voltages

[SaivaHuck]

Bug Report

Fixes in gateware for use of Fastino

One-Line Summary

Three issues with using Fastino that might be possible to fix in gateware

Issue Details

Steps to Reproduce

1. Step 1. Switch on a system with Kasli + Fastino, ARTIQ7
2. Step 2. Look at Fastino output (e.g. one channel on a scope)
3. Step 3. Program different voltages onto the Fastino channel and capture the moment when the voltage is set on a scope

Expected Behavior

• all Fastino channels going to 0 V at startup
• no negative spike when setting the voltages

Actual (undesired) Behavior

• We are using several Kaslis with one Fastino each, using ARTIQ7. We've identified three issues that prevent us from efficiently working with the system, and it seems they may be fixable by gateware changes:

• On startup, all channels go to their maximum negative voltage (so around -10 V) - it would be preferable for them to go to 0 V instead

• When running a script which sets a voltage on one or more channels, the affected channels produce a negative spike (basically trying to go to the negative maximum as far as I can tell) before ramping up to the desired voltage (see a random image of the scope attached, can provide better pictures if needed). This happens only for the first voltage one sets in a script, so we are assuming that it comes from the Fastino init procedure - instead of going to 0 V when being initialized, it seems to be going to 0 m.u. It would be great if it could go to 0 V instead.

• What has changed from ARTIQ6 to ARTIQ7: this negative spike described above is now happening every time one runs the script - with ARTIQ6 it was only happening the first time one was running a script after power-up.

• As an info: Mikolaj was starting to look into these issues and said there is good hope for a gateware fix, but has now asked me to create an issue here.

Your System (omit irrelevant parts)

• Operating System: Windows 10, using Conda

• ARTIQ version: ARTIQ v7.8006.bbb2c75.beta

• Version of the gateware and runtime loaded in the core device: [ 0.003934s] INFO(runtime): software ident 7.8019.f89275b.beta;kasli-aegis-5tc1 [ 0.011344s] INFO(runtime): gateware ident 7.8019.f89275b.beta;kasli-aegis-5tc1

• If using Conda, output of conda list: conda_list_output2.docx

• Hardware involved: Kasli version 2.0, Fastino version 1.2

[jordens]

• You say you have three different issues. Could you file individual issues for them?
• You don't provide anything to reproduce the issue. I assume you have an ARTIQ experiment that corresponds to your observation. Please provide that.
• Also provide the Fastino gateware version.
• What does "startup" mean?
• The DACs have reset/POR voltages that are controlled by part number. There is no way to change that in gateware.
• Be aware of this explicit note https://github.com/m-labs/artiq/blob/f31279411ef7f198ee697290efe957544896ebdb/artiq/coredevice/fastino.py#L69-L70

[SaivaHuck]

• You say you have three different issues. Could you file individual issues for them?

• You don't provide anything to reproduce the issue. I assume you have an ARTIQ experiment that corresponds to your observation. Please provide that.

• Also provide the Fastino gateware version.

• What does "startup" mean?

• The DACs have reset/POR voltages that are controlled by part number. There is no way to change that in gateware.

• Be aware of this explicit note https://github.com/m-labs/artiq/blob/f31279411ef7f198ee697290efe957544896ebdb/artiq/coredevice/fastino.py#L69-L70

• Sure, let's use this one for the negative spike then since I've included the corresponding image here.

• It is not necessary to have any specific type of routine to observe this behaviour. All we have to do to see the spike is in the def run(self) is: self.core.reset() self.fastino0.init() self.core.break_realtime() self.fastino0.set_dac(0, self.voltage) And then the spike is visible before going to the desired voltage. This happens with very different setups we have used - that is why we believe it is a problem of the self.fastino0.init() definition - going to 0 m.u. instead of 0 V.

• On the gateware of the Fastino, we have not changed anything ourselves, so it is just in the same state we got it in - How can I read it out? We have also tried several different Fastinos that we had not received together etc.

• Startup means simply switching on the system (providing power) - but this part will then move to a different issue (which might not be solvable by firmware after all if I understand correctly...).

Thanks!

[jordens]

How can I read it out?

You'd have to download the gateware (https://github.com/quartiq/kasli-i2c) and determine where it comes from by comparing with existing images. Otherwise the people you bought the device from will be able to tell and help you.

It is not necessary to have any specific type of routine to observe this behaviour.

What makes you think that? The code you provide contains exactly two things that look dubious and unmotivated: core.reset() and fastino0.init(). Why are they there? Why do you think you need them each time? Remove those!

Also please format your posts for readability and indicate when/whether this is resolved/explained.

[SaivaHuck]

You'd have to download the gateware (https://github.com/quartiq/kasli-i2c) and determine where it comes from by comparing with existing images. Otherwise the people you bought the device from will be able to tell and help you.

Thank you for the clarification.

What makes you think that? The code you provide contains exactly two things that look dubious and unmotivated: core.reset() and fastino0.init(). Why are they there? Why do you think you need them each time? Remove those!

We are of course not using those two commands every time we set a voltage on one of the channels. We do, however, include it in the beginning of the run() method in every experiment script because it was our understanding that, after switching on the system and declaring the devices in the build(), we need to initialize the used hardware to enable it to be ready for running - and also to clear any de-synchronization etc. issues that may still be present.

So this means that every time we execute a run script, we get this negative spike in the beginning - which is obviously harmful to our setup. Therefore, it would be preferable to initialize Fastino to 0 V instead of 0 m.u.

Also please format your posts for readability and indicate when/whether this is resolved/explained.

I was trying to follow the template here, sorry if there is something off. And yes, sure, once the issue is resolved, I'm happy to report that.

[jordens]

after switching on the system and declaring the devices in the build(), we need to initialize the used hardware to enable it to be ready for running - and also to clear any de-synchronization etc. issues that may still be present.

You said "startup" means powering the system. But now it looks like "startup" means running the experiment code you provide. Which one is it?

Also in both cases simply try not resetting RTIO and not init Fastino as suggested. Neither appears necessary in your case and both are expected to cause transients, as mentioned.

[SaivaHuck]

You said "startup" means powering the system. But now it looks like "startup" means running the experiment code you provide. Which one is it?

Nope, startup still means powering the system. It just so happens that sometimes we run scripts after powering up and sometimes after power has been provided for a while already, and we're trying to make sure this works in both cases. Also, we were under the impression that these commands are generally useful to clear any errors or mismatches from previous runs to start new experiments from a fresh system. Maybe our understanding is wrong? If we don't use the init() method, we obviously don't get the spike. Would you say the system and run routines are still stable without it?

Is there generally any particular reason for going to 0 mu instead of 0 V? I am just assuming 0 V would be safest for any system?

[SaivaHuck]

PS: Or are you sort of suggesting a procedure in which, every time we boot the system ("give power"), we run a default script which initializes everything? So that we can then use it afterwards without having those commands in our scripts?

My questions regarding the reset after mismatch/errors of course still remain in this case, and this seems like a workaround maybe.

[jordens]

Nope, startup still means powering the system.

You get that same oscilloscope screenshot when (a) powering the system and not doing anything else, e.g. and specifically no startup kernel and also when (b) running the script?

Maybe our understanding is wrong?

Yes. Those are generally not needed and cause transients. My recommendation would be to run them not on suspicion and not to remove errors you don't have but only when you see an actual problem.

Would you say the system and run routines are still stable without it?

In this case yes.

Is there generally any particular reason for going to 0 mu instead of 0 V? I am just assuming 0 V would be safest for any system?

The fact that the DAC reset is model-dependent was explained above. Does that answer your question? One thing you can try is playing with afe_pwr (reset deasserted) in the gateware and enabling that late after you have established DAC voltages.

PS: Or are you sort of suggesting a procedure in which, every time we boot the system ("give power"), we run a default script which initializes everything?

Sure. That's how people do it usually.

If you do a new measurement with an oscilloscope you would not reset it each time either, right?

mismatch/errors

What are you referring to? That sounds like a (or multiple) completely unrelated/independent issue and fastino.init() is unlikley to help in that case.

[SaivaHuck]

Hello, I wanted to give an update here because we are now using the workaround for our current experimental runs. We have created a default script to be run every time we power up the system which initializes the hardware. When running a new experiment, i.e. executing a script, we only do self.core.reset() (this is necessary) and are not re-initializing anything else. Thank you again for clarifying that this is the standard procedure, it is of course also working for us - when not using the init() procedure on the Fastino, there is also no spike. We still don't understand why it would initialize to 0 m.u. instead of to 0 V, but since our HW can take the -200 V, we can work like this, and since it is a HW thing implemented during production, I of course understand we cannot change that with firmware now.

As for the first question, we got such an oscilloscope image when executing a script, i.e. using the Fastino init() procedure and then setting the voltage we wanted. When only powering up, all the channels simply go to 0 m.u. (-10 V) and stay there. I mean it makes sense that the voltage the channel goes to at startup and when using the init() procedure is the same, in my opinion, we would just simply prefer 0 V.

We are using the Fastino with additional amplifiers connected to their outputs, so we are currently working on using their timing to also limit spikes at power off etc.

But anyway, it seems to me that this is not something that can be attacked after fabrication, or let's say by SW changes, so for now we are working around it with the standard initialization script - just leaving an update here.

[jordens]

Original issue resolved with initialization script and workaround. Closing in favor of #9.