RISC-V Profiles for Real Products: What Standardization Changes for Portability, Toolchains and Safety Cases

RISC-V has spent most of its first decade being simultaneously overhyped as an ARM killer and underestimated as a production-grade embedded architecture. The honest picture in 2025 is more specific than either extreme. RISC-V is not replacing ARM across the board. It is, however, becoming a credible platform for well-defined categories of embedded products, and the technical reasons for this shift are rooted less in ISA elegance than in a set of standardization milestones that most embedded engineers have not yet fully internalized.

The ratification of the RVA23 profile in October 2024 is the most significant of these milestones for application-class processors. For MCU-class embedded development — the domain of real-time control, safety-critical firmware, and constrained hardware — the trajectory of profile standardization, toolchain certification, and safety IP availability now makes RISC-V a platform that product engineering teams need to evaluate seriously, rather than treating it as research infrastructure with uncertain production applicability.

The Fragmentation Problem That Profiles Are Designed to Solve

The architectural flexibility of RISC-V is also its principal liability for product engineers. Unlike ARM Cortex-M, where a Cortex-M4 from STMicroelectronics and a Cortex-M4 from NXP both execute the same binary, RISC-V silicon vendors can implement different combinations of optional extensions. A device with RV32IMC includes the multiply, compressed instruction, and integer base extensions. Another device adds F for single-precision floating-point, or B for bit manipulation, or V for vector operations. Without an agreed minimum feature set, software cannot be compiled for a portable binary target — the compiler must know exactly what instructions the hardware will execute.

This fragmentation concern is precisely what RISC-V International's profile specification addresses. A profile defines which ISA extensions are mandatory, which are optional but recommended, and which are explicitly excluded. Software built against a profile target can rely on the mandatory feature set being present in any compliant implementation.

The profile hierarchy currently covers two main market segments:

• RVA profiles: target 64-bit application processors running full OS distributions, binary-compatible across multiple hardware vendors. RVA23, ratified in October 2024, mandates the V Vector extension, the H Hypervisor extension, and a set of floating-point, cryptography, and atomic extensions that make it suitable for Linux-class compute including edge AI and server workloads.
• RVB profiles: target customized 64-bit application processors where custom OS builds are acceptable. RVB23, ratified alongside RVA23, provides a large mandatory feature base while allowing more optionality for extensions that are expensive to implement in silicon.

For most embedded MCU-class designs — 32-bit real-time controllers, motor drives, automotive ECUs, industrial sensors — neither RVA23 nor RVB23 is the directly relevant profile. The relevant work is at the 32-bit embedded and microcontroller profile level, where RISC-V International continues active specification work. The MCU-class profile targets devices running RTOS workloads without a full OS, and the feature set maps to what Zephyr, FreeRTOS, and bare-metal firmware actually need: integer math, compressed instructions, hardware multiply, optional floating-point, and memory protection unit support.

The practical consequence of profile ratification at the application level is that it anchors the compiler and OS ecosystem. Ubuntu's decision in August 2025 to require RVA23 as the baseline for RISC-V support — deprecating older profiles — is exactly the kind of ecosystem consolidation that makes software investment predictable. When a toolchain vendor, OS distributor, and hardware vendor all converge on the same profile, binary compatibility becomes a real and testable property rather than a theoretical one.

What Profile Standardization Changes for Toolchain Users

Before profiles, a RISC-V GCC or LLVM build required careful management of the -march and -mabi flags to match the exact extension combination of the target silicon. Switching from one vendor's RV32IMAC implementation to another vendor's RV32IMAFC implementation meant verifying that the compiler flags were updated and that any assembly code or intrinsics referencing specific extensions were compatible. For teams managing firmware across multiple product SKUs using different silicon, this was a concrete maintenance burden.

With a ratified profile as the compiler target, the compiler flag becomes a well-defined contract: build for RVA23U64 and the resulting binary will execute on any compliant implementation. The toolchain vendor's responsibility is to ensure that the code generator produces correct output for all mandatory extensions in the profile. The silicon vendor's responsibility is to implement those extensions and document compliance. The test suites maintained by RISC-V International and contributed implementations in QEMU and Spike provide a reference against which compliance can be verified.

The toolchain landscape for RISC-V has matured considerably since 2020. The key commercial tools relevant for embedded product development are:

