MLIR-AIR fails to generate schedule for Data Movement

[hunhoffe]

I made a small change to my code in the programming_examples/channel_examples/channel_sizes example in the branch channel-scffor-indices where I change a python for-loop which generates ChannelPut ops to an scf.for loop.

When I make this change, the code no longer works. This is because, by using an scf.for loop, I am indicating these operations must happen sequentially which is too complex for the compiler to handle correctly at this time.

I'm recording this in an issue because it seems there is room for improvements either:

• Addressing error handling in these situations, so the user may have a better understanding of why conceptually correct code may fail
• Addressing the underlying problem of being unable to generate the right schedule for a valid situation

[erwei-xilinx]

Just to provide some extra context: currently when the compiler sees an scf.for loop, it is intepreting the schedule as being strictly sequential across its loop iterations; a parallelizable schedule is expected to be represented with scf.parallel or scf.forall.

In this scenario, where when we add scf.for to iterate through each sub-channel in the channel bundle, what that would get materialized in AIE is a chain of BDs, one per DMA channel, executing MM2S (channel put) or S2MM (channel get) data movement in sequence, scheduled by the AIE locks. This lock allocation pattern isn't exercised in mlir-air and, to my knowledge, mlir-aie as of today, too.

If instead of scf.for we put scf.parallel, then I think the program should work through mlir-air?

[erwei-xilinx]

WiP: #765. Code fixups: #766 and #767.

[erwei-xilinx]

Closing this issue as the above PRs have landed, and this pattern is supported by mlir-air now.