qpy serialization for pulse schedule

What is the expected behavior?

Currently we are missing a serialization format for pulse schedule, and this is necessary for the calibration module in qiskit experiments. However implementation is not straightforward.

1. No standard We don’t have any de facto standard of schedule program representation. Currently we have two types of schedule representations Schedule and ScheduleBlock.

• Schedule
  • Closer to hardware program representation. All instruction time is assigned, i.e. (t0, instruction).
  • Timing related parameters cannot be parametrized due to immediate timeslot evaluation (overlap constraint).
  • Still used in many community codebases (conventional representation).
  • Many util functions are supported (filter, pad, align_measure)
• ScheduleBlock
  • Context rich representation of instruction timing, eg AlignLeft block, AlignRight block, etc…
  • We can stretch instruction duration. All instruction parameters can be parametrized with Parameter.
  • Used for the calibration module and the default output of pulse builder.
  • Need conversion to Schedule for execution.

1. Still under (relatively) active development For example, we are trying to upgrade definition of channel with #5977 . This PR can change the program representation. This means we need to pay a lot of effort for backward compatibility in serialization/deserialization logic.

2. Subroutine support Schedule programs support Call instruction, which is one of schedule instructions but refers to another program defined outside the scope of current program, i.e. subroutine (in the current implementation the instruction just entirely copies the subroutine, thus it just looks like a nested program). If we support such data structure, the serialization logic could become complicated.

Regarding the point 1, I’ve tried to unify the Schedule and ScheduleBlock by allowing the block to take an instruction time t0 (kind of soft scheduling) in #6444 . Eventually we can deprecate Schedule with this approach, but currently the pros/cons of this attempt is not well discussed.

[mtreinish]

Yeah, not preserving calibrations is a limitation with qpy currently, this is the tracking issue for it. To be able to serialize calibrations we need to have a representation for a pulse schedule. Once that exists preserving the calibrations should be trivial.

[mtreinish]

This isn’t closed yet, #7300 is needed before this is done.