[POC] Testing qibolab 0.2

[stavros11]

Updated the single shot classification routine to test with qibolab 0.2 (using qiboteam/qibolab#874).

I may try some other routines, but only few, as the pulse API for 0.2 is not finalized yet so it would be a waste of time to start updating routines now.

[stavros11]

@alecandido @hay-k this is how former start sweepers will look after replacing with delay duration. Also, see lines 66-78 above for the creation of the corresponding sequence, in this case for the T2 (Ramsey) experiment and

qibocal/src/qibocal/protocols/characterization/rabi/length_signal.py

Line 103 in df2b1f0

[qd_pulses[qubit] for qubit in targets] + [delays[qubit] for qubit in targets],

qibocal/src/qibocal/protocols/characterization/coherence/t1_signal.py

Line 107 in df2b1f0

[delays[qubit] for qubit in targets],

for Rabi length and T1, which also involve time sweepers. In contrast to before, now it is clear that readout always plays after drive, as we are sweeping the delays in both channels. Let me know if you agree with this interface or have any other suggestions.

The challenge is how this is translated to each driver. In most cases, this is straightforward since Delay is mapped to a wait instruction and if we are sweeping real time the argument of wait will just be a variable that is swept in the instrument. I believe this is supported by most instruments and is already implemented for QM in qiboteam/qibolab#874 in a relatively clean way. However, for QM wait only accepts integers of clock cycles (4ns) that are >4, which is translated to multiples of 4ns > 16ns, therefore special handling (baking, padding with 0s?) is required to support other cases. This is true even when we are not sweeping, however sweepers make it slightly more complicated because a pulse or delay may be defined with a duration that satisfies the wait constraints but some values in the array we are sweeping over do not satisfy the constraints and therefore the special handling is required.

[alecandido]

The interface seems perfect to me.

For the duration discretization, I see it as a separate problem. Either we implicitly support padding and baking in the driver, or just raise an error when it is not possible to realize.

[alecandido]

@stavros11 maybe we should close this comment, and open an issue in Qibolab for 0.2 for the drivers. What do you think?

In particular, for QM there is already qiboteam/qibolab#935

[stavros11]

@alecandido @hay-k I rebased this to latest qibocal main and updated some routines (resonator spectroscopy, Rabi, single shot classification and T1, T2 signal) for the new qibolab API, including the new channels, so that we can test and check how it looks from the user perspective. Here are some working examples with QM: qiboteam/qibolab#933 (comment)

[alecandido]

Thanks @stavros11!

We don't need to have the full Qibocal working as soon as Qibolab 0.2 will be out, but being able to test a few common protocols (with different combination of features used) is definitely helpful.

[stavros11]

Closing in favor of #990.