Pulse compiler skeleton #11743
Pulse compiler skeleton #11743
Conversation
nkanazawa1989
added
mod: pulse
There was a problem hiding this comment.
This looks great @nkanazawa1989!
I left some minor comments for your consideration.
|
|
||
| def __init__( | ||
| self, | ||
| target: Target, |
There was a problem hiding this comment.
Not all passes would require Target. Do we want to force this anyway?
There was a problem hiding this comment.
Yes, this is what circuit passes are trying to realize. This allows passes to reference system configuration without diverging the interface. Probably making it Optional is reasonable suggestion though.
nkanazawa1989
requested review from
eggerdj,
wshanks and
a team
as code owners
|
One or more of the the following people are requested to review this:
|
nkanazawa1989
force-pushed
the
feature-pulse/compiler
branch
from
861648d
to
214884a
Compare
qiskit/pulse/compiler/passmanager.py
Outdated
| def run( | ||
| self, | ||
| schedules: ScheduleBlock | list[ScheduleBlock], | ||
| output: str = "schedule_block", |
There was a problem hiding this comment.
I am not sure if ScheduleBlock should be the default here, as it doesn't support timing data. It's not critical though, and because there is some uncertainty about the output format, we don't need to waste time on it now.
qiskit/pulse/compiler/passmanager.py
Outdated
| callback: Callable | None = None, | ||
| num_processes: int | None = None, | ||
| ) -> Any: | ||
| """Run all the passes on the input pulse schedules. |
There was a problem hiding this comment.
The term "schedules" here (and onward) could be misleading because we're aiming for ScheduleBlock and not Schedule.
…rate converters into compiler itself.
There was a problem hiding this comment.
This looks good.
I think BlockTranspiler is a strange beast which won't see much use, because the ScheduleBlock class doesn't support information which is typically required (mostly, timing). I can imagine going from ScheduleBlock to ScheduleBlock (converting old model to new model, analyzing, etc.) but I think this mostly highlights that we are missing a front end representation - the legacy Schedule? A new format?
In any case, there is nothing wrong with BlockTranspiler, and we can move ahead, but it highlights what more needs to be done.
|
ScheduleBlock could do pseudo scheduling by flattening all instructions into left justified context with proper delay. This is how we currently convert backend calibrations in the Schedule format into ScheduleBlock. This is just for backward compatibility because we don't plan to support PulseQobj or QPy as a compiler backend; i.e.
I think ScheduleBlock output is also convenient for the unit test of model conversion. |
Summary
This PR introduces a skeleton of pulse compiler based on the
BasePassManager.Details and comments
Pulse compiler is expected to support multiple output format. The format can be set at run time, i.e. an argument of
.run. As in the circuit transpiler, the pulse compiler has two base passes for transform and analysis. We expect that a system configuration is provided by QiskitTargetmodel. In future we may integrate workflow of circuit and pulse pass manager via theConversionPass(namely scheduler). Because all circuit passes will gain the target object in their constructor, making theTargetthe single source of truth for quantum program compilation would simplifies our future compiler framework.Note that pulse compiler passes must explicitly implement
__eq__method, otherwise two different objects with the same pass configuration are evaluated as different objects (because equivalence check is deleted toobjectwhere only object id is evaluated). Two passes with the same setup must behave identically, and they must be the same object from PulseIR's point of view. Target object doesn't need to be evaluated, because it doesn't implement__eq__and we expect that the target object is not mutated during the single compilation run -- this information is identical to all running passes.