Pulse Execution and Measurement Data Acquisition

[lumip]

A general idea on the actors and data participating in the execution of a pulse. The main problem is that we (will) allow conditional code execution (i.e., branching and looping based on triggers) such that after the Sequencer creates a Program (i.e., a series of (nested) instructions) it is not clear how exactly the program will execute. It is thus not trivial to configure the measurement devices.

We will likely need some process (Execution Tracker) which tracks how the program executes (for instance by recording the triggers) and collects all executed waveforms in the order of their execution while annotating in which loop iteration they were executed (Executed Program Flow). Simultaneously, measurements must be made such that all possible executions are covered (Raw Measurement Data). After the execution completes, this two pieces of data can be combined to determine what was actually measured (i.e., discarding obsolete raw measurement data from wrongly assumed measurement windows) and possibly applying post-processing filters like downsampling or averaging. However, this will likely not fit really well with the current measurement configuration options of special-measure (periodic masks, etc.) in the long run.

The figure below shows the flow of data (rectangular items) between processes/classes (elliptic items) in the model of which I think that it should sufficiently cover all relevant aspects on a high level.

For programs without conditional execution (i.e., only constant loops by RepetitionPulseTemplate and sequences via SequencePulseTemplate) the tracking of the execution can be determing a priori (as it is deterministic) and thus a precise measurement configuration can be fixed before execution such that usage of special-measure should be no problem. This behavior is also covered in the model above.

The information, where measurement windows are placed, should be provided by the Waveform objects via some get_measurement_configuration method which

• should return None when no measurement window is defined for the Waveform
• should return start and stop time of the measurement window in time units relative to its own duration as well as a desired post-processing operation for the data and an potentially identifier (?)
  The Measurement Configurator can then simply parse the Program by visiting each Waveform and invoking get_measurement_configuration to set up the global measurement configuration. Additionally, since the Execution Tracker collects the exectued waveforms in correct order, they then immediately reveal when (meaningful) measurements should have been made during program execution to allow filtering of the obtained data.

Example:
Consider the following program.

A possible Executed Program Flow could be:

• waveform neg_template (annotation: MainBlock LoopBodyBlock_iteration_1 ElseBranchBlock)
• waveform neg_template (annotation: MainBlock LoopBodyBlock_iteration_2 ElseBranchBlock)
• waveform pos_template (annotation: MainBlock LoopBodyBlock_iteration_3 IfBranchBlock)
• waveform neg_template (annotation: MainBlock LoopBodyBlock_iteration_4 ElseBranchBlock)

If only neg_template would define a measurement window, the Measurement Configurator would set up a periodic measurement such that in each iteration of the loop some data is acquired. After execution and upon inspection of the Executed Program Flow, the data from the third loop iteration would be discarded as it does not corerspond to the execution of a neg_template waveform.