Skip to main content

Ethos-U Backends

Use this page when you are deciding which Ethos-U backend to run for a model and what kind of information each backend is intended to give you. It is for choosing the right backend for the question you need to answer, not for learning the basic MLIA command flow.

BackendUse it when you wantTypical next step
velaThe fastest answer about compatibility, estimated cycles, and memory pressureDecide whether the model is worth iterating further
corstone-300, corstone-310, corstone-320A deeper platform-oriented view of where time is goingValidate or investigate results that need more detail

Choosing between backends​

If you are still deciding whether the model is a good fit for the selected Ethos-U target, start with vela.

If the model already looks promising and you need deeper evidence about runtime behaviour, move to a supported Corstone backend.

If you are unsure, the practical default is simple: use vela first, then only bring in a supported Corstone backend when you need more detail than the fast estimate gives you.

Vela backend​

vela is the quickest way to answer questions like:

  • Does the model map cleanly to the target profile?
  • Is the estimated cost broadly acceptable?
  • Is the result obviously limited by memory rather than compute?
  • Which operators should you inspect first?

Vela backend: good first commands​

Use compatibility first when support is the main concern:

mlia check my_model.tflite --target-profile ethos-u55-256 --compatibility --backend vela

Use performance when you want a quick estimate and machine-readable output:

mlia check my_model.tflite --target-profile ethos-u65-512 --performance --backend vela --json

Vela backend: what to look at in the result​

A Vela run is most helpful when you read it in this order:

  1. Total cycles.
  2. Memory-related cycles.
  3. The small number of operators doing most of the work.

That sequence usually tells you whether the next action should be:

  • Fix compatibility issues.
  • Reduce memory pressure.
  • Focus on a few expensive operators.

When Vela is enough​

If the Vela result is already clearly poor, you usually do not need a heavier backend to tell you that the model needs work. The more useful follow-up is to work out whether the problem is unsupported mapping, memory cost, or a few expensive layers.

Corstone backend​

A target-compatible Corstone backend is the path to use when you need a fuller answer to questions like:

  • Why does the run still look expensive after the quick estimate?
  • Where is the system spending time beyond the top-level estimate?
  • Does a model that looks reasonable in Vela still look reasonable with richer backend evidence?
  • Do I need to run the supported ExecuTorch AOT path instead of the standard .tflite flow?

ExecuTorch performance support​

For --performance, the bundled ExecuTorch inference runners support the following target and backend combinations. This applies both to direct .pte inputs and to .pt2 inputs converted to .pte by mlia-converters-pytorch.

TargetExecuTorch performance backend
Ethos-U55corstone-300
Ethos-U85corstone-320
Ethos-U65Unsupported

For Ethos-U65, performance estimation from a PyTorch .pt2 input is supported only through Vela, with mlia-converters-pytorch installed:

mlia check my_model.pt2 --target-profile ethos-u65-256 --performance --backend vela

This produces compiler-based estimates. Vela does not accept .pte inputs; use the original .pt2 model. There is currently no supported performance backend for Ethos-U65 .pte models.

Corstone support for TFLite models is separate: for example, Ethos-U65 .tflite performance remains supported on corstone-310.

Corstone backend: good first commands​

Run Corstone directly when you already know you want the deeper path:

mlia check my_model.tflite --target-profile ethos-u65-512 --performance --backend corstone-310

Run a supported ExecuTorch AOT path through Corstone:

mlia check my_model.pt2 --target-profile ethos-u55-256 --performance --backend corstone-300

Run both backends together when you want to compare the quick estimate with the more detailed path:

mlia check my_model.tflite --target-profile ethos-u65-512 --performance --backend vela --backend corstone-310

Corstone backend: what to look at in the result​

A Corstone run is most helpful when you want to move beyond a single total and inspect:

  • Layer-level evidence.
  • Traffic-related signals.
  • Active-versus-idle style metrics.
  • Whether the deeper path changes your view of the model.
  • Supported Corstone execution for .pte and .pt2 ExecuTorch workloads.

When Corstone is worth the extra time​

Use Corstone when the quick estimate is not enough to make a decision. That is usually the case when the result is surprising, when you need stronger evidence before acting, or when you are trying to explain where the cost is really coming from.

It is also the backend path to use when you are intentionally validating a supported ExecuTorch AOT flow instead of the standard .tflite-based workflow.

A practical workflow​

A useful Ethos-U workflow is:

  1. Start with vela.
  2. Check whether the result is mainly about compatibility, memory, or a few expensive operators.
  3. Bring in a target-compatible Corstone backend if the answer still needs more detail.
  4. Compare the two results to decide what to change next.