Author: Peter Bechberger, Director of Product Marketing, SoC, Renesas
How centralized computing, chiplets, and open toolchains enable sustainable architectures for software-defined vehicles
Software-defined vehicles (SDVs) are radically transforming the design, development, and evolution of automotive electronic systems throughout the vehicle lifecycle. Advanced driver assistance systems, AI-driven perception and decision-making, increasingly complex cockpit functions, and the expectation of continuous over-the-air updates are driving processing requirements far beyond what traditional, highly distributed ECU architectures can efficiently handle. At the same time, the semiconductor industry is experiencing diminishing returns with the classic scaling of process nodes. Each new node offers smaller improvements in performance and efficiency, while cost, design complexity, and qualification effort increase significantly. For original equipment manufacturers (OEMs) and Tier 1 suppliers, this creates a structural mismatch: software complexity and performance demands are rapidly increasing, while the traditional approach of relying on ever-larger monolithic SoCs in the latest process nodes is becoming economically and technically restrictive. As a result, vehicle electronics architectures are shifting towards centralized computing platforms combined with software-first development models. In this context, Renesas' R-Car Gen5 serves as a central computing platform for software-defined vehicles (SDVs), combining the integration advantages of a monolithic SoC with chiplet-based scalability and an open SDK and toolchain to address automotive system requirements.
Figure 1. Growth in demand for in-vehicle computing and scalable computing platform
Centralized computing as the architectural backbone of autonomous vehicles
Centralized computing is a key factor for autonomous vehicles, as it allows for the consolidation of multiple vehicle domains onto a shared hardware and software base. Instead of maintaining numerous dedicated electronic control units (ECUs) with isolated software stacks, a centralized computing platform can house the functions of advanced driver assistance systems (ADAS), the cockpit, the gateway, and the body within a single system, provided that mixed criticality requirements are properly managed. This consolidation reduces system complexity, wiring effort, and integration costs, while enabling a more consistent software architecture across the entire vehicle.
Figure 2. Transition to centralized E/E architectures
R-Car Gen5 is designed to function as a central computing platform. It combines high-performance application processors with security- and real-time-oriented cores, enabling workloads with vastly different timing, security, and availability requirements to coexist on a single platform. The architectural approach focuses not only on maximum computational performance but also on predictable behavior, long-term availability, and the ability to support software evolution for many years. For software development vehicles (SDVs), this is critical: software is no longer static at the point of sale but continues to evolve throughout the vehicle's lifecycle.
From a systems perspective, centralized computing also allows original equipment manufacturers (OEMs) to define a common hardware and software foundation for multiple vehicle lines. This reduces fragmentation and enables more effective reuse of software components, tools, and processes. The result is not only lower development costs but also higher quality and faster implementation of new features.
Chiplet-based scalability under the constraints of the automotive industry
While centralized computing simplifies the architecture, it doesn't eliminate the need to scale performance. ADAS and AI workloads, in particular, continue to grow rapidly, driven by more sensors, higher resolution, the rise of in-vehicle AI, and more sophisticated models. However, scaling performance by continually increasing the size and complexity of monolithic SoCs presents practical limitations. Lattice size constraints, performance degradation on large chips, and power density challenges make this approach increasingly less attractive, especially for automotive applications with stringent reliability and qualification requirements.
Chiplet architectures offer an alternative
By breaking down a system into multiple silicon chips within a single package, performance can be scaled more flexibly and cost-effectively. For automotive applications, the primary advantage isn't maximum modularity per se, but rather the ability to add computing power wherever needed without redesigning the entire SoC. The R-Car Gen5 embraces this philosophy by combining a powerful base SoC with the option to expand performance using additional chiplets, particularly for AI acceleration.
This approach allows original equipment manufacturers (OEMs) and Tier 1 suppliers to deploy a common hardware platform across different vehicle classes and trim levels, while differentiating performance through optional extensions. Entry-level vehicles can utilize the base configuration, while higher-end variants or later lifecycle upgrades can integrate additional computing resources. Importantly, this scalability is designed to meet automotive industry constraints, such as functional safety, long-term reliability, and predictable behavior. Rather than tightly coupling all chips via shared memory, the architecture prioritizes controlled communication and clear boundaries for fault containment.
Figure 3. Scalable SoC platform with chiplet computing extensions
Maintaining a unified software model
Hardware modularity only generates value if it doesn't fragment the software environment. For software development environments (SDVs), software reuse and portability are essential, as validation and certification efforts increase rapidly with system complexity. Therefore, a fundamental requirement is that hardware scalability—whether through additional cores or chiplets—doesn't necessitate fundamental changes to the software architecture.
R-Car Gen5 and its chiplet extensions are designed to present a unified logical system to the software. Standardized interfaces, virtualization, and abstraction layers ensure that the accelerators are accessed consistently, regardless of whether they are integrated into the base SoC or provided via a chiplet. From the operating system and application perspective, the additional computing resources appear as part of the same system, rather than as special-case devices.
This unified software model reduces integration effort and limits the need for variant-specific software branches. It also simplifies long-term maintenance, as software updates and new features can be developed and validated with a consistent platform abstraction, even as the underlying hardware evolves.
Open SDK and open toolset as a lever to accelerate time to market
As software content increases, development efficiency becomes a critical factor for competitiveness. Hardware capacity alone is insufficient if platform deployment and software integration take too long. Renesas addresses this problem with an open SDK and toolset, known as the R-Car Open Access (RoX) platform, using the Whitebox SDK as the base configuration.
The emphasis is on providing a coherent, production-oriented development environment, rather than a collection of disconnected tools. Linux and Android form the foundation of the high-level software, complemented by virtualization support and real-time operating system options where needed. Standard APIs and open interfaces are used to minimize vendor lock-in and facilitate portability across projects and hardware generations.
One particularly important aspect is the ability to initiate software development early. Virtual platforms and cloud-based development environments allow teams to begin integration, testing, and CI/CD workflows before the final hardware is available. This proactive development approach reduces the risk of late integration and shortens overall development timelines—an increasingly important advantage as vehicle programs multiply and the scope of software expands.
Figure 4. RoX Open SDV Platform
System-level implications for original equipment manufacturers (OEMs) and tier 1 suppliers
The combination of centralized computing, chiplet-based scalability, and an open toolchain has significant system-level implications. OEMs gain the ability to define stable computing and software platforms that span multiple vehicle generations, preserving software investments and reducing architectural changes. Tier 1 suppliers benefit from clearer integration goals and a shared development environment that reduces duplication of effort and accelerates collaboration.
From a lifecycle perspective, this approach allows for incremental performance scalability and feature growth without disruptive hardware changes at the end of the program. It also aligns well with over-the-air (OTA) feature deployments, where new functionality can be introduced years after the start of serial production (SOP), provided sufficient computing power or modular upgrade paths are available.
Conclusion
The transition to software-defined vehicles highlights the limitations of traditional automotive computing approaches. Centralized computing platforms are becoming essential, but they must be scalable, software-compatible, and suitable for extended lifecycles in the automotive industry. R-Car Gen5 combines a centralized computing architecture with chiplet-based scalability and an open SDK and toolset to meet these system-level requirements.
Instead of relying on increasingly large monolithic SoCs, the focus is on modularity, reusability, and development efficiency within the real-world constraints of the automotive industry. For original equipment manufacturers (OEMs) and Tier 1 suppliers, scalable computing and unified software platforms are no longer optional optimizations but fundamental building blocks for competitive SDV architectures.