• GCC 14 and LLVM 18: both provide production-quality code generation for RISC-V 32-bit and 64-bit targets. GCC's RISC-V backend is actively maintained with contributions from SiFive, Alibaba, Andes Technology, and PLCT Lab.
• IAR Embedded Workbench for RISC-V: the functional safety edition is certified by TÜV SÜD for IEC 61508, ISO 26262, IEC 62304 (medical), EN 50128 (railway), and ISO 13849 (machinery). For product teams building safety-critical devices, a certified compiler is a mandatory element of the software qualification evidence package. IAR's December 2025 release extended support to SiFive's E7-A and S7-A automotive cores.
• SEGGER Embedded Studio and J-Link: debug and trace support for RISC-V is available, though trace capabilities for certain RISC-V cores still lag the maturity of Cortex-M trace infrastructure.
• Lauterbach TRACE32: supports RISC-V with hardware trace modules for silicon vendors who implement the RISC-V trace specification.

The table below compares toolchain availability for RISC-V against ARM Cortex-M across the dimensions most relevant for production embedded development:

The gap that remains most significant for safety-critical embedded development is the absence of a universally available, vendor-optimized math library equivalent to ARM's CMSIS-DSP. For DSP-intensive workloads — motor control, audio processing, sensor fusion — CMSIS-DSP provides optimized fixed-point and floating-point routines tuned to the Cortex-M hardware pipeline. RISC-V silicon vendors with vector extensions can achieve comparable performance, but the software layer requires either in-house optimization or reliance on vendor-specific libraries that are not portable across RISC-V implementations.

Building a Safety Case on RISC-V: What Has Changed

The ISO 26262 and IEC 61508 safety case for a product built on RISC-V requires evidence at three levels: the processor IP, the compiler and development toolchain, and the RTOS and safety software libraries. Until 2020, each of these was incomplete or absent. The trajectory since then has been consistent.

At the processor IP level, SiFive has led the commercial RISC-V safety IP market. SiFive's E6-A series supports ASIL B hardware safety for real-time workloads, and the E7-A and S7-A series extend this to more demanding automotive and industrial safety applications. SiFive's automotive RISC-V IP has achieved ISO 26262:2018, IEC 61508:2010, and ISO/SAE 21434:2021 certifications across both its 32-bit E Series and 64-bit S Series cores. This means the silicon IP provider delivers a safety manual, FMEDA documentation, and a qualification package that can be incorporated into the product-level safety case — the same evidence structure that ARM Cortex-M device vendors have provided for a decade.

At the toolchain level, IAR's certified Embedded Workbench for RISC-V closes the most significant gap. A certified compiler removes the need for the development team to perform its own compiler qualification by analysis, which under IEC 61508 Tool Confidence Level 3 requirements would require extensive regression testing and code coverage evidence for the compiler itself. The IAR certification by TÜV SÜD provides this evidence as a pre-existing qualification artifact.

At the software library level, the situation is more variable. Vendors including Andes Technology and WCH provide safety-relevant runtime libraries for their specific silicon. RTOS safety certification is in active progress: the Zephyr project's IEC 61508 Safety Element out of Context certification effort is ongoing, and FreeRTOS has an ASIL D safety library available from SafeRTOS under commercial license. The coverage is not yet as complete as the ARM ecosystem, where a product team can select from multiple pre-certified RTOS and middleware vendors with documented ASIL B or ASIL D qualification packages.

The practical impact on a product safety case is that using RISC-V in a new IEC 61508 SIL 2 or ISO 26262 ASIL C product in 2025 is achievable with the right IP and toolchain selection, but requires more upfront planning than the equivalent ARM-based design. The safety case construction effort is higher because fewer pre-qualified software components are available off the shelf, and the product team needs to allocate engineering time to qualification of components that would be pre-certified in an ARM-based alternative.

This is not a permanent state. The combination of SiFive's safety IP certification, IAR's compiler certification, and the ongoing RTOS and library qualification work means the RISC-V safety ecosystem is tracking a credible path toward ARM equivalency over the next two to three years.

Where RISC-V Actually Fits in Production Embedded Designs Today

The fragmentation concern and the safety case maturity gap define the boundaries of where RISC-V is the practical choice for new product designs versus where it remains a higher-risk option requiring additional qualification investment. The following breakdown reflects the current state, not a multi-year aspiration:

RISC-V is the natural choice today for:

