---

name: matlab-deploy-embedded-ai description: > Deploy AI models to embedded hardware using MathWorks tools (MATLAB, Simulink, Embedded Coder). Covers two workflow patterns: (1) MathWorks-native or imported models rebuilt as dlnetwork for lean hardware, (2) direct C/C++ code generation from PyTorch and LiteRT models. Both patterns support all targets (Cortex-M/A/R, x86, GPU). Trigger when: user wants to deploy AI to embedded targets; generate C/CUDA from neural networks; compress AI models for MCU; integrate AI in Simulink for system-level simulation; import PyTorch/ONNX/TensorFlow models for embedded deployment; optimize AI for resource-constrained hardware; or use loadPyTorchExportedProgram, loadLiteRTModel, importNetworkFromPyTorch, importNetworkFromONNX, importNetworkFromTensorFlow, importNetworkFromKeras, dlquantizer, exportNetworkToSimulink, or Embedded Coder with AI models. license: https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md metadata: author: MathWorks version: "2.1"

Embedded AI for Engineered Systems

Deploy AI models to embedded hardware using MATLAB® and Simulink®. This skill is written specifically for MATLAB R2026a and uses APIs, functions, and workflows introduced in that release. It covers the complete lifecycle: model creation or import, verification, compression, system-level simulation, and code generation for resource-constrained targets.

Requires MATLAB R2026a or newer. Core toolboxes: Deep Learning Toolbox, Statistics and Machine Learning Toolbox, MATLAB Coder, Embedded Coder, Simulink, and Fixed-Point Designer. Workflow-specific support packages are checked during Environment Discovery. The MATLAB and Simulink Agentic Toolkits must be available so the agent can drive a live MATLAB and Simulink session through MCP tools.

When to Use

• Deploying a trained neural network (MATLAB-native or imported) to embedded hardware
• Generating C or CUDA code from a deep learning model for ARM Cortex-M/A/R, x86, or GPU targets
• Deploying imported PyTorch, ONNX, TensorFlow, or LiteRT models to embedded targets (import step handled by /matlab-import-external-ai-model)
• Compressing AI models (quantization, pruning, projection) to fit resource-constrained hardware
• Integrating AI inference into a Simulink system model for closed-loop simulation before code generation
• Using loadPyTorchExportedProgram, importNetworkFromPyTorch, importNetworkFromONNX, importNetworkFromTensorFlow, dlquantizer, exportNetworkToSimulink, or Embedded Coder with AI models
• Choosing between MathWorks-native code generation and direct PyTorch/LiteRT code generation

When NOT to Use

• Training a model purely for research with no deployment target — use Deep Learning Toolbox documentation directly
• Deploying to cloud/server endpoints (no embedded target) — use MATLAB Production Server or MATLAB Compiler SDK
• Working with classical ML models (decision trees, SVMs, ensembles) that aren't neural networks — use Statistics and Machine Learning Toolbox codegen workflows directly. Note: fitcnet/fitrnet neural network models ARE covered by this skill
• Generating code for non-AI Simulink models — use standard Embedded Coder workflows
• Converting between model formats without an embedded deployment goal (e.g., ONNX to MATLAB for desktop inference only)

Workflow Pattern Selection

This skill uses two deployment patterns:

• Pattern 1 — MATLAB Network Codegen: Import or build a dlnetwork, optionally compress it, then generate C/C++ via MATLAB Coder or export to Simulink. See references/pattern1/workflow.md.
• Pattern 2 — PyTorch/LiteRT Direct Codegen: Load a PyTorch (.pt2) or LiteRT (.tflite) model directly and generate C/C++ without converting to a dlnetwork. See references/pattern2/workflow.md.

Decision Tree

Primary discriminator for external models: deployment capabilities + hardware class.

Q1: Where does the AI model come from?
 |
 +-- Trained in MATLAB, or requires training in MATLAB -------> Pattern 1
 |
 +-- External framework (PyTorch, TF, ONNX, Keras) --> Q2
      |
      Q2: Does the deployment need any of these?
       |  - Quantization (INT8 via dlquantizer)
       |  - Pruning or projection
       |  - Weight inspection / modification
       |  - exportNetworkToSimulink integration
       |
       +-- YES --> Pattern 1 (import as dlnetwork)
       |
       +-- NO ---> Q3
            |
            Q3: What is the deployment target?
             |
             +-- Cortex-M: Pattern 1
             |     (compression and Simulink verification typically needed)
             |
             +-- x86 / GPU:
             |     +-- PyTorch (.pt2) or LiteRT (.tflite) --> Pattern 2
             |     +-- ONNX, TF, Keras --> Pattern 1 (convert to ONNX recommended)
             |
             +-- Cortex-A/R:
                   +-- Small model --> Pattern 1
                   |     (import as dlnetwork, then codegen)
                   +-- Large model:
                        +-- PyTorch (.pt2) or LiteRT (.tflite) --> Pattern 2
                        +-- ONNX, TF, Keras --> Pattern 1 (convert to ONNX recommended)

Pattern Summary

| Pattern | When to Use | Primary Toolchain | |---------|-------------|-------------------| | 1 — MATLAB Network Codegen | Model trained in MATLAB, OR external model needing compression/quantization/Simulink export/weight inspection, OR Cortex-M targets | MATLAB Coder™ / Embedded Coder™ | | 2 — PyTorch/LiteRT Direct Codegen | External PyTorch (.pt2) or LiteRT (.tflite) model on x86/GPU/Cortex-A targets; shorter path to C code without compression | MATLAB Coder™ + PyTorch & LiteRT SPKG |

