Graphical User Interface

This section provides step-by-step information on generating, optimizing and validating the code for Infineon targets PSOC™ 6, PSOC™ Edge M55, PSOC™ Edge M55+U55, PSOC™ Edge M33+NNLite using the Graphical User Interface (GUI).

Code Generation Workflow

This is the workflow for generating code using DEEPCRAFT™ Model Converter:

1. Generate Code: Convert your model (.keras, .h5, .tflite, or .pt2) into (.c) and (.h) files which you can deploy onto the Infineon board.

2. Optimize the Model: Use calibration data to apply quantization.

3. Validate the Model: Test the quantized or non-quantized model using validation data to ensure accuracy.

Launch Graphical User Interface

After you download and install the DEEPCRAFT™ Model Converter executable file, the DEEPCRAFT™ Model Converter GUI mode will launch automatically.

Pre-requisites for the PyTorch Models

When generating the code for PyTorch models, you must select one of the following options: Cloud-Based Code Generation or Container-Based Code Generation.

Cloud-Based Code Generation

When you select Cloud-Based Code Generation, the PyTorch model is uploaded to the Imagimob Cloud for code generation. For selecting the Cloud-Based Code Generation, follow the steps:

1. Click Sign In at the top right of the application to open the sign-in window.
2. Enter the Imagimob email and password to login.
3. If you do not have an account, create one here .

Configure the Project File

Lets configure the parameters in the template and save the template as Bring Your Own Model project file (.byom) to generate, optimize, and validate the model. You can reuse this project file to generate the code later. To know more, refer to Working with project files.

This video provides a concise, visual introduction to the workflow described in this documentation.

General Settings

To generate code for the model, configure the following:

1. Target Device: Select the required Infineon board or core type from the following options - PSOC 6, PSOC Edge M55, PSOC Edge M33 with NNLite, PSOC Edge M55 with U55.

2. Input Model: Click the three horizontal dots to browse and select the model file for which you want to generate the code. You can choose from TensorFlow Keras (.h5), TensorFlow Keras (.keras) TensorFlow Lite (.tflite), or PyTorch (.pt2) model formats.

3. Output File Name : Enter the name of the output file.

4. Output Directory: Click the three horizontal dots to browse and select the directory where you want to save the generated code. By default, the application selects Codegen as the default folder for saving the generated code.

5. Model is RNN: Enable this checkbox when the model includes recurrent layers (such as LSTM, GRU, or similar). The toolchain attempts to detect this automatically from the model file, but setting the option explicitly is recommended. This setting does not affect model conversion but only controls how validation and calibration data are handled for streaming models. To know more about this option, refer to Streaming RNN model validation.

6. Interpreterless: Enable the checkbox to generate the static C++ code that executes the neural network directly. The interpreterless mode pre-interprets the model, removing the need for the TensorFlow Lite Micro interpreter at runtime. When this option is enabled, the runtime, memory planner and unused operator code, memory planner are not compiled into the final application, reducing the ROM footprint. This can provide memory savings for very small models (under 400 KB) that use a limited set of operator types. The exact amount of memory saved may vary from model to model but in some cases can be close to ~200KB.

   Interpreterless mode is supported on PSOC™ 6, PSOC™ Edge M33+NNLite targets only.

File specifications for calibration and validation

Before starting model optimization and validation, prepare the calibration and validation data. Calibration data is used to quantize the model, while validation data is used to evaluate the model. For models with a single input and single output, select one of the following data sources: Compressed NumPy (.npz), CSV, or a Recursive Directory. For models with multiple inputs and outputs, use Compressed NumPy (.npz) only, as no other data sources are supported. Specifications for Compressed NumPy file, CSV file or Recursive Directory are listed in Supported Data Formats.

Model Optimization

Model optimization involves refining the code to enhance performance, efficiency, and accuracy of the model on the Infineon targets. It reduces computational cost, shortens inference time, and reduces memory footprint to deliver reliable performance across environments.

To optimize the model, configure the following:

1. Network Quantization: Enable the checkbox, if you want to quantize the network code. If you enable this option, you must provide calibration data to generate a 8-bit quantized model.

