You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on recent updates of pulse program representation (especially, schedule block #5679 and frame #5977), a pulse program needs a chain of data processing, i.e. transformation, to conform to the OpenPulse API. This transformation level depends on how the backend compiler is implemented, thus porting concept of passmanager from the circuit transpiler seems to be reasonable approach.
Now it is good timing to reconsider this great work, while keeping connectivity to the transpiler passmanager.
Necessary transformation chain may look like
- Create a program with pulse builder -> ScheduleBlock with Signal formalism (waveform + frame) # if backend support block and frame, we can directly submit this
- Apply alignment transform to block -> Schedule with Signal formalism
- Resolve Frame -> Schedule with conventional waveform/channel model
- optionally, we can convert ScheduleBlock into DAG representation to resolve time allocation of frame changes before alignment transforms
- Inline subroutines (if transfer layer doesn't support subroutine def) -> Schedule with no subroutine call
- Flatten -> Schedule without nesting # for visualizer
- ParametricPulse to Waveform conversion -> Schedule with acceptable pulses
- Consecutive frame change (phase, frequency) merging -> Schedule without redundant instruction
- Remove compiler directives, i.e. barriers -> Schedule consisting of vISA # this is currently accepted by PulseQobj
The text was updated successfully, but these errors were encountered:
This issue is relevant to #6079, but currently transpiler accepts only circuit and schedule attached to it can be internally processed. I see what I wrote above is still different passes .. not necessary to create circuit for transformation. For example
withpulse.build(backend) asblock: # output is schedule block to support lazy schedulingpulse.play(signal, d0) # play signal, represented by waveform + frame# above `block` doesn't conform to OpenPulse API, so we cannot execute.# need extra 4 lines to use transpiler ...gate=Gate('temp_gate', 1, [])
qc=QuantumCircuit(1)
qc.append(gate, [0])
qc.add_calibration('temp_gate', (0,), block)
backend.run(qc)
We can create the circuit behind the scene, but creating a junk circuit just for transformation seems to be redundant though schedule execution pass may be deprecated in future. Am I missing something or creating such junk circuit is in the correct direction? Can we directly input schedule to transpiler?
sched=transpile(sched, backend)
If this can be covered by #6079 I'll close this issue. @ajavadia ?
I agree @nkanazawa1989, now is a great time to reconsider this. If it can be covered by #6079 that would be great, but I believe a lot of infrastructure is missing for pulse transformations from the current DAGCircuit representation.
What is the expected enhancement?
Based on recent updates of pulse program representation (especially, schedule block #5679 and frame #5977), a pulse program needs a chain of data processing, i.e. transformation, to conform to the OpenPulse API. This transformation level depends on how the backend compiler is implemented, thus porting concept of passmanager from the circuit transpiler seems to be reasonable approach.
The first attempt has already made by @taalexander:
https://github.com/taalexander/qiskit-terra/tree/pulse-compiler
Now it is good timing to reconsider this great work, while keeping connectivity to the transpiler passmanager.
Necessary transformation chain may look like
The text was updated successfully, but these errors were encountered: