ME LP - New artifacts and wording

Author: matt-cossins

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/1-what-is-model-explorer.md

@@ -21,7 +21,7 @@ The artifacts covered in this learning path are:
 
 | Artifact | Model Explorer support | Workflow layer | Use it to inspect |
 | --- | --- | --- | --- |
-| `.pte` | `pte-adapter-model-explorer` | ExecuTorch program | Delegate regions, backend partitioning, CPU fallback, and the deployed ExecuTorch graph |
+| `.pte` | `pte-adapter-model-explorer` | ExecuTorch program | Delegate regions, backend partitioning, work outside delegates, and the deployed ExecuTorch graph |
 | `.tosa` | `tosa-adapter-model-explorer` | Compiler/backend intermediate representation | Lowered operators, tensor shapes, quantized types, graph splits, and missed optimization opportunities |
 | `.vgf` | `vgf-adapter-model-explorer` | Vulkan ML graph artifact | Inputs, outputs, constants, tensor metadata, graph connectivity, and SPIR-V graph modules |
 | `.etrecord` | ExecuTorch ETRecord adapter | Export-time profiling context | Graph structure, debug handles, operator names, and delegate metadata used to map runtime events back to graph nodes |
@@ -99,7 +99,7 @@ A helpful glossary of different terms is provided below:
 | Lower | To transform a model or graph from a higher-level representation into a lower-level representation closer to a target backend. |
 | Convert | To change one artifact format into another, such as TOSA to VGF. |
 | Intermediate representation | A representation between the original model and the final target artifact. TOSA is the main intermediate representation in this learning path. |
-| Delegate | A backend-specific execution path that handles supported parts of a graph. Unsupported parts can remain on a fallback path. |
+| Delegate | A backend-specific execution path that handles supported parts of a graph. Unsupported parts can remain outside the delegate, and can run on a CPU path only when the deployed runtime includes compatible kernels. |
 | Kernel | The code that executes a model operator for a specific runtime or backend, such as a portable ExecuTorch kernel or a CMSIS-NN kernel. |
 | Flatbuffer | A compact binary serialization format. TOSA flatbuffers store TOSA graphs; `.pte` files use a FlatBuffer-based ExecuTorch program format. |
 | SPIR-V | Standard Portable Intermediate Representation - Vulkan. SPIR-V modules inside VGF files describe the Vulkan ML data graph used by the runtime. |

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/4-inspect-ethosu-pte.md

@@ -11,9 +11,9 @@ layout: "learningpathall"
 
 Ethos-U is Arm's microNPU family for embedded and edge AI acceleration. In ExecuTorch Arm Ethos-U flows, suitable quantized subgraphs are lowered for the Ethos-U backend and compiled through the Arm toolchain.
 
-Model Explorer is useful because the final `.pte` shows whether the ExecuTorch program contains a clean NPU delegate region, fragmented delegate regions, or CPU fallback.
+Model Explorer is useful because the final `.pte` shows whether the ExecuTorch program contains a clean NPU delegate region, fragmented delegate regions, or work outside the NPU delegate.
 
