PaperlayerView exact revision on arXiv

Source-linked AI summary

Model-Based Retargeting to Many-Core CPS: Simulink-to-OpenCL Workflow

Ryuga Chiba, Hiroshi Fujimoto, Takuya Azumi

arXiv:2609.29311v1cs.SE

TL;DR

Simulink-based CPS models face a portability gap when deployment targets move beyond vendor-specific GPU toolchains to many-core platforms. The paper retargets GPU-Coder-generated CUDA into OpenCL for a cluster-based many-core processor, and reports meeting the assumed planning-cycle budget for its evaluated Frenet workload. The conclusion is bounded by the model and generated-code structures supported by the workflow.

  • Problem

    Simulink-based CPS development faces a portability gap as computational platforms diversify toward many-core architectures and commercial code generators can lock models to vendor-specific toolchains.

    Source: §1 · p. 1

  • Method

    The workflow uses GPU Coder to generate CUDA from a Simulink planner and translates the supported generated code into OpenCL host and kernel code for many-core execution.

    Source: §6 · p. 14

  • Results

    The workflow met the assumed 100 ms planning-cycle budget for 4,000 trajectory candidates, and latency decreased with cluster count with diminishing returns from fixed overheads.

    Source: §1 · p. 2, §6 · p. 15

  • Takeaways & Limitations

    The study demonstrates GPU-Coder-generated CUDA as an intermediate representation for retargeting Simulink trajectory planners to OpenCL-based many-core processors.

    Source: §6 · p. 15

    The workflow is bounded to models with MATLAB Function computation, independent candidate- or data-wise tasks, and generated CUDA patterns and interfaces supported by the translator.

    Source: §2.6 · p. 5, §6 · p. 15

Abstract

from arXiv · show

This paper addresses the software portability gap between Model-Based Development (MBD) and advanced many-core execution for Cyber-Physical Systems (CPS). We present a workflow-preserving retargeting approach for Simulink-based CPS applications with candidate-wise data parallelism to OpenCL-based many-core processors. Rather than manually rewriting models for new platforms, our toolchain uses MathWorks GPU Coder to extract data-parallel CUDA code, which is then translated into OpenCL host and device code via a custom framework. The conversion handles syntax rewriting, API emulation, and platform-specific argument packing. We deployed this workflow for a computationally intensive Frenet-frame trajectory planner on the Kalray MPPA Coolidge2. The results demonstrate the feasibility of a workflow-preserving retargeting pipeline for the evaluated CPS workload and platform.

1 Introduction

The paper addresses a portability gap between Simulink-based CPS development and execution on many-core platforms. It proposes a GPU-Coder-based CUDA-to-OpenCL retargeting workflow and evaluates it with a candidate-parallel Frenet trajectory planner.

1 Introduction

  • The portability gap arises because commercial code generators can lock MBD models to vendor architectures, while CPS platforms diversify toward many-core systems.The paper frames model-level abstraction versus platform-level execution as a challenge for CPS.Source: §1 · p. 1
  • The workflow uses GPU Coder to extract structured host/device CUDA code from Simulink, then translates it into OpenCL without requiring heavy AST analysis.The proposed approach aims to preserve the established MBD simulation and verification workflow.Source: §1 · pp. 1–2
  • The Frenet-frame planner serves as a representative workload because its trajectory candidates can be evaluated independently.The paper uses this case to examine model structure, translation mechanisms, and runtime behavior, not to restrict the approach to this application.Source: §1 · p. 2
  • The evaluation examines whether the generated implementation meets an assumed planning-cycle budget and how its end-to-end behavior depends on runtime factors.The paper hypothesizes that retargetability depends on exposed data parallelism, preservation of generated-code structure, and system-level execution behavior including runtime overheads.Source: §1 · p. 2
  • The workflow is designed for Simulink-based CPS applications whose computationally intensive logic can be mapped to independent candidate-wise or data-wise computations.The stated contributions include automated trajectory-level data-parallel mapping and an end-to-end evaluation on a physical many-core platform.Source: §1 · p. 2
  • The evaluated workflow meets the assumed 100 ms planning-cycle budget for 4,000 trajectory candidates while examining scalability.This is the paper's reported platform evaluation outcome.Source: §1 · p. 2

2 System Model

The system model connects a Simulink Frenet planner to OpenCL execution on a cluster-based many-core processor. Its target applications must expose independent data-parallel work and satisfy GPU Coder, translator, and platform-interface constraints.

