Simplifying Functional Safety and Security in Aerospace Applications with RISC-V

By: Gerard Vink, Industry Specialist, TASKING and Jay Thomas, Senior Director, Field Engineering, TASKING.

Aerospace software keeps getting bigger, and the processors it runs on keep getting more complicated. Multicore SoCs give flight software the throughput it needs. They also make deterministic behavior harder to prove. Certifying to DO-178C now means meeting the multicore objectives in AMC 20-193 and AC 20-193 as well, and that is where most programs lose schedule.

RISC-V was designed with real-time execution in mind. Reliability and security features are part of the standard architecture. This article looks at how an open, modular ISA takes work out of designing, testing and certifying aerospace systems.

Standardization and Modularization

Many multicore SoCs are built around proprietary architectures, in some cases several such architectures. Consider the variety of Arm implementations. Developers can choose different options, including hardware partitioning, memory management units, and privilege modes. Many Arm vendors build out new capabilities using their own proprietary implementations.

However, this variety comes at the cost of flexibility and ecosystem compatibility. For example, a feature offered by one vendor may differ in implementation from the same feature offered by a different vendor. This can result in effectively a unique SoC architecture in terms of hardware, software, and tools, even between SoCs within the same family.

This leads to vendor lock-in, making it difficult to second source an equivalent architecture. Vendor lock-in also limits the hardware and tools a team can use, shrinking the available development ecosystem and creating challenges when vendors discontinue products, modify roadmaps, or change licensing terms and no equivalent solution is available.

RISC-V avoids many of the disadvantages of proprietary SoCs by being based on an open instruction set architecture (ISA). The ISA is structured as a small base integer set, enabling developers to incorporate just the essential features they need and minimize unnecessary system complexity and cost. SoCs can be customized using standard extensions. Code is more portable between architectures, enabling teams to use similar SoCs from other vendors without a major system migration effort. Advanced security functions can be incorporated without sacrificing compatibility. And engineers can use their tools-of-choice without being locked into a particular development platform.

The modularity of the RISC-V architecture also supports multicore SoCs using only RISC-V cores. This simplifies system development within a single, unified toolchain rather than requiring a distinct tool suite for each core (see Figure 1).

Figure 1: A multicore SoC designed using only RISC-V cores simplifies development with a single, unified toolchain rather than requiring different tools for each core.

Another benefit of modularity is that it clearly defines core functionality and optional extensions, and separates hardware and software as outlined by DO-178C and DO-254. Engineers can document safety-related custom extensions while maintaining standard interface specifications for the base architecture, simplifying requirements traceability and verification processes.

Expansive Ecosystem

Because RISC-V-based SoCs are built on the same ISA, suppliers can innovate around the architecture while maintaining compatibility and code portability. This reduces market fragmentation, creates a larger ecosystem, and gives programs a wider choice of silicon vendors, development tools, and safety-certified components, including radiation-hardened RISC-V processors for space from vendors such as Frontgrade Gaisler. NASA’s next-generation High-Performance Spaceflight Computing (HPSC) processor, which Microchip is building on RISC-V cores, is set to replace the RAD750 that has flown on NASA missions for two decades. RISC-V’s royalty-free licensing model eliminates cost barriers inherent with custom implementations.

Such flexibility is particularly valuable for aerospace programs where long-term product support, component availability, and qualification requirements must be maintained over many years. This stability ultimately reduces both commercial and technical risk. The same applies to tools. Open-source tools move fast, but a long program needs suppliers who qualify their tools for specific market segments and support them for decades.

Reliability and Safety

Determinism is essential for mission-critical systems, and DO-178C requires Worst Case Execution Time (WCET) analysis to verify that real-time deadlines will always be met. Dependencies between tasks, such as data coupling (one component depends on data it does not control) and control coupling (one component influences the execution of another) can add execution delays.

Multicore SoCs introduce timing coupling (what AMC 20-193 calls interference), where contention for shared SoC resources like cache memory or buses arises between otherwise independent tasks. For example, code running on one core could unexpectedly flush the cache for optimized, time-critical code running on another core.

Assessing the impact of timing coupling on WCET requires iterating different code combinations running on different cores to evaluate the potential impact of cache flushing. To help address timing coupling, some RISC-V implementations, such as Microchip’s PolarFire SoC, allow the L2 cache to be configured as RAM. PolarFire SoC also supports asymmetric multiprocessing (AMP), so time-critical code can run bare-metal or under an RTOS on dedicated cores while Linux runs on the others. This capability gives developers more precise control over critical system timing to simplify optimization, increase reliability, and facilitate the WCET analysis required for certification.

