xilinx / mlir-aie Goto Github PK

An MLIR-based toolchain for AMD AI Engine-enabled devices.

License: Other

CMake 1.66% C++ 31.11% MLIR 49.41% Python 13.54% HTML 0.05% Shell 0.37% Makefile 1.05% C 0.71% BitBake 0.06% Tcl 1.58% Jupyter Notebook 0.45%

llvm mlir

mlir-aie's Introduction

MLIR-based AI Engine toolchain

This repository contains an MLIR-based toolchain for AI Engine-enabled devices, such as AMD Ryzen™ AI and Versal™. This repository can be used to generate low-level configurations for the AI Engine portion of these devices. AI Engines are organized as a spatial array of tiles, where each tile contains AI Engine cores and/or memories. The spatial array is connected by stream switches that can be configured to route data between AI Engine tiles scheduled by their programmable Data Movement Accelerators (DMAs). This repository contains MLIR representations, with multiple levels of abstraction, to target AI Engine devices. This enables compilers and developers to program AI Engine cores, as well as describe data movements and array connectivity. A Python API is made available as a convenient interface for generating MLIR design descriptions. Backend code generation is also included, targeting the aie-rt library. This toolchain uses the AI Engine compiler tool which is part of the AMD Vitis™ software installation: these tools require a free license for use from the Product Licensing Site.

This project is primarily intended to support the open-source community, particularly tool builders, with low-level access to AIE devices and enable the development of a wide variety of programming models from higher level abstractions. We provide an example programming flow: Interface Representation for hands-ON (IRON) close-to-metal programming of the AIE-array. IRON is an open access toolkit enabling performance engineers to build fast and efficient, often specialized designs through a set of Python language bindings around the mlir-aie dialect. As such, it contains some examples, however this project is not intended to represent an end-to-end compilation flow for all application designs. If you're looking for an out-of-the-box experience for highly efficient machine learning, check out the AMD Ryzen™ AI Software Platform.

Getting Started on a Versal™ board

Running on a Versal™ board

Getting Started and Running on Windows Ryzen™ AI

Getting Started and Running on Linux Ryzen™ AI

IRON AIE Application Programming Guide

MLIR Dialect and Compiler Documentation

mlir-aie's People

Contributors

Stargazers

Watchers

mlir-aie's Issues

opt: unrecognized architecture 'aie' provided.

I was trying to build the toolchain. My goal was to generate some executables, but some test cases didn't pass check-aie. The following are some parts of the outputs when executing 'ninja check-aie'.

The summary from 'ninja check-aie' using aiengine:

  Unsupported:  14
  Passed     : 118
  Failed     :  25

The summary from 'ninja check-aie' using aienginev2:

  Unsupported:  14
  Passed     : 127
  Failed     :  25

Both aiengine and aienginev2 had the same issue:

Command Output (stdout):
--
Error encountered while running: opt -O2 -strip -S acdc_project/core_1_3.ll -o acdc_project/core_1_3.stripped.ll

--
Command Output (stderr):
--
opt: unrecognized architecture 'aie' provided.

--

The issue might be caused by a line in acdc_project/core_1_3.ll:

target triple = "aie"

The result I got was similar to this.

According to the link above, I think the issue may come from building LibXAIE. The building method I tried might be wrong since I built both aiengine and aienginev2 by running Makefile.Linux and Makefile. If this is true, I would like to have documentation about building these things. It may also help others since somebody also faced the building issue in the link above.

Since the file passed to opt has specified aie target, but The LLVM with specified commithash doesn't have aie target, I think the issue may also come from somewhere that isn't in the documentation. Maybe it modifies LLVM to support aie target, or some conversions were done before opt, or something I don't know.

Remove PATH modifications from aiecc.py

#116 workarounds the PATH modification but remains a dirty fix. aiecc.py should refrain from modifying the PATH entirely, or scope PATH modification to a few commands that require such changes.

Add better documentation for command line routing visualization

Add extra "--help" documentation to the simple routing documentation in tools/aie-routing-command-line
Add a readme file as further documentation with screenshots to explain what the output means
Rename the tool from "print.py" to "visualize.py"

Enable mlir-aie to aiesimulator flow

There is an aiecompiler to aiesimulator flow in Vitis. I would like to know if there is a way to replace aiecompiler with mlir-aie, i.e., having a mlir-aie to aiesimulator flow.

[RoutePacketFlow] Issue when merging packet rules

Hi, I'm trying to route a GEMM design with 40 AIEs using the -create-packet-flows pass, but encountered some issue there.

I dig a little and found it may be caused by the packet rules merging. See the test case below, both packet0 and packet1 from West0 should be connected to Core0 and they are merged into the same packet rule. Based on my understanding, the correct packet rule should be AIE.rule(30, 0, %2) rather than AIE.rule(30, 1, %2) in order to match both packet0 and packet1.

From:

mlir-aie/test/create-packet-flows/test_create_packet_flows5.mlir

Lines 31 to 44 in 9fe6023

  AIE.packet_flow(0x0) { 

  AIE.packet_source<%t11, West : 0> 

  AIE.packet_dest<%t11, Core : 0> 

 } 

  AIE.packet_flow(0x1) { 

  AIE.packet_source<%t11, West : 0> 

  AIE.packet_dest<%t11, Core : 0> 

 } 

  AIE.packet_flow(0x2) { 

  AIE.packet_source<%t11, West : 1> 

  AIE.packet_dest<%t11, Core : 0> 

 }

To:

mlir-aie/test/create-packet-flows/test_create_packet_flows5.mlir

Lines 15 to 24 in 9fe6023

 // CHECK: %1 = AIE.switchbox(%0) { 

 // CHECK: %2 = AIE.amsel<0> (0) 

 // CHECK: %3 = AIE.masterset(Core : 0, %2) 

 // CHECK: AIE.packetrules(West : 1) { 

 // CHECK: AIE.rule(31, 2, %2) 

 // CHECK: } 

 // CHECK: AIE.packetrules(West : 0) { 

 // CHECK: AIE.rule(30, 1, %2) 

 // CHECK: } 

 // CHECK: }

To verify this observation, I disabled the packet rules merging in RoutePacketFlow, which means the test case above is transformed to:

AIE.packetrules(West : 0) { 
  AIE.rule(31, 0, %2)
  AIE.rule(31, 1, %2) 
}

And it works on some small test cases (for example, a scale-down GEMM design with 8 AIEs)!

Then, I tried the modified pass on my original GEMM design, unfortunately, the design still doesn't work - it stalls somewhere due to incorrect streaming. Note that the same GEMM design routed with circuit-mode works correctly on board.

I attached two versions of designs for your reference, the first is connected through FlowOp - it works after -create-pathfinder-flows pass, and the second one is connected through PacketFlowOp - it doesn't work even with the modified -create-packet-flows pass.

Hanchen

tmp-circuit.mlir.txt
tmp-packet.mlir.txt

Add support for VCK5000 over PCIe

I only have a VCK5000 board but you built and test the project on VCK190. Will it work correctly if I follow your workflow on VCK5000?

What is /usr/local/flexlm/licenses/license.dat?

When I run mlir-aie/test/unit_tests/aievec_tests/, with following error

(py38) ➜  aievec_tests xchesscc -f -g +s -p me -P ${XILINX_VITIS}/aietools/data/aie_ml/lib/ +w work +o work -I. -I. testbench.cc kernel.cc 
Configuration: Release_LLVM
Compiling "testbench.cc"
chess-clang -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib --chess-proc-dir=/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib -S -nostdlibinc -D__chess__ -D__tct_release__=2103 -g -I. -I. -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib/runtime_cxx/libcxx-lite/include -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib/runtime_cxx/libs/libcxx-9.0.0/include-lite -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib/runtime/include -I/data/Xilinx/Vitis/2021.2/aietools/tps/boost_1_64_0 -xc++ -O2 -include aie_core.h -std=c++2a -fno-builtin-memcpy -mllvm -disable-lsr -mllvm -replexitval=never -mllvm -enable-load-pre=false -mllvm -chess-disable-add-to-or -mllvm -chess-combine-gep-indices=none -mllvm -chess-disable-fold-phi-of-loads -mllvm -chess-aainfo2chains-algo=4 -mllvm -chess-aggressive-aainfo=false -mllvm -chess-enable-indvarsimplify=0 -mllvm -chess-disable-cse-across-loopboundary -mllvm -chess-tbaa-detect-common-underlying-object=true testbench.cc -owork/testbench.sfg --chess-proc-name=me
ERROR: License check out failed (nowait)
Cannot find license file.
 The license files (or license server system network addresses) attempted are 