2 System Model

  • The system model frames deployment of a Frenet-frame planner on OpenCL many-core processors as a model-based parallelization and code-generation workflow.The stated stages begin with GPU-Coder CUDA generation and continue with CUDA-to-OpenCL conversion.Source: §2 · p. 3

2.1 Frenet-frame-based trajectory planner

  • The Frenet planner samples terminal conditions in Frenet coordinates and selects the lowest-cost feasible trajectory from independent candidates.The study evaluates 4,000 candidates formed from 40 lateral offsets, 10 time horizons, and 10 target speeds.Source: §2.1 · p. 3

2.2 Simulink

  • The Simulink model places computationally intensive planner logic in MATLAB Function blocks so candidate-wise computations can be expressed independently.This structure provides the basis for data-parallel execution and subsequent code generation.Source: §2.2 · p. 4

2.3 GPU Coder

  • GPU Coder generates CUDA kernels primarily from MATLAB Function blocks, while translating other Simulink blocks into host-side code.Thus, computationally intensive parts must be implemented in MATLAB Function blocks for kernel generation.Source: §2.3 · p. 4

2.4 Many-core processors

  • The MPPA Coolidge2 assigns one compute cluster to host the OpenCL runtime and uses the remaining clusters for device kernels.Each cluster has dedicated local memory, so workload partitioning and inter-cluster communication overhead affect execution performance.Source: §2.4 · p. 4

2.5 OpenCL

  • OpenCL provides a vendor-independent heterogeneous programming framework with a host–device model similar to CUDA, supporting systematic translation.The MPPA Coolidge2 supplies the OpenCL runtime used to execute the converted code.Source: §2.5 · p. 4

2.6 Target Application Class and Assumptions

  • The workflow targets models with computationally intensive MATLAB Function logic, independent candidate-wise or data-wise tasks, supported generated CUDA patterns, and platform-compatible kernel interfaces.Scalar-argument packing addresses the MPPA kernel-argument limit; basic-block-dominated models and workloads with strong sequential dependencies are outside the intended scope.Source: §2.6 · pp. 4–5

3 Design and Implementation

The framework retargets Simulink-generated CUDA code to OpenCL while preserving the model-based workflow, adding platform-aware translation and mapping candidate-parallel work onto Kalray MPPA Coolidge2.

3 Design and Implementation

  • The framework converts Simulink-generated CUDA into OpenCL-compatible code that compiles with the Kalray toolchain without manual modification.It rewrites CUDA-specific constructs into forms valid in standard C++ and OpenCL environments.Source: §3 · pp. 5–6

3.1 Rationale for Using CUDA as an Intermediate Representation

  • GPU Coder supplies a structured CUDA host–device representation that can be retargeted without changing the Simulink model; a direct MPPA-ready Simulink-to-OpenCL path was unavailable.The approach uses CUDA as an intermediate representation so platform-specific adaptations can be handled during translation.Source: §3.1 · p. 6

3.2 Workflow Overview

  • A Python-based converter translates GPU Coder output into OpenCL host and kernel files, preserving program structure and producing ready-to-build outputs.The host manages OpenCL context, memory, and kernel invocation; the device file contains parallel kernels.Source: §3.2 · pp. 6–7

Host Code Compilation

  • The host code is cross-compiled with kvx-linux-g++, kernels with kvx-poclcc, and the resulting binaries run through the POCL OpenCL runtime on MPPA Coolidge2.The kernel compiler produces precompiled .pocl binaries.Source: Host Code Compilation · p. 7

3.3 CUDA-to-OpenCL Translation

3.4 Execution Mapping on MPPA

  • One cluster runs the OpenCL host while the others execute kernels, with each candidate trajectory assigned to a work-item distributed across compute clusters.Global memory holds shared data; local and private memory serve per-task computation.Source: Figure 5 · p. 6, §3.4 · p. 8

4 Evaluation

On Kalray MPPA Coolidge2, the evaluation compares sequential and OpenCL-parallel Frenet planning, measures candidate capacity under a 100 ms budget, and examines runtime effects on observed scalability.

4.1 Experimental Setup

  • The planner generated a fixed number of candidates per cycle, and execution time was compared with a CPU serial implementation under repeated, identical conditions.The evaluation ran on Kalray MPPA Coolidge2.Source: §4.1 · p. 9, §4 · p. 9

