Compatibility baseline

HPX owns the exact compatibility baseline in src/helia_profiler/data/compatibility-baseline-v1.json. It is loaded and validated during configuration resolution, then carried through the frozen configuration and result provenance. The baseline is not an NSX lockfile. Stage 5 combines its identity and canonical hash with the NSX registry hash, target, engine, overrides, and relevant build inputs to select an isolated dependency workspace.

The current baseline is hpx-neuralspotx-0.8.1-2026-09:

Identity	Qualified reference
neuralspotx package	0.8.1, wheel SHA-256 7aac6f1b…9094, tag peeled to 2dbe12a2…901f
nsx-ambiq-sdk	v5.2.25, peeled commit aefce2ca…de7c
nsx-ethos-u-driver	f0f99bb1…5a8 (peeled from nsx-ethos-u-driver-v0.1.2; pulled transitively by nsx-npu)
nsx-pmu-armv8m	5725c065…c88
nsx-tflite-micro	7afcf2b4…333
arm-cmsis-nn	6d21a6f8…f7c
ns-cmsis-nn	5f3fed9f…cb8 (v7.39.2, hpx-declared, see below)
nsx-executorch	5514ac1e…b48e
nsx-sensors	c219a2bc…3e25 (v0.3.0, peeled)
heliaRT	1.21.3, commit dc8533ab…f5f, from the runtime record (min supported 1.16.0, from HELIART_MIN_VERSION in code)
heliaAOT	runtime records 0.23.0, 0.24.0, 0.25.0, 0.26.0, 0.27.0; accepted range >=0.23.0,<0.28.0
tflm	profile path: governed by the nsx-tflite-micro and arm-cmsis-nn module refs above (the tflm runtime record describes the fixed fixture’s prepared upstream archive instead); nsx-tflite-micro builds TFLM from the helia-rt-source project, which the baseline does not list and the neuralSPOT-X 0.8.1 registry lock fixes at 7c1b162c (helia-rt v1.17.0)
executorch	0.1.0, commit 5514ac1e…b48e, from the runtime record (a checkout’s version.txt and commit are verified against it)

Every baseline project and module ref is immutable by policy: only a full 40-character Git object ID is accepted. Newly promoted annotated tags are verified and peeled before being recorded.

Engine versions are not part of the baseline. Each runtime version hpx builds has a runtime record, src/helia_profiler/data/runtimes/<name>/<version>.json (listed by hpx runtimes list): its source commit, the precisions it supports and the targets it is qualified on. The default heliaRT version and source commit (HELIART_VERSION, HELIART_SOURCE_COMMIT in engines/helia_rt/artifacts.py) and the ExecuTorch version and commit come from each engine’s default record. The baseline’s helia-rt and nsx-executorch project refs must equal those commits; a test checks it.

heliaAOT is a separately pip-installed package, so HPX cannot select its version; it can only validate the one already installed. engines/helia_aot/compile._check_helia_aot_version() accepts versions from the oldest heliaAOT record to the minor after the newest, and raises a clear EngineError outside that range.

Qualification states

Each resolved run reports one state:

Python callers can load an immutable baseline with load_compatibility_baseline(path) and pass it as ProfileConfig(compatibility_baseline=baseline, ...). YAML and CLI configuration cannot set this reserved field. A baseline whose fingerprint differs from the packaged baseline reports development-overrides.

• qualified: the packaged baseline defaults are used.
• qualified-with-engine-override: an explicit engine source/version override is present (engine.config.{dist_path,source_path,source}, engine.config_path, or one of the HELIART_DIST_PATH / HELIART_SOURCE_PATH environment variables), but no baseline module is replaced. Ordinary engine knobs (e.g. engine.backend, engine.config.variant) do not affect qualification.
• development-overrides: the baseline differs from the packaged baseline, or an NSX module is replaced, either through any build.nsx_modules entry NSX itself resolves (whether or not the baseline pins that module; entries naming an engine-owned module are ignored with a warning and do not count) or through a CMSIS-NN provider selector (engine.config.cmsis_nn_path, engine.config.cmsis_nn_ref, or the CMSIS_NN_PATH environment variable). Overrides are classified by the dependency they replace, not by the config key that carried them: the selector is recorded under the provider module it replaces (nsx-cmsis-nn for the helia engines and ExecuTorch’s ns provider, arm-cmsis-nn for ExecuTorch’s arm provider), so the cmsis_nn_ref form and the build.nsx_modules form of the same ref stamp identically. Empty selector values are not overrides. The dependency provenance’s overrides list uses the same module-scoped record for the selector that took effect.

