Multiplexed readout grouping

[alecandido]

qibosoq/src/qibosoq/programs/base.py

Lines 346 to 363 in f516938

	def group_mux_ro(self) -> list:
	"""Create a list containing readout pulses grouped by start time.
	Example of list:
	[[pulse1, pulse2], [pulse3]]
	"""
	mux_list: List[List[Element]] = []
	len_last_readout = 0.0
	for pulse in (pulse for pulse in self.sequence if pulse.type == "readout"):
	if pulse.start_delay <= len_last_readout and len(mux_list) > 0:
	# add the pulse to the last multiplexed readout
	mux_list[-1].append(pulse)
	else:
	# add a new multiplexed readout
	mux_list.append([pulse])
	len_last_readout = pulse.duration
	return mux_list

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.