listed below.  Use LM_LICENSE_FILE to use a different license file,
 or contact your software provider for a license file.
Feature:       tct_chess_ipp
License path:  /usr/local/flexlm/licenses/license.dat:
FlexNet Licensing error:-1,234.  System Error: 2 "No such file or directory"
Compiling "kernel.cc"
chess-clang -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib --chess-proc-dir=/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib -S -nostdlibinc -D__chess__ -D__tct_release__=2103 -g -I. -I. -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib/runtime_cxx/libcxx-lite/include -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib/runtime_cxx/libs/libcxx-9.0.0/include-lite -I/data/Xilinx/Vitis/2021.2/aietools/data/aie_ml/lib/runtime/include -I/data/Xilinx/Vitis/2021.2/aietools/tps/boost_1_64_0 -xc++ -O2 -include aie_core.h -std=c++2a -fno-builtin-memcpy -mllvm -disable-lsr -mllvm -replexitval=never -mllvm -enable-load-pre=false -mllvm -chess-disable-add-to-or -mllvm -chess-combine-gep-indices=none -mllvm -chess-disable-fold-phi-of-loads -mllvm -chess-aainfo2chains-algo=4 -mllvm -chess-aggressive-aainfo=false -mllvm -chess-enable-indvarsimplify=0 -mllvm -chess-disable-cse-across-loopboundary -mllvm -chess-tbaa-detect-common-underlying-object=true kernel.cc -owork/kernel.sfg --chess-proc-name=me
ERROR: License check out failed (nowait)
Cannot find license file.
 The license files (or license server system network addresses) attempted are 
listed below.  Use LM_LICENSE_FILE to use a different license file,
 or contact your software provider for a license file.
Feature:       tct_chess_ipp
License path:  /usr/local/flexlm/licenses/license.dat:
FlexNet Licensing error:-1,234.  System Error: 2 "No such file or directory"
Compilation not finished (2 errors, 0 warnings)
xchesscc Failed No such device
The Program xchesscc has encountered an unexpected error exiting ... xchesscc Failed No such device
/data/Xilinx//Vitis/2021.2/aietools/bin/xchesscc: line 58: kill: (-14164) - No such process

What is /usr/local/flexlm/licenses/license.dat, and where I can find this license?

-aie-lower-memcpy generates illegal AIE.mem operation

In test/create-cores/test_dma1.mlir, -aie-lower-memcpy convert

  AIE.memcpy @token0(1, 2) (%t11 : <%buf0, 0, 256>, %t22 : <%buf1, 0, 256>) : (memref<256xi32>, memref<256xi32>)
  AIE.memcpy @token1(1, 2) (%t11 : <%buf0, 0, 256>, %t33 : <%buf2, 0, 256>) : (memref<256xi32>, memref<256xi32>)

to (only shows the %t11 side)

  %2 = AIE.mem(%0) {
    %15 = AIE.dmaStart(MM2S0, ^bb1, ^bb4)
    ^bb1:
      AIE.useToken @token0(Acquire, 1)
      AIE.dmaBd(<%1 : memref<256xi32>, 0, 256>, 0)
      AIE.useToken @token0(Release, 2)
      br ^bb4
    ^bb2:
    %16 = AIE.dmaStart(MM2S0, ^bb3, ^bb4)
    ^bb3:
      AIE.useToken @token1(Acquire, 1)
      AIE.dmaBd(<%1 : memref<256xi32>, 0, 256>, 0)
      AIE.useToken @token1(Release, 2)
      br ^bb4
    ^bb4:
      AIE.end
  }

It seems there are two issues here:

^bb2 is unachievable. I think if these two DMAs are chained together, %15 = AIE.dmaStart(MM2S0, ^bb1, ^bb4) should point to ^bb2 rather than ^bb4?
Reuse of MM2S0 channel is marked as illegal in the verification. Who is wrong?

Two related question about the rationale of AIE.mem:

I noticed there are two DMA channels available, if these two DMAs can be mapped to two channels, should the IR looks like this?

  %2 = AIE.mem(%0) {
    %15 = AIE.dmaStart(MM2S0, ^bb1, ^bb3)
    %16 = AIE.dmaStart(MM2S1, ^bb2, ^bb3)
    ^bb1:
      AIE.useToken @token0(Acquire, 1)
      AIE.dmaBd(<%1 : memref<256xi32>, 0, 256>, 0)
      AIE.useToken @token0(Release, 2)
      br ^bb1
    ^bb2:
      AIE.useToken @token1(Acquire, 1)
      AIE.dmaBd(<%1 : memref<256xi32>, 0, 256>, 0)
      AIE.useToken @token1(Release, 2)
      br ^bb2
    ^bb3:
      AIE.end
  }

What is the semantics of the terminator of "bdBlock"? Could it point to a "dmaBlock"? Because I feel if so the semantics is kind of overlapping with the chain successor of AIE.dmaStart 🤔

I'll be happy to update and fix the -aie-lower-memcpy pass once I have a better understanding on the semantics of AIE.mem!

Hanchen

Add logical model of locks

Currently locks are accessed absolutely, i.e. with a specific tile location and lock number. In addition, host code has explicit libXAIE calls. We should create a local model for locks that is similar to the logical model of buffers and generate the actual lock locations through an allocation algorithm.

Error during 12_julia and 13_julia_fp tests (Ubuntu 18.04 and gcc 7.5.0)

The error is:
error: unknown target triple 'aie', please use -triple or -arch

About vck190 boot from sd card?

I build aie_platform successfully. And I copy mlir-aie/platforms/vck190_bare_prod/aie_platform/sd_dir files to sd card of fat32 format. But do not boot successfully. Do I left something or ?

Device specific variables: Refactor to separate device, platform, and board information

Make aie-vectorize robust to unimplementable vector sizes

Currently the vectorizer will simply assert if an incompatible vector size is created with the super-vectorizer.

platforms/vck190_base build generates results in source directory

This needs to get moved to a proper build location.

Develop method to detect loops in routing

When detecting routing errors, there are cases where loops might be present. Develop a method for detecting these loops along the routing path.

Pathfinder: routing to or from a shim tile without a NOC connection leads to assertion

Assertion leads to core dump instead of providing hints for debugging. Should change assertion to error message for clarity.

On VCK5000, when I run unit_tests/01_memory_read_write unit test, find these errors

When I run unit_tests/01_memory_read_write unit test, find these errors

>>> python aiecc.py --sysroot=/ --aie-generate-xaiev2 ~/work/new-aie/mlir-aie/test/unit_tests/01_memory_read_write/aie.mlir -I/home/lay/work/new-aie/mlir-aie/runtime_lib /home/lay/work/new-aie/mlir-aie/runtime_lib/test_library.cpp ~/work/new-aie/mlir-aie/test/unit_tests/01_memory_read_write/test.cpp -o test.elf
>>> ./test.elf
....
MW: 0x20000072000, 0x2, 0x0
MW: 0x20000072008, 0x8080, 0x8000
MW: 0x20000072000, 0x1, 0x1
MW: 0x200000b2000, 0x2, 0x0
MW: 0x200000b2008, 0x8080, 0x8000
MW: 0x200000b2000, 0x1, 0x1
MW: 0x200000f2000, 0x2, 0x0
MW: 0x200000f2008, 0x8080, 0x8000
MW: 0x200000f2000, 0x1, 0x1
MW: 0x20000872000, 0x2, 0x0
MW: 0x20000872008, 0x8080, 0x8000
MW: 0x20000872000, 0x1, 0x1
MW: 0x200008b2000, 0x2, 0x0
MW: 0x200008b2008, 0x8080, 0x8000
MW: 0x200008b2000, 0x1, 0x1
R: 0x200008c100c, 0x0
R: 0x200008c100c, 0x0
ERROR After memory writes. Check [3]=14: mlir_aie_read_buffer_a(_xaie, 3) expected 14, but was 0!
R: 0x200008c1014, 0x0
R: 0x200008c1014, 0x0
ERROR After memory writes. Check [3]=14: mlir_aie_read_buffer_a(_xaie, 5) expected 8, but was 0!
R: 0x200008c1024, 0x0
R: 0x200008c1024, 0x0
ERROR After memory writes. Check [3]=14: mlir_aie_read_buffer_a(_xaie, 9) expected 14, but was 0!
Fail!
test done.

