# NPU power and energy profiles AT110 remains a specific supported target: Ethos-U85 with 256 MACs, ULP and HP operating modes, SSRAM and its port-1 memory choices. Those silicon and timing facts come from helia-npu's `socs/atomiq110.yaml`, through `load_soc`. Energy characterization is a separate HELX input, not a second silicon definition. ## One source for characterization `helia_estimator/platforms/at110.yaml` references the versioned profile under `helia_estimator/energy_profiles/`. That area is the sole maintained copy of AT110 energy coefficients, their evidence and historical calibration numbers. The current private distribution bundles it so existing examples still work. Moving that profile to controlled distribution is a later publication step; this cleanup does not make the current repository or its history public-safe. The Arm reference in `helia_npu.npu_reference` is public reference data. AT110's mode scaling and physical-memory transfer energies are separate characterization inputs. Inspect the values available in your installation with: ```bash uv run helx platform show at110 uv run helx platform show at110 --verbose ``` Do not copy that output into public examples or reports. Characterization revisions and raw evidence belong with the profile, not in duplicated guide tables. Confirmed, fitted and unverified describe evidence status, not an accuracy guarantee. A placeholder stays unverified until it is characterized. ## Supply a profile outside the checkout A local platform wrapper can reference a supplied file without copying values into the package. For example, save this as `local/at110-characterized.yaml`: ```yaml soc: atomiq110 energy_profile: /path/to/authorized/at110-energy.yaml ``` ```bash uv run helx validate platform local/at110-characterized.yaml uv run helx platform show local/at110-characterized.yaml ``` Point `run.platform` in your experiment at that wrapper. A relative `energy_profile` path resolves against the wrapper's directory. The profile has `schema_version: 1`, `id`, `revision`, compatible `soc` and `soc_revision`, an `energy` block and optional `revisions` history. Unknown fields, missing files and incompatible SoC revisions are errors. Inline `energy` remains supported for custom/synthetic platforms; give exactly one source. Result provenance records the selected profile id, revision and SHA-256 of its captured bytes. Its revision can change independently of the SoC definition. The generated energy YAML binds physical memories to the run's AXI ports and converts pJ to joules. FVP and Vela estimates use the same selected model. Legacy `run.energy_model` can replace that generated model with a port-bound YAML; such an override does not claim the platform profile's identity. ## Equations and a fictional example Core energy is `NPU total cycles × reference pJ/cycle × mode scaling`. Memory energy sums `read bits × read pJ/bit + write bits × write pJ/bit`, then applies the configured logic overhead. Beat width comes from the SoC, not the profile. For illustration only, take a fictional 100 pJ/cycle reference, scaling 0.5, 2 pJ/bit reads and 3 pJ/bit writes. Then 1,000 cycles cost 50 nJ of core energy; a 128-bit read costs 256 pJ. These numbers are not AT110 characterization. The what-if platforms similarly use explicitly synthetic energy while retaining useful, concrete timing/placement experiments. ## Interpretation and ownership Core, memory, total energy, average power and efficiency remain experimental. FVP counters are simulator observations; energy is calculated from a profile. The profile defines its characterization window and whether static energy is folded into a coefficient. These estimates do not establish application CPU, peripheral, retention or whole-board power. Energy-enabled result bundles and logs can expose coefficients directly or through their derived values. Share them under the same conditions as the profile. Public fixtures use independent synthetic inputs. helia-platforms owns the shared silicon catalogue/overlay design; energy remains a consumer responsibility. When its public catalogue is ready, the existing SoC-loading boundary can adapt those facts while HELX retains its characterization profiles. Today the silicon provider is helia-npu.