Explicit local paths, branches, and SHAs remain supported. They are never silently replaced by the baseline; the state and override names are recorded in run_metadata.json, summary.json, result_manifest.json, and terminal output.

The baseline exposes a canonical SHA-256 fingerprint. Ordinary profiles never refresh a structurally compatible lock: they reuse its exact bytes and run nsx sync --frozen. A missing or incompatible lock is resolved without the NSX update flag. Only hpx profile --update-dependencies (or build.update_dependencies: true) deliberately refreshes refs. The exact resulting nsx.lock and typed resolution provenance are copied into every completed result bundle.

Baseline history

Why earlier promotions changed these pins

This revision moves neuralSPOT-X 0.7.17 → 0.8.1 for the Apollo4 Blue Lite board descriptor fix (AmbiqAI/neuralspotx#250, closing hpx#263): 0.7.17’s apollo4l_evb and apollo4l_blue_evb descriptors cleared NSX_SYSTEM_SOURCE, so the startup library was built without the CMSIS system file and every profiler firmware for those boards failed to link with SystemCoreClock undefined. Besides the tool row, this revision moves nsx-ambiq-sdk to v5.2.25 for the Ethos-U work: v5.2.25 adds the nsx-npu module and the AM_PART_ATOMIQ110 branch in nsx-core’s nsx_mem.h (v5.2.24’s placement macros expand to nothing on that part, so SRAM arena placement would be silently inert). 0.8.1’s packaged registry itself still resolves nsx-core at v5.2.24 module-level (only nsx-npu is overridden to v5.2.25 upstream), which is why the baseline pins the SDK project and HPX re-points every sdk-owned app module to it. The remaining projects stay at 0.7.17’s tags (nsx-pmu-armv8m v0.2.0, nsx-tflite-micro and arm-cmsis-nn v0.1.0, nsx-sensors v0.3.0, and still ns-cmsis-nn v7.29.2 under the hpx-declared v7.35.0), each re-peeled to the commit already recorded. Two 0.8.x changes are worth knowing: the Python floor rose to 3.11 (HPX already requires it), and the packaged board and tooling modules changed content hash (neuralspotx#247), so an nsx.lock produced under 0.7.17 cannot be nsx sync --frozen’d against 0.8.1; the dependency workspace is keyed on the baseline fingerprint and registry hash, so a promoted run resolves a fresh lock rather than reusing a stale one. With this baseline apollo4l_blue_evb joins the nightly hardware-validation default board list.

heliaRT 1.20.0, heliaAOT 0.20.0 and ns-cmsis-nn v7.32.0 (issue #279) move together because they must: v7.32.0 consolidated the float switches onto ARM_NN_ENABLE_F32/F16 and aborts the configure when a retired NSX_CMSIS_NN_ENABLE_* name is defined at all, while heliaRT 1.19.0 aborts when that same retired name is missing. No single spelling satisfies both, so the core and both engines are one atomic promotion. heliaRT 1.20.0 reads the capability from the resolved ns-cmsis-nn target through its own query rather than from a cache variable, and it accepts a float16-input DEQUANTIZE, which is the LiteRT converter’s standard FP16 model shape (helia-rt#255, closing hpx#251). heliaAOT 0.20.0 pins the same core and now rejects float on the six operators ns-cmsis-nn ships integer kernels for, naming the operator and dtype instead of failing at link time (helia-aot#396).

heliaRT 1.21.0 (fe025f2b…56f), heliaAOT [0.22.0, 0.23.0) and ns-cmsis-nn v7.35.0 (cad3c8fa…1a6) then move together (#380); every other ref above is unchanged. heliaRT 1.21.0 pins that exact core for its own builds, and its NSX module differs from 1.20.0 only in its version, so neuralSPOT-X 0.8.1 is unchanged. v7.33.0 to v7.35.0 add float kernels without changing a public kernel signature. heliaRT 1.21.0’s float kernels call them (square root and reciprocal square root, fill, pack, unpack, split, gather, arg minimum and maximum), so a float heliaRT 1.21.0 build needs at least v7.35.0 and an engine.config.cmsis_nn_ref below it fails to compile. heliaAOT 0.22.0 lowers float square root and reciprocal square root, gather, reduce minimum and maximum, and arg minimum and maximum to them and raises a module’s floor to match (up to v7.35.0 for ARG_MAX/ARG_MIN), so the qualified core builds every float operator it emits. Its module-wide floor stays v7.32.0; a float module requires the core’s ns_cmsis_nn_float_support() query at configure time; and the interfaces HPX drives (the converter and its arguments, the codegen context, and the generated model API that main_aot.cc.j2 calls) are unchanged apart from additive fields.

Verified (host only). With helia-aot 0.22.0 installed, the int8 KWS model converts through the heliaAOT engine’s own stages for Apollo510, the rendered main_aot.cc is byte-identical to the 0.20.0 render, and the generated module and rendered firmware compile (Arm GNU 15.2, -Werror -fsyntax-only) against the v7.35.0 core. A float model using SQRT and ARG_MAX compiles against v7.35.0 and stops on its own #error floor against v7.32.0. For the fp32 and fp16 KWS models HPX enables every float kernel the generated module requires. No build, flash or hardware run is recorded for this revision yet.

heliaRT 1.21.2 (ce03af57…a11), heliaAOT [0.23.0, 0.24.0) and ns-cmsis-nn v7.36.1 (630a1c39…c6c) then move together (#393); every other ref above is unchanged. heliaAOT 0.23.0 keeps the converter, codegen context and generated model API HPX drives, adding fields only. It raises its module-wide floor from v7.32.0 to v7.35.0, for integer models too, so an engine.config.cmsis_nn_ref below v7.35.0 no longer compiles; its dilated one-dimensional depthwise route raises a module’s floor to v7.36.0. v7.36.0 adds kernels and keeps every public kernel callable as before (it only adds const to arm_sqrt_s8’s lookup table). The core is v7.36.1, one patch above the v7.36.0 that heliaRT 1.21.2 and heliaAOT 0.23.0 were released against, because it fixes two Cortex-M55 vector defects that v7.35.0 already had: an over-read in arm_depthwise_conv_fast_s16 for channel counts not a multiple of four, and missing saturation of the output offset in arm_elementwise_mul_s8. v7.36.1 otherwise adds vectorized s8 depthwise, s8 add/mul and float MEAN paths and leaves the public kernel header unchanged. HPX’s default heliaRT build compiles from source, so both engines compile against this core. ExecuTorch’s ns backend uses the same core and is not separately verified here.

Verified (host only). With helia-aot 0.23.0, int8 keyword-spotting, temporal-convolution (dilated), anomaly-detection, heart-rhythm, segmentation, visual-wake-word and image-classification models and fp32 and fp16 sleep-staging models convert and build for Apollo510 with ATfE. heliaRT 1.21.2 builds from source against v7.36.1 for the int8 keyword-spotting model (Arm GNU and ATfE) and the fp32 and fp16 sleep-staging models (ATfE).

heliaAOT [0.23.0, 0.26.0) and ns-cmsis-nn v7.38.0 (82786f27…9db) then move together (#393); every other ref above is unchanged. heliaAOT’s main branch after its 0.24.0 release routes int8 first convolutions and 3x3 depthwise convolutions to direct kernels that need v7.37.0 or later (helia-aot#528), so the core both engines compile against moves to v7.38.0. That branch still reports version 0.24.0, the same as the release, and HPX records only the version, so a consumer that pins heliaAOT main identifies the install by its commit. The range admits 0.25.x so that heliaAOT main keeps qualifying after its 0.25.0 release is cut; no 0.25.x build is verified yet, and one needs a host sweep before any cited result uses it. v7.37.0 and v7.38.0 add the direct int8 convolution and 3x3 depthwise entries, route low input-depth convolutions to them from arm_convolve_wrapper_s8, so heliaRT’s int8 convolutions pick them up too, fix the s4 and padded s8 depthwise tails, and accumulate MVE float16 dot products in float32 every 32 terms (ns-cmsis-nn#600), which changes float16 results. ExecuTorch’s ns backend uses the same core and is not separately verified here.

Verified (host). heliaAOT main (1ba7ed57) converts the 36 benchmark models through HPX’s heliaAOT adapter, with placement rules for an Apollo510 SRAM arena and MRAM weights; the generated modules link for Cortex-M55 against v7.38.0 with Arm GNU, and a plain-C host build runs them. That host run does not exercise the MVE kernels (its integer rows run from modules converted for apollo4p_evb) and does not cover HPX’s own firmware build. The released helia-aot 0.23.0 and 0.24.0 each convert and build int8 keyword-spotting, visual-wake-word, image-classification, anomaly-detection, temporal-convolution, heart-rhythm and segmentation models and fp32 and fp16 sleep-staging and fp16 denoising models against v7.38.0 through HPX’s firmware build with ATfE for Apollo510. heliaRT 1.21.2 builds from source against v7.38.0 with ATfE for the int8 keyword-spotting model and the fp32 and fp16 sleep-staging models. On hardware, heliaAOT 0d0acc58 on v7.38.0 passed 35 of 36 fixed-fixture benchmark plans on an Apollo510 EVB; the remaining TimePPG A8W8 failure is fixed by helia-aot#537, which no device run covers yet. Neither release has a device run on v7.38.0.

ns-cmsis-nn v7.38.1 (72482be6…649) then replaces v7.38.0; the heliaAOT range and every other ref above are unchanged. v7.38.1 carries eight kernel correctness fixes over v7.38.0 and a test-suite fix: the MVE s8 GEMM and vec-mat loads, the fp16 conv1d k5 tail, the depthwise s8_opt scratch check, s4 nibble decoding, and the s8 1xN convolution routing and staging. The 1xN routing sits inside arm_convolve_wrapper_s8, so it reaches every engine that calls the wrapper. heliaAOT main from 5bec204b routes one-row int8 convolutions to arm_convolve_1_x_n_s8 as v7.38.1 does (helia-aot#548), and its generated modules refuse to compile against an older core.

Verified (host). heliaAOT main (5bec204b) converts the 36 benchmark models through HPX’s heliaAOT adapter with the same Apollo510 placement rules, links them for Cortex-M55 against v7.38.1, and the plain-C host build produces outputs bit-identical to 1ba7ed57 on v7.38.0. As before, that host run does not exercise the MVE kernels (its integer rows run from modules converted for apollo4p_evb). Under QEMU (Cortex-M55, MVE on and off) the int8 TimePPG and heart-segmentation 1xN layers match exactly. The released helia-aot 0.23.0 and 0.24.0 each convert and build the same ten models listed above against v7.38.1 through HPX’s firmware build with ATfE for Apollo510. heliaRT 1.21.2 builds from source against v7.38.1 with ATfE for the int8 keyword-spotting model and the fp32 and fp16 sleep-staging models. ExecuTorch’s ns backend uses the same core and is not separately verified here; HPX’s TFLM engine offers only the reference and cmsis_nn backends, so it does not use this core. No device run covered v7.38.1 when that revision was made.

heliaRT 1.21.3 (dc8533ab…f5f) and ns-cmsis-nn v7.39.2 (5f3fed9f…cb8) then replace 1.21.2 and v7.38.1; heliaAOT’s range is unchanged and the locked heliaAOT is the 0.25.0 release. heliaRT 1.21.3 is the release built on v7.39.2. v7.39.0 to v7.39.2 add a table-free int16 square root and fix pooling window checks, float ARG_MAX/ARG_MIN NaN handling, the float depthwise scratch sizers and the pack include path. Results change where float ARG_MAX/ARG_MIN meet a NaN (a NaN never wins), where float32 TANH on Cortex-M55 meets NaN or signed zero (now passed through), and in the last bits of fp16 depthwise with ch_mult > 1 on targets without MVE. Costs change too: float32 TANH is up to about 5% slower per layer on Cortex-M55, and each pooling call costs a fixed ~150 cycles more (arm_avgpool_s8, ~118). heliaAOT 0.25.0 stops at configure time when the linked core is older than its generated module needs. heliaAOT 0.23.0 and 0.24.0 stay inside the range but were not re-verified against v7.39.2. The TFLM engine is unaffected: its nsx-tflite-micro module (7afcf2b4…333) builds TFLM from the helia-rt-source project, which this baseline does not list; the neuralSPOT-X 0.8.1 registry fixes it at 7c1b162c (helia-rt v1.17.0). ExecuTorch’s ns backend builds against the same ns-cmsis-nn core and is not separately verified here.

Verified. For int8 keyword spotting, hpx analyze and hpx doctor succeed on each of heliaAOT, heliaRT and TFLM. On an Apollo510 EVB (LP, MRAM weights, SRAM arena), heliaAOT 0.25.0 and heliaRT 1.21.3 ran the MLPerf Tiny keyword-spotting, visual-wake-word, image-classification and anomaly-detection models at A8W8 and A16W8, plus nine HeartKit, SleepKit, CompressionKIT, TimePPG, keyword and voice-activity models, all qualified against this baseline. heliaAOT latency is within 1.7% of earlier runs of heliaAOT main 5bec204b (which reports 0.24.0) on v7.38.1 for every model. heliaRT 1.21.3 is 5-15% faster than 1.21.2 on the int8 keyword-spotting, visual-wake-word and image-classification models and within 1% on the other MLPerf Tiny rows; the other nine models have no heliaRT 1.21.2 device run to compare. Those device runs do not compare outputs.

The previous revision is recorded below. heliaRT 1.19.0 and heliaAOT 0.19.0 (issue #246) are the releases that add FP16 and FP32 kernels. That revision promoted both HPX-owned engine pins and moved one neuralSPOT-X ref, ns-cmsis-nn, to v7.31.0 (below); every other NSX ref is unchanged: heliaRT 1.17.0 → 1.19.0 (038a0c44…a83), heliaAOT [0.18.0, 0.19.0) → [0.19.0, 0.20.0), with ai-edge-litert relocked to 2.2.0 (floor unchanged at >= 2.1.6; the _tflite_reader schema constants re-verified unchanged against it). HELIART_MIN_VERSION stays 1.16.0; 1.17 → 1.19 is additive from HPX’s perspective.

The core moves with the engines, and hpx now declares it. heliaRT links a consumer-provided ns-cmsis-nn (heliaCORE); it does not vendor one. The previously qualified v7.29.2 is the core heliaRT 1.18.0 (withdrawn) shipped “with its float defects as known issues”, and heliaAOT 0.19.0 refuses it outright: every generated module carries an unconditional #error "CMSIS-NN version too old; need at least v7.31.0" whose rationale names v7.29.x/v7.30.0 as defective for int8 as well (helia-aot#356). So this revision qualifies ns-cmsis-nn v7.31.0 and, because neuralSPOT-X’s packaged registry (0.7.17, and still 0.8.1) resolves v7.29.2, hpx declares nsx-cmsis-nn at that ref on both engines’ source routes instead of inheriting the registry’s choice. The module thereby moves from the registry-governed tier to the hpx-declared tier (next section); neuralSPOT-X itself is unchanged. heliaRT 1.19.0 accepts any >= v7.28.0, so both engines now build against one core with no override, and a run stamps qualified.

Integration change. The float kernels are opt-in and must be requested before the ns-cmsis-nn module is added, since an option() default cannot be overridden afterwards. engines/cmsis_nn.py::cmsis_nn_cmake_vars derives the switches from the model: ARM_NN_ENABLE_F32 when it computes in float at all, and ARM_NN_ENABLE_F16 additionally when it carries FLOAT16 tensors (computed or dequantized weights) on a Cortex-M55, since ns-cmsis-nn below v7.30.0 ICEs on GCC 14 for its fp16 sources (PR 118460). An integer-only model links neither: measured on the int8 KWS DS-CNN, dropping the forced fp32 kernels returns 32.6 KB of MRAM (311,180 B → 277,764 B on heliaRT) with cycles unchanged at 2.06 M, which recovers the growth 1.19.0’s unconditional requirement introduced. heliaAOT is unaffected either way (151,180 B), since it generates only the kernels its graph uses. A model that cannot be read enables fp32 rather than profiling float work on the reference path unannounced. ARM_NN_ENABLE_* is the only spelling the core accepts; emitting a retired NSX_CMSIS_NN_ENABLE_* name is a configure error, and a regression test asserts no board or model combination emits one (#279).

Behavior deltas in 1.19.0 that a float baseline must expect (all toward correctness): NaN now propagates through float ADD/MUL instead of being clamped; QUANTIZE/TRANSPOSE_CONV/SVDF kernel failures surface as kTfLiteError instead of kTfLiteOk over unwritten output; float16 UNIDIRECTIONAL_SEQUENCE_LSTM output shifts ~2.3e-2.

Verified. Host: the full suite passes under helia-aot 0.19.0 + litert 2.2.0 with no other change, and the int8/uint8 Softmax preflight boundaries (#147) did not move. heliaAOT emits native arm_*_f32 kernels for an FP32 graph and native arm_*_f16 kernels for an all-FLOAT16 graph on all three M55 targets; its float coverage is partial (MEAN and a tier of shape ops remain int8/int16-only; see helia-aot#345). Bench (Apollo510 EVB, Arm GNU 15.2.Rel1, 96 MHz, core v7.31.0, tests/fixtures/kws_float_fp32.tflite and its all-FLOAT16 cast, 43,520 MACs): heliaRT and heliaAOT agree within 0.3 %; FP32 ≈ 1.17 M and FP16 ≈ 1.08 M clean cycles on both, with identical layer profiles, so the single-input-channel first CONV_2D (93 % of the run) and the slower-in-f16 FULLY_CONNECTED are heliaCORE kernel properties, not either runtime’s. Every plan-vs-measured memory region matched. int8 is unchanged in speed but larger: the qualified int8 KWS DS-CNN measured 2.07 M cycles on 1.17.0 and 1.19.0 alike (−0.02 % on the same core, run noise) while .text grew 277,420 B → 308,868 B (+31.4 KB) with .data/.bss/arena unchanged, consistent with the fp32 kernel paths 1.19.0 requires riding into an int8 image (compiling the fp16 kernels too, as an earlier run did, added another 35 KB; hence the model gating). Moving the core v7.29.2 → v7.31.0 on 1.19.0 changed that int8 run by −0.4 % cycles and +2.3 KB .text. With the core declared at v7.31.0, hpx validate passes kws/vww/ic/ad on both engines (8/8; heliaAOT was 0/4 on v7.29.2), every float run above reproduces its numbers with no override and stamps qualified, and the converter’s weights-only FP16 form now builds and runs on heliaAOT (1,230,144 cycles); heliaRT still rejects that form (helia-rt#255). ExecuTorch’s ns provider, which shares the module helper, also builds and runs kws on v7.31.0 (2,135,764 clean cycles, qualified). Two of the five power windows were INVALID by design: the JS320 GPI-stream gate edges disagreed with the firmware window clock and host poll edges (which agree to <5 ms) by a random −54 / +81 / +38 / −1 / +5 ms (#249).

heliaRT 1.17.0 (issue #89) is a build-system and docs release from HPX’s perspective: the prebuilt distribution’s exported-symbol surface, header set, and core/toolchain/variant library matrix are identical to 1.16.0 (all 18 archives verified symbol/member/.text-identical in review). NB the CMake changes land squarely in HPX’s default build path (the registry flow is a source build, engines/helia_rt/adapter.py, and the changes land in the backend-target function it enters), but each is behavior-neutral for HPX, verified rather than assumed. The six changes: (1) the recording allocators and (2) the test/mock/fake helpers drop out of the default source set (both now opt-in profiles; HPX uses MicroAllocator::Create and none of the helpers); (3) the removed NS_CMSIS_NN define branches nothing (zero preprocessor uses in the entire tree, ns-cmsis-nn self-defines it in arm_nn_types.h); (4) the newly-unconditional ethos_u/ethosu.cc TU is an inert stub without the driver; (5) the new explicit -fno-exceptions (CXX, PRIVATE) is a strict subset of what the NSX board flags already impose on all three toolchains; (6) a private ns-cmsis-nn include-dir was added on the link branch, upstreaming the header-prefix shim helia-rt’s NSX module already carried. Empirically, the full 1.16→1.17 source-axis A/B showed a 0 B .text delta, and single-run cycle deltas of −41 and −531 (−0.002% / −0.026%; KWS DS-CNN, two independent apollo510_evb benches, gcc), at or near run noise, with no claim of a real kernel effect. hpx compare surfaces such a promotion via the engine_version comparability dimension (#193): the measured run_metadata.engine.version renders as an Engine version row in the compare Config table and an informative dimension.engine_version_differs warning when the two sides differ (absent for artifacts predating the dimension, and for tflm/executorch runs, which record no resolved version). HPX consumes the Ethos-U kernel support since the atomiq110 work (PR #284): the ethos_u engine backend opts in via NSX_HELIA_RT_ENABLE_ETHOSU on a heliaRT source build, which requires a helia-rt newer than 1.17.0 for the flag mapping. Minimum supported version stays 1.16.0 for the CPU backends (which rely on nothing 1.17-only).

neuralSPOT-X 0.8.0 added the atomiq110_fpga_turbo starter profile (retained in 0.8.1), and nsx-ambiq-sdk v5.2.25 adds the nsx-npu module (Ethos-U core driver and bring-up) that both engines’ ethos_u backend declares. Those are the two reasons this revision moved off v5.2.24. 0.7.17 had fixed the J-Link flash-verification false negative that aborted idempotent re-flashes of an unchanged image, and enforces ExitOnError 1 in generated flash recipes (AmbiqAI/neuralspotx#220). The packaged registry still resolves ns-cmsis-nn at v7.29.2; that promotion advanced the qualified ref in lockstep, and the 2026-09 revision then moved nsx-cmsis-nn into the hpx-declared tier at v7.31.0.

The qualification states in this document cover dependency and source resolution only. They do not qualify Atomiq110 hardware, make measurements from its experimental FPGA target representative of production silicon, or promote that target’s support status.

Baseline refs relate to the packaged registry in two tiers. Modules HPX itself declares in generated apps (the SDK monorepo, PMU, heliaRT, nsx-sensors and, since the 2026-09 revision, nsx-cmsis-nn) carry manifest pins at the baseline refs, and those pins defeat the packaged registry (concretely: a module whose NsxModuleRef.ref is set is rendered into the app’s module-registry override, which NSX locking honours over its packaged default); nsx-sensors stays at its audited v0.3.0 pin (0.7.17’s registry default was older; 0.8.1’s matches it), and nsx-cmsis-nn builds at v7.31.0 where the registry would resolve v7.29.2. The stock-TFLM engine’s declared modules (nsx-tflite-micro, arm-cmsis-nn) sit in the registry-governed tier: hpx renders informational manifest revisions for them, but NSX locking reads only the registry’s module revision. For this whole tier the post-lock validation refuses to build when the resolved commit disagrees with this baseline, so a promotion must advance exactly these refs together with the tool, never “adopt the registry” for the pinned tier. nsx-nanopb (promoted in 0.7.16) is outside HPX’s qualified module graph. The neuralSPOT-X tag is verified and stored as its peeled commit. The nsx-tflite-micro and arm-cmsis-nn rows still pin the same qualified v0.1.0 tags but are now recorded as their peeled commits; earlier baselines recorded the annotated tag-object ids, which a resolved NSX lock can never match. All other project, module, and engine refs (SDK, PMU, heliaRT, nsx-sensors) are unchanged.