Xilinx/mlir-aie

Summary The memory-module lock trace events on AIE2/AIE2P (LOCK_SEL0..7_ACQ_EQ, LOCK_SEL0..7_ACQ_GE, LOCK_SEL0..7_EQUAL_TO_VALUE and LOCK_0..7_REL) do not refer to fixed lock IDs. Each one reports the lock chosen by selection slot n, which is the Locks_Event_Selection_n register. None of the trace paths in mlir-aie write those registers today: the aie.trace dialect (trace.event, trace.reg, trace.combo_event, trace.edge_event); aie.utils.trace.configure_trace; IRON's Program.enable_trace. All eight slots keep their reset value. Its lock-select field is 0, so every LOCK_SELn_* and LOCK_n_REL event reports lock 0. A trace that asks for LOCK_SEL2_ACQ_GE looks plausible but shows lock 0's activity. This matters most when you are hunting a lock stall. CoreEvent.LOCK_STALL tells you the core stalled. The per-lock memory-module events would tell you which ObjectFifo, but right now they cannot. Registers The registers are identical in aie-rt xaie2pgbl_params.h and in mlir-aie lib/Dialect/AIE/

One note from asm analysis: IRON's range_ casts to index: 64-bit counters on the core, two registers and a carry each. aie2p is not friendly with 64-bit integers, and as result, it produces larger program code, and adds more register pressure. The workaround from user side exists: use custom function with scf.for from 0 to stop (an int or an i32 value) with i32 bounds; yields the i32 induction variable def range32(stop: object) -> Iterator[object]: c0, c1 = arith.constant(T.i32(), 0), arith.constant(T.i32(), 1) stop = arith.constant(T.i32(), stop) if isinstance(stop, int) else stop if isinstance(stop.type, IndexType): stop = index.casts(T.i32(), stop) for_op = scf.ForOp(c0, stop, c1) with InsertionPoint(for_op.body): yield for_op.induction_variable scf.yield_([]) However, I wonder, it can be improved on mlir-aie side? The simplest solution is add dtype= parameter to _range and let user to decide, but maybe there is something smarter than this

#3440 fixed the legal start-column set for virtualized NPU partitions by adding a free physicalColumns(AIEDevice) function in SidecarFiles.h, consumed only by aiecc's makePartitionJson. From that thread (#3440 (comment)): Yes, I think something exactly like that in the TargetModel would make a lot of sense. For now, just fixing the value in aiecc is good too, just wanted to check I'm not missing a historic reason why it is the way it is. Proposal, to fold the per-device switch into TargetModel itself so other call sites (placement, partitioning) can share it instead of re-deriving the array width: /// Width of the physical array this (possibly virtualized) device is carved from. /// Defaults to columns(), which is correct for any device that is the whole array. virtual int physicalColumns() const { return columns(); } /// First physical column at which a partition may be anchored. Column 0 on the /// NPUs has no shim tile, so nothing can be fed there. virtual int firstPlaceableColum

What happened? Many aie_kernels loops take their element count as a runtime argument and then hand the compiler an AIE_LOOP_MIN_ITERATION_COUNT(n) to get it pipelined. Peano predefines __AIECC__, so that macro expands to a real #pragma clang loop min_iteration_count(n) — a promise the compiler is entitled to schedule against, not a check. Build the kernel at a size below n and the pipelined loop runs past the tile. The factory already knows the tile size at build time and already passes -DBIT_WIDTH=... per config. If the size travelled the same way, the loop bound would be a compile-time constant, LLVM would derive the exact trip count itself, and the promise — along with the whole hazard class — would be unnecessary. Measured on Phoenix (aie2), passthrough, 2048×int32, median core cycles: variant cycles 4-iteration tile promise to violate runtime count + min_iteration_count(6) (today) 269 hangs yes (UB) runtime count, pragma removed 1164 ok none compile-time constant

Summary XRTTensor creates host BOs with group_id=0 (default in python/utils/hostruntime/xrtruntime/tensor.py:79), but amdxdna kernels declare a per-argument memory group (kernel.group_id(3+i) from kernels.json). Running with group-0 BOs against kernels that declare non-zero groups yields silently wrong results (ERT reports ERT_CMD_STATE_COMPLETED, the NPU never touches the data buffers). At large shapes this also wedges the NPU (IO_PAGE_FAULTs + aie2_set_cmd_timeout in dmesg) until a PCI remove/rescan. mlir-aie's own C++ tests bind every host BO with the kernel's declared group (test/npu-xrt/many_buffers/test.cpp: xrt::bo(device, size, XRT_BO_FLAGS_HOST_ONLY, kernel.group_id(3 + p*2))); the Python runtime never does. Environment Ryzen AI MAX+ 395 (Strix Halo), XDNA2 NPU (8 col x 4 row), amdxdna driver, XRT 2.21.75 mlir-aie from devel (iron-venv), IRON GEMM operator with dtype_in="i8" Reproduction (silent garbage) # INT8 GEMM 1024x512x1024, 8 cols, tile 64; kernel.group_id(3..5) == 0x