Arm Virtual Hardware  Version 2.2.0
Solution Overview
 
Loading...
Searching...
No Matches
Development Workflow

Using Arm FVP models enables a flexible approach that combines desktop and cloud-native development tools thus simplifying and accelerating the development of embedded software.

Continuous Integration (CI)

New functionality can be quickly developed on a simulation model with frequent changes being automatically verified upon the code commits to a cloud based version control system such as GitHub which executes a complete CI/CD integration flow. Figure below illustrates the concept.

Continuous Integration (CI) workflow
  1. Local development is done by engineers on local machines using common embedded tools such as Keil MDK with Arm FVP models used for simulation. See FVPs on Desktop for details. The software can also be already prepared for real hardware as explained in Migration to Physical Hardware.
  2. A code repository is used as a source code management system for synchronization, storage and version control.
  3. CI pipeline implements the continuous integration flow (for example GitHub Actions) that gets triggered on every code update in the target repository.
  4. CI execution includes automated program build and testing and is performed in the cloud with results being reported back to the repository and user. See Infrastructure for details.
  5. Failure analysis and local debug: developers can observe the CI test results and in case of any failures also use a local setup to reproduce and debug the issues.

Learn more about benefits from CI workflow at Continuous Testing.

Migration to Physical Hardware

Modular programming recommends to separate the functionality of a program into independent, interchangeable modules that use defined interfaces that abstract the hardware functionality.

This "software-first" design concept simplifies code re-use and allows to implement "Virtual Drivers" and "Hardware Drivers" that expose the same API and implement the same logical behavior. If built correctly, it overcomes many issues that are typically found in monolithic software and enables a staged software validation with multiple test levels such as unit, integration, and system testing.

To simplify re-targeting from Arm FVP simulation models to final production hardware, the examples implement the concept of software layers. This makes it easy to work on a combination of simulated and physical hardware. The picture below exemplifies this concept.

Re-target from Simulation to Hardware