Channel autorouting#213
Open
gpeairs wants to merge 32 commits into
Open
Conversation
… not in longest vcg dag path
gpeairs
force-pushed
the
gp/auto-channel
branch
from
8a8a667 to
f20bf76
Compare
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds autorouting for channel routing based on Hashimoto and Stevens (1971), Yoshimura and Kuh (1982), and Condrat, Kalla, and Blair (2013).
Typical superconducting qubit devices are very regular by construction. Components lie on a repeating grid, and routes follow channels between them. Channel routing as described in the references above can take advantage of that regular structure to quickly produce reasonable routing solutions, which designers (or optimizers) can iterate on.
This PR adds an algorithmic core in
src/paths/channel_routing_core.jl, which is DeviceLayout.jl-independent, andsrc/paths/channel_autorouter.jl, which defines theChannelRouterobject that connects DeviceLayout structures (Paths,Routes, ...) to the core interface.The existing
SingleChannelRouting <: RouteRule(#123) lets users route multiple paths along a single channel with manual track assignment (or a simple auto-incrementing track). This PR introducesAutoChannelRouting <: RouteRule, which allows simultaneously routing many nets through multiple intersecting channels and automatically assigns tracks to avoid crossings. The channel and track assignment problem is solved by aChannelRouterobject inside the AutoChannelRouting rule, then the rule is used to construct the actual routes based on those assignments together with a rule for transitioning between channels (the same way SingleChannelRouting works, but chaining multiple channels together rather than only transitioning to the start and end pins).Routing proceeds in two steps: channel assignment (choosing which channels each net's wire passes through) and track assignment (assigning non-overlapping tracks within each channel). Track assignment within a channel is crossing-aware (based on Condrat et al.): If a crossing is avoidable (without changing assigned channels or already-assigned tracks), then it will generally be avoided. (This does mean that the quality of a solution can depend on the order channels are processed for track assignment.)
See
docs/src/concepts/channel_autorouter.mdfor explanation (preview) andexamples/ChannelAutorouter/ChannelAutorouter.jlfor examples (preview).Some follow-ups will make this more useful for complex problems, but are out of scope for this PR: