[atassis]

Problem

xrt-smi examine reports aie_architecture_version (aie2, aie2p, aie4, aie2ps), resolved
from query::pcie_id through smi_hardware_config (#9861). The same fact is not reachable from the
library: xrt::device::get_info<xrt::info::device::platform>() puts only name and total_columns
in the Ryzen static region, so a program linked against XRT -- including pyxrt consumers -- has to
run xrt-smi and parse its output to learn which AIE architecture it is on.

The name field is not a substitute. It is the driver's vbnv string, resolved at runtime from a
firmware revision query, so it carries the SKU name and falls back to a different naming scheme when
that query fails. On this host {0x17f0, 0x10} reports NPU Gorgon Point 1, while the same pair is
stxB0 in hardware_map.

Fix

Add aie_architecture_version to the Ryzen branch of add_static_region_info, resolved through the
same smi_hardware_config helper and stored under the same key as the examine report, with N/A
when the identity cannot be resolved -- so the key is always present, as it already is in the alveo
branch of the same function. ReportRyzenPlatform prints it.

No new query and no new API surface: there is no added xrt::info::device enumerator and no
signature change. It is additive to the JSON that xrt::device::get_info<xrt::info::device::platform>()
already returns, which is a change to that output's shape, not to the API itself.

Test

Built Release with -DXRT_NPU=1 -DXRT_ENABLE_WERROR=1; xrt-smi links clean.

The NPU on this host is {device 0x17f0, revision 0x10} (/sys/class/accel/accel0/device/), vbnv
NPU Gorgon Point 1. Calling the resolver this patch uses, in the library built from this branch:

17f0:10   family=strix   get_aie_architecture_version=aie2p

so the Ryzen platform report gains aie_architecture_version: aie2p next to the existing name and
total_columns.

Scope

I could not run the built xrt-smi against the device on this host: the tree is 2.26.0 while the
installed NPU driver plugin is 2.21.75, and the core-to-plugin interface is not versioned across that
gap. The rendering path is covered by construction rather than by a device run.

[xrt-pr-bot]

⚠️ Authorization Failed

@atassis is not a repository collaborator.

To proceed:

• XRT Admins: Add the build label to authorize this PR build
• OR Add @atassis as a repository collaborator

[xrt-pr-bot]

⚠️ Authorization Failed

@atassis is not a repository collaborator.

To proceed:

• XRT Admins: Add the build label to authorize this PR build
• OR Add @atassis as a repository collaborator

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[aktondak]

Though this is a nice to have addition, this will need to go through approvals for this information to be a part of the platforms report.
You can redirect the output of host report to a json as well and get arch from there, if parsing is an issue :
xrt-smi examine -r host -o output.json

{
    "schema_version": {
        "schema": "JSON",
        "creation_date": "Tue Sep  1 17:35:00 2026 GMT"
    },
    "system": {
        "host": {
          .
          .
            "devices": [
                {
                    "bdf": "0000:c5:00.1",
                    "device_class": "Ryzen",
                    "name": "NPU Strix",
                    "id": "0000c500-0000-0100-0000-000000000000",
                    "firmware_version": "1.1.2.64",
                    "cert_firmware_version": "N\/A",
                    "aie_topology": "6x8",
                    **"aie_architecture_version": "aie2p",**
                    "instance": "user(inst=0)",
                    "is_ready": "true"
                }
            ]
        }
    }
}

[aktondak]

Please go through my last comment and let us know if it suffices

[atassis]

It does not. The gap is the subprocess, not the parsing.

aie_architecture_version in the host report comes from core/tools/common/XBUtilities.cpp:263, compiled only into xbutil2 and xbmgmt2, never into libxrt_coreutil. A linked program reading it must exec xrt-smi, needs the CLI installed alongside, and depends on the report's schema_version instead of an API. -o output.json fixes none of that. pyxrt consumers have the same problem in-process.

A correction to my own framing. core_common_smi_objects is already linked into xrt_coreutil and xrt_coreutil_static (core/common/CMakeLists.txt:87,95), so get_aie_architecture_version ships in the library today. Only the declaration is missing: smi.h is in no install list. Three options:

1. Add the key to the Ryzen static region, as here.
2. Install smi.h. A consumer still parses get_info<pcie_info>() for device and revision to build the hardware_type, so the parsing moves in-process instead of going away.
3. Status quo.

I took (1): no new query, no xrt::info::device enumerator, no signature change. The alveo branch of the same function already emits jtag_idcode and fpga_name unconditionally with an N/A fallback.

I can take it through whatever approval the platform report needs, or switch to (2). Your call.