Tests that still require Chess after #3451, and what each one is waiting on

[atassis]

#3451 makes every test state its own backend and moves the ones that never needed Chess onto Peano.
This issue records what is left, so the reason a given test still needs Vitis is written down rather
than remembered.

Counts are against the head of #3451 (7936ffd). grep -rl 'REQUIRES:.*chess' test programming_examples programming_guide returns 76 files, in four groups.

1. Chess instruction-set simulator (53)

These run under the Chess simulator, not on hardware. There is no open equivalent, so nothing here can
move until one exists. Two forms:

aiecc --get-aiesim (21). --get-aiesim requires --xbridge, and the generated project is built
and run by aiesimulator from Vitis.

21 files

test/aiecc/cpp_aiesim.mlir
test/unit_tests/aie2/29_aie2_nd_dma_even_odd/aie.mlir
test/unit_tests/aie2/30_aie2_nd_dma_transpose_repeat/aie.mlir
test/unit_tests/chess_compiler_tests/01_precompiled_core_function/aie.mlir
test/unit_tests/chess_compiler_tests/02_precompiled_kernel/aie.mlir
test/unit_tests/chess_compiler_tests/03_cascade_core_functions/aie.mlir
test/unit_tests/chess_compiler_tests/04_shim_dma_kernel/aie.mlir
test/unit_tests/chess_compiler_tests/05_shim_dma_core_function/aie.mlir
test/unit_tests/chess_compiler_tests/07_shim_dma_core_function_with_loop/aie.mlir
test/unit_tests/chess_compiler_tests/08_tile_locks/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/01_precompiled_core_function/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/02_precompiled_kernel/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/03_cascade_core_functions/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/03_simple/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/04_shared_memory/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/04_shared_memory/aie_row.mlir
test/unit_tests/chess_compiler_tests_aie2/04_shim_dma_kernel/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/05_shim_dma_core_function/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/07_shim_dma_core_function_with_loop/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/08_tile_locks/aie.mlir
test/unit_tests/chess_compiler_tests_aie2/09_memtile_locks/aie.mlir

xca_udm_dbg (32). All of test/unit_tests/aievec_tests/aie2/. Each compiles the vectorized dut
with Peano, builds the testbench with xchesscc_wrapper, then runs it under xca_udm_dbg against
%aietools/data/aie_ml/lib/ with profiling.tcl. The Chess dependency is the runner and the aietools
data directory, not the kernel.

Worth knowing before anyone invests in porting these: 27 of the 32 are XFAIL: *. Only
bf16_exp_lut, bf16_max_reduce, bf16_min_reduce, i16_max_reduce and i16_min_reduce are expected
to pass. Whatever these cost to keep, the coverage they currently provide is close to nothing, so
"delete or rewrite" is at least as reasonable as "port the runner".

32 files

test/unit_tests/aievec_tests/aie2/bf16_exp_lut/bf16_exp_lut-llvm.mlir
test/unit_tests/aievec_tests/aie2/bf16_max_reduce/bf16_max_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/bf16_min_reduce/bf16_min_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/bf16xbf16_max_elem/bf16xbf16_max_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/bf16xbf16_min_elem/bf16xbf16_min_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/bf16xbf16_mul_elem/bf16xbf16_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/bf16xbf16_mul_elem/bf16xbf16_mul_elem-llvm-scalar.mlir
test/unit_tests/aievec_tests/aie2/bf16xbf16_mul_elem_2/bf16xbf16_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/floatxfloat_mul_elem/floatxfloat_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/floatxfloat_mul_elem/floatxfloat_mul_elem-llvm-scalar.mlir
test/unit_tests/aievec_tests/aie2/i16_max_reduce/i16_max_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/i16_min_reduce/i16_min_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/i16xi16_max_elem/i16xi16_max_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i16xi16_min_elem/i16xi16_min_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i16xi16_mul_elem/i16xi16_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i16xi16_mul_elem/i16xi16_mul_elem-llvm-scalar.mlir
test/unit_tests/aievec_tests/aie2/i16xi16_mul_elem_2/i16xi16_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i16xi16_mul_elem_2/i16xi16_mul_elem-llvm-scalar.mlir
test/unit_tests/aievec_tests/aie2/i32_max_reduce/i32_max_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/i32_min_reduce/i32_min_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/i32xi32_max_elem/i32xi32_max_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i32xi32_min_elem/i32xi32_min_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i32xi32_mul_elem/i32xi32_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i32xi32_mul_elem/i32xi32_mul_elem-llvm-scalar.mlir
test/unit_tests/aievec_tests/aie2/i8_max_reduce/i8_max_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/i8_min_reduce/i8_min_reduce-llvm.mlir
test/unit_tests/aievec_tests/aie2/i8xi8_max_elem/i8xi8_max_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i8xi8_min_elem/i8xi8_min_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i8xi8_mul_elem/i8xi8_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i8xi8_mul_elem/i8xi8_mul_elem-llvm-scalar.mlir
test/unit_tests/aievec_tests/aie2/i8xi8_mul_elem_2/i8xi8_mul_elem-llvm.mlir
test/unit_tests/aievec_tests/aie2/i8xi8_mul_elem_2/i8xi8_mul_elem-llvm-scalar.mlir

