The goal of the former function would be to group together simultaneous readout pulses.
The concept of simultaneity for pulses may be ambiguous, since any kind of overlap is possible. In this case, the definition suggested by the function would be that they are simultaneous if any kind of overlap is happening (notice that this is not a transitive relation, so you could end up grouping together two non-simultaneous pulses, just because they are both simultaneous to a third one in the middle).
However, the current code is not even implementing this solution, since it is comparing the length of the previous readout pulse with the start delay with respect to the previous pulse (i.e. any kind of pulse). This means that a readout - drive - readout may end up making the two readout pulses simultaneous, when they are not even overlapping to the same one, e.g.:
r1: ############
d1: ####
r2: ############
(the difference r2.start - d1.start is definitely shorter than r1.length)
In general, the simultaneity determined by Qibosoq is not reliable.
I'm not sure what are the constraints imposed by the QICK firmware, but on the one side, whatever it is doing should be reproduced. If there is no QICK-related constraint, I would give up on simultaneity, and just have a flat list of readouts.
https://github.com/qiboteam/qibosoq/blob/f51693873575251eea5bbfab9998f4977c17aced/src/qibosoq/programs/base.py#L346-L363
The goal of the former function would be to group together simultaneous readout pulses.
The concept of simultaneity for pulses may be ambiguous, since any kind of overlap is possible. In this case, the definition suggested by the function would be that they are simultaneous if any kind of overlap is happening (notice that this is not a transitive relation, so you could end up grouping together two non-simultaneous pulses, just because they are both simultaneous to a third one in the middle).
However, the current code is not even implementing this solution, since it is comparing the length of the previous readout pulse with the start delay with respect to the previous pulse (i.e. any kind of pulse). This means that a
readout - drive - readoutmay end up making the tworeadoutpulses simultaneous, when they are not even overlapping to the same one, e.g.:(the difference
r2.start - d1.startis definitely shorter thanr1.length)In general, the simultaneity determined by Qibosoq is not reliable.
I'm not sure what are the constraints imposed by the QICK firmware, but on the one side, whatever it is doing should be reproduced. If there is no QICK-related constraint, I would give up on simultaneity, and just have a flat list of readouts.