Adding coupling-map and target to HighLevelSynthesis #10477
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 |
mtreinish
left a comment
There was a problem hiding this comment.
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.
I think having some examples here would go a long way for plugin maintainers.
There was a problem hiding this comment.
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.
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.
Yes, good to know, thanks!
There was a problem hiding this comment.
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).
| ) | ||
| ) | ||
| 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.
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.
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.
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.
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.
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.
mtreinish
left a comment
There was a problem hiding this comment.
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>
mtreinish
left a comment
There was a problem hiding this comment.
LGTM, thanks for the quick update.
|
@mtreinish, many thanks for the improvements! Though the commit af27ba8 was problematic: the function |
|
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,targetanduse_qubit_indicestoHighLevelSynthesistranspiler pass, and adds the argumentscoupling_map,targetsandqubitstoHighLevelSynthesisPlugin. The change is backward-compatible.Details and comments
This reimplements yet another component of #9250, and consists of defining a cleaner API for
HighLevelSynthesisandHighLevelSynthesisPluginthat takescoupling_mapandtargetinto account. See discussion here and here.The argument
use_qubit_indicesprovides the context toHighLevelSynthesiswhether 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 totargetand hence to the coupling map of the device (this was not this way beforetargetwas added).