Port MobileNet to the IRON API

[hunhoffe]

Adds an IRON implementation of MobileNet (aie2_mobilenet_iron.py) that produces a functionally-equivalent xclbin for Strix. The original placed-API design (aie2_mobilenet.py) did the hard work of validating the network topology, kernel selection, and tile placement on Strix; this PR ports those proven decisions into a more declarative form using IRON.

Summary

• IRON design: bottleneck families expressed as reusable per-family helpers (bottleneck/{regular,cascade,pipeline}.py) driven by a single NETWORK spec; scale factors carried as a dict.
• StaticWeightStream (lowlevel_dma.py): MemTile→compute weight DMA with optional ping-pong, for layers where ObjectFifo's semantics weren't a fit.
• CascadeFlow in IRON: first-class CascadeFlow(src, dst) that lowers to aie.cascade_flow after placement.
• ObjectFifo additions: disable_synchronization, allocate_on.
• Validation: mobilenet_numpy.py bit-exact reference, per-block IRON e2e + numpy lit suites.

Test plan

• make build/final_mobilenet.xclbin + test_mobilenet.py pass on Strix against data/aie_output.txt.
• run_e2e.lit and run_numpy_per_bn.lit green.
• test/python/npu-xrt/test_cascade_flow.py passes.

Note for reviewers

AIE output has a known max-delta=9 vs the brevitas golden (mlir-aie #3009); test_mobilenet.py follows the existing convention of atol=9 against data/golden_output.txt.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

[jackl-xilinx]

@hunhoffe This is a nice refactor and I like how the different common patterns are abstracted so that we could, for example, make a different choice to merge two other bottleneck blocks with the fused wrapper and generate a different design. I'm still digging through the source to check a few more things but so far, I like how it's structured.

I did wonder if the A,B,C now called regular, pipeline, and cascade should stay separated. With the way things are wrapped, it might be possible to merge them into one file so you could, for example, choose a "regular" pattern for a block in the "cascade" section if you wanted to (though you can't really because weights buffer size is too big. I also wonder if the init and L1, L2 blocks should also be in another wrapper python class not in the top design file. It was done this way in the placed design to quickly build the design but it seems having all blocks outisde the top level python wrapper would be more consistent.

So just to double check, the iron version will replace the placed version, but some of the design files like the gen_golden*py will remain.

[hunhoffe]

@jackl-xilinx Thanks for taking a look! I'm very open to suggestions. I don't have strong feelings towards the specific organization of the code, although -- as you might be able to tell from the structure of the code -- I was wondering if perhaps we can eventually put some bottleneck patterns in algorithms and share them amongst ML examples as an example of how to reuse mlir-aie patterns. That was some of the intent behind this, but I'm still pretty new to this design so that may/may not be a good goal.

I'll look into your suggestions for:

• A, B, C separation
• Wrappers for init and L1, L2 blocks in separate python wrappers

I'm open to keeping both designs in the repo; I thought replacement helped to make the diffs more obvious for the purpose of reviewing. I do worry about the maintenance effort of keeping both versions consistent and functional, so I have a preference towards just having one design long-term. I would be interested to hear your thoughts on this matter.

[hunhoffe]

Hi @jackl-xilinx — it took me a bit to explore your feedback so far.

On wrapping init / L1 / L2: ✅ done in 11f7169 — they're now bottleneck/init.py / post_l1.py / post_l2.py mirroring the existing sibling shape. Top file drops 590 → 250 lines and MLIR is unchanged, so this was a simple refactor.

On "should A / B / C stay separated?": I was approaching the desire for cross-pattern reuse in a different way. Commits 0ff172e and 22d1c4d extract common algorithms — 1x1 row driver, 3x3 sliding window with replicate borders, skip-add row driver — into python/iron/algorithms/conv_pipeline.py as four small composable helpers. I kept the per-file structure because regular/pipeline/cascade encode real hardware-strategy decisions (1-tile vs 3-tile vs 5-tile cascade) and flattening them doesn't seem to reduce code complexity much. By focusing on the algorithm itself, I was able to extract helpers applicable to mobilenet, resnet's conv2_x, ml/bottleneck, the conv2d family, and vision/edge_detect.

Let me know if any of this feels like the wrong direction; happy to revisit either the extraction shape or the per-file factoring.