Pattern 2's generated C is portable to any target, but Cortex-M deployments typically require Pattern 1 capabilities (compression, Simulink verification).

Import step (Pattern 1): For PyTorch/ONNX/Keras/TensorFlow model import, use /matlab-import-external-ai-model. This skill takes over after import for the compression, Simulink integration, and code generation phases.

Pattern 1 vs Pattern 2 Capability Comparison

| Capability | Pattern 1 (dlnetwork) | Pattern 2 (PyTorch/LiteRT direct) | |-----------|----------------------|----------------------| | C code generation | Yes | Yes | | Target: Cortex-M, Cortex-A/R, x86, GPU | Yes | Yes | | Weight inspection / modification | Yes | No | | dlquantizer (INT8) | Yes | No | | Projection (compressNetworkUsingProjection) | Yes | No | | Pruning | Yes | No | | Simulink integration | Yes (exportNetworkToSimulink) | Yes (PyTorch SPKG Simulink blocks) | | Combined compression | Yes | No | | Speed to first C code | Slower | Faster |

Rule of thumb: Choose Pattern 1 when you need to compress, quantize, inspect weights, or use exportNetworkToSimulink — or when the model is already a dlnetwork, or when targeting Cortex-M. Choose Pattern 2 when the model is already in PyTorch (.pt2) or LiteRT (.tflite) format and you want the shorter path to C code without compression.

Stats/ML models (fitrnet/fitcnet): These follow Pattern 1 but have their own Simulink integration path. Use the RegressionNeuralNetwork Predict block (for fitrnet) or ClassificationNeuralNetwork Predict block (for fitcnet) from the Statistics and Machine Learning Toolbox library — do NOT use exportNetworkToSimulink (which is for dlnetwork only). Configure simulation programmatically with Simulink.SimulationInput.

Common Start: Prerequisites

Regardless of pattern, always begin with these two prerequisite steps before entering the pattern-specific phases (which start at Phase 1):

1. Environment Discovery (silent): Load references/shared/environment-setup.md
2. Project Discovery (interactive): Load references/shared/project-discovery.md

Project Discovery determines the workflow pattern via the decision tree above.

Do Not Use (Legacy Functions)

| Legacy | Modern Replacement | |--------|-------------------| | trainNetwork / train (for DL) | trainnet | | DAGNetwork / SeriesNetwork / network | dlnetwork | | taylorPrunableNetwork / updateScore / updatePrunables | compressNetworkUsingTaylorPruning (when trainable with trainnet); use taylorPrunableNetwork for custom training loops | | csvread / xlsread | readmatrix / readtable | | datenum | datetime |

For legacy import functions (importONNXNetwork, importKerasNetwork, etc.), see /matlab-import-external-ai-model which handles all model import workflows.

Global Rules

Advisory vs Execution Mode

Distinguish between two modes based on the user's intent:

• Advisory ("How should I approach this?", "What workflow?", "Which pattern?"): Answer the routing question directly — state the recommended Pattern, explain why, and outline the high-level steps. Do NOT enter Environment Discovery or start asking prerequisite questions. After giving the recommendation, ask if the user wants to begin execution.
• Execution ("Deploy my model", "Walk me through", "Write the script"): Enter the full prerequisite flow (Environment Discovery → Project Discovery → step-by-step phases).

ALWAYS

• Check toolboxes via detect_matlab_toolboxes and support packages via matlabshared.supportpkg.getInstalled before any workflow step
• If a support package is missing, ask the user to download from Add-On Explorer -- never install on their behalf
• Guide the user step-by-step -- one phase at a time
• Use consistent data partitioning (e.g., fixed indices or a stored partition object) for reproducibility
• Verify numerical equivalence at each transformation step
• Generate MEX for desktop validation before generating C code for target
• Use single precision for all inference inputs
• Script-based execution: For each workflow step done in MATLAB, create a .m script file and execute it with run_matlab_file or evaluate_matlab_code. Do NOT run ad-hoc MATLAB commands without first writing the script file. If a script needs changes, edit the script file and re-run it. This gives users full visibility into what code is being executed and enables reproducibility. IMPORTANT: run_matlab_file sets the working directory to the script's folder. Always use absolute paths (via fullfile) for model files, data, and saved outputs — never rely on pwd or relative paths.
• Pause after each workflow step: After every workflow step completes, pause and explicitly ask the user for permission to proceed to the next step. The goal is to let the user read/inspect the MATLAB scripts you created, review results, and ask questions before moving on.
• Deep Network Designer: When a model is trained in MATLAB, imported, or rebuilt as a native dlnetwork, load it in Deep Network Designer (deepNetworkDesigner(net)) so the user can visually inspect the architecture. Announce this action and wait for user acknowledgment before proceeding.
• Numerical equivalency tests (import workflows): For any import from PyTorch or ONNX:
  1. Run inference on the original model (via bundled Python for PyTorch, or ONNX runtime) to collect ground-truth reference data. Do NOT use the imported MATLAB model as reference — for PyTorch imports in R2026a, custom autogenerated layers may not support code generation and the model may need to be rebuilt natively. (ONNX autogenerated layers have supported code generation since R2025a and may not require a rebuild.)
  2. Run the same inputs through the rebuilt native MATLAB model and compare against ground truth
  3. After compression, report the accuracy delta vs. the uncompressed baseline (MAE, max error, % accuracy drop). Compute these from v