The car is being rebuilt around the computer
RISC-V automotive is a story of good timing. Just as carmakers tear up decades of electrical architecture and rebuild the vehicle around a handful of powerful computers, an open, scalable, safety-certifiable instruction set turns up ready to fill them. The demands are brutal, and RISC-V has quietly started meeting them.
From a hundred boxes to a handful
A modern car has spent years accumulating electronic control units, one for the engine, one for the brakes, one for each window and mirror and seat, until a premium vehicle carried well over a hundred of them, lashed together by kilometres of wiring. It worked, but it became unmanageable: heavy, expensive, and impossible to update coherently.
The industry’s answer is consolidation. Instead of one box per function, the new architecture uses a few zonal controllers, organised by physical location in the car, feeding into central compute units that do the heavy thinking. Fewer, far more capable chips, less wiring, and a platform you can actually update. That shift is exactly the kind of scalable, cost-sensitive, customisable compute problem RISC-V was built for, which is why it is arriving in cars at precisely this moment.
Clearing the highest safety bar there is
Nothing goes into a car’s safety systems without satisfying ISO 26262, which grades integrity on the ASIL scale from A to D. ASIL D, the top, covers the things that kill people when they fail: braking, steering, airbags. This was long the moat that kept newcomers out, and RISC-V has now crossed it. NSITEXE, a spin-off from Denso, certified the first ASIL-D-ready RISC-V processor with a vector extension back in 2021. SiFive’s automotive cores are ISO 26262 certified up to ASIL D in split-lock mode, and SiFive was the first supplier to achieve ISO/SAE 21434 cybersecurity product certification. Nuclei reports ASIL-D-compliant RISC-V CPUs winning real automotive designs.
The certified toolchains have followed, from IAR, TASKING and Green Hills, and that is the tell. Compiler and debugger certification is expensive and nobody invests in it ahead of real production volume, so its arrival is a leading indicator that RISC-V is going into cars for real, not just into slideware. This continues the same functional-safety story told for the factory in RISC-V in industrial IoT, now at automotive stakes.
The transparency argument, automotive edition: a car’s safety case must be defended to regulators and, eventually, to courts. With a closed core the architecture beneath that case sits behind a vendor NDA. With RISC-V it is published and freely readable, and a carmaker weighing a second source can assess it in familiar terms. For a platform that has to survive fifteen years and a supplier going wobbly, that openness is a safety and supply-chain feature at once.
One chip, many criticalities
Here is the part that is easy to get wrong. When you consolidate onto a central compute unit, you are running wildly different workloads on the same silicon, and they cannot be allowed to interfere. The crucial detail: the ASIL-D control loop does not run Linux. It runs a small, statically verified real-time operating system or a bare-metal safety kernel on a lockstep safety core, two cores executing in step and cross-checking each other, precisely because a general-purpose OS has failure modes that are near-impossible to bound to the standard’s satisfaction.
Meanwhile the perception, navigation and infotainment, the compute-hungry, best-effort work, run Linux and the newer AUTOSAR Adaptive stack on application cores. Keeping those worlds apart falls to a certified hypervisor and dedicated safety islands that supervise the main cluster independently. It is the same control-versus-inference split from RISC-V for robotics, enforced with the rigour a two-tonne vehicle demands.
The layers inside a zonal compute unit
| Layer | What runs there | RISC-V role |
|---|---|---|
| Safety island | ASIL-D control loops, supervision | Lockstep cores, verified RTOS |
| Real-time control | AUTOSAR Classic, actuation | Deterministic real-time cores |
| Application compute | Perception, AUTOSAR Adaptive, infotainment | Application cores plus vector / NPU |
| Security | Keys, V2X, secure boot | Certified crypto cores, root of trust |
Doing all four on one instruction set is the prize: a single toolchain, a single skill set, and hard separation enforced in hardware rather than bolted on.
Why carmakers are looking now
Beyond the safety credentials, the pull is strategic. A car platform lives for fifteen years and a model line longer, so being tied to a single vendor’s proprietary core is a risk no purchasing director enjoys. An open ISA with several qualified IP sources means a carmaker can second-source, negotiate, and outlast any one supplier’s stumbles. The security side matters just as much, because a connected car is an attack surface, and the auditable root of trust described in RISC-V security is exactly what a vehicle needs.
All of this is really the on-ramp to a bigger change: once the compute is centralised and updatable, the car becomes a device defined by its software rather than its wiring. That is the subject of the next post, RISC-V and software-defined vehicles, and it is the automotive expression of the whole thesis running through the RISC-V and IoT cornerstone.
Last updated 23 August 2026. Sources: ISO 26262 automotive functional safety (ASIL A to D) alongside ISO 21448 (SOTIF), ISO/SAE 21434 (cybersecurity) and UN R155/R156, per ISO and RISC-V International; NSITEXE achieved the first ISO 26262 ASIL-D-ready certification for a RISC-V processor with vector extension (DR1000C, 2021); SiFive Automotive cores certified to ISO 26262 (ASIL B, ASIL D in split-lock) and first to ISO/SAE 21434 product certification per SiFive; Nuclei reports ASIL-D-compliant RISC-V CPUs in automotive design wins; on a production automotive SoC the ASIL-D control loop runs a verified RTOS on a lockstep safety core rather than Linux, with hypervisor-certified separation for Linux and AUTOSAR coexistence, per industry analysis, 2026.