2. Enable Sparsity: Enable the checkbox to further optimize the model by packing sparse weights, thereby saving memory when deploying the model on the target device.

3. Quantization Type: Select the quantization type as Int8x8 or Int16x8.

   In Int8x8 quantization, both weights and activations are quantized to 8-bit integers (Int8). Int8x8 quantization reduces the time consumption and minimizes memory and bandwidth usage but at the cost of some accuracy. In Int16x8 quantization, weights are quantized to 8-bit integers (Int8), but activations are quantized to 16-bit integers (Int16).

   Int16x8 quantization can provide higher accuracy with only a marginal increase in compute time, model binary size, and work-buffer memory by storing intermediate values in 16-bit integers rather than 8-bit. However, the benefit is model-dependent, so you must evaluate Int8x8 and Int16x8 side by side to determine which configuration suits your needs.

   You can generate the code twice — first with Int8x8 quantization, then with Int16x8 quantization and compare the results side by side in the Output window. For complex models, review quantitative metrics (for instance, see the validation results) in the code_generation_report.md file to assess differences.

4. Calibration Data Type: Select the calibration data source as one of the following: Compressed NumPy file (.npz), CSV file, or a directory. For models with multiple inputs and outputs, use Compressed NumPy (.npz) only, as no other data sources are supported.

   • Recursive Directory Search: Select this option to load calibration data from a directory.

   • CSV File: Select this option to load calibration data from a CSV file.

   • Compressed NumPy File (.npz) File: Select this option to load calibration data from a compressed NumPy file.

   Refer to Supported Data Formats to know the specifications for Compressed NumPy file, CSV file or Recursive Directory.

5. Max Samples: Enter the maximum number of samples to use for calibration. If the number of samples in the provided dataset exceeds this value, the dataset will be truncated to the first N samples.

6. Calibration Data Path: Click the three horizontal dots to browse and select the CSV file, compressed NumPy file or directory corresponding to the selected calibration data type.

Validation Data Configuration

Model validation evaluates the optimized model to the original baseline and generates a report. The report summarizes how closely the converted model’s predictions match your reference outputs along with other validation metrics. You can validate both quantized and non-quantized models on desktop as well as on the target device.

To validate the model, configure the following:

1. Max Samples: Enter the maximum number of samples to use for validation. If the number of samples in the provided dataset exceeds this value, the dataset will be truncated to the first N samples. For on-device profiling, select a smaller value to ensure the data fits on the target device.

2. Validation Data Type: Select the validation data source as one of the following: Compressed NumPy file (.npz), CSV file, or a directory. For models with multiple inputs and outputs, use Compressed NumPy (.npz) only, as no other data sources are supported.

   • Recursive Directory Search: Select this option to load calibration data from a directory.

   • CSV File: Select this option to load calibration data from a CSV file.

   • Compressed NumPy File (.npz) File: Select this option to load calibration data from a compressed NumPy file.

   Refer to Supported Data Formats to know the specifications for Compressed NumPy file, CSV file or Recursive Directory.

3. Validation Data Path: Click the three horizontal dots to browse and select the CSV file, compressed NumPy file or directory corresponding to the selected validation data type.

4. Validation Mode Options: Select the validation mode options as one of the following: Validation or Use Provided Reference.

   • Default: Select this option to validate the generated model against the desktop TFLite interpreter. The Model Converter first runs the float TFLite model on the validation dataset and uses the outputs as the reference baseline, then compares the quantized variants (INT8×8 and INT16×8) against that float baseline during desktop validation. For on-device profiling, the generated .h files use the selected deployment quantization level (float, INT8×8, or INT16×8). This option is recommended for most workflows.

   • Use Provided Reference: Select this checkbox to use the output data in the validation file as the reference. The Model Converter reads the reference outputs directly from the validation NPZ file instead of generating reference data by running model inference. Use this option when the validation dataset includes precomputed ground-truth outputs (for example, from a simulation, a reference implementation, or the original training framework) and you want to validate the on-device model against those outputs rather than against TFLite. Refer to NPZ Data Formats to know the specifications for Compressed NumPy file in detail.

