-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Implementing pluggable HighLevelSynthesis #8548
Implementing pluggable HighLevelSynthesis #8548
Conversation
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
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.
Few quick comments, this looks good so far. It would be good to see if this can be further consolidated with UnitarySynthesis
.
…wing to specify these lists in config's __init__
Pull Request Test Coverage Report for Build 3160677768
💛 - Coveralls |
I have tweaked the documentation following @kdk's comments. I think that the suggestion to combine high-level-synthesis plugin file and unitary-synthesis plugin file into one, and to extend documentation to cover both cases makes sense, but I would like to get @mtreinish opinion before starting to change things. @kdk raised some very interesting questions:
I don't have great answers for these, so suggestions are highly welcome! |
I find it difficult to grasp the current state of the plugin, so I will simply list what I'd like to use it for and you can discuss which of those should make it in if they are not already. First and for most, I'd use it for the purposes of solving qubit routing (without really routing), so I need a coupling map. For this part, I will assume that is done.
I think most of these uses require some specific representation of (part of) the circuit. From there, you can make many different algorithms that synthesize from that representation. I expect it would make sense to have various different subclasses of the HighLevelSynthesis class, for each representation, such that we can call the LinearFunction plugin from the GraySynth plugin (for example). While some of the different strategies for full-circuit synthesis require very different representation from each other. Then, when I have those, I'd like to play around with different heuristics in each of these algorithms and maybe take gate fidelities into account. Hope my ramble is useful. |
@Aerylia - it seems that you have a great plan! I hope that this PR will get merged soon, so that you can continue with your suggested work. |
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 for the updates! I think after the documentation consolidation from #8548 (comment), this will be good to go.
…ivrii/qiskit-terra into pluggable_high_level_synthesis
Co-authored-by: Kevin Krsulich <[email protected]>
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 for the updates, this LGTM!
Summary
Implementing "pluggable" high-level synthesis, based on previous feedback and discussions. Further feedback is welcome.
[Updated on Sept. 12]
Details and comments
The
transpile
function has a new argumenthls_config
(possibly better name is needed) that gets propagated all the way toHighLevelSynthesis
transpiler pass. This requires minor changes totranspiler.py
,passmanager_config.py
,preset_passmanagers/__init__.py
,preset_passmanagers/common.py
andpreset_passmanagers/level*.py
. This is similar to howunitary_synthesis_method
andunitary_synthesis_plugin_config
arguments are propagated, except that we put all the arguments for all higher-level objects of interest in a singleHLSConfig
class.The
HLSConfig
allows to specify for each higher-level-object of interest, a list of synthesis methods and their arguments to use.For instance,
says to synthesize
LinearFunctions
usingdepth_opt
(with no additional arguments), and if this fails -- then withcount_opt
(with no additional arguments); to skip synthesis forCliffords
(since the passed list is empty); and to usedefault
method for every other higher-level-object (when such adefault
method is available).HighLevelSynthesis
transpiler pass is now very generic, only based on the name of the dag node, hls_config, and available plugins. There are still multiple things to sort out there, but the idea is that this transpiler pass should not change each time that a new higher-level-object or synthesis method is added.For each higher-level-object of interest in Qiskit, we write synthesis algorithms for this object, and register them via entry points in
setup.py
asHere the "group name"
qiskit.synthesis
is always the same, and the strings such aslinear_function.depth_opt
consist of the higher-level-object name (linear_function
) and the synthesis method (depth_opt
).The
high_level_synthesis_plugins.py
contains two new default pluginsDefaultSynthesisClifford
andDefaultSynthesisLinearFunction
for synthesizingCliffords
andLinearFunctions
respectively , and can be extended in the future to cover more higher-level-objects. Possibly we should make a directory for plugins instead.The
depth_opt
andcount_opt
entry points insetup.py
correspond to what the user may write, and are not be a part of Qiskit. A slightly better example with two OperationsOpA
andOpB
and their synthesis methods (mimicking what a user may potentially write) appears intest/python/transpiler/test_high_level_synthesis.py
.Some possible use-cases
The user wants to use the "default" method for every higher-level operation. This is the default behavior of
transpile
, without needing to passhls_config
parameter. Alternatively one can pass totranspile
the argumenthls_config = HLSConfig(use_default_on_unspecified=True)
orhls_config = HLSConfig()
.The user wants to use the "default" method for every higher-level operation, except for
linear_functions
, for which the user wrote a special synthesis algorithm (e.g.,LinearFunctionSynthesisPluginForDepth
). This needs to be registered in entry points (under the namelinear_function.depth_opt
). Then one can createand pass that to
transpile
. All the higher-level-objects not mentioned in the hls_config are synthesized using the "default" method (when available) or skipped (when not available).depth_opt
and leave all the other higher-level objects as they are. This is accomplished byTo do
HighLevelSynthesis
transformation pass (for example,coupling_map
ormin_qubits
), and whether to extend the required interface ofHighLevelSynthesisPlugin
with certainsupport_*
functions. Though maybe we can start simple, and add these once relevant synthesis algorithms become available.