Skip to content
heliaEstimator
User guide
HELIA HUB

How estimation works

From YAML to a result bundle

Section titled “From YAML to a result bundle”
Experiment pipeline YAML resolves into compiler and memory-timing paths. Vela output and timing adapters join in the runtime and FVP, producing the result bundle. Experiment YAML + model Platform · NPU mode · memory placement Resolve the experiment Validate inputs and derive platform settings COMPILER PATH Vela compilation Optimized model + NPU command streams MEMORY PATH Timing adapters Latency · bandwidth · outstanding requests Runtime + Corstone FVP Execute the compiled model; collect PMU counters Result bundle Cycles · memory traffic · analysis · provenance
Compiler output and memory timing meet at the FVP. Vela-only experiments stop after compilation.

1. Resolve the experiment

Section titled “1. Resolve the experiment”

The YAML names one model, one memory placement and one runtime. run.platform selects the platform; run.platform_mode selects its NPU mode. A platform combines the SoC definition with an energy model and revision history. Validation rejects unsupported execution combinations before building the runner.

The same selected memories drive both the compiler configuration and timing adapters. This keeps the experiment’s assumptions explicit, although the compiler and simulator use them differently.

2. Compile with Vela

Section titled “2. Compile with Vela”

Vela receives the LiteRT model, NPU configuration, memory mode and generated system configuration. It schedules operations and emits an optimized model containing NPU command streams, a summary CSV, and analysis output when requested. Some operations may remain on the CPU; compilation does not establish that every operation runs on the NPU.

The generated vela_config.ini includes memory latency, burst length, outstanding transactions, port count and clock scale. Inspect it with:

Terminal window
uv run helx platform export-vela-ini at110 --mode ULP
uv run helx platform export-vela-ini at110 --mode HP

Vela estimates describe compiler modelling. They are kept distinct from counters collected by an executed FVP run.

3. Build the runtime

Section titled “3. Build the runtime”

helx builds the selected LiteRT, heliaRT or heliaAOT runner. Its linker layout places constants, tensor arena and optional fast cache in the FVP regions required by the selected memory mode. The FVP’s SRAM and DDR act as proxies for the platform memories; they are not literal AT110 memory devices.

4. Apply timing and execute

Section titled “4. Apply timing and execute”

Timing adapters sit on the simulated NPU memory paths. Their latency, queue depth, burst and bandwidth settings approximate the selected platform’s memory behaviour. Physical latency is converted to NPU cycles as ceil(latency_ns × npu_clock_hz / 1e9).

The bandwidth fraction is limited by the memory-interface clock relative to the NPU clock. A faster NPU clock therefore does not imply proportionally faster memory. Compiler-specific adjustments to the Vela configuration are not a change to the physical memory model.

The runner collects cycle counts and port-level memory-transfer counters. Port mapping joins the names used by Vela, the adapters and the PMU.

5. Analyse and preserve

Section titled “5. Analyse and preserve”

The pipeline combines counters with the platform model and writes JSON, CSV, Markdown and a file manifest. Core energy is derived from cycles and mode scaling; memory energy is derived from transferred beats and per-bit coefficients. This site does not publish AT110 power specifications or energy coefficients.

Optional analysis adds estimated per-layer attribution or a second, fenced execution for per-segment PMU counters. See Layer and segment analysis.

What the simulation does not establish

Section titled “What the simulation does not establish”

The focus is Ethos-U85 execution and its memory paths. The FVP host CPU runs the inference harness; its timing is not a Cortex-M55 performance estimate. Use NPU counters for the comparisons this model is designed to support, rather than treating CPU or whole-run timing as AT110 system performance.

Corstone-320 supplies the U85 simulation with a Cortex-M85 host. That host difference does not change the focus of the experiment: NPU execution under explicit memory-timing assumptions.

Other-master contention, complete interconnect saturation, detailed DRAM page/refresh behaviour, CPU clocks and TCM placement are not modelled as a full SoC. Timing fits carry provenance; they must not be mistaken for physical memory specifications.