[AssignChannels] Prioritize channel assignment for control packets #1106
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
requested review from
makslevental,
MaheshRavishankar,
nirvedhmeshram,
yzhang93,
Abhishek-Varma and
jtuyls
as code owners
jtuyls
reviewed
Feb 14, 2025
| ChannelAssignmentMode mode) { | ||
| std::optional<uint8_t> channel; | ||
| switch (mode) { | ||
| // Select the first available channel for circuit flow. |
There was a problem hiding this comment.
I would prefer the docs inside the case statements for readability.
| if (!assignedProducerChannels.count(i)) { | ||
| lastRetrievedProducerChannel = i; | ||
| return i; | ||
| // Select the first available channel for packet flow. |
There was a problem hiding this comment.
I would prefer the docs inside the the case statements for readability.
| i = (lastRetrievedProducerChannel + offset) % numProducerChannels; | ||
| } else { | ||
| assert(false && "Unsupported ChannelAssignmentMode"); | ||
| std::optional<uint8_t> getAndAssignProducerDMAChannel( |
There was a problem hiding this comment.
I think we create a .cpp file and add the definitions there.
| %channel_0 = amdaie.channel(%tile_0_0, 0, port_type = CTRL, direction = S2MM) | ||
| %3 = amdaie.logicalobjectfifo.placeholder{%tile_0_0} : !amdaie.logicalobjectfifo<memref<?xi32>> | ||
| %4 = amdaie.logicalobjectfifo.placeholder{%tile_0_0} : !amdaie.logicalobjectfifo<memref<?xi32>> | ||
| %5 = amdaie.connection(%4 {%channel_0}, %3 {%channel}) {connection_type = #amdaie<connection_type Packet>} : (!amdaie.logicalobjectfifo<memref<?xi32>>, !amdaie.logicalobjectfifo<memref<?xi32>>) |
There was a problem hiding this comment.
Could you add a test as well with a pre-existing circuit connection or update this one to include both?
There was a problem hiding this comment.
Added the test at:
Yu-Zhewen
force-pushed
the
zhewen_channels
branch
from
2f5cfa4 to
e11585c
Compare
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.
Changes in this PR:
AssignChannelspass, followed by control flow channel assignment with theGenerateControlOverlay pass. This PR reverses the order, ensuring that control flow channels are assigned before data flow channels.ChannelGenerator, packet flow channels were not explicitly marked as assigned (so that they can be reused), while only circuit flow channels were tracked. However, this could result in a packet flow channel later being mistakenly reused by another circuit flow. Now, both circuit and packet flows track their assigned channels and store them separately. This ensures that circuit flow channels remain exclusive, while packet flow channels can be reused but only by other packet flows.