Automotive Chip Design for ADAS and Autonomous Driving
Designing chips for cars is a different animal than designing for phones or data centers. I've watched colleagues move from consumer SoC design to automotive, and they're always surprised by how much the constraints change. You're not just hitting a performance target — you're proving to an OEM and a regulatory body that your silicon won't kill anyone. That changes everything from the RTL architecture to the verification methodology to how you test finished parts.
The Functional Safety Imperative
ISO 26262 is the standard that governs functional safety for automotive electronics, and it classifies systems by ASIL (Automotive Safety Integrity Level), from A (lowest) to D (highest). Braking, steering, and airbag control require ASIL-D. ADAS functions like automatic emergency braking (AEB) typically need ASIL-B or ASIL-C, depending on the OEM's safety architecture.
What does ASIL-D mean for chip design? In practical terms:
- Single-point fault metrics need to exceed 99% — meaning 99% of dangerous random hardware failures must be either prevented or detected
- Latent fault metrics must exceed 90% — faults that sit dormant and could combine with another fault to cause harm
- Diagnostic coverage must be extremely high, often requiring dual-core lockstep (DCLS) processors where two identical cores run the same instructions simultaneously and a comparator flags any disagreement
Infineon's AURIX TC4xx family is probably the most widely deployed ASIL-D microcontroller in production today. It uses triple-core lockstep with a checker core, ECC on all memories, and end-to-end data protection. NXP's S32 platform takes a similar approach. These are real-time control processors, not the big application processors that handle perception — but they illustrate the safety overhead that automotive demands.
The Compute Architecture for Autonomous Driving
For perception and planning in L2+ through L4 autonomous systems, you need serious compute. The workload is a mix of:
- Camera processing — typically 8 to 12 cameras at 2-8 megapixels each, running object detection CNNs at 30 fps
- Lidar point cloud processing — millions of points per second, requiring sparse 3D convolutions or transformer-based models
- Radar signal processing — including 4D imaging radar with angle, range, velocity, and elevation
- Sensor fusion — combining outputs from different sensor modalities into a unified world model
- Path planning and control — running prediction models and trajectory optimization in real time
NVIDIA's DRIVE Orin, shipping since 2022, delivers 254 TOPS with a power envelope around 45-60W. It combines Arm Cortex-A78AE CPU cores (the AE suffix means "Automotive Enhanced" with lockstep and split-lock modes), an Ampere-based GPU, and dedicated deep learning accelerators. Orin is ASIL-D capable for the CPU subsystem and ASIL-B for the GPU subsystem when used with the right software architecture.
For a related perspective, see ARM Architecture Evolution: From ARMv8 to ARMv9 and Custom C.
NVIDIA's next-generation DRIVE Thor, expected in vehicles starting around 2025-2026, promises up to 2,000 TOPS by combining a Blackwell-derived GPU with a Grace-derived CPU. That's a massive jump, and honestly, I'm skeptical we'll see the full 2,000 TOPS deployed in a single chip for autonomous driving — power and thermal constraints in a car are real. But having headroom means you can run larger, more accurate perception models.
Mobileye's Different Approach
Mobileye (an Intel subsidiary) takes a notably different architectural approach with their EyeQ chips. Rather than using a general-purpose GPU as the primary compute engine, they've built custom accelerator cores optimized specifically for vision processing. The EyeQ Ultra, announced for production around 2025-2026, targets 176 TOPS while consuming significantly less power than GPU-centric solutions.
Mobileye also designs their own ISP (image signal processor) blocks tailored for automotive cameras, and they have proprietary algorithms for their Road Experience Management (REM) mapping system. Their advantage is vertical integration — they control the full stack from silicon to perception software to HD maps. The disadvantage, from an OEM perspective, is that it's harder to bring your own algorithms when the hardware is optimized for Mobileye's software.
Qualcomm, Texas Instruments, and the Rest
Qualcomm entered the automotive compute market aggressively with the Snapdragon Ride platform. Their SA8650P targets digital cockpit and ADAS convergence, running infotainment and driver assistance on the same SoC. Qualcomm brings strong expertise in AI inference from mobile (their Hexagon DSP heritage) and good power efficiency, but they're still building automotive credibility and functional safety track records.
TI doesn't compete at the high end of autonomous driving compute, but their TDA4VM and newer TDA4VEN processors own a significant chunk of the ADAS market in the 8-32 TOPS range. For L2 systems — lane keeping, adaptive cruise control, parking assist — TI's parts are well-regarded for their reliability, long product life guarantees, and strong support for functional safety. In my experience, TI's tools and reference designs for automotive are among the best in the industry.
We covered a related topic in Yield Engineering: Why Chip Manufacturing Yield Matters More.
Automotive Qualification: AEC-Q100 and Beyond
Beyond functional safety, automotive chips must pass AEC-Q100 qualification testing, which defines stress tests for different temperature grades:
- Grade 3: 0 to 85 C (cabin electronics)
- Grade 2: -40 to 105 C (under-hood, general)
- Grade 1: -40 to 125 C (under-hood, near engine)
- Grade 0: -40 to 150 C (very close to engine, exhaust)
Most ADAS SoCs target Grade 2 or Grade 1. The qualification involves high-temperature operating life tests (HTOL), thermal cycling, moisture sensitivity, and electromigration testing — hundreds of parts tested for thousands of hours. The whole process takes 6-12 months and adds real cost to development.
Parts also need to guarantee a supply lifetime of 10-15 years minimum, which is wildly different from the consumer electronics world where a smartphone chip might be in production for 18 months. Automotive foundry agreements with TSMC, Samsung, or GlobalFoundries include long-term supply commitments that consumer designs rarely need.
The Memory and I/O Challenge
Autonomous driving generates enormous data flows. A single 8MP camera at 30 fps produces about 230 MB/s of raw Bayer data. Multiply that by 8-12 cameras, add lidar and radar, and you're looking at 3-5 GB/s of raw sensor input. Processing these streams through neural networks requires substantial memory bandwidth — Orin uses LPDDR5 at up to 205 GB/s, while Thor is expected to use LPDDR5X with higher bandwidth.
The I/O interfaces matter too. Automotive Ethernet (100BASE-T1, 1000BASE-T1, and now 10GBASE-T1 per IEEE 802.3ch) is replacing legacy CAN and LIN buses for high-bandwidth sensor connections. MIPI CSI-2 with C-PHY or D-PHY carries camera data. PCIe Gen4 or Gen5 connects to additional accelerators or storage. Integrating all of these interfaces on a single SoC while meeting automotive EMI and ESD requirements is a serious design challenge.
Related reading: Semiconductor Metrology: How Chip Features Are Measured at t.
What I'd Watch Going Forward
The automotive chip market is consolidating around a few major architectures, but there's still room for disruption. Here's what I think matters most in the next few years:
First, the centralized compute trend is real. Cars are moving from dozens of distributed ECUs to a handful of high-performance domain controllers or even a single central computer. This favors companies that can build large, complex SoCs — think NVIDIA, Qualcomm, and potentially AMD (who acquired Xilinx with its automotive FPGA business).
Second, chiplet architectures are coming to automotive. Today's monolithic SoCs will eventually give way to multi-die designs that can mix compute, AI accelerators, and I/O in flexible configurations. But automotive qualification of chiplet interfaces (like UCIe) is still early.
Third, the software-defined vehicle concept means the SoC needs to support over-the-air updates and potentially new neural network models deployed years after the car ships. Hardware needs enough margin and flexibility to run models that don't exist yet when the chip is designed. That's a fundamentally different design philosophy than optimizing for a fixed set of workloads.
Automotive chip design isn't glamorous. The timelines are long, the qualification burden is heavy, and the margins can be thin compared to data center parts. But it's one of the fastest-growing segments in the semiconductor industry, and the technical challenges are genuinely interesting.