How to debug this problem?

Create model for device relocation

Currently, we target a device where Tile 0,0 is always in the lower left corner of the device. However, in many cases we want to implement code onto a portion of the device and generate code that is relocatable/replicatable to different locations on the device. One challenge with this is that relocatability is likely only possible vertically every two rows (because of the asymmetric nature of the cascade chains). This will involve identifying the places in the existing codebase where we assume mapping to a specific device. Note that libXAIEv2 supports a model of relocation that this could target.

cmake errer when building on X86

When I set up AIE tools according to the following steps https://xilinx.github.io/mlir-aie/Building.html) I encountered the following problems。

How to solve it？
Thanks!

Board crashes when running the generated executable (SError Interrupt on CPU0, code 0xbf000002)

Hi,

Thanks for the help on previous issues! I've been able to generate an elf executable on my local test case :D However, I encountered an issue when running this executable on board. To locate the issue, I reduced my main function of the host to:

int main(int argc, char *argv[]) {
  printf("----------\nTest start.\n----------\n");

  size_t aie_base = XAIE_ADDR_ARRAY_OFF << 14;
  XAIEGBL_HWCFG_SET_CONFIG((&AieConfig), XAIE_NUM_ROWS, XAIE_NUM_COLS,
                           XAIE_ADDR_ARRAY_OFF);
  XAieGbl_HwInit(&AieConfig);
  AieConfigPtr = XAieGbl_LookupConfig(XPAR_AIE_DEVICE_ID);
  XAieGbl_CfgInitialize(&AieInst, &TileInst[0][0], AieConfigPtr);

  printf("----------\nmlir_configure_cores\n----------\n");
  mlir_configure_cores();

  printf("----------\nTest done.\n----------\n");
}

The terminal outputs the following information and hangs there:

root@vck190_linux:/mnt/sd-mmcblk0p1# ./2mm_test_why.elf
----------
Test start.
----------
metal: info:      Registered shmem provider linux_shm.
metal: info:      Registered shmem provider ion.reserved.
metal: info:      Registered shmem provider ion.ion_system_contig_heap.
metal: info:      Registered shmem provider ion.ion_system_heap.
metal: info:      device [   81.213475] SError Interrupt on CPU0, code 0xbf000002 -- SError
[   81.213478] CPU: 0 PID: 612 Comm: 2mm_test_why.el Tainted: G           O      5.4.0-xilinx-v2020.1 #1
[   81.213479] Hardware name: Xilinx Versal vck190 Eval board revA (DT)
[   81.213481] pstate: 60000000 (nZCv daif -PAN -UAO)
[   81.213482] pc : 0000007fa4c3c914
[   81.213483] lr : 0000007fa4dbf930
[   81.213484] sp : 0000007ffaa06160
[   81.213485] x29: 0000007ffaa06160 x28: 0000007ffaa06230
[   81.213488] x27: 0000007ffaa0622c x26: 0000007ffaa06234
[   81.213491] x25: 0000000000000004 x24: 0000000000000004
[   81.213494] x23: 00000000000000a0 x22: 0000007ffaa071c8
[   81.213497] x21: 0000007ffaa06228 x20: 0000000000000000
[   81.213500] x19: 000000000916d2b0 x18: 0000000000000000
[   81.213503] x17: 0000007fa4c3c910 x16: 0000007fa4dd6cc0
[   81.213506] x15: 0000000000000030 x14: 0000000000000022
[   81.213508] x13: 0000080000000000 x12: 0000000000000000
[   81.213511] x11: 0000000000000000 x10: 0000000000000000
[   81.213514] x9 : 0000000000000000 x8 : 0000000000000008
[   81.213516] x7 : 0000000000000000 x6 : 0000000000000001
[   81.213519] x5 : 0000000000000000 x4 : 000000000916dcb8
[   81.213522] x3 : 0000007ea0000000 x2 : 0000007fa4d26000
[   81.213524] x1 : 0000007ea0800420 x0 : 000000000917a090
[   81.213528] Kernel panic - not syncing: Asynchronous SError Interrupt
[   81.213530] CPU: 0 PID: 612 Comm: 2mm_test_why.el Tainted: G           O      5.4.0-xilinx-v2020.1 #1
[   81.213531] Hardware name: Xilinx Versal vck190 Eval board revA (DT)
[   81.213532] Call trace:
[   81.213533]  dump_backtrace+0x0/0x140
[   81.213535]  show_stack+0x14/0x20
[   81.213536]  dump_stack+0xac/0xd0
[   81.213537]  panic+0x140/0x2f8
[   81.213538]  __stack_chk_fail+0x0/0x18
[   81.213539]  arm64_serror_panic+0x74/0x80
[   81.213540]  do_serror+0x114/0x118
[   81.213541]  el0_error_naked+0x14/0x1c
[   81.213553] SMP: stopping secondary CPUs
[   81.213554] Kernel Offset: disabled
[   81.213556] CPU features: 0x0002,21006008
[   81.213557] Memory Limit: none

Note that the printf("----------\nmlir_configure_cores\n----------\n"); before mlir_configure_cores(); seems not be executed. It looks the ARM CPU is incorrectly interrupted by an unknown source.

Interestingly, I'm almost sure that the issue is somehow caused by mlir_configure_cores();, because the code runs well if I comment out mlir_configure_cores();:

root@vck190_linux:/mnt/sd-mmcblk0p1# ./2mm_test.elf
----------
Test start.
----------
metal: info:      Registered shmem provider linux_shm.
metal: info:      Registered shmem provider ion.reserved.
metal: info:      Registered shmem provider ion.ion_system_contig_heap.
metal: info:      Registered shmem provider ion.ion_system_heap.
metal: info:      device xilinx-aiengine in use by driver uio_dmem_genirq
metal: info:      metal_uio_dev_open: No IRQ for device f70a0000.aie-npi.
----------
mlir_configure_cores
----------
----------
Test done.
----------

Has anyone ever encountered this before? Just FYI, in this particular test case, the original program is mapped to 35 AIE cores: (1-16,1), (1-16, 2), and (1-3, 3).

Thanks,
Hanchen

Chess compiler doesn't handle memref.alloc with alignment

mnist.mlir file in https://gist.github.com/HadXu/8987a2bca3e2a6400cc8c533b6d132c2

And this mlir can run with mlir-runner with success.

(py38) ➜  mnist-mlir mlir-opt mnist.mlir --lower-affine -convert-scf-to-cf -convert-linalg-to-llvm -convert-memref-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts | mlir-cpu-runner -O3 -e entry -entry-point-result=void -shared-libs=/home/lay/work/llvm-study/llvm-project/build/lib/libmlir_runner_utils.so
Unranked Memref base@ = 0x5586bc4f8900 rank = 2 offset = 0 sizes = [1, 10] strides = [10, 1] data = 
[[84.3589,   -71.8258,   -2.66961,   -23.2588,   -22.6759,   9.23774,   18.8853,   -13.7729,   -2.07476,   0.823274]]

And I want to this file can run on vck190 with mlir-aie, but with build error

