RISC-V vs ARM
A comparison of RISC-V and ARM as competing instruction set architectures (ISAs) — licensing models, extensibility, ecosystem maturity, and typical deployment today. This is a conceptual/reference doc; specific performance and market-share figures should be cross-checked against current vendor data before use in analysis.
1. What They Are
Both RISC-V and ARM are instruction set architectures built on RISC (Reduced Instruction Set Computer) design principles — small, uniform instructions, load/store-only memory access, and an emphasis on simplicity over the complex, variable-length instructions found in CISC architectures like x86. The meaningful difference between them isn't RISC-ness, it's governance and licensing: RISC-V is an open standard, ARM is a proprietary architecture licensed by a single company.
2. Comparison Table
| Aspect | RISC-V | ARM |
|---|---|---|
| Origin | UC Berkeley, 2010 (Krste Asanović et al.) | Acorn Computers, 1985 |
| Licensing model | Open standard, royalty-free — anyone can implement without paying fees | Proprietary — companies license cores or the architecture itself from Arm Holdings |
| Governance | RISC-V International (nonprofit, member-driven) | Arm Holdings (private company, owned by SoftBank as of last data) |
| Base ISA | Small, modular base (RV32I/RV64I) with optional standard extensions (M, A, F, D, C, V, etc.) | Fixed core architecture per version (e.g., ARMv8-A, ARMv9-A), defined entirely by Arm |
| Customization | Highly extensible — companies can add custom instructions/extensions | Limited — Arm controls the spec; custom extensions require Arm's cooperation |
| Instruction encoding | Fixed 32-bit base, with optional 16-bit compressed extension (C) for density | Fixed 32-bit (AArch64), or 16/32-bit Thumb mixed mode on 32-bit ARM |
| Registers | 32 general-purpose registers (RV32/64) | 31 general-purpose 64-bit registers (AArch64) |
| Maturity / ecosystem | Younger, ecosystem still maturing — fewer high-performance commercial cores, growing tooling/OS support | Mature, decades of tooling, compilers, OS support, and existing software base |
| Performance today | Competitive in embedded/microcontroller space; high-performance server/mobile cores still emerging (e.g., SiFive, Alibaba) | Dominant in mobile (virtually all smartphones), strong in embedded, growing fast in servers/laptops (Apple Silicon, AWS Graviton) |
| Typical use today | Microcontrollers, embedded systems, custom silicon, some emerging server/AI chips | Smartphones, tablets, Apple M-series, embedded systems, increasingly cloud servers |
| Vendor lock-in | None — open spec, no single company controls it | Yes — dependent on Arm's licensing terms and roadmap |
| Verification / compliance | RISC-V International runs compliance/conformance testing; implementations can vary more due to optional extensions | Arm tightly controls compliance, giving more consistency across licensees |
| Geopolitical angle | Increasingly attractive to countries/companies wanting to avoid US/UK export-control exposure (open spec) | Subject to UK/Arm's export and licensing policies |
3. Why Firmware Engineers Expect Porting to Be Hard
The instruction set itself isn't the obstacle — RISC-V is arguably simpler and more orthogonal than Thumb. The friction comes from a deliberate design choice: ARM standardizes the system around the core; RISC-V only standardizes the core itself.
ARM's Cortex-M architecture spec doesn't stop at the instruction set — it defines a fixed, memory-mapped System Control Space. The NVIC lives at a specific address, SysTick lives at a specific address, the MPU lives at a specific address, on every Cortex-M chip from every vendor. That's what CMSIS is built on: NVIC_EnableIRQ() behaves identically on an STM32, an NXP part, and a Nordic part because the hardware is required to match.
RISC-V's privileged spec standardizes the core (the base ISA, the CSRs like mstatus/mtvec/mepc/mcause) but deliberately leaves most system-level details — the interrupt controller's exact register layout, the timer, TCM, the memory map — as platform-defined. There's a baseline (CLINT/PLIC, and now CLIC as a newer standard), but vendors diverge in a way ARM licensees architecturally can't. So the thing engineers actually miss isn't "RISC-V" — it's a universal CMSIS equivalent, and nothing has that level of adoption yet (Nuclei's NMSIS is the closest attempt, but it isn't industry-wide).
3.1 Interrupt handling — the biggest single complaint
| ARM Cortex-M (NVIC) | RISC-V (baseline) | |
|---|---|---|
| Exception entry | Hardware auto-stacks R0–R3, R12, LR, PC, PSR | Software must save context in the trap handler prologue |
| Vectoring | Hardware vector table, jumps straight to handler | mtvec direct mode = one shared handler, or vectored mode (needs CLIC or a vendor extension) |
| Tail-chaining / late-arrival | Hardware optimizes back-to-back interrupts automatically | Not architected in the base spec — CLIC adds it, but it's an extension |
| Priority levels | Hardware NVIC, configurable priority + preemption, nesting "just works" | No architected priority controller in the base spec — vendor-specific (PLIC has priority, but coarser, typically external-interrupt only) |
| Fault diagnosis | Dedicated HardFault/MemManage/BusFault/UsageFault with fault status registers | Generic mcause with a numeric cause code — less granularity unless the vendor adds more |
CLIC closes most of this gap and vendor cores (SiFive, Andes) have decent interrupt controllers, but interrupt latency and ISR structure aren't portable across RISC-V vendors the way they are across every Cortex-M vendor.
3.2 Tightly-coupled memory — a clean example of the pattern
- On ARM (Cortex-M7, Cortex-R), TCM is an architected concept with defined configuration registers and a documented relationship to the core. Every vendor's M7 TCM behaves the same way at the programming-model level.
- On RISC-V, there is no standardized TCM at all. If a vendor's core has tightly-coupled memory, it's a vendor-specific address range with vendor-specific (or nonexistent) control registers. Code placing a hot ISR or a lookup table in TCM may need a different linker script and enable sequence on every RISC-V vendor's core, even though the concept is identical.
The same pattern shows up in the overall memory map (ARM mandates where code/SRAM/peripheral/system regions live; RISC-V doesn't) and in security isolation (TrustZone is one architected mechanism across all ARM licensees; PMP is architected but coarser, and anything TrustZone-equivalent on RISC-V is vendor-proprietary and non-portable).
3.3 Boot and startup code
ARM Cortex-M has a hardware-defined boot sequence: on reset, the core automatically reads the initial stack pointer and reset handler address from a fixed location, and CMSIS ships a standard startup_device.s template every vendor fills in the same way. RISC-V has no architected reset-vector convention in the same sense — the reset PC is implementation-defined, there's no automatic SP load, and startup assembly is written per-toolchain and per-vendor rather than following one blessed template.
3.4 Ecosystem maturity, not architecture
This likely explains more of the perceived difficulty than any technical item above:
- Toolchains/debuggers — decades of mature Keil/IAR and SWD/CoreSight debug on ARM vs. newer, less uniformly polished RISC-V debug and trace support (the RISC-V Debug Spec is standardized, but tool support varies by vendor).
- HALs and driver stacks — STM32Cube, MCUXpresso, etc. represent a decade of validated peripheral drivers; RISC-V vendor HALs are younger and thinner.
- Certification evidence — safety-critical teams (ISO 26262, DO-178) have years of accumulated static-analysis rulesets and qualification evidence specific to ARM cores; switching architectures means redoing much of that paperwork independent of how similar the C code looks.
- Institutional muscle memory — engineers know NVIC quirks and debugger workflows cold; that expertise doesn't transfer directly.
4. Key Takeaway
The core tension is freedom vs. maturity. RISC-V trades ecosystem maturity for openness and customizability — no fees, no lock-in, and the ability to tailor the ISA to a specific use case. ARM trades that freedom for a mature, consistent, battle-tested ecosystem with guaranteed compatibility across licensees. That same trade-off is what makes porting firmware from ARM to RISC-V feel harder than a recompile: ARM's architectural rigidity is exactly what standardized the system-level programming model that RISC-V deliberately left open for vendors to differentiate on.
Sources
- Notes compiled from general architecture knowledge; verify current market share, licensing terms, and performance benchmarks against vendor/RISC-V International documentation before citing in formal analysis.
- CMSIS overview and NVIC/interrupt behavior — Arm CMSIS documentation (arm-software.github.io/CMSIS_6)
- RISC-V CLIC (Core-Local Interrupt Controller) spec — github.com/riscv/riscv-fast-interrupt
- RISC-V PLIC spec — github.com/riscv/riscv-plic-spec