Advanced Options

The following advanced settings can be configured before generating code. You can select the target API, configure API-specific and memory placement options for the Imagimob API, and set advanced optimization options for PSoC™ Edge M55+U55.

Target API

Select the Target API as one of the following: Ml-middleware API or Imagimob API. By default, Ml-middleware API is selected as the target API when you generate code.

• Ml-middleware API: Select this option when you want direct control over model integration in your ModusToolbox™ application. This option runs the ML core tools only and skips the Imagimob code generation steps. It generates the model artifacts that your firmware uses through Infineon’s mtb_ml_* API, so your application handles initialization, tensor arena setup, input handling, and inference. Refer to Ml-middleware API for more details.

• Imagimob API: Select this option when you want a ready-to-use wrapper around the same middleware flow. This option runs the full code generation flow after the ML core tools and generates model.c and model.h with the IMAI_* API. Use it when you want the generated code to handle initialization, arena setup, quantization, and inference through IMAI_init() and IMAI_compute(). Refer to imagimob api imagimob api for more details.

To know more about the Target API, refer to Deployment API.

When you select Imagimob API as the target API, the following options appear:

1. Override Arena Size: By default, this parameter is set to 0 to enable automatic calculation of the arena size. However, if the model fails to initialize on the embedded device and crashes during initialization (IMAI_int()), modify the arena size value. Increase in increments of 4096 bytes from the default calculated size. When you find a working value, decrease in steps of 1024 bytes or less to determine the minimum stable size that does not crash. The calculated arena size can be found in the code_generation_report.md under the Scratch memory column in the Memory Usage section. Refer to Insufficient model arena memory during deployment for detailed information.

2. Output API Prefix: Enter the prefix to be added at the beginning of the generated API functions.

3. API Input/ Output Data Auto Quantization: Enable the checkbox to automatically quantize the input data and de-quantize the output data to Float32 format. If your real world input data is not in float32 format, do not enable this checkbox.

4. Use zero-copy output API: The zero-copy output API returns pointers to internal buffers where the outputs of the model are stored so you can access the results directly. This avoids copying the outputs to the user-provided external buffers, which is the default behavior.

5. Skip Cleanup: Enable the checkbox if you do not want the application to delete certain temporary files created during code generation. If necessary, you can delete these files manually at a later time. When this checkbox is disabled, the application will automatically delete the temporary files.

Memory Placement options for the Imagimob API

The Imagimob API lets you configure the memory placement and allocation strategy for both the tensor arena, which the model uses as working memory, and the model weights.

• Arena allocation: Use Static allocation, the default, to place the tensor arena in a fixed-size global buffer. You can control where this buffer is placed with the CY_ML_ARENA_MEM Makefile variable. Use Dynamic (Heap) allocation to allocate the arena with malloc() at runtime, so it consumes RAM only while the model is loaded.

• Weights placement: Configure the storage location for the model weights and define how the application accesses the weights at runtime.

  • Flash: Places the weights in flash memory for read-only access without copying them to RAM.

  • Static: Places the weights in a fixed-size buffer controlled by the CY_ML_ARENA_MEM Makefile section.

  • Dynamic: Keeps the const weights in flash, allocates RAM with malloc() at runtime, and copies the weights into that buffer during IMAI_init().

    Use Dynamic placement when running from RAM provides better performance than execute-in-place from flash.

Advanced optimization for PSOC™ Edge M55+U55

The following optimization settings are part of the Vela compiler and generate optimizations for code targeting the Ethos-U55 NPU. These options reduce scratch memory usage with minimal to no impact on model accuracy.

1. System Configuration: Select SOCMEM 300MHz QUAD XIP or SOCMEM 200MHz QUAD XIP as the system configuration of the Ethos-U NPU. Refer to Silicon documentation to know more.

2. Memory Mode: Select Shared SRAM or SRAM Only as the memory mode. Shared SRAM is shared between Ethos-U and Cortex-M software, whereas SRAM Only is dedicated to Ethos-U. The non-SRAM memory is considered read-only. By default, Shared SRAM is selected.