Performing detailed WCET analysis of multicore RISC-V SoCs requires software development tools integrated to take full advantage of the RISC-V architecture’s unique capabilities. WCET analysis crosses between compile, debug, and test tools to accurately assess complex timing coupling between cores. A unified platform like the TASKING toolchain automates many manual tasks and leverages agentic AI to accelerate analysis and verification. Agentic AI-based automation can run more task and core combinations, which widens coverage of possible interference. The timing evidence itself still comes from measurement on the target with qualified tools.

Integral Security

Connected systems must protect themselves from an expanding threat landscape and be able to adapt as new cyberattacks arise. Essential security capabilities such as privilege levels and memory protection are part of the base standard, and advanced features are implemented using standard extensions. This means basic security is integral to every system from the ground up. Standard ISA extensions add more, such as forward- and backward-edge control-flow integrity (Zicfilp, Zicfiss) and scalar cryptography (Zk). And, as an open ISA, RISC-V provides transparency that enables developers to better understand, evaluate, and improve overall system security.

Microarchitectural Instruction Fusion

RISC-V processors can accelerate performance through instruction fusion, a process where instruction pairs that use different functional units can be executed together as a single instruction. Traditionally, instruction fusion has been implemented by introducing new “fused” instructions. However, fused instructions can only run on processor implementations that support them, limiting portability of code. As a result, instruction fusion has contributed to ecosystem fragmentation and vendor lock-in.

To maintain standardization, RISC-V leaves instruction fusion to the microarchitecture. Fusion is not performed by the compiler but rather internally within the instruction pipeline. This maintains full RISC-V code compatibility between processors.

To take full advantage of instruction fusion, however, the compiler needs to be microarchitecturally aware. For example, TASKING built its RISC-V compiler in close cooperation with the ARC-V team, now part of MIPS by GlobalFoundries, to fully exploit the ARC-V’s fusion capabilities. The compiler aligns optimizations to generate fusible instruction pairs. This reduces pipeline pressure, lowers decode overhead, and increases instruction throughput. Developers benefit from more efficient software without any direct effort on their part.

Accelerated Development Through Virtualization

To meet tight deadlines, teams need to be able to start software development before hardware is available. RISC-V facilitates early design space exploration, system evaluation, and validation through the availability of virtual platforms.

Through virtualization, teams can start writing software with TASKING’s RISC-V compiler and execute it on a virtual platform under the control of the TASKING winIDEA debugger (See Figure 2). They can also use TASKING’s LDRA tool suite to begin testing software.

Note that this compile-debug-test workflow can scale into the cloud. This is especially useful for automating and accelerating complex iterative testing and analysis, such as is required to accurately evaluate WCET.

Figure 2: Developers can scale development into the cloud with a virtual platform to accelerate iterative testing and analysis such as evaluating Worst-Case Execution Time (WCET).

All this work can be accomplished pre-silicon, before hardware is even available. In addition, developers can move from the virtual platform to target hardware while using the same toolchain and consistent DevOps workflows. For example, all test scripts developed pre-silicon can be leveraged without modification from design through to production.

This approach also has the benefit of enabling verification and certification to begin at the earliest stages of development. This shift-left approach to development enables potential issues to be identified faster and resolved with less effort (see Figure 3). Developers can detect many design flaws before hardware manufacturing begins, reducing cost and risk.

Figure 3: Testing earlier in the development lifecycle identifies potential issues sooner and reduces the development cost to resolve them.

Simplified Certification

RISC-V’s open architecture provides options for implementing dissimilar redundancy strategies for systems that are assigned Design Assurance Level A (DAL A). Engineering teams can deploy varying processor configurations within a single system or use different RISC-V vendor implementations while preserving architectural consistency. Additionally, they have the flexibility to integrate diverse architectures in mixed-criticality systems where safety requirements and certification levels vary across components. These implementation approaches minimize the complexity of certification evidence required to demonstrate protection against common-mode failures.

The growing number of certification-ready RISC-V IP cores from major vendors also reduces certification overhead. Developers can leverage existing certification documentation when using these certification-ready cores, reducing compliance effort.

The RISC-V architecture is a strong option for aerospace applications. With security and safety built into the core architecture and into software development tools that target functional safety and cybersecurity, RISC-V is a good fit for reliable, real-time aerospace systems. The open modularity of RISC-V gives programs access to the SoCs and toolchains of their choice, reducing vendor lock-in and simplifying certification while reducing cost and risk. And with the right integrated toolchain, developers can optimize the entire development lifecycle, from design through test and certification, while maintaining safety, security, and reliability standards.