Duplicated functionality in UHFQC_LookuptableManager

[antsr]

The functionality of both Pulse_Generator / UHFQC_LookuptableManager / UHFQC_LookuptableManagerManager and Pulse / Element / Pulsar seems to be to generate pulse sequences and upload them to an instrument (UHFLI and AWG5014) for playback. Is there any reason these libraries have to be separate and one should not implement UHFLI awg-sequence programming in the Pulsar class.

[AdriaanRol]

@antsr , Yes there is a good reason why these are different.

The Pulsar is geared towards the 5014 where we are forced to put an entire experiment in a single (very long) element (or lookuptable). The UHF (and other AWG's) supports working with smaller lookuptables that correspond to individual pulses.

It is true that the pulses from pulsar would work for this, however I consider them to be much too heavy weight for what they do (there is a lot of clutter and other things to make it work with the 5014). As such the different lookuptables all get their pulses from a single module that contains the waveform functions measurement.waveform_control_CC.waveform.py. It is true that the pulsar could also get it's primitives from here but that is a bit of an overkill IMO.

On a different note, the above arguments apply if you intend to control the UHF using a central controller that provides codewords (as we intend to do), if on the other hand you don't have such a device then it makes sense to do the sequencing in the device itself, in which case it makes a lot of sense to use the pulsar for this purpose.

Let me know if this is what you were looking for, and then I can close the issue, or if you disagree then we can probably work out a way to make everything a bit better.

[johu2]

To be clear, do you think you will tune up the qubits using CC? I can also imagine CC to only run the error correction cycles and the tuneup is still coordinated by more flexible PyCQED.

If LUT manager is work in progress and in future it will not be a copy of Pulsar, but meant for preparing UHFLI for CC controll, then I do see the distinctly different functionality.

[AdriaanRol]

Yes, most certainly. The operations will be controlled using the Central Controller. This means the tuneup must use the same hardware and it should be close to as flexible as the current Pulsar given the hardware constraints.

Note that in some respects it provides more power, e.g., when doing memory intensive things like GST.

[johu2]

I did not want to propose using a different hardware. I also did not want to propose not reusing pulse sequencing on UHFLI / AWG8 to save waveform memory for GST.

I just can imagine the tuneup being orchestrated by PyCQED: it would configure AWGs and interpret the data from UHF-QC to pick the optimal pulse parameters. Then it configures the LUT for DIO and hand over the control to CC.

[AdriaanRol]

I think we have a different perception of what the CC does. I don't think the CC will ever be the magical box that takes care of everything, we still have to program it. In my view this would be done from PycQED.

I see the CC as the processor that executes the (pre-programmed) sequence code, just as what we now program in the 5014 using the pulsar. In all these case you preprogram what you want in the 5014/CC and hand over real-time control to these devices during the experiment, or am I misunderstanding your comments?

[johu2]

Sure... the lack of understanding about what CC does in the tuneup step is the very reason why I asked.

In the end we are interested in a nice virtual layer to control several AWG-like instruments independent of them playing long waveforms or ZIC. You could say we want to generalize pulsar and it seemed that perhaps LUT manager was already meant for that. From reading the code we can only get what it is doing and not always what you plan it to do in the future :)