Outputs and Metrics

Overview

Ethos-U runs in MLIA usually give you two things at once:

• A quick human-readable summary in the console.
• Structured results that you can inspect later, save as JSON, or compare between runs.

The most important part is not the format itself, but what the output helps you decide. Good Ethos-U metrics help you answer questions like:

• Is the model broadly viable for this target profile?
• Is the cost mainly compute or memory?
• Which layers or operators deserve attention first?
• Do the deeper results change what the quick estimate suggested?

Common output forms

Typical Ethos-U outputs include:

• Console summaries printed directly by MLIA.
• JSON output when --json is used.
• Backend-generated artifacts such as CSV data in Corstone-oriented flows.
• Logs and intermediate files in the output directory.

Treat the console output as the summary and the JSON or artifacts as the detail you return to when something needs explanation.

Example JSON shape

The following abridged fragment focuses on result data and omits the required standardized-output envelope. Metrics are represented as objects in a list. Per-operator and per-layer metrics are stored in breakdowns linked to result-local entities

{
  "schema_version": "1.1.0",
  "target": {"profile_name": "ethos-u55-256", "target_type": "npu"},
  "backends": [{"id": "vela", "name": "Vela Compiler"}],
  "results": [
    {
      "kind": "performance",
      "producer": "vela",
      "metrics": [
        {"name": "total_cycles", "value": 123456, "unit": "cycles"},
        {"name": "inference_time", "value": 207.0, "unit": "ms"},
        {"name": "model_weight_memory", "value": 4096, "unit": "bytes"}
      ],
      "entities": [
        {
          "id": "source_operator/operator/0",
          "kind": "source_operator",
          "name": "operator/0",
          "placement": "NPU"
        }
      ],
      "breakdowns": [
        {
          "entity_id": "source_operator/operator/0",
          "metrics": [
            {
              "name": "op_cycles",
              "value": 1000,
              "unit": "cycles",
              "aggregation": "sum"
            },
            {
              "name": "sram_usage",
              "value": 4096,
              "unit": "bytes",
              "aggregation": "max"
            }
          ]
        }
      ]
    }
  ]
}

The complete document also includes run, tool, model, context, entity, advice, warning, and breakdown fields where applicable. Treat metric names as data: find the object whose name matches the metric you need instead of relying on array order.

What to read first in a Vela run

When the run uses vela, start with:

1. total_cycles
2. Memory-related cycle counters such as sram_access_cycles and dram_access_cycles
3. The small number of operators contributing most of the cost.

Common Vela metrics include:

• total_cycles
• npu_cycles
• inference_time
• inferences_per_second
• target_utilization
• sram_access_cycles
• dram_access_cycles
• model_weight_memory
• Memory area size metrics.
• Additional Vela summary statistics such as encoded weights or total bytes when Vela reports them.
• Per-operator cycle and utilisation data.

Vela omits optional summary metrics that it reports as NaN or infinity so that the output remains valid JSON. Required standardized metrics use "availability": "unavailable" with a reason when their value cannot be derived.

Layer aggregation

Layer breakdown metrics can include an aggregation field that defines how to combine values across layers:

• sum applies to additive work and traffic metrics such as cycles, MAC count, and transferred bytes.
• max applies to peak or high-water-mark metrics such as SRAM usage.
• Metrics without an aggregation policy should not be combined automatically.

These policies describe how to roll up breakdown values; they do not change the model-level metrics already reported in results[].metrics.

What Vela numbers help you decide

Use them to decide whether the next step should be to:

• Fix unsupported or awkward mapping.
• Reduce memory pressure.
• Focus on a few expensive operators.
• Stop and change the model before doing deeper validation.

What to read first in a Corstone run

When the run uses a Corstone backend, start with:

1. The total cycle picture.
2. Active-versus-idle style metrics.
3. Traffic-related counters.
4. Layer-level detail.

Common Corstone signals include:

• npu_active_cycles
• npu_idle_cycles
• npu_total_cycles
• AXI data-beat counters.
• Standardized memory and weight metrics when they can be derived from the backend result.
• Per-layer CSV metrics covering cycles, memory access, and utilisation.

What Corstone numbers help you decide

Use them to decide whether the deeper path confirms the quick estimate, or whether system-level behaviour is changing the story in a useful way.

A practical reading pattern

A good review pattern is:

1. Read the top-level total first.
2. Decide whether the result looks acceptable, suspicious, or clearly poor.
3. Separate compute-heavy behaviour from memory-heavy behaviour.
4. Only then move to operator or layer detail.

This keeps you from getting lost in details before you know what kind of problem you are dealing with.

When numbers look bad

If total cycles are high but most of the cost comes from a few operators, focus there first.

If memory-related metrics dominate, treat that as a sign that model layout, tensor sizes, or data movement deserve more attention than the raw compute path.

If Vela and Corstone tell noticeably different stories, do not assume one is wrong. Differences often mean the deeper path is revealing behaviour the quick estimate could not show on its own.

If expected metrics are missing, or the result shape looks odd, treat that as a troubleshooting problem before drawing performance conclusions.

Cross-links

• See backends for choosing between Vela and Corstone variants.
• See the CLI guide for commands that produce these results.
• See troubleshooting if output is missing, incomplete, or surprising.

Terminal compatibility reasons

Ethos-U supplies Vela support descriptions and constraint details.

Reasons are stored consistently in entity-linked checks:

{
  "id": "operator_support_0",
  "entity_id": "source_operator/example",
  "status": "fail",
  "details": {
    "reasons": [
      {"description": "Operator is unsupported", "detail": ""}
    ]
  }
}

Each reason has a description and a detail string, which may be empty. A rejection without a backend explanation has an empty reasons list; passing checks may omit reasons. Reasons are not duplicated in entity attributes. Entity kind and placement remain in JSON. The terminal entity table keeps Name, Kind, ID and Placement, joins checks by entity_id, and combines multiple reasons with semicolons. Reason appears only when a displayed entity has a reason; other rows show -. Long reasons wrap to the terminal width, and full details remain in JSON. Whole-model errors are not assigned to individual operators.