The current Qibolab design requires the user to know in advance the whole pulse sequence, before requesting the execution.
However, this limits the possible experiments to be run, since, e.g., it should be possible to branch in real-time based on the acquired data (e.g. #592).
This is hard to represent as a pulse sequence, since the sequence will be the result, but not the instructions describing the execution.
Moreover, other real-time operations could be possible (e.g. sampling random numbers), that have no reasonable description in terms of pulses.
Because of this, the proposal is to deprecate the sequence API (not the pulses themselves, of course) to move towards a program-oriented API, where instructions are specified (which could be pulses, but not only).
The program will have an AST representation, and possibly a textual one (to read it and manually write, while programmatic creation should use the AST types).
We will then turn drivers into compiler backends, just receiving a program and compiling it into the assembly of the device (or whatever representation is exposed to us).
As side remarks:
this should further simplify the execute() signature, #861, since sweepers will be part of the program, and not separate from the sequence
the compilation process will inspect anyhow the whole content of the program, giving a natural place to implement advanced features support (as described in #854)
The current Qibolab design requires the user to know in advance the whole pulse sequence, before requesting the execution.
However, this limits the possible experiments to be run, since, e.g., it should be possible to branch in real-time based on the acquired data (e.g. #592).
This is hard to represent as a pulse sequence, since the sequence will be the result, but not the instructions describing the execution. Moreover, other real-time operations could be possible (e.g. sampling random numbers), that have no reasonable description in terms of pulses.
Because of this, the proposal is to deprecate the sequence API (not the pulses themselves, of course) to move towards a program-oriented API, where instructions are specified (which could be pulses, but not only).
The program will have an AST representation, and possibly a textual one (to read it and manually write, while programmatic creation should use the AST types). We will then turn drivers into compiler backends, just receiving a program and compiling it into the assembly of the device (or whatever representation is exposed to us).
As side remarks:
execute()signature, #861, since sweepers will be part of the program, and not separate from the sequence