Port placement to MLIR and placer enhancement

[yenjames]

Description

This issue will track a series of effort to port IRON SequentialPlacer into MLIR infrastructure and enhancements to placement in MLIR-AIE.

Specific tasks and their related issues/PRs

In Progress

• Define tile types as enum Add tile type for tile classification #2885
• Create interface to abstract over concrete tile ops Add TileLike interface to abstract tile properties #2886
• Implement logicalTileOp to define unplaced tiles Create aie.logical_tile operation to define unplaced tiles #2888
• MLIR placement pass Introduce placement pass #2900
• Emit logical tiles from IRON, deprecate SequentialPlacer [New] Deprecate IRON sequential placer #3016
• Placer improvement: [AIEPlacer] Simulated Annealing-based Placer #3146

Related works to enable placement migration

• Automatically insert trace packet flows and runtime sequence configuration for aie.trace Insert trace flows pass  #2962
• IRON trace configuration to use aie.trace instead of setting up npu.write ops Declarative trace IRON API #2988

Nice to haves

• [PR Draft with basic functionality] Routing visualization Routing visualization with Graphviz  #2936
• Placer visualization

[erwei-xilinx]

mlir-air RFC Xilinx/mlir-air#1567 is migrating AIR to emit aie.logical_tile across all tile-creation sites; PR Xilinx/mlir-air#1570 has Stage A complete (memtiles + shim tiles + compute tiles routed through the placer with tight constraints, byte-identical placements vs. before).

Stage B (constraint relaxation, where AIR genuinely gives up placement decisions) needs additional placer capabilities. Concrete asks based on a survey of the placer at origin/main:

G1. Row-range constraint on LogicalTileOp — (col, [row_min, row_max]) so AIR can express "this herd starts at row N" without hardcoding individual rows. Today only exact rows or full freedom is expressible. This is the primary blocker for AIR compute-tile relaxation: when AIR emits (col, ?), the placer fills the column from the bottom (row 1 on VC1902), ignoring row_offset=3.

Suggested syntax:

%t = aie.logical_tile<CoreTile>(2, 3..5)
%t = aie.logical_tile<CoreTile>(2, 3..)     // open upper bound

G2. Other connectivity sources beyond objectfifos — read aie.flow, aie.packet_flow, aie.cascade_flow, and shared-buffer cross-references for channel-requirement and grouping. AIR's DMA path (when clUseObjFifo=false) never creates objectfifos; today the placer is blind to it. Cascade likewise — AIELowerCascadeFlows validates adjacency at lowering time but the placer plays no role.

I see this is partly already in progress (the aie.flow / aie.packet_flow parts in your placer-read-flow-ops branch). The remaining piece is aie.cascade_flow so the placer can natively enforce cascade adjacency rather than relying on lowering-time errors.

G3. Adjacency / mem-affinity constraint primitives between LogicalTileOps — express "these N tiles must be physically adjacent (cardinal neighbours, or isLegalMemAffinity)." Cascade requires cardinal adjacency; shared L1 requires mem-affinity. With this primitive AIR could emit (?, ?) and let the placer find any valid placement for cascade kernels.

Suggested syntax (separate constraint op vs attribute on LogicalTileOp are both reasonable):

%t1 = aie.logical_tile<CoreTile>(?, ?)
%t2 = aie.logical_tile<CoreTile>(?, ?)
aie.constrain_adjacent %t1, %t2 {direction = "south"}      // cascade
aie.constrain_mem_affinity %t1, %t2                        // shared L1

G4. Cluster-based packing heuristic (lower priority) — herd-aware grouping for multi-herd segments. air-place-herds does largest-first 2D bin-packing today; the current placer just walks availability.compTiles column-major. Matters mainly at near-full segment capacity.

---

For context on what AIR currently does at each placer call site:

AIR call site	When invoked	Sees objectfifos?
outlineAIEMemtiles	Pre-lowerAIRChannels	No
ShimDMAAllocator (DMA path)	Mid-lowerAIRMemcpyOp, interleaved with flow creation	No (objectfifos never created on this path)
outlineAIECores	Pre-lowerAIRChannels	No
resolveLogicalShimTiles (after lowerAIRChannels)	Post-lowerAIRChannels	Yes

So three of four current invocations don't benefit from connectivity-aware placement (constraints are tight enough that this doesn't matter for current behavior, but it does matter for any relaxation). G2 is a prerequisite for closing this gap, but isn't sufficient on its own — the first three call sites run before flows exist in IR (or interleaved with flow creation), so realizing the benefit there requires AIR-side pipeline restructuring (deferring placement until after channel lowering).

Detailed file:line references and pseudocode of the algorithm in mlir-air RFC #1567 and a local analysis doc; happy to share the full doc as a follow-up comment if useful.

[erwei-xilinx]

MLIR-AIR-side support PRs are all landed.