Model and target requirements

Choose the hardware the generated module will run on. This walkthrough uses apollo510_evb; later, the firmware build must select the same board family. Target inspection tells you the compiler’s assumptions. Conversion then checks whether it can lower your particular graph.

List the targets

Registered targets · excerpt

        $
        helia-aot list-targets
      
        
        TARGET                 CPU         CAPABILITIES
      
        
        ---------------------  ----------  -------------------------------
      
        
        apollo4p_evb           cortex-m4   MCU, USB, DSP
      
        
        apollo510_evb          cortex-m55  MCU, USB, PSRAM, DSP, MVE, FP16
      

$ helia-aot list-targets TARGET CPU CAPABILITIES --------------------- ---------- ------------------------------- apollo4p_evb cortex-m4 MCU, USB, DSP apollo510_evb cortex-m55 MCU, USB, PSRAM, DSP, MVE, FP16

Selected rows from the registry output are shown above. Your installed version prints the complete list.

This reads the installed package’s registry, so it needs no board or repository checkout. The Targets reference presents the same registry data. Names are case-insensitive; emitted artifacts use the canonical lowercase spelling.

Read one target

helia-aot target-info --name apollo510_evb

Check the core, capabilities, memory capacities, preferred memory order and minimum alignment against your firmware setup. Use the installed registry output and the target reference for exact values.

The planner uses these capacities and kernel selection uses these capabilities. They do not configure your board clock, reserve memory from your application or install linker sections. The firmware build and linker map must agree with the plan. Do not choose a larger target simply to make a model fit.

platform.name and module.type answer different questions: the former names the hardware; the latter selects integration files such as Zephyr or neuralSPOT. This walkthrough uses apollo510_evb with module.type: zephyr.

Custom targets and application memory budgets

For a smaller application memory budget, use memory constraints, or set platform.memories on a registered target name: the sizes you give replace the target’s for that conversion. Registered sizes are the totals a program links into, so leave your application’s own share with max_size. Other platform fields are ignored for registered target names. A changed hardware definition needs a complete custom target under an unregistered name; see custom targets. Native FP16 support also has a Cortex-M55 CPU fallback, so even a custom definition with an empty capability list does not universally disable it.

Check your model

Input format. heliaAOT reads LiteRT .tflite flatbuffers. Convert ONNX, SavedModel or a training checkpoint upstream first. Training and calibration are not part of heliaAOT.

Shapes. Every tensor extent must be known before planning. A dynamic shape signature can be accepted when concrete model inputs and shape propagation resolve it. Runtime-dependent output sizes cannot become fixed allocations; the conversion reports unresolved tensors before planning.

Precision. Check the role of each tensor as well as the operator name.

Path	Check before building
int8	Operator quantization, shapes and supported attributes; the supplied KWS model uses this path
int16	Each operator’s activation, weight and state requirements; int16 state does not imply int16 model I/O support
FP32	Operator coverage and any required library float switches
FP16 compute	Operator coverage, native FP16 target support and library switches

Half-precision storage is different from native FP16 computation. For example, a DEQUANTIZE node can widen FP16 weights to FP32 in software on a non-FP16 target. Operators requiring native FP16 reject an incompatible target during conversion. Precision explains the gates and build requirements. Floating-point operator support is experimental.

Check your operators

Read the operator catalog for the model’s operators, tensor types and restrictions. A listed name does not guarantee every shape, attribute or input/output type combination is supported. Copy and alias operations also differ from arithmetic kernel calls.

The authoritative lowering check is the conversion: it resolves every remaining node before emitting code. There is no separate per-model coverage-report command. A successful conversion establishes that the graph can be lowered with that configuration. Linking and comparing its output are later checks.

For this first deployment, use the known model and fixture on the next page. Once that works, replace them with your own model and repeat these checks.