Review the Ethos-U Deployment

In this module, you prepared MobileNetV2 for Ethos-U and ran it through a target-like bare-metal application.

Model preparation and delegation

• The FP32 model remained on the ExecuTorch fallback path because its compute was not accepted by the Ethos-U backend.
• Calibration and INT8 quantization produced a model that Vela compiled into one large Ethos-U delegate. Comparing the FP32 and converted INT8 predictions provided an early check that quantization had not caused an obvious problem on the sample image.
• Inserting LRN split the graph into two Ethos-U delegates and left aten.avg_pool3d.out on the fallback path. The added delegate boundaries also introduced q/dq operations and potential data-movement overhead.

Target execution and application code

• The CMake build combined the .pte artifact, ExecuTorch runtime, Ethos-U delegate, drivers, allocators, and platform support into a bare-metal ELF.
• The Corstone-320 FVP loaded the prepared input tensor, executed the Ethos-U delegate, and wrote the model output. This validates the target software path, but does not provide final hardware performance measurements.
• The classification runner showed how C++ application code can turn the output logits into ImageNet labels and top-five results without a separate host-side decoder.

Before deploying on hardware

Before deployment, test accuracy across a labeled validation set and measure latency, memory use, power, and thermal behavior on the intended hardware. If quantization causes unacceptable accuracy loss or unsupported operators fragment important parts of the graph, revise the model or consider another backend.

For another model, repeat the same checks rather than assuming it will behave like MobileNetV2: confirm the required precision, inspect delegation and fallback operations, review the Vela resource estimates, run the compiled program on the FVP, check the application output handling, and then test on the intended hardware.