# Understand your model before the board.

Understand your model. Before the board.
Compile a model, simulate its execution and inspect the results. heliaEstimator connects each estimate to the configuration and platform assumptions behind it.
[Get started](https://ambiqai.github.io/helia-estimator/getting-started/)
[Understand the estimates](https://ambiqai.github.io/helia-estimator/guides/estimates/)

ONE EXPERIMENT · ONE RESULT BUNDLE
01 Configure Model · runtime · platform
02 Compile & simulate Vela · Corstone FVP
03 Inspect & compare Results · artifacts · provenance

## One question. A reproducible experiment.

Explore how a model behaves under an explicit runtime, memory setup and platform configuration. Start with compilation, add simulation when you need it, and keep the evidence with the result.

Start small → Run a supplied Vela-only example before setting up the simulator.
Make assumptions explicit → One configuration captures the model, runtime and platform choices.
Keep the evidence → Inspect structured results, artifacts and the provenance behind each run.

## From configuration to counters.

One YAML file connects the model you compile to the environment you simulate. The platform definition supplies the memory assumptions used along the way.

01 · CONFIGURE
Describe the experiment
Select a model, runtime, NPU mode and memory placement. Validate the configuration before running it.
02 · COMPILE
Let Vela schedule the work
Generate the compiler configuration and produce an optimized model, NPU command streams and compiler analysis.
03 · SIMULATE
Execute with memory timing
The Corstone FVP runs the selected runtime. Timing adapters model memory latency, bandwidth and outstanding transactions.
04 · INSPECT
Read the evidence
Inspect NPU cycles, memory traffic and modelled energy alongside the configuration, tool versions and platform provenance.

[Follow the complete process →](https://ambiqai.github.io/helia-estimator/guides/how-it-works/)

## Explore the tradeoffs that matter.

Change one dimension at a time and compare runs on a consistent basis. helx makes the choices explicit so a difference in results can be traced back to the experiment.

Where should data live? → Compare placements for weights, tensor arena and cache across the platform's available memories.
Which runtime fits? → Explore LiteRT, heliaRT and heliaAOT using the supported target and execution combinations.
Where does time go? → Inspect NPU counters and compiler attribution, then use fenced segment runs for a closer look.

## Focus on the NPU memory paths.

For Atomiq AT110, helx models Ethos-U85 execution with explicit memory placement and timing. It translates the selected memories into Vela's logical ports and the FVP timing adapters.

The NPU has three physical AXI ports connected to the shared AXI crossbar. Vela represents their memory traffic through two logical port classes: Sram (port 0) and Dram (port 1). These are compiler abstractions, not two physical ports on the crossbar.

In the AT110 model, SSRAM maps to Sram; one of HBLRAM, PSRAM or RRAM maps to Dram per run. RRAM is a weights-only choice because the physical memory is read-only.

This is an NPU-focused model. CPU execution and full-system contention are outside its timing scope.

[Explore AT110 settings →](https://ambiqai.github.io/helia-estimator/guides/at110/) · [Understand port mapping →](https://ambiqai.github.io/helia-estimator/guides/port-mapping/)

Physical NPU memory connections
Ethos-U85 has three physical AXI ports connected to a shared AXI crossbar. Cortex-M55 with MVE Helium also connects to the crossbar. SSRAM, HBLRAM, PSRAM and RRAM connect to that fabric. Vela's two logical port classes are a separate modelling abstraction.

Ethos-U85
3 physical
AXI ports

Cortex-M55

MVE / Helium

AXI
crossbar

SSRAM

HBLRAM

PSRAM

RRAM

Physical connectivity. Vela represents NPU memory traffic using two logical classes: Sram (port 0) and Dram (port 1).

## A result you can inspect and reuse.

Each experiment writes a self-contained bundle. Read the summary in the terminal, compare structured fields, or inspect the compiler and simulator artifacts behind a result.

Readable summaries
helx show and Markdown summaries bring the run, counters, memory and provenance together.
Structured outputs
JSON and CSV support your own analysis. The manifest records files, sizes and hashes.
Repeatable comparisons
Keep the input configuration and platform revision with every result. Export bundles into a comparison table.

[See representative output →](https://ambiqai.github.io/helia-estimator/getting-started/results/)

## Start with the setup that suits you.

Compile a first model without the FVP, then add simulation when you need execution counters. On Apple silicon, run native host tools with the FVP in Docker, or use the supplied full dev container. Linux supports native FVP execution; Windows uses the dev container for full runs.

[Choose your installation path →](https://ambiqai.github.io/helia-estimator/getting-started/install/)

## Estimates with context.

Simulator counters and modelled energy are not measurements from a physical board. Every result carries its platform revision and value status so you can see the assumptions behind a comparison. [Learn how to interpret results](https://ambiqai.github.io/helia-estimator/guides/estimates/).

Public documentation. Access by request.
heliaEstimator is available for selected customer evaluations. Contact your Ambiq representative to request the tool and discuss your model and target. These docs are open to everyone.