nklangford
commented
8 years ago I have a few brief thoughts to start with:
1) I think it's a very good idea to use a waveform description which allows different ways of defining pulse timing. It would be almost impossible now for us to make a decision now to choose one way over the other which would not later prove to be deficient in some way, especially since none among us actually have enough experience with all elements of experimental pulse sequencing to make a sufficiently well-informed judgement.
2) We heard Adriaan yesterday talking about "pulses", "pulse lists", "channels", "segments", "sequences", etc. These run from one end, the relatively abstract end, where pulses and pulse sequences are defined in terms of which quantum object they ought to act on, to the more physical end, such as a "channel", which refers more to a specific physical input into the fridge or device. We know that individual pulses mostly (though not always) relate to a specific device element. Channels relate to a physical input. Device elements (e.g., a qubit) can often be addressed by multiple channels (flux line, direct drive line, readout resonator/feedline). However, one channel may also address multiple device elements (e.g., a single feedline which couples to multiple qubits, or a global external flux). I suggest we need to define an intermediate level, called something like signal "streams". This would allow some flexibility in terms of how pulse sequences may be combined on individual channels. For example, even if one feedline is used to both drive and readout multiple qubits, each of these functions could be separated out into individual streams. The channel would then contain information about which streams contribute to it and rules for combining them. However, it can also be quite powerful to have the flexibility to define multiple streams for a single task (e.g., device element / channel combination), because sometimes it is convenient to describe a drive pulse sequence for an individual qubit as a combination of sequences in different paradigms. There's no reason, for example, why, on an AWG, one might not wish to address multiple qubit transitions simultaneously, but it may be much simpler to define the logic of those sequences independently.
3) I think it is unlikely that one would want to mix "absolute pulse timing" with "relative pulse timing" in an individual signal "stream". So it may be that one would assign a "timing method" per stream.
4) I know that Adriaan has already put quite a lot of effort into updating and implementing the python sequencer. But if this step is as important as we all seem to agree it is, I think it's important not to limit the discussion based on what directions have already been taken. I'm pretty sure Adriaan agrees with me on this. Adriaan?
5) I know everyone is quite intimidated by the mathematica sequencer. And I am only too aware of some of the frustrations of working with it. And furthermore I completely agree that we need to have an integrated python based sequencer. However, to give some context to Adriaan's and Niels' assessments that the python sequencer is "easy" or "easier", I would make the following observation. From what I understand, it took me a similar amount of time (a day or few) to familiarise myself with the mathematica sequencer in all its existing complexity, once I dedicated the time to do it, to what it took Adriaan to familiarise himself with and start using the python sequencer in arguably a much simpler form. And that was despite the fact that I was not very familiar with mathematica at the start of the process, by comparison with Adriaan's existing expertise in python. The main problem we had with "ease of use" of the mathematica code, is that we were mostly learning it without having someone sufficiently knowledgeable to show us the ropes. My point is that we are not trying to sell why we should move away from the mathematica sequencer, so we should avoid making easy but possibly misleading comparisons.
6) Universality and simplicity are good metrics, but I don't think are enough. Intuitiveness, which is different from simplicity, and flexibility, which is different from universality, are also critical. Also, where possible and where beneficial, we should maintain the ability to design sequences in a way which is reflective of the underlying experimental structure / hardware we are dealing with. This is related also to flexibility.
Okay, this didn't end up being all that brief, but I'll sign off now.
wvlothuizen
AdriaanRol
In the meeting yesterday, I have the some ideas about the pulse generation.
Software & Hardware Implementation Separation
There should be a separation between the hardware implementation of the pulse generation and software waveform definition.
For example, the following waveform generation framework would support this separation:
Here I suggest a QuTech Uniform Waveform Format and a Generation Interface. The interface is written in Python in QCoDeS. The uniform format can be derived from the waveform format of AWG5014, CBox and QWG. Universality and simplicity are the two most important metrics for this uniform waveform format.
Every kind of AWG receives waveform in its predefined format translated by dedicated waveform translator from the QuTech Uniform Waveform Format. For example, AWG5014 receives a list of samples which may last for several milliseconds in its own format file, and CBox receives the eight groups of samples indicating eight pulses and timing tape [(pulse number, interval), ...] presenting the combination of pulses. For most of the devices, dedicated waveform translators have already been developed in QCoDeS.
In the upper layer, every user can easily write his own waveform generating function based on the Uniform Waveform Generation Interface. Specifying the time is based on 1) the absolute time, 2) the interval between consecutive pulses or 3) the interval between the starting points of two consecutive pulses can be determined by the user-defined wave generation functions.
(If experiments only invoke waveforms in the QuTech Uniform Waveform Format, it could free the programmer to generate waveforms in more flexible methods. However, this assumption implies an idea: generating waveform and using waveform should be separated. I don't know if it is feasible in experiment.)
In this way, the software implementation is independent of the hardware implementation, and every user can have his own preferred way to generate the waveform based on the experiment requirements. If there come any new devices, only dedicated waveform translator requires to be developed, and all upper layer software structure requires little change.
However, developing such kind of waveform format might be timing-consuming. I cannot estimate the pros & cons of this method at this stage.
Uniform Waveform Format Definition
Defining the format would be the most unclear part. It should possess the following properties: Can be easily translated into AWG5014/CBox_AWG/QWG waveform format. Flexible configuration parameters:
I cannot go into too much detail because 1) I have little experience in carrying on experiments; 2) we are not sure if this method would help and further this proposal is going to be taken or not.
We can have more discussion on this.