Allow building Alveo and NPU at the same time

[superm1]

In Debian we recently tried to enable Alveo at the same time as NPU, but found out there are some potential incompatibilities with this.

So I wanted to get a ticket in place we can track having a build that has both at the same time for both products.

[superm1]

@shramov identified the following when looking at it. I haven't personally looked at the code but heard this incompatibility from @stsoe

Yep, there are two places where XRT_NPU really affects code:

XRT/src/runtime_src/xdp/CMakeLists.txt

Line 34 in 35edec7

if (XRT_NPU)

Adds -DSKIP_IOCTL, skips appdebug and debug subdirs but enables XDP_CLIENT_BUILD_CMAKE varaiable that adds bunch of AIE plugins.

XRT/src/runtime_src/core/common/xdp/CMakeLists.txt

Line 14 in 35edec7

if (XRT_NPU)

Adds -DXDP_CLIENT_BUILD=1 that enables some callbacks (have not digged more)
Other XRT_NPU matches do not affect code (https://github.com/search?q=repo%3AXilinx%2FXRT%20%20XRT_NPU&type=code)
We are not using XDP so I can not confirm that something is broken there. But basic usecases are just fine - XRT kernels/buffer objects/registers, xrt-smi utility.

[shramov]

Basic functionality is working just fine, no issues so far. Only difference that it's backport to ubuntu20.04

[superm1]

Changes necessary are now in 202610.2.21.17

[shramov]

202610.2.21.17

Typo in tag, shoud be 202510...

[shramov]

@superm1 Can you ping @stsoe with tag name issue? This will break debian/watch for example

[stsoe]

@shramov @superm1 The tag is correct. We bumped the release version. We do that every 6 months to match with Vitis releases.

[shramov]

So 2025.2 release will be skipped? And next one will be 2026.1?

2026 prefix in 2025 year is a bit strange, but if you are sure - let it be so.

[stsoe]

It's just a tag. The tag comes off the master branch, which is actually in development for 2026. I am not back porting all upstream changes to our 2025.2 branch.

[shramov]

It's better to be safe than sorry :) I've just raised this question since it looks suspicious. Sorry for bothering you.

[stsoe]

It's better to be safe than sorry :) I've just raised this question since it looks suspicious. Sorry for bothering you.

Appreciate the watchful eye. Thanks for all your suggestions and patches.

[shramov]

Regarding xdna-driver. Is it possible to add it into xrt as a submodule like aiebu and others?
Looks like it is simple (xdna-driver is placed in src/runtime_src/xdna-driver):

diff --git a/src/runtime_src/CMakeLists.txt b/src/runtime_src/CMakeLists.txt
index 8f4864399..4789f88d3 100644
--- a/src/runtime_src/CMakeLists.txt
+++ b/src/runtime_src/CMakeLists.txt
@@ -41,6 +41,11 @@ if (XRT_ALVEO)
   xrt_add_subdirectory(ert)
 endif()
 
+if (XRT_NPU)
+  set(XRT_PLUGIN_VERSION_STRING ${XRT_VERSION_STRING})
+  add_subdirectory(xdna-driver/src/shim)
+endif()
+
 # --- Optional HIP bindings ---
 if (XRT_ENABLE_HIP)
   xrt_add_subdirectory(hip)

[stsoe]

Regarding xdna-driver. Is it possible to add it into xrt as a submodule like aiebu and others? Looks like it is simple (xdna-driver is placed in src/runtime_src/xdna-driver):

diff --git a/src/runtime_src/CMakeLists.txt b/src/runtime_src/CMakeLists.txt
index 8f4864399..4789f88d3 100644
--- a/src/runtime_src/CMakeLists.txt
+++ b/src/runtime_src/CMakeLists.txt
@@ -41,6 +41,11 @@ if (XRT_ALVEO)
   xrt_add_subdirectory(ert)
 endif()
 
+if (XRT_NPU)
+  set(XRT_PLUGIN_VERSION_STRING ${XRT_VERSION_STRING})
+  add_subdirectory(xdna-driver/src/shim)
+endif()
+
 # --- Optional HIP bindings ---
 if (XRT_ENABLE_HIP)
   xrt_add_subdirectory(hip)

XRT is used in many projects (not just NPU) that want to control the git hash of XRT they are compatible with and have been tested against. I prefer not to add xdna to XRT itself. We go through integration testing of xdna, prior to committing a new XRT hash in that repo. The upstream tarball reflects the compatible pieces.

This doesn't mean including xdna as a sub-module is a bad idea, and we have indeed considered this in the past, but our CI is not currently set up for validating this tighter coupling between XRT and xdna-driver.