You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
codegenRelated to emitting (System)Verilog.optimizerRelated to IR optimization or analysis🧦 soxstitchingIssues related to stitching, multi-proc codegen, and integration with external verilog modules
Consider the situation where a receive is performed and the data is ignored- one scenario where this could happen is a top proc with an array of channels where it receives from each of N identical child procs and for whatever reason the top proc drops the data on the floor for half of the children.
Currently, this results in a few different not-great things:
we don't narrow the channels where data is ignored (they could be zero-width)
This problem is currently manifesting for me as unread ports (3), but ideally we'd also have (1) and/or (2) to obviate the need for waivers.
Footnotes
is it a good thing to DCE ports? It might be useful to keep them around to facilitate testing internal blocks, but I don't think we have a strong contract wrt what internal blocks look like. ↩
The text was updated successfully, but these errors were encountered:
grebe
added
codegen
Related to emitting (System)Verilog.
optimizer
Related to IR optimization or analysis
stitching
Issues related to stitching, multi-proc codegen, and integration with external verilog modules
🧦 sox
labels
Feb 13, 2025
codegenRelated to emitting (System)Verilog.optimizerRelated to IR optimization or analysis🧦 soxstitchingIssues related to stitching, multi-proc codegen, and integration with external verilog modules
Consider the situation where a receive is performed and the data is ignored- one scenario where this could happen is a top proc with an array of channels where it receives from each of
N
identical child procs and for whatever reason the top proc drops the data on the floor for half of the children.Currently, this results in a few different not-great things:
This problem is currently manifesting for me as unread ports (3), but ideally we'd also have (1) and/or (2) to obviate the need for waivers.
Footnotes
is it a good thing to DCE ports? It might be useful to keep them around to facilitate testing internal blocks, but I don't think we have a strong contract wrt what internal blocks look like. ↩
The text was updated successfully, but these errors were encountered: