Xilinx
Allow building Alveo and NPU at the same time
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.
@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: https://github.com/Xilinx/XRT/blob/35edec7f7ba6f92ddb6565f3b21e2f4926b8014d/src/runtime_src/xdp/CMakeLists.txt#L34 Adds -DSKIP_IOCTL, skips appdebug and debug subdirs but enables XDP_CLIENT_BUILD_CMAKE varaiable that adds bunch of AIE plugins. https://github.com/Xilinx/XRT/blob/35edec7f7ba6f92ddb6565f3b21e2f4926b8014d/src/runtime_src/core/common/xdp/CMakeLists.txt#L14 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.
Basic functionality is working just fine, no issues so far. Only difference that it's backport to ubuntu20.04
@superm1 Can you ping @stsoe with tag name issue? This will break debian/watch for example
@shramov @superm1 The tag is correct. We bumped the release version. We do that every 6 months to match with Vitis releases.
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.
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.
It's better to be safe than sorry :) I've just raised this question since it looks suspicious. Sorry for bothering you.
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.
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)
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.