-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Adding coupling-map
and target
to HighLevelSynthesis
#10477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ith target and coupling_map
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 5834603069
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this LGTM, the interface makes sense as it's explicitly setting the required arguments. Just a few small questions/comments inline. One other thing is do you think we should add some details about this to the plugin interface docs: https://github.com/Qiskit/qiskit-terra/blob/main/qiskit/transpiler/passes/synthesis/plugin.py#L159 because we're adding on to the interface.
- | | ||
Added the arguments ``coupling_map``, ``target`` and ``qubits`` to :class:`.HighLevelSynthesisPlugin`. | ||
This change is backward-compatible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think having some examples here would go a long way for plugin maintainers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. At the moment I don't have any good examples, but I would after the last part of #9250 gets cleaned up, i.e. actually having some plugins that take coupling_map
and qubits
into account. And then we would be able to mention/reference these specific plugins in the plugin interface docs. By the way, thanks for reminding to update these docs, that's done in 54bd00b.
if coupling_map is None: | ||
raise TranspilerError("Coupling map should be specified!") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it doesn't matter in this case since we're just testing the raise, but you can do target.build_coupling_map()
to get a coupling map from a target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good to know, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have also added a test that when only the target is set, the synthesis plugin does see a valid coupling map (because indeed the HighLevelSynthesis
pass builds it using the function above).
@@ -217,7 +217,7 @@ def generate_unroll_3q( | |||
target=target, | |||
) | |||
) | |||
unroll_3q.append(HighLevelSynthesis(hls_config=hls_config)) | |||
unroll_3q.append(HighLevelSynthesis(hls_config=hls_config, coupling_map=None, target=target)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if there is a potential issue here because unroll3q is typically run before layout so the qubit indices that get set in the pass will not be indices in the coupling map (ie qubit 0 in the circuit is not yet decided to be qubit 0 on the target backend). Maybe we need a flag to skip the qubits or otherwise flag that we've yet to set a layout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. At the moment I think having qubits=None
is exactly an indication that the layout has not yet been chosen. I have added a sentence on that to the plugin reference docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But won't this still set qubits
to a value because it's unconditionally populated in the plugin_method.run()
call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: I spoke with Matthew in private, and he has convinced me that HighLevelSynthesis
needs to know whether it's running before or after the layout is set, and suggested to add a flag use_qubit_indices
to HighLevelSynthesis
transpiler pass. This is now done in e3211fb.
transpiler pass. | ||
- | | ||
Added the arguments ``coupling_map``, ``target`` and ``qubits`` to :class:`.HighLevelSynthesisPlugin`. | ||
This change is backward-compatible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also it might be worthwhile to call out that if they're not explicitly added to a plugin's run()
method kwargs the coupling map, target, and qubits will end up in the options input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a pass over release notes in 5a1365a.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM, thanks for the quick update. I had a couple of small suggestions inline but nothing worth really blocking over. If you don't think we should make these changes I'm happy to approve and move forward with this.
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the quick update.
@mtreinish, many thanks for the improvements! Though the commit af27ba8 was problematic: the function |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, you're correct, I neglected that the coupling_map
isn't available there. Sorry for applying an incorrect suggestion. This is ready to go from my perspective then.
Sorry, I just removed this from the queue because I think it may be worth holding off merging anything until the cross-repo merge I'm just writing up now is complete. |
…kit#10477) * extending HighLevelSynthesis and HighLevelSynthesisPlugin interface with target and coupling_map * improving docstrings and adjusting arguments to implemented plugins * adding test that the coupling map gets passed correctly * release notes * docs * using DAGCircuit's find_bit * removing debug print * updating plugin interface docs * improvements to release notes * removing unused variable * adding use_qubit_indices; updating release notes and tests * Update qiskit/transpiler/passes/synthesis/plugin.py Co-authored-by: Matthew Treinish <mtreinish@kortar.org> * Update qiskit/transpiler/passes/synthesis/plugin.py Co-authored-by: Matthew Treinish <mtreinish@kortar.org> * Update qiskit/transpiler/preset_passmanagers/common.py Co-authored-by: Matthew Treinish <mtreinish@kortar.org> * Update qiskit/transpiler/preset_passmanagers/common.py Co-authored-by: Matthew Treinish <mtreinish@kortar.org> * Update qiskit/transpiler/preset_passmanagers/common.py Co-authored-by: Matthew Treinish <mtreinish@kortar.org> * Update qiskit/transpiler/preset_passmanagers/common.py * setting coupling_map to None --------- Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
### Summary Make the Clifford synthesis algorithm for RB circuits pluggable (implementing it as a `HighLevelSynthesisPlugin`). Fixes #1279 and #1023. Change to accept Clifford elements consisting only of instructions supported by the backend for `interleaved_element` option in `InterleavedRB`. Speed up 2Q RB/IRB for backends with unidirectional 2q gates, e.g. IBM's 127Q Eagle processors. ### Details and comments Previously, for 3Q+ RB circuits, entire circuit is transpiled at once and hence for each of the resulting Cliffords, the initial and the final layout may differ, that means sampled Cliffords are changed during the transpilation. Also in the worst case, the resulting circuit may use physical qubits not in the supplied `physical_qubits`. To avoid that, this commit changes to transpile an RB sequence Clifford by Clifford. The Clifford synthesis algorithm (`rb_default`) is implemented as a `HighLevelSynthesisPlugin` (see `RBDefaultCliffordSynthesis` in `clifford_synthesis.py`), which forces the initial layout (i.e. guarantees the initial layout = the final layout) and physical qubits to use. As a byproduct, the performance of 2Q RB/IRB for backends with directed 2q gates (e.g. IBM's 127Q Eagle processors) is drastically improved. For those cases, previously we had to rely on `transpile` function to make generated circuits comply with the coupling map, however, after this commit, we can synthesize Cliffords with considering the 2q-gate direction and go through the fast path introduced in #982. Depends on Qiskit/qiskit#10477 (qiskit 0.45) --------- Co-authored-by: Helena Zhang <Helena.Zhang@ibm.com>
Summary
This PR adds the arguments
coupling_map
,target
anduse_qubit_indices
toHighLevelSynthesis
transpiler pass, and adds the argumentscoupling_map
,targets
andqubits
toHighLevelSynthesisPlugin
. The change is backward-compatible.Details and comments
This reimplements yet another component of #9250, and consists of defining a cleaner API for
HighLevelSynthesis
andHighLevelSynthesisPlugin
that takescoupling_map
andtarget
into account. See discussion here and here.The argument
use_qubit_indices
provides the context toHighLevelSynthesis
whether it's running before or after the layout has been set, that is, whether the qubit indices of higher-level-objects correspond to qubit indices on the target backend. One thing which I did not realize initially is that even when passes like unroll3q or high-level-synthesis are running on the abstract circuit, they have access totarget
and hence to the coupling map of the device (this was not this way beforetarget
was added).