Found Vitis at /data/Xilinx/Vitis/2021.2
chess-clang: warning: argument unused during compilation: '-I /data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib' [-Wunused-command-line-argument]
chess-clang: warning: argument unused during compilation: '-I /data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libcxx-lite/include' [-Wunused-command-line-argument]
chess-clang: warning: argument unused during compilation: '-I /data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include-lite' [-Wunused-command-line-argument]
chess-clang: warning: argument unused during compilation: '-I /data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime/include' [-Wunused-command-line-argument]
chess-clang: warning: argument unused during compilation: '-include aie_core.h' [-Wunused-command-line-argument]
warning: overriding the module target triple with pdarch-unknown-unknown-elf [-Woverride-module]
1 warning generated.
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9269, column 13: loop count of type `unsigned long long' is converted to `w32' via `int', the first stage of which is non-nil
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 19963, column 14: loop count of type `unsigned long long' is converted to `w32' via `int', the first stage of which is non-nil
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9219, column 13: (approximate): uninitialized variable `__tmp' is used (unconditionally) by `r_update_dint_low (internal)'   (sig .67061 used by opn <90477> in arg 1)
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9339, column 13: (approximate): uninitialized variable `__tmp' is used (unconditionally) by `r_update_dint_low (internal)'   (sig .67210 used by opn <90668> in arg 1)
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (approximate): uninitialized variable `__tmp' is used (unconditionally) by `r_update_dint_low (internal)'   (sig .67255 used by opn <90721> in arg 1)
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 19913, column 14: (approximate): uninitialized variable `__tmp' is used (unconditionally) by `r_update_dint_low (internal)'   (sig .67585 used by opn <91129> in arg 1)
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20034, column 14: (approximate): uninitialized variable `__tmp' is used (unconditionally) by `r_update_dint_low (internal)'   (sig .67734 used by opn <91320> in arg 1)
Warning in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20082, column 14: (approximate): uninitialized variable `__tmp' is used (unconditionally) by `r_update_dint_low (internal)'   (sig .67779 used by opn <91373> in arg 1)
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9216, column 13: undefined operation `operator void *(unsigned long long)' <50701> remaining after optimisation, used by:
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (approximate): ... 2nd argument of `entry (internal)' <75486>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9339, column 13: undefined operation `operator void *(unsigned long long)' <50833> remaining after optimisation, used by:
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (approximate): ... 2nd argument of `entry (internal)' <75562>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9447, column 13: ... 1st argument of `void *add(void *, amod)' <91039>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9447, column 13: ... 1st argument of `void *add(void *, amod)' <91080>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9447, column 13: ... 1st argument of `void *add(void *, amod)' <93427>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 9387, column 13: undefined operation `operator void *(unsigned long long)' <50878> remaining after optimisation, used by:
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (approximate): ... 2nd argument of `entry (internal)' <75661>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 19952, column 5: (approximate): ... 1st argument of `void *add(void *, amod)' <92161>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 19912, column 14: undefined operation `operator void *(unsigned long long)' <51060> remaining after optimisation, used by:
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (approximate): ... 2nd argument of `entry (internal)' <75874>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20034, column 14: undefined operation `operator void *(unsigned long long)' <51174> remaining after optimisation, used by:
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (approximate): ... 2nd argument of `entry (internal)' <76081>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20082, column 14: undefined operation `operator void *(unsigned long long)' <51414> remaining after optimisation, used by:
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (approximate): ... 2nd argument of `entry (internal)' <76823>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91405>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91412>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91419>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91426>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91433>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91440>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91447>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91454>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91461>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91468>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91475>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91482>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91489>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91496>
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 20161, column 14: ... 1st argument of `void *add(void *, amod)' <91503>
Error: 
... conversions to built-in types (even when not represented) may be due to a unique, but inappropriate, C++ matching, e.g.,
... t @ i ...becoming... t @ (T)(double)i ...
Error in "/home/lay/work/aie-mlir-tutorial/demo/acdc_project/core_1_3.opt.mlir", line 15: (imprecise line-number, the error occurred somewhere in this function): variable __tmp (581) of unrepresented type `dint' remaining after optimisation

*** fatal error -- giving up
This error occurred while running: noodle -I/data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib -I/data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/isg -I/data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libcxx-lite/include -I/data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include-lite -I/data/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime/include +Oitm -iaie_core.h +Sinl +Olbb=200 +Opmsa +Olzyinl +wchesswork18104 chesswork18104/core_1_3.chesslinked.sfg +Q1=+Sinl,+Olbb=200,+Opmsa,+Olzyinl +Q2=+Sinl,+Olbb=200,+Opmsa,+Olzyinl +Q3=+Sinl,+Olbb=1000,+Opmsa,+Olzyinl +Qfast=+Sinl,+Olbb=1000,+Opmsa,+Olzyinl,+Opfp +Qs=+Sinl,+Olbb=200,+Opmsa,+Olzyinl +Qz=+Sinl,+Olbb=200,+Opmsa,+Olzyinl me
xchesscc Failed No such device
The Program xchesscc has encountered an unexpected error exiting ... xchesscc Failed No such device
Error encountered while running: xchesscc_wrapper -d -f +P 4 acdc_project/core_1_3.chesslinked.ll  +l acdc_project/core_1_3.bcf -o ./core_1_3.elf

how to debug this problems?

mlir_aie_mem_alloc assumes DWORDS

Tutorial 5 https://github.com/Xilinx/mlir-aie/blob/tutorial/tutorials/tutorial-5/test.cpp#L55-#L56 uses mlir_aie_mem_alloc to allocated memory in DRAM. It is implicitly assumed DWORDS (int) are being allocated, while malloc typically allocates bytes.

Due to AIE alignment restriction, we most likely need 32b (or maybe an even coarser alignment)?

In vck190, "make aie_platform_build" error?

Environment:

v++: Vitis/2021.2/bin/v++
petalinux: 2021.2

And make xsa petalinux_build petalinux_sysroot is successful.
make aie_platform_build error. Some info below.

...
Attempting to get a license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 17-349] Got license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 21-403] Loading part xcvc1902-vsva2197-2MP-e-S
INFO: [VPL 19-234] Refreshing IP repositories
INFO: [VPL 19-1700] Loaded user IP repository '/data/Xilinx/Vitis/2021.2/data/cache/xilinx'.
INFO: [VPL 19-1700] Loaded user IP repository '/home/lay/work/vck190/mlir-aie/platforms/vck190_bare_prod/aie_platform/_x/link/vivado/vpl/.local/hw_platform/ipcache'.
INFO: [VPL 19-1700] Loaded user IP repository '/data/Xilinx/Vitis/2021.2/data/ip'.
INFO: [VPL 19-2313] Loaded Vivado IP repository '/data/Xilinx/Vivado/2021.2/data/ip'.
Command: synth_design -top ext_platform_emb_mem_gen_0_0 -part xcvc1902-vsva2197-2MP-e-S -mode out_of_context
Starting synth_design
Attempting to get a license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 17-349] Got license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 21-403] Loading part xcvc1902-vsva2197-2MP-e-S
[08:53:39] Block-level synthesis in progress, 0 of 7 jobs complete, 7 jobs running.
INFO: [VPL 8-7079] Multithreading enabled for synth_design using a maximum of 1 processes.
INFO: [VPL 8-7078] Launching helper process for spawning children vivado processes
INFO: [VPL 8-7075] Helper process launched with PID 8179
Command: synth_design -top ext_platform_icn_ctrl_0 -part xcvc1902-vsva2197-2MP-e-S -mode out_of_context
Starting synth_design
Attempting to get a license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 17-349] Got license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 21-403] Loading part xcvc1902-vsva2197-2MP-e-S
INFO: [VPL 8-7079] Multithreading enabled for synth_design using a maximum of 1 processes.
INFO: [VPL 8-7078] Launching helper process for spawning children vivado processes
INFO: [VPL 8-7075] Helper process launched with PID 8183
INFO: [VPL 8-7079] Multithreading enabled for synth_design using a maximum of 1 processes.
INFO: [VPL 8-7078] Launching helper process for spawning children vivado processes
INFO: [VPL 8-7075] Helper process launched with PID 8184
Command: synth_design -top ext_platform_cips_noc_0 -part xcvc1902-vsva2197-2MP-e-S -mode out_of_context
Starting synth_design
Attempting to get a license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 17-349] Got license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 21-403] Loading part xcvc1902-vsva2197-2MP-e-S
INFO: [VPL 8-7079] Multithreading enabled for synth_design using a maximum of 1 processes.
INFO: [VPL 8-7078] Launching helper process for spawning children vivado processes
INFO: [VPL 8-7075] Helper process launched with PID 8178
Command: synth_design -top ext_platform_noc_ddr4_0 -part xcvc1902-vsva2197-2MP-e-S -mode out_of_context
Starting synth_design
Attempting to get a license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 17-349] Got license for feature 'Synthesis' and/or device 'xcvc1902'
INFO: [VPL 21-403] Loading part xcvc1902-vsva2197-2MP-e-S
INFO: [VPL 8-7079] Multithreading enabled for synth_design using a maximum of 1 processes.
INFO: [VPL 8-7078] Launching helper process for spawning children vivado processes
INFO: [VPL 8-7075] Helper process launched with PID 8182
INFO: [VPL 8-7079] Multithreading enabled for synth_design using a maximum of 1 processes.
INFO: [VPL 8-7078] Launching helper process for spawning children vivado processes
INFO: [VPL 8-7075] Helper process launched with PID 8181
INFO: [VPL 8-7079] Multithreading enabled for synth_design using a maximum of 1 processes.
INFO: [VPL 8-7078] Launching helper process for spawning children vivado processes
INFO: [VPL 8-7075] Helper process launched with PID 8180
[08:54:05] Block-level synthesis in progress, 0 of 7 jobs complete, 7 jobs running.
[08:54:05] Run vpl: FINISHED. Run Status: synth ERROR
WARNING: [VPL 60-732] Link warning: No monitor points found for BD automation.
ERROR: [VPL 60-1328] Vpl run 'vpl' failed
WARNING: [VPL 60-1142] Unable to read data from '/home/lay/work/vck190/mlir-aie/platforms/vck190_bare_prod/aie_platform/_x/link/vivado/vpl/output/generated_reports.log', generated reports will not be copied.
ERROR: [VPL 60-806] Failed to finish platform linker
INFO: [v++ 60-1442] [08:54:14] Run run_link: Step vpl: Failed
Time (s): cpu = 00:04:40 ; elapsed = 00:06:29 . Memory (MB): peak = 2071.855 ; gain = 0.000 ; free physical = 6885 ; free virtual = 8300
ERROR: [v++ 60-661] v++ link run 'run_link' failed
ERROR: [v++ 60-626] Kernel link failed to complete
ERROR: [v++ 60-703] Failed to finish linking
INFO: [v++ 60-1653] Closing dispatch client.
Makefile:164: recipe for target 'vck190_aie_base_graph_hw.xclbin' failed
make[1]: *** [vck190_aie_base_graph_hw.xclbin] Error 1
make[1]: Leaving directory '/home/lay/work/vck190/mlir-aie/platforms/vck190_bare_prod/aie_platform'
Makefile:39: recipe for target 'aie_platform_build' failed
make: *** [aie_platform_build] Error 2

Where should $VitisSysroot point to?

I assume it is $mypath/Xilinx/Vitis/2020.1, but it seems this is not the case?

remove magic register offsets from tests

These magic register values should get factored out somewhere, probably runtime_lib/test_library.cpp

Pathfinder: the example json file for visualization tool is obsolete

Currently the example json file included in tools/aie-routing-command-line/switchbox.json is obsolete, and it no longer works with the visualization tool tools/aie-routing-command-line/print.py.

Vectorized core's executable doesn't work in some cases

I was trying to vectorize AIE cores but found an issue when testing the executables on board. See the following 3 cores:

core(2, 2): works
core(9, 2): doesn't work
core(6, 2): works

Note that the only difference between the first and second cores is the loop iteration number -- the first core is 32*4, while the second core is 8*4. Interestingly, I tried to change the second core to 16*4, then it works!

So I thought the issue is related to the loop iteration number, but if we look at the third core, it works although it's also 8*4. I'm wondering whether I'm using the vector operations in a wrong way here.

I attached the MLIR code and host code for reference.

reduce.mlir.txt
reduce.host.cpp.txt

Thanks!
Hanchen

#map = affine_map<(d0) -> (d0 * 8)>
module @kernel_2mm  {
  %7 = AIE.tile(2, 2)
  %8 = AIE.lock(%7, 15)
  %9 = AIE.buffer(%7) {address = 4096 : i32, sym_name = "buf0"} : memref<32x32xf32>
  %10 = AIE.buffer(%7) {address = 8192 : i32, sym_name = "buf1"} : memref<f32>
  %11 = AIE.core(%7)  {
    %cst = constant 0.000000e+00 : f32
    %324 = affine.load %10[] : memref<f32>
    %325 = vector.broadcast %324 : f32 to vector<8xf32>
    affine.for %arg0 = 0 to 32 {
      affine.for %arg1 = 0 to 4 {
        %326 = affine.apply #map(%arg1)
        %327 = vector.transfer_read %9[%arg0, %326], %cst : memref<32x32xf32>, vector<8xf32>
        %328 = mulf %327, %325 : vector<8xf32>
        vector.transfer_write %328, %9[%arg0, %326] : vector<8xf32>, memref<32x32xf32>
      }
    }
    AIE.useLock(%8, Release, 1, 0)
    AIE.end
  }

  %49 = AIE.tile(9, 2)
  %50 = AIE.lock(%49, 15)
  %51 = AIE.buffer(%49) {address = 4096 : i32, sym_name = "buf14"} : memref<8x32xf32>
  %52 = AIE.buffer(%49) {address = 5120 : i32, sym_name = "buf15"} : memref<f32>
  %53 = AIE.core(%49)  {
    %cst = constant 0.000000e+00 : f32
    %324 = affine.load %52[] : memref<f32>
    %325 = vector.broadcast %324 : f32 to vector<8xf32>
    affine.for %arg0 = 0 to 8 {
      affine.for %arg1 = 0 to 4 {
        %326 = affine.apply #map(%arg1)
        %327 = vector.transfer_read %51[%arg0, %326], %cst : memref<8x32xf32>, vector<8xf32>
        %328 = mulf %327, %325 : vector<8xf32>
        vector.transfer_write %328, %51[%arg0, %326] : vector<8xf32>, memref<8x32xf32>
      }
    }
    AIE.useLock(%50, Release, 1, 0)
    AIE.end
  }

  %54 = AIE.tile(6, 2)
  %55 = AIE.lock(%54, 15)
  %56 = AIE.buffer(%54) {address = 4096 : i32, sym_name = "buf16"} : memref<8x32xf32>
  %57 = AIE.core(%54)  {
    %cst = constant dense<0.000000e+00> : vector<8xf32>
    affine.for %arg0 = 0 to 8 {
      affine.for %arg1 = 0 to 4 {
        %324 = affine.apply #map(%arg1)
        vector.transfer_write %cst, %56[%arg0, %324] : vector<8xf32>, memref<8x32xf32>
      }
    }
    AIE.useLock(%55, Release, 1, 0)
    AIE.end
  }
}

Need MLIR representation for where the stack goes

Currently AssignMemBuffers reserves some space for the stack of each core and the backend targets will eventually generate a linker script that puts the stack in the corresponding place, however this is somewhat wasteful since it means we lose some explicit control over how the stack is allocated. In addition, we also lack any validation that the stack size is correct WRT the requirements of the code, which should be based on some static analysis.

So, probably the right thing is to have an AIE.buffer-like object that represents the stack, which would be generated explicitly in AssignMemBuffers, then serialized in the linker scripts appropriately.

Replace !aievec.acc<> with vector<>

At the level of MLIR, modeling the accumulator separately doesn't add much and complicates the code significantly, since it has to deal with these types independently.

-aie-standard-lowering doesn't handle AIE.wire

Hi,

I'm playing with a test case like this:

  %0 = AIE.tile(1, 1)
  ... ...
  %266 = AIE.core(%0)  {
    ... ...
  }
  ... ...
  %339 = AIE.switchbox(%0)  {
    AIE.connect<DMA : 0, East : 0>
  }
  ... ...
  AIE.wire(%0 : Core, %339 : Core)
  AIE.wire(%0 : DMA, %339 : DMA)

When aiecc calls aie-opt --aie-standard-lowering=tilecol=1 tilerow=1 acdc_project/input_with_addresses.mlir -o acdc_project/core_1_1.mlir, the AIE.tile is erased while AIE.wires still using it. Error massage:

acdc_project/input_with_addresses.mlir:8:8: error: failed to legalize operation 'AIE.tile' marked as erased
  %0 = AIE.tile(1, 1)
       ^
acdc_project/input_with_addresses.mlir:8:8: note: see current operation: %0 = "AIE.tile"() {col = 1 : i32, row = 1 : i32} : () -> index
acdc_project/input_with_addresses.mlir:2409:3: note: found live user of result #0: AIE.wire(%0 : DMA, %300 : DMA)
  AIE.wire(%0 : DMA, %339 : DMA)

Did I miss anything, such as AIE.wire should be handled in an earlier stage of the pipeline?

Thanks,
Hanchen

Error: no input files xchesscc Failed No such device The Program xchesscc has encountered an unexpected error exiting ... xchesscc Failed No such device

When I run python aiecc.py unit tests, but Xilinx/Vitis/2021.2/aietools/xchesscc Failed No such device.

>>> lspci -vd 10ee:
18:00.0 Memory controller: Xilinx Corporation Device 5048
        Subsystem: Xilinx Corporation Device 000e
        Physical Slot: 1
        Flags: bus master, fast devsel, latency 0, IRQ 18, NUMA node 0
        Memory at 387ff0000000 (64-bit, prefetchable) [size=128M]
        Memory at 387ff8000000 (64-bit, prefetchable) [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: xclmgmt
        Kernel modules: xclmgmt

18:00.1 Memory controller: Xilinx Corporation Device 5049
        Subsystem: Xilinx Corporation Device 000e
        Physical Slot: 1
        Flags: fast devsel, IRQ 19, NUMA node 0
        Memory at 387ff8020000 (64-bit, prefetchable) [size=64K]
        Memory at 387fe0000000 (64-bit, prefetchable) [size=256M]
        Capabilities: <access denied>
        Kernel driver in use: xocl
        Kernel modules: xocl

And I reinstall vitis_2021.2. I do not how to debug this problems.

Error during create-flows/broadcast.mlir (Ubuntu 18.04 and gcc 7.5.0)

Error is:
error: CHECK: expected string not found in input
// CHECK: AIE.flow(%[[T20]], DMA : 0, %[[T82]], DMA : 0)
^
:297:37: note: scanning from here
AIE.flow(%6, DMA : 0, %12, DMA : 0)
^
:297:37: note: with "T20" equal to "6"
AIE.flow(%6, DMA : 0, %12, DMA : 0)
^
:297:37: note: with "T82" equal to "16"
AIE.flow(%6, DMA : 0, %12, DMA : 0)
^
:298:2: note: possible intended match here
AIE.flow(%6, DMA : 0, %9, DMA : 0)

Build direct-to-binary backend target

Current backend targets use the LibXAIE API to configure the AIE array through memory-mapped accesses. This has a number of downsides:

LibXAIE has significant memory usage and we want to run this configuration on an embedded microblaze.
LibXAIEv1 lacks a way to aggregate configuration. (LibXAIE does have a mechanism that bundles reconfiguration)
LibXAIE assumes that a processor is doing configuration, while we may need to push configuration through AXI streams

LibXAIEv2 may have some pieces that can be leveraged to achieve this, or at least verify that the result is correct.

Pathfinder: Currently it doesn't indicate whether the pathfinder has failed after MAX_ITERATIONS

Should add a check to whether MAX_ITERATIONS has been breached immediately after pathfinder has been called, and if so, an error message with MLIR diagnostic.

Dependencies missing in make builds

When I built AIE tools on x86, I met a fatal error " 'aie/Dialect/ADF/ADFDialect.cpp.inc' file not found." as the following picture.

Then I checked my build folder, and I do miss the file. So I delete the code in the cpp file and built successfully. Does deleting the "#include" code affect the following test results?

Linking errors in chess_compiler_tests (Ubuntu 18.04 and gcc 7.5.0)

01_precompiled_core_function:
Error: Undefined symbol "func"
... Symbol is referenced in file : core_1_3.chesslinked.o (core_1_3.chesslinked.o)
... Symbol is referenced in : _main @ offset 80
Error in "core_1_3.elf.map": Linking ended with errors, check the map file for an overview of already mapped symbols.
xchesscc Failed

03_cascade:
Error: Undefined symbol "do_mul"
... Symbol is referenced in file : core_1_3.chesslinked.o (core_1_3.chesslinked.o)
... Symbol is referenced in : _main @ offset 0
Error in "core_1_3.elf.map": Linking ended with errors, check the map file for an overview of already mapped symbols.
xchesscc Failed

05_shim_dma_core_function:
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : _main @ offset 240
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : _main @ offset 80
Error in "core_7_3.elf.map": Linking ended with errors, check the map file for an overview of already mapped symbols.
xchesscc Failed

07_shim_dma_with_core:
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 1360
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 1184
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 1008
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 832
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 624
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 448
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 272
Error: Undefined symbol "func"
... Symbol is referenced in file : core_7_3.chesslinked.o (core_7_3.chesslinked.o)
... Symbol is referenced in : core73 @ offset 96
Error in "core_7_3.elf.map": Linking ended with errors, check the map file for an overview of already mapped symbols.
xchesscc Failed

Error during test compilation (ninja check-aie, when running aiecc.py) (Error generated: cassert non found, bits/c++config.h not found)

The aiecc.py has some hard coded references to xaiengine headers/libs in the sysroot that doesn't match the current platform. This reference should be corrected and made more generic and flexible.

Manually having the clang call in aiecc.py start with the below change works but is itself too inflexible.
clang --target=aarch64-xilinx-linux -std=c++11 --sysroot=<sysroot base> -I<sysroot base>/usr/include/c++/9.2.0 -I<sysroot base>/usr/include/c++/9.2.0/aarch64-xilinx-linux -I<sysroot base>/usr/include/c++/9.2.0/backward ....

Add logical process model and placement algorithm.

Currently, we consider the location where code runs to be physical locations in specific tiles. We should create a logical model of processes and channels (possibly based on the CIRCT handshake dialect) and add a placement algorithm that will locate these processes on particular cores. This model could be similar to the product Vitis tools.

build problems?

-- Found v++:/data/soft/Xilinx/Vitis/2021.2/bin/v++
-- Found xchessmk:/data/soft/Xilinx/Vitis/2021.2/aietools/bin/xchessmk
-- Found libme.a:/data/soft/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/Release/libme.a
-- Found AIE libc.a:/data/soft/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime/lib/Release/libc.a
-- Found AIE libm.a:/data/soft/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime/lib/Release/libm.a
-- Unable to find Vitis include folder
-- Could NOT find Vitis (missing: VITIS_INCLUDE_DIR) 
-- Building with -fPIC
-- Using MLIRConfig.cmake in: /home/lay/work/xilinx/llvm-project/build/lib/cmake/mlir
-- Using LLVMConfig.cmake in: /home/lay/work/xilinx/llvm-project/build/lib/cmake/llvm
-- Found v++:/data/soft/Xilinx/Vitis/2021.2/bin/v++
-- Found xchessmk:/data/soft/Xilinx/Vitis/2021.2/aietools/bin/xchessmk
-- Found libme.a:/data/soft/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/Release/libme.a
-- Found AIE libc.a:/data/soft/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime/lib/Release/libc.a
-- Found AIE libm.a:/data/soft/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime/lib/Release/libm.a
-- Unable to find Vitis include folder
-- Could NOT find Vitis (missing: VITIS_INCLUDE_DIR) 
-- Could NOT find LibXAIE (missing: XILINX_XAIE_INCLUDE_DIR XILINX_XAIE_LIBS) 
-- Building with -fPIC
Translations: MLIRTargetCpp;MLIRSPIRVDeserialization;MLIRSPIRVSerialization;MLIRSPIRVBinaryUtils;MLIRSPIRVTranslateRegistration;MLIRArmNeonToLLVMIRTranslation;MLIRArmSVEToLLVMIRTranslation;MLIRAMXToLLVMIRTranslation;MLIRLLVMToLLVMIRTranslation;MLIRNVVMToLLVMIRTranslation;MLIROpenACCToLLVMIRTranslation;MLIROpenMPToLLVMIRTranslation;MLIRROCDLToLLVMIRTranslation;MLIRX86VectorToLLVMIRTranslation;MLIRTargetLLVMIRExport;MLIRToLLVMIRTranslationRegistration;MLIRTargetLLVMIRImport
-- Configuring done
-- Generating done

how to set the Vitis and LibXAIE config, and I had build LibXAIE with embeddedsw repo?

Linking external object file

Hi all,

I am trying to compile an example I was given where a kernel function is defined. It looks something like this:

kernel_code.cc:

void func(int32_t *a, int32_t *b)
{
...
}

The mlir code references the function like this:
aie.mlir

call @func(%buf13_0, %buf13_1) : (memref<256xi32>, memref<256xi32>) -> ()

I am able to use xchesscc to compile kernel_code.cc, but when I use the aiecc.py driver, I get the following error message:

aie.mlir:25:3: error: custom op 'func' is unknown (tried 'builtin.func' as well)
  func private @func(%A: memref<256xi32>, %B: memref<256xi32>) -> ()
  ^
Error encountered while running: aie-opt --lower-affine --aie-assign-buffer-addresses -convert-scf-to-cf aie.mlir -o acdc_project/input_with_addresses.mlir

This example works for me in a containerized environment where everything was pre-built for me. However, with upstream mlir-aie, I get the above error message.

I took a look at the driver in the container, and I saw this piece of python:

do_call(['aie-opt', '--lower-affine', '--aie-assign-buffer-addresses', '-convert-scf-to-std', opts.filename, '-o', file_with_addresses])

In the upstream mlir-aie repo, I see:

do_call(['aie-opt', '--lower-affine', '--aie-assign-buffer-addresses', '-convert-scf-to-cf', opts.filename, '-o', file_with_addresses])

The difference is the between the flags -convert-scf-to-std and -convert-scf-to-cf. I'm not sure if this is the issue, but this is at least one difference that I have observed.

For extra context, I am able to generate a .o file with xchesscc.

Is anyone else experiencing similar issues? #87 is kind of similar, but it's not a type issue; it just looks like aie-opt doesn't know that func exists, even though the object file it's defined in does exist.

Any help is appreciated!

Thanks,
Anthony

Could NOT find LibXAIE (missing: XILINX_XAIE_INCLUDE_DIR XILINX_XAIE_LIBS)

I built up the vck190 bare platform following the board setup instructions, but the generated rootfs at mlir-aie/platforms/vck190_bare/petalinux/sysroot/sysroots/aarch64-xilinx-linux doesn't contain /opt/xaiengine, making cmake fail to find the LibXAIE package. I must have missed something here, any ideas?

Thanks,
Hanchen

xchesscc compilation issue with floating-point vectorized C++

Hi @pssrawat, I generated a vectorized GEMM kernel using the aievec-to-cpp exporter. The int32 version can be successfully compiled, but the float version cannot. The error message is:

segmentation violation
This error occurred while running: mist -B -I/tools/Xilinx/Vitis/2020.1/cardano/data/cervino/lib -I/tools/Xilinx/Vitis/2020.1/cardano/data/cervino/lib/isg -r +H/tools/Xilinx/Vitis/2020.1/cardano/data/cervino/lib/elongation +Omodo -k64 +Omsbr=100 +Opnll +A +pnopALU +pnopLDA +pnopLDB +pnopSTS +pnopVEC +Ofexm +Onzmem +Onombt +Ochex +Omsmfi +Omslactc=lckLdaRsrc_E1,lckLdbRsrc_E1:2 gemm.kernel-extern_kernel_ me
xchesscc Failed 
The Program xchesscc has encountered an unexpected error exiting ... xchesscc Failed 
/tools/Xilinx/Vitis/2020.1/cardano/bin/xchesscc: line 58: kill: (-717567) - No such process

I attached the MLIR and C++ file for your reference. My compilation command is:

    ${VITIS_DIR}/cardano/bin/xchesscc -g -p me \
      -P ${VITIS_DIR}/cardano/data/cervino/lib \
      -o kernel.o -c gemm.kernel.cc

gemm.kernel.cc.txt
gemm.polyaie.mlir.txt

My Vitis version is 2020.1. Any idea?

Thanks,
Hanchen

Error during create-flows/mmult.mlir (Ubuntu 18.04 and gcc 7.5.0)

Error is:
error: 'AIE.connect' op targets same destination South0 as another connect operation

Reference design `MM_2x2` requires `cardano.h`

The new reference design MM_2x2 (#147) requires cardano.h. Based on some digging, it seems like cardano is something that doesn't exist in Vitis 2021.x versions, but they exist in Vitis 2020.x versions. (I am using Vitis 2021.2). I took a peak at cardano.h in Vitis 2020.2, and in the file, there is a note that says:

#warning "cardano.h and cardano namespace are deprecated. Use adf.h and adf namespace instead."

I do have adf.h in my Vitis 2021.2 install, and I tried to just replace #include cardano.h with #include adf.h. However, I get the following error:

$ xchesscc -I/tools/Xilinx/Vitis/2021.2/aietools/include -p me -P /tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib -c kernel.cc                                    
In file included from /tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include-lite/type_traits:10,                    
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/window/window.h:6,                                                                                                                            
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf.h:8,                                                                                                                                          
                 from kernel.cc:8:                                                                                                                                                                                  
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:850:18: error: missing binary operator before '(' 
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:871:18: error: missing binary operator before '(' 
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:982:18: error: missing binary operator before '(' 
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:1456:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:1565:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:1602:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:1628:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:2382:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:2701:52: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:2817:18: error: missing binary operator before '('                       
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:2875:18: error: missing binary operator before '('                                                                                                     
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:2893:18: error: missing binary operator before '('                                                                                                     
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:2966:18: error: missing binary operator before '('                                                                                                     
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3031:18: error: missing binary operator before '('                                                                                                     
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3036:20: error: missing binary operator before '('                                                                                                     
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3063:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3153:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3279:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3315:18: error: missing binary operator before '('
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3331:18: error: missing binary operator before '('                                                                                                     
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/type_traits:3349:18: error: missing binary operator before '('                                                                                                     
Error in "/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/__nullptr", line 64, column 30: old function argument style, not supported                                                                               
... symbol being parsed: nullptr_t                                                                        
In file included from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port_sizes.h:13,                      
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port.h:14,                                                                                                                 
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf.h:10,                                                                                                                                         
                 from kernel.cc:8:                                                                                                                                                                                  
/tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port_dims.h:10:9: warning: #pragma once is obsolete                                                                                                                                        
In file included from /tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include-lite/__tuple:10,                                                                                                                             
                 from /tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/utility:207,                                                                                                                                 
                 from /tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include-lite/utility:10,                                                                                                                             
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port_dims.h:14,                       
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port_sizes.h:13,                                                                                                           
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port.h:14,                            
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf.h:10,          
                 from kernel.cc:8:                                                                        
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/__tuple:105:19: error: missing binary operator before '('                                                                                                          
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/__tuple:147:18: error: missing binary operator before '('                                                                                                          
/tools/Xilinx/Vitis/2021.2/aietools/data/cervino/lib/runtime_cxx/libs/libcxx-9.0.0/include/__tuple:259:19: error: missing binary operator before '('                                                                                                          
In file included from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port_dims.h:15,
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port_sizes.h:13,
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port.h:14,                            
                 from /tools/Xilinx/Vitis/2021.2/aietools/include/adf.h:10,   
                 from kernel.cc:8:                             
/tools/Xilinx/Vitis/2021.2/aietools/include/adf/buffer_port/buffer_port_macros.h:11:9: warning: #pragma once is obsolete                                                                                                                                      
xchesscc Failed                                                
The Program xchesscc has encountered an unexpected error exiting ... xchesscc Failed                                           
/tools/Xilinx/Vitis/2021.2/aietools/bin/xchesscc: line 58: kill: (-1656029) - No such process                                  
make: *** [Makefile:14: kernel.o] Error 255

I don't know if substituting adf.h for cardano.h is the appropriate fix, but at any rate, could someone help debug this, please?

Invalid compilation target `aie`

During the regression tests, quite some fails are caused by this command:

llc acdc_project/core_7_3.stripped.ll -O2 --march=aie --filetype=obj -o acdc_project/core_7_3.o

with an error:

llc: error: error: invalid target 'aie'.

I dug a little into this and found the path of llc is the common llvm-project build, which doesn't support aie as target. Any idea on this?

Thanks,
Hanchen

Add "antenna detector" to --aie-find-flows

We should detect and report partial routes that don't start or end in a valid endpoint. Could also find routing cycles in the stream switches.

Canonicalizer merges multiple DMA blocks into one

When two DMA blocks are present, the canonicalizer may merge them into one, for example:

 ^bb5:  // 2 preds: ^bb4, ^bb5
    "AIE.useLock"(%4) {action = 0 : i32, value = 1 : i32} : (index) -> ()
    "AIE.dmaBdPacket"() {packet_id = 4 : i32, packet_type = 4 : i32} : () -> ()
    "AIE.dmaBd"(%32) {AB = 0 : i32, len = 1024 : i32, offset = 0 : i32} : (memref<1024xi32>) -> ()
    "AIE.useLock"(%4) {action = 1 : i32, value = 0 : i32} : (index) -> ()
    "AIE.useLock"(%3) {action = 0 : i32, value = 1 : i32} : (index) -> ()
    "AIE.dmaBdPacket"() {packet_id = 5 : i32, packet_type = 5 : i32} : () -> ()
    "AIE.dmaBd"(%33) {AB = 0 : i32, len = 1024 : i32, offset = 0 : i32} : (memref<1024xi32>) -> ()
    "AIE.useLock"(%3) {action = 1 : i32, value = 0 : i32} : (index) -> ()
    "cf.br"()[^bb5] : () -> ()

This triggers the error in #114 . AIETargetXAIE seems currently depend on blocks so simply reverting #114 does not solve the issue.

Propagate alignment information to called functions.

The MLIR assume_aligment op can annotate alignment information on memrefs. We currently generate an assume_alignment op for all AIE buffers:
memref.assume_alignment %lineOut, 32 : memref<16xi32>
This will enable successful vectorization in some cases in the backend, since vector loads and stores must be aligned in the AIE architecture. Without this, an unaligned code sequence must be generated.

Unfortunately, the assume_alignment information in MLIR is not inter-procedural, so if we want to leverage function calls, then we need to propagate this. Probably the right thing to do is to generate a specialized copy of the function with alignment information from the original call sites.

Using --aie-generate-xaiev2 to run unit tests with xaiev2

Hi all,

I am still very new to this project and still get very lost, but reading through some issues (#106 #77) and @nqdtan's fork of this project, I have updated the RUN: scripts in the unit tests to pass the --aie-generate-xaiev2-- option to aiecc.py. To do this, I navigate to the this directory and issue the commands:

find ./ -name aie.mlir | xargs sed -i 's/--sysroot=%VITIS_SYSROOT%/--sysroot=%VITIS_SYSROOT% --aie-generate-xaiev2/g'
find ./ -name aie_row.mlir | xargs sed -i 's/--sysroot=%VITIS_SYSROOT%/--sysroot=%VITIS_SYSROOT% --aie-generate-xaiev2/g'

I probably could have just cherry-picked from @nqdtan's commits, but this seemed easier since I didn't need the hard-coded include and library paths.

With this, when I issue ninja check-aie, I go from this:

  Unsupported:  15                                                                                                                                                                                                  
  Passed     : 130                                                                                                                                                                                                  
  Unresolved :   2                                                                                                                                                                                                  
  Failed     :  23

to this:

  Unsupported:  15
  Passed     : 153
  Unresolved :   2

I don't understand the AIE versions or all of the available options you can pass to aiecc.py, but I just wanted to share this in case it was helpful to anyone else trying to follow the instructions from here.

Too specific clang compilation options in aiecc.py when targeting petalinux 2021.2 sysroots (--aie-generate-xaiev2)

Clang compilation options were added to aiecc.py (main.py) when targeting petalinux 2021.2 sysroots (like the vck190_bare_prod_2021.2 platform) in order to find the correct library dependencies. See https://github.com/Xilinx/mlir-aie/blob/main/tools/aiecc/aiecc/main.py#L157-L162. This should ideally be automatically found with just the --sysroot argument but that doesn't seem to be enough. If I run the aiecc.py on any of the main unit tests with the following command:

aiecc.py -v --sysroot=/group/xrlabs2/platforms/vck190_prod_bare_2021.2_sysroot/ --aie-generate-xaiev2 --xbridge ./aie.mlir -I../../../runtime_lib ../../../runtime_lib/test_library.cpp ./test.cpp -o test.elf

It is successful because of the added options. But if I were to call clang on the test.cpp without them, such as:

clang --target=aarch64-linux-gnu -std=c++11 --sysroot=/group/xrlabs2/platforms/vck190_prod_bare_2021.2_sysroot/ -DLIBXAIENGINEV2 -I/group/xrlabs2/platforms/vck190_prod_bare_2021.2_sysroot//opt/xaiengine/include -L/group/xrlabs2/platforms/vck190_prod_bare_2021.2_sysroot//opt/xaiengine/lib -Iacdc_project -fuse-ld=lld -lm -rdynamic -lxaiengine -ldl -I../../../runtime_lib ../../../runtime_lib/test_library.cpp ./test.cpp -o test.elf

the error received is:

In file included from ../../../runtime_lib/test_library.cpp:13:
../../../runtime_lib/test_library.h:12:10: fatal error: 'cmath' file not found
#include
^~~~~~~
1 error generated.
./test.cpp:11:10: fatal error: 'cassert' file not found
#include
^~~~~~~~~
1 error generated.

	AIE.packet_flow(0x0) {
	AIE.packet_source<%t11, West : 0>
	AIE.packet_dest<%t11, Core : 0>
	}

	AIE.packet_flow(0x1) {
	AIE.packet_source<%t11, West : 0>
	AIE.packet_dest<%t11, Core : 0>
	}

	AIE.packet_flow(0x2) {
	AIE.packet_source<%t11, West : 1>
	AIE.packet_dest<%t11, Core : 0>
	}

	// CHECK: %1 = AIE.switchbox(%0) {
	// CHECK: %2 = AIE.amsel<0> (0)
	// CHECK: %3 = AIE.masterset(Core : 0, %2)
	// CHECK: AIE.packetrules(West : 1) {
	// CHECK: AIE.rule(31, 2, %2)
	// CHECK: }
	// CHECK: AIE.packetrules(West : 0) {
	// CHECK: AIE.rule(30, 1, %2)
	// CHECK: }
	// CHECK: }

xilinx / mlir-aie Goto Github PK

mlir-aie's Introduction

MLIR-based AI Engine toolchain

mlir-aie's People

Contributors

Stargazers

Watchers

Forkers

mlir-aie's Issues

Recommend Projects

Recommend Topics

Recommend Org