Separate the routing for control flows and data flows #1082
Conversation
This file contains 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
Yu-Zhewen
changed the title
CTRL and non-CTRL
Yu-Zhewen
changed the title
Yu-Zhewen
commented
Feb 11, 2025
| @@ -236,7 +236,8 @@ def AIE_PacketRuleOp: AIE_Op<"rule"> { | |||
| let arguments = ( | |||
| ins I8Attr:$mask, | |||
| I8Attr:$value, | |||
| Index:$amsel | |||
| Index:$amsel, | |||
| OptionalAttr<DenseI32ArrayAttr>:$packet_ids | |||
There was a problem hiding this comment.
When lowering packet_flow to packet_rule, the IDs can be used to calculate the mask and value. However, the reverse operation (calculating the IDs from the mask and value) is not feasible, as we will probably get a superset of actual IDs. This can cause issues during the second run of the router.
Yu-Zhewen
commented
Feb 11, 2025
| @@ -108,22 +139,17 @@ PacketRulesOp getOrCreatePacketRules(OpBuilder &builder, SwitchboxOp &swboxOp, | |||
| return packetRules; | |||
| } | |||
|
|
|||
| struct ConvertFlowsToInterconnect : OpConversionPattern<FlowOp> { | |||
There was a problem hiding this comment.
Can't use OpConversionPattern, as it is also conditional based on whether it is control flow or not.
Yu-Zhewen
commented
Feb 11, 2025
| // CHECK: aie.rule(31, 10, %3) | ||
| // CHECK: aie.rule(27, 11, %3) | ||
| // CHECK: aie.rule(24, 8, %2) | ||
| // CHECK: aie.rule(31, 13, %[[VAL_70]]) |
There was a problem hiding this comment.
Yu-Zhewen
commented
Feb 11, 2025
| @@ -132,6 +117,23 @@ struct PhysPortAndID { | |||
| TUPLE_LIKE_STRUCT_RELATIONAL_OPS(PhysPortAndID) | |||
| }; | |||
|
|
|||
| struct RouterImpl; | |||
| struct Router { | |||
There was a problem hiding this comment.
The struct Router has been moved after the definition of PhysPort to accommodate the newly introduced addFixedPacketConnection function.
Yu-Zhewen
requested review from
makslevental,
MaheshRavishankar,
nirvedhmeshram,
yzhang93,
Abhishek-Varma and
jtuyls
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The routing results for control flows should remain unchanged, no matter whether (or how many data flows) are present. Therefore, the routing pass is now run twice, with the first time to route control flows only, and the second to route data flows. To achieve this,
Note:
mlir-aiehandled the problem by still running the routing pass only once, and sorting flows before invoking Dijkstra's algorithm (https://github.com/Xilinx/mlir-aie/blob/a60888210c76266cc932d5a0cc922fceef0322f0/lib/Dialect/AIE/Transforms/AIEPathFinder.cpp#L349). However, since Dijkstra is an iterative, congestion-aware algorithm, sorting alone does not fully prevent congestion from data flows affecting control flow routing.