Infineon Adds RISC-V to AURIX: Why Three CPU Architectures?
At Hot Chips 2026, Infineon outlined how it plans to bring RISC-V into automotive computing, particularly as vehicle electrical/electronic (E/E) architectures transition from domain controllers toward zonal control units and centralized computing.
The important takeaway is that Infineon does not view RISC-V as a replacement for its existing processor architectures.
Instead, the company is building a three-architecture automotive portfolio spanning its established TriCore architecture, Arm-based products, and a new RISC-V line under the AURIX brand.
That strategy reflects a broader reality of automotive computing: the instruction set architecture is only one layer of the problem.
For RISC-V to become a mainstream automotive platform, vendors still need to solve functional safety, cybersecurity, virtualization, deterministic real-time execution, software tooling, standardized interfaces, long-term product support, and ecosystem compatibility.
In other words, the open ISA may be the starting point—but it is not the finished product.
🚗 01. From Domain Controllers to Zonal Computing #
Infineon describes automotive E/E architecture as moving through three broad stages.
Legacy Domain Controllers #
Traditional vehicles divide computing resources according to functional domains:
- Powertrain
- Body electronics
- Infotainment
- ADAS
- Chassis
Each domain typically has its own electronic control units (ECUs), communication paths, and software stack.
This model works, but it can result in large wiring harnesses, duplicated computing resources, and increasing system complexity.
Zonal Control Units #
The next stage is the zonal control unit (ZCU).
Instead of assigning an ECU to every individual function, a zonal controller aggregates local inputs and outputs, power distribution, communication, and real-time control for a physical region of the vehicle.
High-level intelligence can then move toward centralized computers while the ZCU handles local, latency-sensitive workloads.
This can reduce wiring complexity and allow multiple functions to share local computing resources.
Central Vehicle Computer #
At the top of the hierarchy sits a central vehicle computer responsible for increasingly sophisticated workloads such as:
- ADAS
- Infotainment
- Vehicle dynamics
- Global vehicle policies
- High-level data processing
The resulting architecture separates global intelligence from local control.
That division fundamentally changes what an automotive MCU must handle.
⚙️ 02. Why Zonal Controllers Need Heterogeneous Computing #
A zonal controller cannot necessarily be treated as a conventional MCU with more processing power.
Its workload can span dramatically different timing and performance requirements.
Extreme Workload Heterogeneity #
A single zonal device may need to combine:
- Deterministic real-time control
- DSP workloads
- AI inference
- Audio processing
- Low-power service functions
- Local I/O management
- Communication processing
These requirements can coexist within the same physical controller.
An entry-level body zone might need relatively modest computing resources, while a more sophisticated zonal controller could simultaneously manage power electronics, communications, local vehicle functions, and latency-sensitive control loops.
Timing Requirements Vary by Orders of Magnitude #
The timing requirements can be equally diverse.
A motor-control loop may require a deadline below 10 ms, with interrupt latency measured in tens of nanoseconds.
Other strategic vehicle-management workloads can tolerate response times on the order of seconds and interrupt latencies around milliseconds.
Trying to optimize one homogeneous processor architecture for every workload can therefore create unnecessary compromises.
This is one reason heterogeneous and multi-architecture approaches are becoming increasingly relevant to software-defined vehicles.
🧠 03. The Zonal Controller Becomes a “Super-Integration” Point #
Infineon considers two broad approaches to zonal controllers.
Optimized Multi-Domain Zonal Controller #
The first approach consolidates edge ECUs into a more capable controller that can:
- Aggregate local I/O
- Manage power distribution
- Execute latency-sensitive control loops
- Host multiple localized vehicle functions
This turns the ZCU into an intelligent edge-computing node rather than simply a network gateway.
Low-Complexity I/O Aggregator #
The alternative is a relatively simple controller that primarily passes information between local devices and the central computer.
This minimizes local processing requirements but places more responsibility on centralized computing.
Infineon’s architectural direction favors the optimized multi-domain zonal controller.
The reasoning is straightforward: functions that require deterministic local response can remain close to the hardware, while global policy and more computationally intensive decisions move to the central vehicle computer.
This division can also reduce unnecessary communication, simplify maintenance, and potentially reduce the vehicle’s overall attack surface.
Adding an MPU Island #
For higher-end “super-integration” designs, Infineon proposes combining traditional real-time MCU resources with an MPU island.
The MPU can run a POSIX-compatible software environment, including an adaptive automotive software stack such as Adaptive AUTOSAR.
This allows non-real-time workloads to execute separately while dedicated real-time cores remain focused on deterministic control.
The result is a hybrid architecture positioned between a conventional MCU and a full application processor.
One major advantage is responsiveness: an automotive MCU-oriented design can preserve fast boot and wake-up characteristics while gaining additional application-processing capability.
🔓 04. What RISC-V Actually Brings to Automotive #
The main attraction of RISC-V is its open and extensible instruction set architecture.
Unlike proprietary ISAs, the RISC-V specification allows vendors to build processor implementations without depending on a single ISA owner for the basic instruction-set definition.
For automotive semiconductor companies, this can create opportunities for:
- Custom instruction extensions
- Reusable processor IP
- Domain-specific accelerators
- Greater architectural control
- Cross-market IP reuse
- Reduced dependence on proprietary ISA licensing
However, the ISA itself does not determine how an automotive processor behaves.
Two RISC-V processors can implement the same base ISA while having dramatically different:
- Pipeline structures
- Instruction latencies
- Cache architectures
- Memory systems
- Interconnects
- Coherency mechanisms
- Lockstep implementations
- Security features
- Safety mechanisms
This distinction is critical in automotive applications.
RISC-V provides the architectural foundation. The silicon vendor still has to engineer the complete processor and SoC around it.
🧩 05. Standardization Matters More Than the ISA Alone #
One of the most important pieces of Infineon’s presentation is the emphasis on standardization.
A RISC-V automotive ecosystem needs more than a common instruction set.
The broader stack includes standardized processor profiles, software interfaces, debugging infrastructure, safety mechanisms, virtualization, and application-specific extensions.
A simplified view of the RISC-V automotive profile framework is:
RVI AUTO-SIG Standardized Profile Framework
├── Base Specification: RV32E / RV32I
├── Core Extensions: M (Multiply), U (User Mode)
└── Optional Capabilities:
├── Supervisor Mode
├── Floating Point: F / D
├── Vector: V
└── Hardware Virtualization: H
The optional features become increasingly important as automotive controllers evolve beyond simple single-purpose MCU workloads.
Hardware Virtualization #
Hardware virtualization is particularly significant for zonal architectures.
A capable RISC-V processor could potentially host multiple isolated software environments on the same physical silicon.
That enables different software domains to coexist while maintaining stronger separation between workloads with different safety, security, or timing requirements.
For software-defined vehicles, this type of isolation can become increasingly important as a single controller takes responsibility for functions that previously lived on separate ECUs.
The challenge is that virtualization must integrate cleanly with automotive safety and security requirements. Simply adding a hypervisor-capable CPU does not automatically produce an automotive-grade mixed-criticality platform.
🏎️ 06. Why Infineon Is Keeping Three Architectures #
In March 2025, Infineon announced a new RISC-V automotive microcontroller line under the AURIX brand.
Rather than replacing its existing products, the RISC-V line expands the company’s processor portfolio.
Infineon is therefore maintaining three distinct architectures across its automotive products.
| Architecture | Product Families | Primary Strength | Typical Applications |
|---|---|---|---|
| TriCore | AURIX TC3x / TC4x | Proven deterministic real-time processing, functional safety, and large automotive software base | Powertrain, chassis, safety, high-end zonal control |
| Arm | TRAVEO, PSoC | Broad software ecosystem and developer familiarity | Body electronics, clusters, infotainment, general automotive MCUs |
| RISC-V | Upcoming AURIX RISC-V line | Open ISA, extensibility, custom IP, virtualization potential | Next-generation ZCUs, custom accelerators, SDV nodes |
The strategy may appear redundant from a pure processor-architecture perspective.
From an automotive product perspective, however, the three architectures address different constraints.
TriCore: Legacy and Deterministic Control #
TriCore remains valuable because automotive manufacturers have accumulated years of software, development tools, safety certification, and engineering expertise around it.
Replacing that ecosystem simply because another ISA is newer would impose substantial migration costs.
Arm: Broad Ecosystem Compatibility #
Arm provides access to a massive global software and developer ecosystem.
For applications where compatibility, existing software, and third-party development resources matter more than architectural customization, Arm remains a practical option.
RISC-V: Architectural Flexibility #
RISC-V provides Infineon with another option for future products where customization, extensibility, and tighter control over processor IP are strategically valuable.
This makes the three architectures complementary rather than directly interchangeable.
🛡️ 07. What Must Be Solved Before Automotive RISC-V Goes Mass Market? #
The hardest problems are not necessarily inside the instruction decoder.
Automotive deployment requires a complete hardware-software ecosystem capable of surviving extremely long product cycles and stringent safety requirements.
Functional Safety #
Automotive processors need to support standards such as ISO 26262.
That means implementations may require:
- Hardware lockstep
- Error detection and correction
- Fault tracing
- Safety monitoring
- Diagnostic mechanisms
- ASIL-D-capable architectures where required
These capabilities must be validated as part of the complete silicon platform.
Cybersecurity #
Modern vehicles are networked computers, making security another fundamental requirement.
Automotive RISC-V platforms need technologies such as:
- Hardware security modules
- Secure boot
- Trusted execution mechanisms
- Key management
- Secure enclaves or equivalent isolation
- Hardware-assisted cryptography
These functions must integrate with the vehicle’s broader security architecture and ISO/SAE 21434 processes.
Software Isolation #
As ZCUs consolidate more functions, isolation becomes increasingly important.
A single controller may host workloads with different levels of safety and security criticality.
Memory protection, virtualization, hypervisors, interrupt isolation, and deterministic resource allocation therefore become essential building blocks.
Automotive Toolchains #
Perhaps the most underestimated requirement is the development environment.
Automotive customers need mature:
- Compilers
- Debuggers
- Static-analysis tools
- Safety-qualified toolchains
- AUTOSAR MCAL implementations
- Operating-system support
- Debug and trace infrastructure
- Long-term software maintenance
A technically excellent RISC-V core is of limited value if developers cannot build, debug, certify, and maintain production software around it.
🔬 08. The Real Competition Is at the System Level #
RISC-V’s open ISA attracts attention because it changes the relationship between processor architecture and semiconductor vendors.
But openness alone does not determine commercial success.
The more meaningful competition will happen at the system level.
That includes:
Microarchitecture:
How efficiently does the implementation execute real automotive workloads?
Memory and interconnect:
Can the processor provide predictable bandwidth and latency across multiple domains?
Accelerators:
Can vendors integrate custom hardware for DSP, AI, security, networking, and other specialized workloads?
Safety architecture:
Can the platform provide the required fault detection, isolation, and certification evidence?
Security architecture:
Can multiple software domains operate without compromising one another?
Software ecosystem:
Can automakers migrate existing applications and development processes without unacceptable cost?
Product longevity:
Can suppliers support automotive products over the long lifetimes expected by vehicle manufacturers?
This is why automotive RISC-V should not be viewed simply as an Arm-versus-RISC-V ISA contest.
It is more accurately a competition between complete computing platforms.
🔮 09. Why Three Architectures May Coexist for Years #
The automotive industry has an unusually strong reason to avoid rapid architectural consolidation: software and vehicle platforms have extremely long lifecycles.
A new processor architecture must coexist with existing software, tooling, safety certifications, engineering expertise, and production infrastructure.
That makes a three-architecture strategy practical.
Legacy workloads can remain on TriCore.
Applications benefiting from the broader Arm ecosystem can continue using Arm.
New zonal and software-defined vehicle designs can selectively adopt RISC-V where its flexibility provides a compelling advantage.
This approach also gives automakers more choice in balancing performance, software reuse, customization, safety requirements, and supply-chain considerations.
The result is unlikely to be a single architecture replacing everything else overnight.
Instead, automotive computing is moving toward heterogeneous platforms in which different processor architectures coexist at different points in the vehicle.
🚀 The Bigger Picture: RISC-V Is the Beginning, Not the Destination #
Infineon’s Hot Chips 2026 presentation highlights a broader shift in automotive semiconductor design.
The transition from domain controllers to zonal architectures is forcing automotive processors to handle a much wider range of workloads. Real-time control, networking, AI, audio, security, and application software increasingly need to coexist within the same vehicle computing hierarchy.
RISC-V offers an attractive architectural foundation because it is open and extensible.
But the instruction set is only the first layer.
The long-term success of automotive RISC-V will depend on standardized interfaces, safety certification, virtualization, security architecture, qualified toolchains, AUTOSAR support, reliable silicon, and a mature software ecosystem.
That is also why Infineon is not abandoning TriCore or Arm.
The future of automotive computing may not be about finding one universal ISA. It may instead be about selecting the right architecture for each layer of an increasingly heterogeneous vehicle platform.
In that environment, TriCore, Arm, and RISC-V can coexist—not because the industry has failed to choose a winner, but because modern vehicles increasingly need different types of computing in different places.