4.2 Performance Results

  • 17.4 ms median and 18.9 ms maximum end-to-end time on four clusters yielded an approximately 11.2× speedup over the single-core sequential baseline and stayed below the 100 ms budget.The figure compares sequential execution and OpenCL cluster parallelization for 4,000 candidates.Source: Figure 6 · p. 10, Absolute Performance Improvement · p. 10
  • Execution fell from 36.4 ms with one cluster to 17.4 ms with four, a 2.1× speedup; fixed host-side overheads increasingly limited gains as per-cluster workload decreased.Two and three clusters achieved 1.5× and 1.9× speedups, respectively, relative to one cluster.Source: Cluster-Level Scalability · p. 10

4.3 Maximum Processable Candidates Under 100 ms Planning-Cycle Budget

  • Within 100 ms, capacity rose from 14,000 candidate trajectories with one cluster to 31,000 with four, a 2.21× increase.The reported thresholds mark the first candidate count exceeding the budget, so the maximum count within budget is 1,000 below each threshold.Source: Figure 7 · p. 11, §4.3 · p. 11

4.4 Runtime Granularity and OS-Level Effects

  • Early sleep-based polling rounded times to approximately 10 ms ticks and masked fine-grained scaling; busy-wait polling removed quantization, tracing the apparent limit to runtime scheduling rather than hardware.The refined measurements showed consistent performance improvements as cluster count increased.Source: §4.4 · pp. 11–12

4.5 Lessons Learned

  • Retargetability requires MATLAB Function blocks with independent candidate- or data-wise tasks, while feasibility depends on end-to-end latency and runtime overhead, not kernel execution alone.The lessons also caution that cluster scaling is not linear because of host orchestration, synchronization, memory transfer, and operating-system or runtime behavior.Source: §4.5 · pp. 12–13

5 Related Work

Related work addresses CUDA translation, portability abstractions, and model-based parallelization, but the paper distinguishes its workflow-preserving retargeting across heterogeneous many-core platforms from these approaches.

5.1 CUDA-to-OpenCL Translation

  • CU2CL, Swan, and Du et al. address CUDA-to-OpenCL translation, but the cited translators do not target Simulink-generated code or MPPA-specific constraints.The passage describes CU2CL as AST-based and Swan as a lightweight Python converter.Source: §5.1 · p. 13

5.2 High-Level Intermediate Representations

  • SYCL and AMD HIP offer higher-level portability, but their runtime requirements limit direct applicability to platforms such as Kalray MPPA.The passage describes SYCL as a single-source C++ model and HIP as a GPU portability layer.Source: §5.2 · pp. 13–14

5.3 Model-Based Parallelization

  • MBP and ROS 2 parallelized code generation exploit parallelism in Simulink models, but focus on execution within a target platform rather than retargeting across architectures.Source: §5.3 · p. 14

5.4 Summary of Differences

  • The proposed framework targets GPU-Coder-generated CUDA, preserves the Simulink workflow, and addresses platform-specific kernel-argument limits and cluster mapping; its focus is cross-platform retargeting.Source: §5.4 · p. 14

6 Conclusion

The paper concludes that GPU-Coder-generated CUDA can serve as an intermediate representation for deploying Simulink trajectory planners on OpenCL many-core processors, with feasibility shaped by workload structure and end-to-end latency.

6 Conclusion

  • The workflow retargets a Simulink Frenet planner through GPU-Coder-generated CUDA to OpenCL host and kernel code for candidate-parallel execution on Kalray MPPA Coolidge2.The evaluation demonstrates deployment on a cluster-based many-core processor.Source: §6 · p. 14
  • Retargetability depends on MATLAB Function blocks and independent candidate- or data-wise tasks; platform-aware NDRange mapping, API emulation, and argument packing preserve execution under constraints.Source: §6 · p. 14
  • Feasibility depends on end-to-end latency, and admissible search-space size varies with the planning-cycle budget; cluster-count gains diminish under host, synchronization, and runtime overheads.The paper emphasizes model structuring, workflow-level latency evaluation, and runtime configuration for deployment.Source: §6 · p. 15
  • The converter targets observed common GPU Coder CUDA patterns rather than guaranteeing exhaustive coverage, and generalizability across additional application domains remains future work.Source: §6 · p. 15
Loading 2609.29311v1…