3. Optimize: Select the optimization strategy based on Size or Performance. The Size strategy ensures minimal RAM usage by avoiding the use of the arena cache memory area size whereas the Performance strategy prioritizes maximal performance by utilizing the specified arena cache memory area size. By default, Performance strategy is selected.

4. Tensor Allocator: Select Linear Alloc, Greedy or HillClimb to specify the algorithm for allocating non‑constant tensors on the NPU and CPU. By default, HillClimb is selected.

5. Arena Cache Strategy: Select the strategy to determine the arena cache size for Ethos-U55 NPU memory optimization: Min, Max or Custom.

   • When you select Min, the arena cache size is set to the minimum size required by the model.
   • When you select Max, the arena cache size is set to the maximum size allowed by the target platform. This is the default strategy.
   • When you select Custom, the arena cache size is set to the specified size manually. When this option is selected, the Arena Cache Size parameter becomes available.

6. Arena Cache Size: Set the size of the arena cache memory area, in bytes. The size of the arena cache memory area must be any integer greater than or equal to 0. By default, the value of arena cache memory is set as 2936012. The arena cache is an optimization hint for U55 acceleration. It is not the same as the overall tensor arena used by the model. This parameter is available only when the Arena Cache Strategy is set to Custom.

7. Force Python Backend: Enable this option to force the use of the deprecated Vela Python API backend for model optimization. When selected, additional advanced parameters related to the Python backend optimization flow are available, such as Max Block Dependencies and Recursion Limit.

8. Max Block Dependency: Set the maximum value that can be used for the block dependency delay between NPU kernel operations. A lower value may result in longer execution time. You may set: 0, 1, 2 or 3 as the value for Npu block dependency. By default, the value of block dependency is set as 3. This option is applied only when the Force Python Backend option is enabled.

9. Recursion Limit: Set the Python internal limit to depth of recursion. For very large networks, increasing the recursive limit may be necessary due to the recursive graph traversal algorithm. If generation fails with a RecursionError, increase the limit using this option. By default, the recursion limit is set as 1000. This option is applied only when the Force Python Backend option is enabled.

Saving the Bring Your Own Model (BYOM) Project File

BYOM file is a project file that contains the configuration for the model converter. It is saved as a .byom file and can be reused later to generate the code for the model. After configuring the project file, navigate to File> Save and assign a descriptive name to save the project file (.byom). See Working with project files for code generation to know more.

Generate Code for the Model

Enable the Verbose output checkbox to display additional information about the model conversion and code generation process. This option is useful for debugging and troubleshooting issues that may occur during code generation. By default, Verbose output is disabled. When disabled, only standard information, warnings, and errors are displayed.

Click the Start button to generate the code for the model. The code (model.c/.h files) is generated in the Output Directory defined earlier along with the code generation report. You can also view the validation and optimization results in the output window at the bottom of the model converter.

After generating the code for the model, let’s deploy the code on the Infineon boards using the ModusToolbox™. To know how refer to Deploy model on PSOC™ Edge using the Code Examples.

Working with project files for code generation

To streamline code generation for multiple models, you can capture your settings in project file (.byom). You can open the project file with the saved configuration later either in the GUI or from the CLI without re-entering options. Below is a compact workflow and some best practices to help you organize and reuse configurations effectively.

• Save your configuration: After configuring code-generation options for a model, navigate to File> Save and assign a descriptive name to the project file.

• Reuse an existing configuration: To re-generate code using saved configuration, navigate to File> Open, browse and select the required project file.

• Create a new configuration for another model: Navigate to File> New to open a new project file and configure the code generation settings for the model, and save as a project file.

• Maintain multiple configurations: Keep separate project files for different models or targets. Open the one you need whenever you want to generate code for that setup.

• Use from the command line: The project files can also be used from the CLI, which helps avoid retyping long command strings. Refer to the CLI documentation for instructions on loading a saved project file and running code generation in command-line mode.

Whats Next?

After you have generated, optimized and validated the code for your model, the next step is to deploy the code onto the Infineon boards using ModusToolbox™. To learn how to deploy the code, refer to Deploy model on PSOC™ Edge using the Code Examples.