Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Program API #917

Open
alecandido opened this issue Jun 11, 2024 · 1 comment
Open

Program API #917

alecandido opened this issue Jun 11, 2024 · 1 comment
Labels
execution Execution API (sequences, program, configs, ...)
Milestone

Comments

@alecandido
Copy link
Member

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, Unify execution interface #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 Advertise Instruments capabilities #854)
@alecandido
Copy link
Member Author

alecandido commented Aug 22, 2024

The PulseSequence should be kept, because, when no runtime instruction is involved, the sequence format provides more explicit information.
So, it would be nice to have a partial function compile(Program) -> PulseSequence, failing when there is no valid representation as a sequence.

E.g., an align instruction is much more expressive as part of a Program (targeting many channels), and directly compiled into the akin instruction in the various drivers (when present). But it should be possible to compile it as a sequence with delays, essentially how it is done in

def align_to_delays(self) -> "PulseSequence":

(though it might also be compiled as another Program with delays, when possible, as this transformation is sometimes useful, both for simpler drivers missing a native align, that could often make use of just the PulseSequence, with no difference, and for those supporting it, but forcing it at runtime - while delay compilation will attempt making it static)

@alecandido alecandido added the execution Execution API (sequences, program, configs, ...) label Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
execution Execution API (sequences, program, configs, ...)
Projects
None yet
Development

No branches or pull requests

1 participant