Workload-Specific Silicon
As an industry open standard, the RISC-V ISA enables a unified hardware and software ecosystem in which automotive engineers can target every workload in the software-defined vehicle (SDV).
Unused Compute Is Just Curb Weight.
Standardization of parts is common across today’s multi-model, and often multi-vendor, vehicle platforms. Sharing powertrains across model ranges, for example, makes clear economic sense. But fitting an 800V, 100kWh battery pack into a city car does not. Silicon in the software-defined vehicle (SDV) should work the same way: a common instruction set scaling throughout, with each implementation right-sized to the workloads it actually runs.
Consider the alternative. A general-purpose “do-all” processor, bought off the shelf or integrated as proprietary “black-box” IP, will naturally offer a broader range of capabilities – but the workloads that chip is given may well touch only a fraction of those capabilities.
Underutilized silicon still carries a significant cost in power, silicon area, cooling, component price, and software complexity — none of which an OEM can design out once the architecture is fixed.
Multiply this across the potentially thousands of chips in a vehicle, and the hundreds of thousands of vehicles in a production program, and it’s easy to see why those costs can spiral out of even the most disciplined automaker’s economic control.
What is workload-specific silicon?
Workload-specific silicon is a chip deliberately scoped around a ‘workload’: the capability envelope needed to compute a defined set of tasks. It’s the alternative to a one-size-fits-all chip, which can attempt any workload but at far greater cost in power and silicon area. Chip designers balance that envelope’s breadth against cost, complexity, and headroom for adding future tasks.
Workload-specific compute enables automotive OEMs and Tier 1 suppliers to obtain:
- Higher performance and lower latency for the intended workload
- Lower power consumption and thermal demand
- Less silicon area and lower unit cost
- Simpler software integration and validation
- The flexibility to add new capabilities within a planned workload envelope
Use Case, Workload, Task: What’s the Difference?
| Use Case | Workload | Task |
|---|---|---|
| The vehicle function or outcome to deliver: it maps to no single chip, spanning multiple workloads, domains, and zones. | A software bundle that helps deliver a use case: each type carries its own compute character, which should shape its silicon profile. | One discrete unit of execution, such as a control-loop iteration or inference pass: the point where a tuned extension or accelerator earns its keep in power, performance, and area (PPA). |
| Deploy airbags | Crash sensing | Sample acceleration sensor |
| Filter sensor signal | ||
| Check reading for plausibility | ||
| Crash classification | Calculate impact direction | |
| Estimate impact severity | ||
| Restraint control | Select deployment strategy | |
| Trigger firing circuit |
What Does Future Readiness Actually Require?
Imagine that a year of test-fleet data reveals that a revised low-speed calibration can reduce stopping distance by 0.2%. This adjustment amounts to a handful of hex digits, delivered securely to thousands of vehicles overnight via an over the air (OTA) parameter update. No extra compute capability is required within the existing hardware.
Now imagine that eight years after launch, new environmental regulations force replacement brake pads to use a new low-particulate compound. Engineers discover that its friction coefficient changes sharply within a particular temperature range. Thermistors originally fitted only to trigger an overtemperature warning must now feed a real-time thermal model. The ABS controller now needs to perform physical AI-based sensor fusion across temperature, pressure, wheel speed and recent braking history to estimate friction at each wheel and continually adjust its target slip ratio.
Future readiness therefore means engineering for foreseeable evolution rather than buying a general-purpose chip or bloating your design in a bid to support every conceivable task. It means providing appropriate compute headroom, memory bandwidth, virtualisation support, hardware acceleration, and software-defined interfaces from the outset. An over-the-air (OTA) update cannot create a missing physical capability, but well-designed, workload-specific silicon can provide the foundations needed for software to make full use of its hardware over time.
RISC-V for Automotive
Subscribe today for the latest industry insights on the Software-Defined VehicleWorkload-Specific SiliconPervasive AISafety and SecuritySupply Chain ResilienceEconomic Control
Why RISC-V?
Why RISC-V?How RISC-V Enables Workload-Specific Silicon
As RISC-V is an open standard, RISC-V International does not productize the ISA in any way. Unlike proprietary ISA vendors, it does not design and license/provide processor cores. This role is left to IP vendors and chip designers, who create categories, roadmaps and licensing terms of their own making.
Anyone is free to design a chip that conforms to the RISC-V standard. This chip will have the distinct benefit of software portability; an operating system (OS) or app designed for one RISC-V processor should run cleanly on another RISC-V processor, even if these chips were designed by strangers on the other side of the world. This ability to source comparable implementations from multiple vendors sits at the heart of a more resilient supply chain.
Conversely, anyone is free to build a chip that does not conform to the RISC-V standard. Even if the ISA is followed in 9 out of 10 decisions and is independently verified to function as intended, it is not a RISC-V processor. An application processor built in this way will require its own custom software stack, with any applications or updates specifically recompiled to work on it. Adopting such a processor in an automotive setting would likely lead to consistent compatibility issues and a stack that sits outside the central collaboration benefits of the RISC-V ecosystem.
RISC-V International and its members actively mitigate this kind of fragmentation through a ratification process that involves widespread testing of standard extensions, which are then used as ingredients in profiles. To understand how RISC-V enables workload-specific silicon, we need to understand the importance of hardware extensions and profiles.
RISC-V Extensions
Architectural Extensions Enable the Creation of Workload-Specific, Hardware-Accelerated Processors
How do RISC-V architectural extensions enable workload-specific silicon?
RISC-V’s core ISA provides a minimal, standard instruction set, which designers augment with ratified standard extensions or with their own custom extensions. Because an extension is a modular ISA feature rather than a product, the same capability spans the whole range of vehicle compute, from the smallest microcontroller to the central high-performance computer, rather than being tied to one class of chip.
RISC-V is a modular, extensible instruction set architecture (ISA). The core ISA provides a minimal set of standard instructions; chip designers then choose from a defined set of standard hardware extensions, or develop their own custom extensions, in order to augment their chip design with additional capabilities and features.
This simple yet enormously powerful concept is what makes RISC-V uniquely placed to enable automakers to build workload-specific silicon that spans every specific use case within the SDV. And because an extension is a modular ISA feature rather than a product, the same extension scales across the full range of vehicle compute – from the smallest microcontroller to the central high-performance computer (HPC) – rather than being tied to any one class of chip.
Standard Extensions
Examples of standard extensions include:
| Extension | What it does | Why it matters for automotive |
|---|---|---|
| VectorV | Alongside matrix multiplication (for which ratification work is ongoing), an efficient way to perform data-level parallelism on-chip. Vector’s defining trait is that it is vector length agnostic (VLA): one binary runs unchanged across implementations with different hardware vector widths, without recompilation. | Serves radar and lidar signal processing, camera image pipelines, cryptography, and AI-driven sensor fusion. VLA enables a single codebase to run across every vector-enabled chip in the vehicle, whatever vector width each workload calls for. |
| HypervisorH | Adds hardware support for virtualization, enabling multiple guest operating systems to run on one core. A second stage of address translation and new virtualized privilege modes isolate guests with low overhead. | Underpins consolidating mixed-criticality workloads on a single chip. Technically enables a single chip to run a music streaming workload alongside safety-critical braking logic, with precise task scheduling to ensure that safety commands always get calculated before infotainment commands. |
| Scalar Cryptography | Delivers efficient hardware acceleration for the NIST algorithm suite and enables constant-time execution without the need for the Vector or Vector Cryptography Extension. While the base ISA supports cryptographic processing in software, this extension delivers far more efficient hardware acceleration for such workloads in microcontrollers and edge devices. | Accelerates secure boot, authenticated OTA updates, and in-vehicle communication in microcontrollers and edge devices built to support ISO/SAE 21434 and UN R155/R156 security compliance. |
Custom Extensions
Beyond the standard set, RISC-V also reserves dedicated opcode space for custom extensions, letting vendors add their own instructions to differentiate a design without breaking compatibility with the core ISA or the standard extensions. These sit outside the profiles and rely on the vendor’s own toolchain support, and they represent the most finely tuned form of workload-specific silicon: hardware shaped to a single function.
RISC-V Profiles
RISC-V Profiles Create a Common Hardware Baseline for Portable Software
What are RISC-V profiles, and why do they matter for automotive?
Profiles are standardized, versioned groupings of architectural features – a mandated base instruction set, memory model, supervisor architecture, and a defined set of extensions. They give hardware and software vendors a common target, so a binary compiled for one profile-conformant core runs on another without recompilation. RISC-V International currently supports two ratified application-class profiles: RVA23 and RVB23.
Today, RISC-V International has focused on delivering two profiles, both ratified in late 2024 and both targeting application processors rather than microcontrollers. However, it should be recognized that many chips in the SDV that might have been a traditional microcontroller a decade ago have since evolved into application processors; with an ISA as modular and extensible as RISC-V, the span of chips rarely fits into concise categories of MCU, apps processor, etc anymore. This is what allows one open standard ISA to deliver workload-specific silicon that spans the whole vehicle, scaling from the microcontroller to the central high-performance computer.
Profiles for Central AI, Connectivity and Mixed-Criticality Workloads
The two current ratified profiles for high-capability application-class processors are:
RVA23
The RVA23 profile defines the hardware baseline for a highly capable application-class 64-bit RISC-V processor, with a vector processing unit and hypervisor capabilities. A chip meeting the RVA23 profile is capable of running a Linux-class operating system such as Automotive Grade Linux (AGL) or Android within the digital cockpit, delivering conversational voice, personalization, and agentic in-cabin assistants.
RVA23 also mandates the hypervisor extension, which provides hardware support for virtualization, giving automakers the tools to consolidate mixed-criticality workloads on a single chip – for example, a safety-relevant instrument cluster sharing silicon with a non-critical infotainment stack.
RVB23
Built on the same application-class, 64-bit foundation as RVA23, RVB23 offers a capable baseline for a physically lighter-weight application processor. While it shares the same RV64I base instruction set, memory model, and supervisor architecture, it differs in how it treats non-base hardware extensions and instruction-set capabilities – with vector and hypervisor support among several extensions that are explicitly optional.
This makes it well suited to application-class processors for which trading guaranteed software binary portability between implementations or hypervisor-driven mixed criticality is deemed a worthy exchange for smaller, lower-power silicon capable of targeting workloads in gateways and communications systems.
However, the absence of a vector unit in no way precludes AI capability. An RVB23 chip might rely on scalar processing or offload AI inference to a dedicated accelerator such as an NPU. Yet a mandatory vector unit adds significant silicon to a chip design, and this only compounds at platform scale. For vendors that need application-class performance without explicit binary portability across devices, RVB23 offers a path to lower BOM, smaller silicon area, lower power, and less hardware to verify before tape-out.
Profiles for Powertrain, Zonal Control, Physical AI and Edge Workloads
RVM
The upcoming RVM profile is the first RISC-V profile targeting microcontrollers (MCUs) rather than application processors. Once ratified, it will anchor the lower end of the compute scale: the deterministic, real-time controllers that outnumber every other processor in the vehicle and, far from being designed out by centralization, are gaining intelligence as vehicles shift toward physical AI at the edge.
The profile’s value is its common software foundation. It mandates a shared set of standard extensions – integer multiply and divide, bit-manipulation, code-size reduction, and conditional operations among them – giving toolchains and library suppliers one stable target across an automaker’s hundreds of MCUs. Cryptographic and constant-time extensions stay optional but come from the same standard menu, so secure boot, authenticated OTA, and trusted communication under UN R155/R156 and ISO/SAE 21434 build on verified primitives.
Heterogeneous Compute
Workload-Specific Silicon Supports Heterogeneous Compute Through Domain-Specific Architecture (DSA)
The founding decision to enable anyone to build workload-specific silicon for the requirements of today, with the headroom to support the workloads of tomorrow, has become a driving force behind RISC-V’s adoption in automotive – where chips may remain on the road for a decade or more.
This need to match workload to silicon is often discussed in terms of ‘heterogeneous compute’, which describes a hardware architecture that mixes different types of processor within the same system to handle different workloads. However, heterogeneous compute stops short of each individual building block being tailored to its role: you could build a heterogeneous system out of entirely general-purpose, commercial-off-the-shelf (COTS) parts.
If heterogeneity was a significant step forward for modular compute, workload-specific silicon is a giant leap. It enables the processor itself to be uniquely designed and optimized for a particular use case. In 2026, automakers and vendors are using RISC-V to design their own processors that collectively scale across the vehicle and span every use case, from deterministic, functional-safety microcontrollers to high-performance central computers powering ambient AI in the digital cockpit.
Domain-Specific Architecture (DSA)
Workload-specific silicon also builds on the same principle as domain-specific architecture (DSA): the idea that a processor tailored to one or more specific workloads beats a general-purpose one at the same job, for less power and silicon area. DSA was first set out by two of computing’s most influential figures: David Patterson, UC Berkeley professor emeritus and a founding RISC-V mentor, and John L. Hennessy, Stanford president emeritus, computer scientist and (Google parent) Alphabet chairman. The pair championed DSA as two long-standing trends began to run out of road: Moore’s Law (steadily more transistors per chip) and Dennard scaling (more performance without more power). As both slowed, general-purpose processors could no longer deliver the gains they once had.
While RISC-V’s suitability for DSA (and therefore workload-specific silicon) is rooted in the ISA’s origins, we use “workload-specific” rather than “domain-specific” to avoid confusion with automotive domain controllers.
FAQ
Frequently Asked Questions about Workload-Specific Silicon
What is workload-specific silicon in RISC-V?
Workload-specific silicon is hardware shaped to the task it performs, rather than a one-size-fits-all processor asked to do everything. Each chip carries only the physical logic its job needs, spending its power and area budget where it counts. Across a software-defined vehicle’s many compute nodes, that precise fit compounds into real gains in performance, efficiency, and cost.
How does RISC-V enable workload-specific silicon?
RISC-V is a modular, extensible ISA: a minimal core instruction set that chip designers augment with ratified standard extensions or their own custom extensions. Because an extension is a modular ISA feature rather than a product, the same architecture spans the smallest microcontroller to the central high-performance computer, letting automakers tailor each processor to its workload while sharing one software foundation.
Does RISC-V suit domain, zonal or central compute architectures?
Domain and zonal are competing SDV topology approaches, while central compute connects to both. Domain organizes controllers by function; zonal by physical location. Many (though not all) OEMs are transitioning toward zonal architectures, with hybrid designs likely for years. RISC-V is topology-agnostic: workload-specific silicon is defined by the compute a controller performs, not where it sits or the vehicle function it serves.
Is workload-specific compute the same as domain-specific architecture (DSA)?
Workload-specific silicon and domain-specific architecture (DSA) are both ways to describe heterogeneous compute. DSA is a principle from David Patterson (who directed the Berkeley lab where RISC-V was created in 2010) in response to the slowing of Moore’s Law. We avoid using DSA because “domain” has a different meaning in automotive.
What is the difference between a RISC-V standard extension and a custom extension?
Standard extensions are ratified, widely tested ISA features — such as the vector or hypervisor extensions — that any conformant chip can implement and that software can rely on across vendors. Custom extensions use dedicated opcode space reserved in the ISA, letting a vendor add bespoke instructions for a specific workload without breaking compatibility with the core ISA or the standard extensions.
What is a RISC-V profile?
A profile is a standardized, versioned grouping of architectural features. It may mandate a base instruction set, memory model, supervisor architecture, and set of extensions. Profiles let hardware and software developers target a common baseline, so a binary compiled for one profile-conformant core runs on another without recompilation, encouraging shared toolchains across the ecosystem.
What is the difference between RVA23 and RVB23?
Both are ratified 64-bit, application-class profiles from late 2024. RVA23 mandates the vector and hypervisor extensions, suiting Linux-class cockpit workloads and mixed-criticality consolidation. RVB23 shares the same base but makes vector and hypervisor optional, trading guaranteed binary portability for smaller, lower-power silicon well suited to gateways and communications systems.
Does a RISC-V chip need a vector unit to run AI?
No, a chip can run AI inference on scalar processing or offload it to a dedicated accelerator such as an NPU. This is why a profile like RVB23 can still target AI-capable, application-class workloads, and a microcontroller can run AI workloads via standard CPU scalar processing (though a microcontroller can also include a vector unit – it doesn’t have to be defined in a profile).
What does 'Vector Length Agnostic' mean in RISC-V?
Vector length agnostic (VLA) means one binary runs unchanged across implementations with different hardware vector widths, from narrow embedded cores to wide designs, without recompilation. For automakers, a single codebase can serve every vector-enabled chip in the vehicle, whatever vector width each workload calls for, across radar and lidar processing, image pipelines, cryptography, and AI-driven sensor fusion.
Can a chip that only partly follows the standard still be called RISC-V?
No. If a design ignores part of the standard, it is not a RISC-V processor – even if it follows the ISA in most decisions and is independently verified to work. Such a chip needs its own custom software stack, with applications and updates recompiled specifically for it, and sits outside the collaboration benefits of the RISC-V ecosystem.
Does 'Workload-Specific' Infer Single-Criticality (or Uniform-Criticality)?
No. ‘Workload-specific’ describes scope, not uniformity: a chip’s capability envelope can encompass multiple workloads at different criticality levels. This is the basis of mixed-criticality chips, which run high-criticality and Quality Management (QM) workloads on the same silicon, using a hypervisor to keep them safely partitioned.
What's the difference between a use case, a workload and a task?
In a software-defined vehicle context, a use case is an overall vehicle function or operational scenario; a workload is an application, service, or coherent bundle of software functions that helps deliver it; and a task is a discrete unit of execution performed within a workload. Take the use case of deploying a vehicle’s airbags milliseconds after impact. Delivering it draws on several workloads: crash sensing, crash classification, occupant classification, and restraint control. Those workloads in turn run many individual tasks: sampling an accelerometer or gyroscope reading, checking it for plausibility, estimating impact direction and severity from the fused reading, reading an occupant’s seatbelt status, selecting the appropriate restraint strategy, and energizing one pyrotechnic restraint’s firing circuit once a crash is confirmed.
RISC-V Automotive Hub
RISC-V for Automotive
The open standard architecture for smarter and more scalable automotive compute.
Economic Control
Preserve cost competitiveness and roadmap ownership throughout decade-plus vehicle platform programs.
Supply Chain Resilience
Source equivalent implementations from multiple vendors across geographies, without depending on any one price list or roadmap.
Pervasive AI
Deploy intelligence throughout the vehicle, spanning voice assistants in the digital cockpit, ADAS and automated driving, and physical AI in microcontrollers.
Workload-Specific Silicon
Standardize on a single architecture for every workload, with a software stack spanning every purpose-built chip in the vehicle.
Safety and Security
Design certifiable silicon on open, transparent foundations to meet exacting functional safety and cybersecurity standards.