-Ethos-U execution is heterogeneous: supported subgraphs are delegated to the NPU, while unsupported operators fall back to the CPU. The PyTorch blog [Efficient Edge AI on Arm CPUs and NPUs](https://pytorch.org/blog/efficient-edge-ai-on-arm-cpus-and-npus/) describes this flow as quantizing the model, lowering supported regions to TOSA, running Vela to produce an optimized Ethos-U command stream, and packaging the result into the final `.pte`. In this section, you inspect three MobileNetV2 artifacts in order: FP32 with no NPU delegation, INT8 with clean delegation, and INT8 with fragmented delegation.
+Ethos-U execution is heterogeneous: supported subgraphs are delegated to the NPU, while unsupported operators remain outside the NPU delegate. Whether that remaining work can execute on the CPU depends on the kernels included in the deployed ExecuTorch runtime. The PyTorch blog [Efficient Edge AI on Arm CPUs and NPUs](https://pytorch.org/blog/efficient-edge-ai-on-arm-cpus-and-npus/) describes this flow as quantizing the model, lowering supported regions to TOSA, running Vela to produce an optimized Ethos-U command stream, and packaging the result into the final `.pte`. In this section, you inspect three MobileNetV2 artifacts in order: FP32 with no NPU delegation, INT8 with clean delegation, and INT8 with fragmented delegation.
 
 To run through how the artifacts used in this section are obtained, used the [ExecuTorch on Arm Practical Labs](https://github.com/arm-education/executorch_on_arm_labs).
 
@@ -36,13 +36,13 @@ Inspect the graph and answer:
 
 ![Screenshot of examining an FP32 Ethos-U PTE in Model Explorer.#center](ethos_fp32.png "Inspecting FP32 Ethos-U PTE with Model Explorer")
 
-Ethos-U execution expects quantized integer workloads. This artifact was generated from an FP32 MobileNetV2 model, so the graph is not in the form Ethos-U needs for NPU execution. As a result, the work falls back on to the CPU instead of being packaged as an Ethos-U delegate region.
+Ethos-U execution expects quantized integer workloads. This artifact was generated from an FP32 MobileNetV2 model, so the graph is not in the form Ethos-U needs for NPU execution. As a result, the work remains outside an Ethos-U delegate region.
 
 - The graph is much larger at the top level, with many visible `aten::convolution`, `aten::_native_batch_norm_legit_no_training`, and `aten::hardtanh` nodes.
 - You should not see an `EthosUBackend` delegate node.
 - The input and output shapes still match the image classification model: `[1, 3, 224, 224]` to `[1, 1000]`.
 
-This shows why quantization matters for Ethos-U. A model can be structurally valid and still fall back to CPU execution if it is not in a supported quantized form.
+This shows why quantization matters for Ethos-U. A model can be structurally valid and still fail to produce an NPU delegate region if it is not in a supported quantized form.
 
 ## Open a delegated INT8 Ethos-U artifact
 
@@ -88,23 +88,23 @@ Look for:
 
 - Multiple delegate regions
 - Operators between delegate regions
-- Unsupported operations that force CPU fallback
+- Unsupported operations or graph patterns outside the NPU delegate
 - Extra tensor movement around backend boundaries
 
 ![Screenshot of examining a fragmented INT8 Ethos-U PTE in Model Explorer.#center](ethos-u-int8-fragmented.png "Inspecting fragmented INT8 Ethos-U PTE with Model Explorer")
 
 Fragmentation often means that the model was only partly suitable for the target backend. Common causes include unsupported operators, unsupported tensor shapes, quantization issues, or target-specific compiler constraints.
 
-LRN is not natively supported by the Ethos-U flow used here, so it is decomposed into lower-level operations during lowering. Not all of those operations can be delegated to the NPU. Model Explorer should therefore show supported regions delegated to Ethos-U and unsupported work left on the CPU path. In summary: a single unsupported operation can break an otherwise clean NPU region into multiple segments, increasing transitions between CPU and NPU.
+LRN is not natively supported by the Ethos-U flow used here, so it is decomposed into lower-level operations during lowering. Not all of those operations can be delegated to the NPU. Model Explorer should therefore show supported regions delegated to Ethos-U and unsupported work left outside the NPU delegate. In summary: a single unsupported operation can break an otherwise clean NPU region into multiple segments, increasing the number of delegate boundaries.
 
 In Model Explorer, compare it with the clean delegated artifact:
 
 - The graph still has one input with shape `[1, 3, 224, 224]` and one output with shape `[1, 1000]`.
 - You should see two `EthosUBackend` delegate nodes instead of one.
 - You should see quantize and dequantize nodes around the delegated regions.
-- You should see an `aten::avg_pool3d` node between the delegate regions. This is the visible CPU-side work that breaks the otherwise contiguous NPU path.
+- You should see an `aten::avg_pool3d` node between the delegate regions. This is visible non-delegated work that breaks the otherwise contiguous NPU path.
 
-This is what fragmentation looks like in a `.pte`: the NPU still accelerates supported regions, but unsupported work splits the graph and creates extra boundaries between CPU execution and Ethos-U execution. These extra boundaries can cause extra overhead that leads to reduced performance.
+This is what fragmentation looks like in a `.pte`: the NPU still accelerates supported regions, but unsupported work splits the graph and creates extra delegate boundaries. In a deployed runtime, non-delegated work can run on the CPU only if the runtime includes compatible kernels for those operators, dtypes, layouts, and shapes. Cortex-M bare-metal runtimes often include a narrower kernel set than Cortex-A runtimes, and both can use selective builds that include only the kernels required by the product.
 
 ## Compare targets only with target-specific artifacts
 
@@ -132,6 +132,6 @@ Try them out, and compare differences in the model graphs between TensorFlow Lit
 
 ## What you have learned
 
-You have inspected three Ethos-U `.pte` artifacts and seen how quantization and operator support affect NPU delegation. The FP32 MobileNetV2 artifact stays on the CPU path because Ethos-U expects supported quantized integer workloads. The INT8 MobileNetV2 artifact shows the clean delegated pattern: quantize, run a compact `EthosUBackend` region, then dequantize. The LRN example shows fragmentation, where unsupported work splits one clean NPU region into multiple delegate regions with CPU work between them.
+You have inspected three Ethos-U `.pte` artifacts and seen how quantization and operator support affect NPU delegation. The FP32 MobileNetV2 artifact does not produce an Ethos-U delegate region because Ethos-U expects supported quantized integer workloads. The INT8 MobileNetV2 artifact shows the clean delegated pattern: quantize, run a compact `EthosUBackend` region, then dequantize. The LRN example shows fragmentation, where unsupported work splits one clean NPU region into multiple delegate regions with non-delegated work between them.
 
 Next, you will inspect TOSA artifacts directly to see the intermediate representation that sits between model lowering and backend compilation.

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/6-inspect-tosa.md

@@ -11,7 +11,7 @@ layout: "learningpathall"
 
 TOSA is the Tensor Operator Set Architecture. It is a stable operator-level intermediate representation (IR) used between model export and backend-specific compilation or conversion.
 
-You have already seen Ethos-U `.pte` files. Those `.pte` files show the final ExecuTorch program after supported regions have been delegated or left on the CPU path. TOSA lets you inspect an earlier stage: the graph representation that backend tools such as Vela or the Arm ML SDK Model Converter can consume.
+You have already seen Ethos-U `.pte` files. Those `.pte` files show the final ExecuTorch program after supported regions have been delegated or left outside the NPU delegate. TOSA lets you inspect an earlier stage: the graph representation that backend tools such as Vela or the Arm ML SDK Model Converter can consume.
 
 This is why this section does not include separate TOSA artifacts for the Cortex-A portable, Cortex-A XNNPACK, or Cortex-M examples. In the flow introduced at the start of this learning path, those routes do not need a TOSA intermediate representation: portable kernels stay in the ExecuTorch operator path, XNNPACK uses an ExecuTorch delegate for Cortex-A CPU acceleration, and Cortex-M uses its own Cortex-M/CMSIS-NN-oriented lowering path. TOSA becomes relevant for the backend routes that consume TOSA, such as Ethos-U and VGF.
 
@@ -76,7 +76,7 @@ ml-model-artifacts/tosa/mv2_lrn_int8_1.tosa
 ml-model-artifacts/tosa/mv2_lrn_int8_2.tosa
 ```
 
-You saw earlier that the LRN `.pte` contained two `EthosUBackend` delegate nodes with CPU-side work between them. These two TOSA files help explain why.
+You saw earlier that the LRN `.pte` contained two `EthosUBackend` delegate nodes with non-delegated work between them. These two TOSA files help explain why.
 
 Inspect both TOSA files and answer:
 
@@ -94,7 +94,7 @@ The first LRN TOSA file is the smaller fragment. It has two inputs, with shapes
 
 The second LRN TOSA file is the larger fragment. It starts from the original image input shape `[1, 3, 224, 224]` and contains most of the quantized MobileNetV2 CNN structure. It has many `RESCALE`, `CONV2D`, and `DEPTHWISE_CONV2D` operations, and produces intermediate outputs with shapes `[1, 1280, 7, 7]` and `[1, 1, 1284, 7, 7]` that cross the break in the graph.
 
-The graph fragmentation has become visible as multiple backend-ready TOSA artifacts. That matches the fragmented `.pte` view, where two `EthosUBackend` delegate regions were separated by CPU-side work.
+The graph fragmentation has become visible as multiple backend-ready TOSA artifacts. That matches the fragmented `.pte` view, where two `EthosUBackend` delegate regions were separated by non-delegated work.
 
 ## Use TOSA outside ExecuTorch
 

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/8-etrecord-etdump-overlays.md

@@ -218,7 +218,7 @@ This shows a clean CPU delegate acceleration pattern. The model still has some n
 
 ## Inspect the FP32 Ethos-U example
 
-Next, inspect the MobileNetV2 FP32 example. We tried to delegate this to an Ethos-U, but ultimately it falls back to CPU execution on Cortex-M because Ethos-U requires INT8 quantization:
+Next, inspect the MobileNetV2 FP32 example. We tried to delegate this to an Ethos-U, but it does not produce an Ethos-U delegate region because Ethos-U requires supported quantized integer workloads:
 
 ```output
 ml-model-artifacts/etrecord/mobilenetv2_fp32_ethosu.etrecord
@@ -230,7 +230,7 @@ Look for:
 - No `EthosUBackend` delegate calls
 - Native `aten.convolution.default` events
 - A large `Method::execute` total
-- Runtime behavior that matches the FP32 `.pte` fallback view from the Ethos-U section
+- Runtime behavior that matches the FP32 `.pte` view from the Ethos-U section
 
 ![Screenshot of examining an FP32 MobileNetV2 ETRecord and ETDump overlay in Model Explorer.#center](fp32_profile.png "Inspecting FP32 MobileNetV2 runtime overlays")
 
@@ -270,8 +270,8 @@ ml-model-artifacts/etdump/mobilenetv2_lrn_int8_ethosu.etdp
 Compare it with the clean INT8 profile:
 
 - Are there two `EthosUBackend` delegate calls instead of one?
-- Which CPU operators appear between or around the delegate regions?
-- How large is the CPU fallback cost compared with the NPU cost?
+- Which native operators appear between or around the delegate regions?
+- How large is the non-delegated native cost compared with the NPU cost?
 - Do quantize and dequantize events appear around delegate boundaries?
 
 ![Screenshot of examining fragmented INT8 Ethos-U ETRecord and ETDump overlays in Model Explorer.#center](ethos_lrn_profile.png "Inspecting fragmented INT8 Ethos-U runtime overlays")
@@ -280,12 +280,12 @@ This profile shows why "delegated" is not always enough. The ETDump contains abo
 
 The overall `Method::execute` total is about 1.70 billion cycles because a large CPU `aten.convolution.default` island accounts for about 1.67 billion cycles. The profile also shows quantize and dequantize work around the delegate boundaries, including `dequantize_per_channel` at about 21.6 million cycles and `quantize_per_tensor` at about 6.47 million cycles.
 
-This is the runtime version of the fragmentation pattern you saw in the `.pte` and TOSA sections. The graph contains Ethos-U delegate regions, but unsupported or poorly placed CPU work dominates execution.
+This is the runtime version of the fragmentation pattern you saw in the `.pte` and TOSA sections. The graph contains Ethos-U delegate regions, but unsupported or poorly placed native work dominates execution in this provided trace.
 
 ## What you have learned
 
 ETRecord and ETDump add runtime context to static graphs. ETRecord gives you the graph and debug metadata. In the first Model Explorer overlay used in this Learning Path, ETDump contributes runtime timing data. Used together, with the adapter and data provider in the new Model Explorer ExecuTorch extension, they show which parts of the graph actually cost time on the target.
 
-The OPT-125M profiles made the CPU case clear: the portable run stayed on native operators, while the XNNPACK run moved most of the work into delegate calls. The MobileNetV2 profiles showed the same pattern for Ethos-U. CPU fallback, clean Ethos-U delegation, and fragmented delegation are much easier to tell apart once the runtime data is overlaid on the exported graph.
+The OPT-125M profiles made the CPU case clear: the portable run stayed on native operators, while the XNNPACK run moved most of the work into delegate calls. The MobileNetV2 profiles showed the same pattern for Ethos-U. Native CPU execution, clean Ethos-U delegation, and fragmented delegation are much easier to tell apart once the runtime data is overlaid on the exported graph.
 
 You have now completed the full artifact-inspection flow in this learning path. You started with `.pte` files to understand deployed ExecuTorch programs, moved through TOSA and VGF to inspect backend and Vulkan ML artifacts, and finished with ETRecord and ETDump overlays to connect the graph to runtime cost. The next steps page points to deeper workflows for generating, running, profiling, and optimizing your own models.

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/_index.md

@@ -1,9 +1,7 @@
 ---
 title: Visualize ExecuTorch PTE, TOSA, VGF, ETRecord, and ETDump artifacts with Google's Model Explorer
 
-draft: true
-cascade:
-    draft: true
+
 
 description: Learn how to inspect ExecuTorch PTE, TOSA, VGF, ETRecord, and ETDump model artifacts with Google Model Explorer and Arm adapters.
 
@@ -15,7 +13,7 @@ learning_objectives:
   - Explain what Google Model Explorer is and how adapters add support for Arm model artifacts
   - Install Model Explorer, launch it with the PTE, TOSA, and VGF adapters, and use the runtime overlay extension for ETRecord and ETDump
   - Open ExecuTorch .pte files and compare portable CPU, XNNPACK CPU, and Ethos-U artifacts
-  - Use PTE visualization to reason about delegate regions, CPU fallback, graph fragmentation, and backend-specific changes
+  - Use PTE visualization to reason about delegate regions, work outside delegates, graph fragmentation, and backend-specific changes
   - Inspect TOSA flatbuffers as an intermediate representation used by Arm compiler and backend workflows
   - Inspect VGF artifacts for Vulkan ML and neural graphics workloads
   - Use ETRecord and ETDump overlays to connect exported graph structure with runtime profiling data