# 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

```text
$ 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](https://ambiqai.github.io/helia-aot/reference/targets/) presents the
same registry data. Names are case-insensitive; emitted artifacts use the
canonical lowercase spelling.

## Read one target

```sh
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](https://ambiqai.github.io/helia-aot/reference/targets/) 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](https://ambiqai.github.io/helia-aot/guide/memory-placement/#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](https://ambiqai.github.io/helia-aot/guide/targets/#overriding-a-platform). 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](https://ambiqai.github.io/helia-aot/guide/precision/) explains the gates
and build requirements. Floating-point operator support is experimental.

## Check your operators

Read the [operator catalog](https://ambiqai.github.io/helia-aot/reference/operators/) 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.