Open alecandido opened 2 weeks ago
@rodolfocarobene notice that, as I tried to describe above, I believe that we could already make this work with the current Qibolab (even 0.1), just playing a bit at the level of the drivers.
We should even try doing this, since I believe we could clarify a better way to support this setup in Qibolab during the process.
While platforms accepts multiple instruments, the role of them mostly consist in requiring a connection, possibly uploading some parameters during initialization.
However, the active role is usually performed by a single instrument, that will be responsible for playing pulses, the
Controller
. This is not truly a requirement, since the situation of multipleController
s is already accounted for: https://github.com/qiboteam/qibolab/blob/f335e4d37376c973ea8372b6c95905245409fe71/src/qibolab/platform/platform.py#L168-L174However, notice that this is happening sequentially, playing the same sequence on many instruments, and acquiring a result from each of them. This could even be enough, since:
play
It could be more explicit and helpful if:
Platform
layout, if neededsequence
to all the actively involved instruments (e.g.instrument.upload(sequence)
, instead ofinstrument.play(...)
)An example setup, that is currently non-trivial to support, is the case where the pulses on different channels are played by different instruments and acquired by a separate acquisition card, without an internal clustering structure. Qibolab should provide this structure, or an easy-as-possible way to implement it.