• High-volume consumer IoT and industrial sensing products where unit economics dominate, functional safety certification is not required, and the Espressif ESP32-C and ESP32-H series RISC-V MCUs provide a well-supported SDK and strong community.
• Edge AI inference on Linux-class processors where the RVA23 mandatory V extension makes RISC-V competitive for ML workloads and the OS/toolchain ecosystem is converging on the ratified profile.
• Custom SoC development where a RISC-V licensable core is integrated into a purpose-built chip with domain-specific accelerators, avoiding ARM licensing costs and enabling instruction set customization.
• Gateway and connectivity modules where Zephyr RTOS portability is more important than vendor-optimized hardware abstraction.

RISC-V remains a higher-risk choice today for:

• ISO 26262 ASIL C/D or IEC 61508 SIL 3 products where the pre-qualified software component ecosystem is thinner than ARM and the additional qualification effort needs to be budgeted explicitly.
• DSP-intensive control applications requiring CMSIS-DSP-equivalent performance without the engineering overhead of in-house library optimization.
• Products with 15+ year production lifecycle commitments where long-term silicon vendor support guarantees for RISC-V MCUs are less established than the equivalent ARM-based alternatives from STMicroelectronics, NXP, or Renesas.

The direction of travel is clear. RISC-V International reported one billion RISC-V cores shipped in 2024, and Infineon joined as an automotive-focused Premier member in 2025, explicitly to shape RISC-V's development for automotive safety applications. Qualcomm's acquisition of Ventana Micro in December 2025 signaled that RISC-V is reaching the performance tier where it competes directly with high-end ARM cores in data center and edge compute contexts, not just in constrained embedded applications.

For product engineering teams, the actionable implication is that RISC-V should be included in platform feasibility analysis for any new program starting design in 2025 or later, particularly when unit volume, supply chain resilience, or long-term ISA licensing independence are design inputs. The time when RISC-V could be dismissed as insufficiently mature for production use has passed. The time when it can be adopted without careful qualification strategy has not yet arrived for safety-critical domains.

Quick Overview

RISC-V profile standardization — particularly the RVA23 and RVB23 ratifications in October 2024 — marks a shift from fragmented vendor-specific implementations to a defined binary compatibility baseline for application-class processors. For embedded product development, the significance is not only portability across silicon vendors but the downstream effect on toolchain consolidation, OS ecosystem stability, and the construction of functional safety cases for production hardware.

Key Applications

Edge AI inference on Linux-class RISC-V processors targeting the RVA23 mandatory V extension, high-volume IoT and industrial sensing using Espressif RISC-V MCUs with Zephyr or ESP-IDF, custom SoC development requiring licensable RISC-V IP without ARM royalties, automotive ECU designs using SiFive E-Series and S-Series safety-certified RISC-V cores, gateway modules requiring cross-vendor firmware portability.

Benefits

Profile standardization provides a stable compiler target across multiple silicon vendors, reducing the -march flag fragmentation that complicated multi-vendor RISC-V firmware maintenance. IAR Embedded Workbench for RISC-V delivers a TÜV SÜD-certified compiler covering IEC 61508, ISO 26262, IEC 62304, and EN 50128, eliminating the need for in-house compiler qualification. Royalty-free ISA licensing reduces unit-level silicon cost for high-volume designs and enables full custom instruction extension without licensor approval.

Challenges

No universal CMSIS-DSP equivalent exists for RISC-V, creating optimization overhead for DSP-intensive control applications. Pre-certified RTOS and safety middleware is less available than for ARM Cortex-M, increasing the qualification burden for SIL 2 and ASIL C or D products. Long-term production lifecycle guarantees from RISC-V MCU silicon vendors are less established than equivalent ARM-based suppliers. Hardware trace infrastructure is vendor-specific and not yet uniformly mature across RISC-V silicon families.

Outlook

RISC-V International reported one billion RISC-V cores shipped in 2024. Infineon joined as an automotive-focused Premier member in 2025 to shape RISC-V for safety-critical applications. Qualcomm's acquisition of Ventana Micro in late 2025 signals RISC-V reaching high-performance compute tiers beyond embedded. MCU-class profile standardization, ongoing RTOS safety certification efforts, and expanding silicon vendor commitment suggest the ARM-equivalency gap in safety-critical embedded tooling will narrow substantially by 2027.

Related Terms

RVA23, RVB23, RISC-V profile, RISC-V ISA extensions, RV32IMAC, V Vector extension, Zephyr RTOS, FreeRTOS, IAR Embedded Workbench, GCC RISC-V, LLVM RISC-V, CMSIS-DSP, IEC 61508, ISO 26262, ASIL D, SiFive E-Series, SiFive S-Series, Espressif ESP32-C, RISC-V International, TÜV SÜD, safety case, functional safety compiler, MISRA-C