Closes when: an open simulator covers these paths, or the aievec group is retired on its own
merits. Not tracked by anything today.

2. bfp16 block_datatypes examples (11)

Blocked on one Peano bug. The AIE2P backend aborts the legalizer on a <8 x s8> G_BUILD_VECTOR
coming out of matmul_vectorized_bfp16, so these cannot build with Peano at all.

Fix is open as Xilinx/llvm-aie#1184 ([AIE2P][AIE2PS] Legalize the 64-bit bfp16 block-exponent G_BUILD_VECTOR, fixes Xilinx/llvm-aie#995).

11 files

programming_examples/ml/block_datatypes/gemm_asymmetric_tile_buffering/config1/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/gemm_asymmetric_tile_buffering/config2/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/gemm_asymmetric_tile_buffering/config3/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/in_core_shuffle/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/single_core/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/single_core_mixed/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/single_core_no_tiling/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/single_core_no_tiling_mixed/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/whole_array/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/whole_array_mixed/run_strix_makefile_chess.lit
programming_examples/ml/block_datatypes/matrix_multiplication/whole_array_shuffle/run_strix_makefile_chess.lit

Closes when: llvm-aie#1184 merges and the Peano pin here advances past it. This is the one group
with a live upstream dependency, and the one most likely to be forgotten once that PR lands. I will
convert these when the pin moves.

3. Tests whose subject is the Chess path (9)

These exist to exercise Chess. Converting them would delete coverage rather than move it, so they stay
indefinitely.

• test/aiecc/cpp_xchesscc_basic.mlir, cpp_xchesscc_compile_only.mlir, cpp_xchesscc_multi_core.mlir
  test the xchesscc C++ path itself.
• test/aiecc/simple.mlir, simple_aie2.mlir, simple_xclbin.mlir, generate_pdi.mlir FileCheck both
  backends side by side in one file (--check-prefix=XCHESSCC and --check-prefix=PEANO).
• test/generate-mmap/allocation_error_chess.mlir checks the Chess-specific allocation diagnostic.
• test/unit_tests/chess_compiler_tests_aie2/00_itsalive/aie.mlir runs all four unified/xchesscc
  combinations.

Closes when: never, unless Chess support is dropped outright.

4. Peano feature gaps found on device (3)

I moved these to Peano in this branch and the device job caught them, so they went back to Chess with a
TODO in place. Each is a specific missing piece in Peano, not a property of the test.

