# Layer and segment analysis

## Two different views

Vela's per-layer performance output provides estimated attribution. When that output is available, helx can produce per-layer and per-original-operation breakdowns and Model Explorer overlays. Attribution derived from compiler estimates is not independent measurement of every layer.

Per-segment analysis changes the experiment: helx inserts `ETHOS_U_STREAM_SPLIT` fences into the source model, recompiles it, runs it again on the FVP and collects counters at the segment boundaries. It emits segment PMU CSV and estimated-versus-executed comparison data.

The U85 `sram_stall` profile counts read and write queue pressure together;
see the [read/write diagnostics walkthrough](https://ambiqai.github.io/helia-estimator/guides/view-results/#sram-read-and-write-diagnostics).
Queue counters may overlap useful work and each other, so they do not measure
additive time lost or predict a speedup. U85 SRAM events sum across AXI
ports; event/NPU-active-cycle ratios can exceed 100% and are not elapsed-time
occupancy. Layer lanes are heuristics.

## Enable deliberately

Use the `per_layer` fields in the [configuration schema](https://ambiqai.github.io/helia-estimator/reference/config/) and the supplied examples. Per-segment PMU profiling is supported by LiteRT, heliaRT and heliaAOT (1.3.0 or later).

Fences can change scheduling and therefore the measured workload. Compare the fenced and unfenced runs explicitly; do not assume segment totals reproduce the original model's execution.

See the [ETHOS_U_STREAM_SPLIT contract](https://ambiqai.github.io/helia-estimator/guides/stream-split/) for boundary semantics and model identity, and the [runtime contract](https://ambiqai.github.io/helia-estimator/guides/runtime-contract/) for PMU profiles and acquisition rules.

## Compare counters carefully

A matching event list is insufficient to compare helx and heliaPROFILER captures. Counter reset, accumulation, overflow handling and cycle-counter semantics also matter. The runtime contract describes these acquisition differences.

## Energy calculation boundaries

Core energy uses NPU cycles multiplied by a reference coefficient and mode scaling. Memory energy uses transferred beats, beat width, per-bit coefficients and model overhead. Total energy combines the terms; power divides energy by the modelled inference duration.

This covers the model's accounted NPU and memory transfers. It is not whole-board power, and does not account for every peripheral, host workload or leakage condition. Actual AT110 coefficients and specified power numbers are not included in this documentation.

For step-by-step model overlays and timelines, see
[Parse and visualize results](https://ambiqai.github.io/helia-estimator/guides/view-results/).

The [energy profile guide](https://ambiqai.github.io/helia-estimator/guides/energy-profiles/) explains
versioned characterization files, external profiles and a fictional worked example.