Pulse instructions should be scheduled with delays

[taalexander]

What is the expected enhancement?

Currently, all pulse.Instructions are stored in a Schedule with a two-tuple containing the (start_time, Instruction). While this makes it clear the explicit starting time of every pulse it leads to convoluted internal data structures such as TimeslotCollection for tracking the time of all instructions.

It also encourages inefficient operations such as taking the union of two schedules. At first glance this operation should be efficient since all one needs to do is specifying the starting time of the instructions, but this requires verification that no instructions overlap in time in the two schedules resulting in expensive checks. The requirement for such a check to merge two schedules is obvious within the relatively schedules model, as one must look to make sure a delay exists in the first schedule for all instructions of the second schedule to merge.

Furthermore, explicit timing of instructions will become confusing with the introduction of control-flow to quantum programs as it would become difficult to program experiments containing loops that are not unrollable.

We should move to a model where instructions are explicitly scheduled with Delays (think NOPs) of a given duration. This will:

• Make appending two schedules a much simpler operation as the dependency of instructions will be specified by their order on operands
  • This will allow a simple transformation to a DAG representation of a basic pulse schedule block
• Have positive performance impacts.
• Have implications for the current pulse API. I believe this should be mostly internal-facing and that not many changes will exist for users.

Requirements for closure of this issue include:

• Approved RFC
• Implementation

[lcapelluto]

RFC started (only a draft now). RFC link added to description. Qiskit/RFCs#16

[taalexander]

This has long since merged. Closing.