Packet-flow routing at SHIM DMA MM2S channels, for control packets #712
Conversation
…cket_routing_at_shim
|
Cc: @Yu-Zhewen |
| // Create an overlay of packet flow network sending control packets from shim | ||
| // dma mm2s channels to tiles in a column. | ||
| void createControlPacketFlow(AIE::DeviceOp device) { |
There was a problem hiding this comment.
As far as I can tell this is a mlir-aie transformation. Can we put it there instead? If it was generalized a bit then it could already be used to fix this which is just a very small control overlay. It could be inserted with a pass instead. And I can think of several other uses.
There was a problem hiding this comment.
Yeah that makes great sense to me. It could totally become an mlir-aie pass, because it was only looking at aie.tile ops in the IR.
This overlay being generated comes with some constraints though. One thing that I haven't figure out is, if the mlir-aie design already has circuit-switch routed shim dma mm2s channel usage, then we certainly cannot use those channels for control packets. In AIR that was easily controlled, because we generate the whole design, and we can force the design to never circuit-switch reserve any shim s2mm channels to begin with. Whereas if this one becomes an mlir-aie pass, then I haven't figured out how to make this overlay flexible to an existing aie design, while still enfocing full connectivitly to every tile's control port...
Maybe we can discuss this in greater details in our meeting on Friday?
This PR adds to
air-to-aiethe option toinsert-control-packet-flow, which performs the following actions:aie.packet_flowinstead ofaie.flowops for any shim dma mm2s streaming connections. Packet-flow routing allows for sharing of shim dma channels as fanout.TODO: board test added in this PR shall fail for now, until mlir-aie's pathfinder for packet-flow allocation is updated.TODO: the new board test shall pass once this PR lands in mlir-aie: Xilinx/mlir-aie#1694TODO: bump mlir-aie once pathfinder update has landed.