Engines
Start with heliaAOT when your model is supported. It compiles your model into C, plans execution and memory at build time, and runs without an interpreter. Use hpx to measure the latency, memory and energy tradeoffs on your target.
Prefer an interpreter? heliaRT brings Ambiq-tuned kernels to a familiar LiteRT workflow. It remains the default when you do not specify an engine.
Which engine
Section titled “Which engine”| Engine | Use it for | Model |
|---|---|---|
| heliaAOT | Our recommended starting point for compiled inference and per-tensor memory placement. | .tflite |
| heliaRT | Interpreter-based inference with Ambiq-tuned kernels. The hpx default. | .tflite |
| LiteRT | An upstream interpreter baseline to compare with the HELIA engines. | .tflite |
| ExecuTorch (experimental) | Profiling an exported Cortex-M program from your PyTorch workflow. | .pte |
Support depends on your model’s operators and target. Compare saved runs to choose the engine that meets your requirements; gains vary by model and configuration.
heliaAOT
Section titled “heliaAOT”Install the AOT extra, then select helia-aot in your profiling command:
hpx profile --config hpx.yml --engine helia-aot --output-dir results/aotYour configuration supplies the model and board. hpx invokes the compiler and builds the generated code into profiling firmware. If compilation reports an unsupported operator, check heliaAOT operator support or try heliaRT for that model.
Once the first run works, explore per-tensor memory placement. Keep the model and measurement settings consistent while testing placement choices.
heliaRT
Section titled “heliaRT”Choose helia-rt to run a TFLite model with Ambiq’s interpreter and kernel backends:
hpx profile --config hpx.yml --engine helia-rt --output-dir results/rthpx resolves the runtime and builds the required operators into the firmware. The first build needs network access to fetch pinned dependencies through neuralSPOT-X.
LiteRT
Section titled “LiteRT”Use litert for an upstream baseline: LiteRT for Microcontrollers (TensorFlow Lite Micro), with reference or upstream CMSIS-NN kernels:
hpx profile --config hpx.yml --engine litert --output-dir results/litertSelect the kernel backend deliberately and record it with the result. The engine comparison example walks through the setup.
ExecuTorch
Section titled “ExecuTorch”ExecuTorch support is experimental. Use executorch for an exported .pte program. A matching manifest from helia-torch supplies the program’s memory and I/O defaults; otherwise configure them explicitly. See ExecuTorch configuration.
Power capture is not supported by this engine. Keep power.enabled: false and compare timing and memory instead.
Compare your runs
Section titled “Compare your runs”Run the same model with the same board and measurement settings, changing the engine. Then compare the result bundles:
hpx compare results/litert results/aotRead the configuration differences and comparability notes alongside the metrics. A different operation sequence can prevent a layer-by-layer comparison even when whole-model measurements remain useful. See Comparing runs.
Go further
Section titled “Go further”- Engine configuration: adapter options, dependency overrides and source builds.
- Memory placement: control where weights and working memory live.
- Toolchains: choose the compiler used to build profiling firmware.
Testing an unrecorded AOT version
Section titled “Testing an unrecorded AOT version”For local development, explicitly opt out of the AOT package version range:
engine: type: helia-aot allow_unsupported_version: true config: cmsis_nn_path: /path/to/ns-cmsis-nnengine.allow_unsupported_version defaults to false, accepts only a YAML
boolean, and is supported only for helia-aot. It permits an installed AOT
version outside HPX’s recorded range; it does not install a package, change
CORE selection, or suppress compiler/build errors. The local CORE path above
is optional and remains an independent selector.
Every opted-in run warns with the installed version and recorded range and
records development-overrides with engine.allow_unsupported_version in
its compatibility provenance, even when the installed version is in range.
The actual AOT version remains in run metadata. Such a run is experimental,
not evidence that the dependency combination is generally compatible.