Sequencing / Hardware Interface

[lumip]

The hardware interface to allow sequencing(/waveform generation) of pulses seems proposed in #20 is not powerful enough. A better solution is required.

A current approach, which seems to be working, consists of the following:
API: HardwareSequencingInterface, Sequencer

Internal: Class representations of an abstract hardware instruction set for waveform generation with the instructions

• exec < waveform > - execute a single waveform from device memory
• cjmp < condition/trigger > < target > - perform a conditional jump to a target instruction index
• goto < target > - an unconditional jump
• stop - stop playback

Change in PulseTemplate:
Removed generate_waveform(..).
Add build_sequence(Sequencer, Parameters, TargetInstructionBlock).

HardwareSequencingInterface:
Abstract, will be implemented by hardware specific classes. Methods:

• register_waveform(..) gets a table definition of a waveform and returns a device specific handle for use in instructions. Will handle the upload of the waveform to the device in implementations.

Sequencer:
Used to convert the tree structure of pulse templates to a instruction sequence/block. Holds a HardwareSequencingInterface instance. Maintains a stack of pulse templates which are processed one by one. Subtemplates are pushed to the stack by their parent when it is processed.

The translation process is roughly as follows for the different PulseTemplate subtypes:

• Table: register_waveform(); add instruction "exec " to block;
• Sequence: push subtemplates in reverse order;
• Loop: create subblock b; push body-template with target block b; add instruction "cjmp < b >"
• Branch: create subblocks b1, b2; push if- and else-template with target block b1/b2; add instruction "cmp < condition > < b1 >" and "goto < b2 >"

Invoking Sequencer.build() "compiles" an instruction sequence covering all templates until either the stack is empty or the top-most stock element requires a stop. This sequence can then be easily interpreted by some interpreter to configure the specific hardware devices.

[lumip]

Somewhat related with #25 .

[lumip]

Concept generally approved during meeting 4.