• test/npu-xrt/cascade_flows/run.lit and test/npu-xrt/matrix_multiplication_using_cascade/run.lit
  call upd_elem and ext_elem. Peano defines those only for aie2p, in
  lib/clang/*/include/aie2p/aie2p_scl2vec.h. There is no aie2 definition, so the object compiles and
  the link fails with undefined symbol: upd_elem(int vector[32], int, int).
• test/npu-xrt/tile_mapped_read/run.lit pins its probe variable at the tile-mapped base with
  chess_storage(TM : 0x80000) to read the lock registers. Peano defines chess_storage(...) as an
  empty macro in aiebase_chess.h, so the address is dropped, the variable lands wherever the linker
  puts it, and the test reads unrelated memory. This one builds and links clean and is wrong only on
  device.

Closes when: Peano gains aie2 upd_elem/ext_elem, and an absolute-placement mechanism equivalent
to chess_storage(TM : addr). Both are small, well-scoped Peano changes. The second cannot be validated
by building, it has to be checked on hardware.

Note on the numbers in #3451

The PR description was written before the last commit and says 73 remaining and 38 moved. After
7936ffd put those three back on Chess it is 76 remaining and 35 moved. The three-way split of the
original 73 in that description is still correct.

[FIM43-Redeye]

I am working VERY HARD on an open equivalent to aiesimulator and would gladly integrate it into mlir-aie but it's in Rust and may be far too large. I've also been working primarily from probing the real hardware with no ability to reverse-engineer aiesimulator, so accuracy is no guarantee, but I'd really like to help with this where possible.

[atassis]

@FIM43-Redeye Hi there! I haven't thoroughly checked ur project, but it looks like a decent work! I'll admit that independent Rust app might not be the most convenient way to integrate simulator (IMHO), but from other points of view your work looks interesting and promising! I have partially implemented a simulator already, but I was testing it against a newer AMD NPU. What do you think about thinking how we can all benefit from current situation and make a simulator which does well against both current versions of a hardware? You can have a look at these mlir-aie llvm-aie branches.
My main reasoning is to keep as least amount of repositories as possible, and to reuse ideas which create the least amount of friction during development cycles. I was also thinking about starting this project in Rust (most of my latest opensource projects use Rust), but this is another language, toolchain, etc etc, it creates another thing to worry about. If you have any suggestions, ideas- I am glad to hear them.
I had no idea someone was implementing the simulator for last 8 months!

[atassis]

Besides the common points why simulator is needed, another big concern to do an integrated simulator is a Vitis (Chess) dependency. As I understand, you had to reimplement some parts of a toolchain, which makes it harder to support your version of a simulator, and versioning is already creating friction for maintainers (again, IMHO, but still)

[FIM43-Redeye]

No worries, I totally get it! Yeah, this project has been a hobby thing which has also been limited by only having access to NPU1 until recently. I'm also very shy about making LARGE contributions to any of these project, hence building the sim in isolation. My sim is also trying to model the management processor and such, along with being truly cycle-accurate.

If maintainers would be happy with having a simulator in mlir-aie and llvm-aie, I'd be happy to put it directly there, but the complexity of such a thing also implies enormous PRs, doesn't it? I'm new to software engineering (highly unconventional path) so I'm cautious.

[FIM43-Redeye]

Thanks for the branches, by the way, super helpful! I compared their interfaces with xdna-emu’s architecture, and to me the efforts look complementary rather than mutually exclusive.

The seven ess_* functions are the obvious integration point. xdna-emu already has the underlying primitives: a flat register bus, tile memory, global memory, and whole-array stepping. I’ve also used this same symbol seam to drive aie-rt’s SIM backend in a separate validation bridge. It should be possible to expose xdna-emu through a compatibility library without modifying aie-rt or moving the Rust implementation into mlir-aie.

One Phoenix topology detail is worth noting: mlir-aie’s npu1 model exposes four logical application columns, while xdna-emu models all five physical columns. I intentionally retain physical column 0 because it exists and matters for low-level research, but it has no shim tile and its remaining tiles are DPU-reserved—it is not an ordinary application column. The compatibility layer would map logical columns 0–3 onto physical columns 1–4. That should be a straightforward logical-to-physical translation.

One meaningful distinction in the current aie_iss contract is that structural-hazard waits advance the ISS’s internal core clock by multiple cycles within one step() call, after which the call returns RETIRED. The array model treats that whole call as a single fabric cycle. That makes sense for the RFC’s current functional-testing goal, but it would collapse core time relative to DMA, locks, streams, and memory arbitration if used as xdna-emu’s cycle-accurate core boundary. The current ISS implementation is also AIE2P-only. Neither point should block the simulator you’re building, but a future timing-preserving ABI would probably need one externally observable core cycle per step—or an equivalent explicit scheduling contract—and a way for mapped memory to report temporary backpressure rather than a fault.

I had an interoperability-proof idea, if you’re interested:

1. an optional/selectable simulator library in aiecc --get-sim, instead of always linking the in-tree libaie-sim;
2. a shared ABI-level conformance test for the seven ess_* symbols; and
3. one existing NPU1 00_itsalive design running through xdna-emu.

I definitely don’t want xdna-emu to become a required dependency of mlir-aie. It's my hobby/proving-ground project, and my obsessive focus on NPU1 is deliberate- I've got hardware right now, but said hardware is dying while also being the mainboard in my Framework, so I'm gonna swap my 7940HS for an HX 370 soon. I’m trying to preserve NPU1 behavior while it can still be measured directly, but it's kind of urgent, the iGPU has started randomly wedging under any 3D load whatsoever. Not pleasant.

Chess’s aiesimulator is very specifically oriented around Versal, it was never designed for this application of XDNA. It's got lots of FPGA widgets and it's perfect for emulating the AIE portion of a Versal chip, but it doesn't model the management processor or any of the peculiarities of the NPU. That leaves full-system timing and lifecycle behavior outside its scope, which is why timing accuracy matters so much for xdna-emu.

Either way, I agree that the in-tree C++ simulator should remain the default. A small interface allowing external simulators to plug in—xdna-emu today, ideally other or directly AMD-maintained implementations eventually—seems ideal to me. If that sounds useful, I’ll put together a prototype. What do you think?