From CPU to GPU: A Safe and Structured Migration Approach Using Architecture Verification

The availability of high-performance GPUs that drastically speed up computations in many different domains gives a new push to the idea of migrating legacy systems’ CPU algorithms to their GPU counterparts to benefit from the speedups. Migrating existing CPU-based C/C++ code to GPU-accelerated implementations (CUDA® or similar models) is not primarily a syntactic transformation. It is an architectural intervention. Not limited to safety-regulated systems, e.g. in medical devices or automotive, the challenge is not only about rewriting functions but also about preserving system integrity while introducing a fundamentally different execution model.

A disciplined approach is required to control risk, maintain correctness, and ensure long-term maintainability. This post outlines a method that combines architectural analysis with continuous verification and CUDA-specific safety enforcement.

1. Establishing an Architectural Baseline

A migration effort without architectural visibility tends to degrade system structure. Therefore, the first step is to establish a reliable architectural baseline.

1a. Existing Architecture Available

If a formal software architecture already exists, it should be validated against the current implementation using Axivion’s architecture verification capabilities. This step ensures:

• Conformance between intended and actual structure

• Identification of erosion or drift

• A stable baseline for subsequent migration decisions

This baseline acts as a contract. Any GPU-related changes can later be validated against it.

1b. No Architecture Available

In many legacy systems, architecture documentation is non-existent, incomplete, or outdated. In such cases, architecture recovery is required.

Axivion’s architecture recovery extracts a structural model directly from the codebase, including:

• Component boundaries

• Dependency graphs

• Layers and subsystems

The recovered architecture is then refined into a working model that serves the same purpose as a documented architecture: a reference point for controlled evolution. This recovery step can benefit from the assistance of available domain experts - and from the use of GenAI.

2. Identifying and Preparing Migration Candidates

Not all components are suitable for GPU migration. Selection should be based on computational characteristics such as:

• Data parallelism

• High arithmetic intensity

• Low branching complexity

Once candidate components are identified, their interfaces must be explicitly defined and stabilized.

Why Interface Definition Matters

GPU migration often introduces:

• Memory boundary changes (host ↔ device)

• Data layout transformations

• Asynchronous execution semantics

Without clearly defined interfaces, these changes propagate unpredictably through the system.

In addition, insufficient architectural control commonly leads to:

• Accidental tight coupling between components

• Forgotten or implicit dependencies resurfacing during refactoring

• Violations of intended layering and component boundaries (thinking of “Freedom from Interference” between components of different safety integrity levels)

Using Axivion’s architecture tooling, teams can:

• Document component interfaces

• Enforce dependency constraints

• Support systematic decoupling of components

• Detect and eliminate hidden or unintended dependencies early

This step effectively isolates migration scope and reduces systemic risk.

3. Iterative Migration with Continuous Verification

Migration should proceed incrementally, not as a single large transformation. Each iteration introduces GPU functionality while maintaining system correctness.

Continuous Architecture Verification

After each iteration:

• The updated codebase is checked against the architectural model

• Violations (e.g., new dependencies, layer breaches) are detected early

• Missing dependencies are identified

• Structural degradation is prevented

This ensures that changes due to GPU integration does not compromise the overall system design. Furthermore, an automated comparison between old and new architecture can reveal if the GPU-based implementation interacts with the overall system in the same way the CPU-based component did. Any diversion might indicate that the newly developed component is not as much a “drop-in replacement” as desired.

4. Enforcing CUDA Safety Rules

GPU programming introduces new classes of flaws that are not present in CPU-only systems.  To address these, CUDA-specific safety rules must be applied consistently across both legacy and newly introduced code.

Axivion is currently the only tool that can statically analyze CUDA source code while enforcing NVIDIA’s CUDA safety programming rules. This provides a unified analysis capability across:

• Host-side C/C++ code interacting with CUDA APIs

• Device-side CUDA kernels

• Memory management and transfer logic

By integrating CUDA safety rules into one joint analysis pipeline, teams achieve:

• Uniform quality standards across heterogeneous code

• Early detection of GPU-specific defects

• Reduced debugging and validation effort

5. Outcome: Controlled and Verifiable Migration

This approach produces several concrete benefits:

• Traceability: Every migration step is tied to architectural intent

• Isolation: Changes are confined to well-defined components

• Correctness: Continuous verification prevents structural and functional safety regressions

• Safety: CUDA-specific risks are systematically mitigated

The result is not just a GPU-enabled system, but one that remains structurally sound and maintainable.

Closing Remark

GPU migration is often framed as a performance optimization task. In practice, it is a system evolution problem. Treating it as such—by combining architecture recovery, verification, and safety rule enforcement—enables teams to scale migration efforts without losing control over system complexity.

This article was written in co-operation with Dr. Sebastian Krings.