At the semiconductor level, automotive poses huge challenges due to an experience mismatch. On one hand are the traditional automotive semiconductor companies, who have a deep experience in automotive reliability, but mostly in low-complexity devices manufactured in non-leading-edge processes with perhaps a decade of manufacturing data, and with a leisurely production schedule to match the old automotive design cycles.
On the other hand, there are consumer electronics companies and their suppliers that have a lot of experience in high-complexity devices, in leading-edge processes, with an aggressive consumer design cycle. But very little experience in reliability, at least at the automotive level.
The problem is that ADAS and autonomous driving requires both these to be combined. The needs of vision/radar/lidar cannot be met with the old automotive approach. But automotive reliability is not something that can be given up to achieve the performance. However, nobody has ever needed to deliver automotive reliability on leading-edge processes before.
This requires a multi-level approach.
At the lowest level, there needs to be specialized automotive processes that can deliver the required performance, qualified using the AEC-Q100 temperature range for the appropriate grade. TSMC decided to make 16FFC their automotive process node. High performance, consumer cost, and with already a couple of years of volume manufacturing experience.
At the highest level, there need to be functional safety approaches around the approach to SoC design and software, with ISO 26262 being the relevant functional safety standard. A process like 16FFC can deliver perhaps 500 FITS (failures in time, failures per billion hours of operation, about 115,000 part-years) but automotive requires maybe 10 FITS. This can only be achieved by detecting failures in the silicon, including transient failures due to SEE, and handling them in some safe way. The relevant safety levels are known as ASIL (automotive safety integrity level) B, C, D (level A exists but is not really applicable in this context).
To build an automotive SoC requires attention to all these things. The process has to be characterized for automotive. The architecture needs to address failures. But there are a lot of blocks on those chips, and many of them are standard components like microprocessors, memories, and interfaces. For these, IP is required. TSMC has created a program for this under the name of the TSMC 9000A ecosystem (the A is for automotive, of course).
For standards-based blocks, it makes no sense for every automotive chip manufacturer to develop these themselves. Although they are “standard”, that doesn’t make them easy to develop. Big design groups could make the investment if they chose, but why would they? There is no differentiation in a block where "meet the standard" is the spec. Smaller groups do not have the expertise to develop these high-performance designs. They barely know what an eye-diagram is.
Last week, Cadence announced a range of automotive IP, based on its existing portfolio of IP but extended to address the additional requirements of automotive. This wasn’t done in a vacuum. One key partner for this development is the leading automotive SoC manufacturer, Renasas.
Cadence announced it is delivering a comprehensive automotive portfolio for the 16FFC automotive process. This IP portfolio is targeted at a host of applications ranging from in-vehicle infotainment, in-cabin electronics, vision subsystems, digital noise reduction, and ADAS subsystems. These have been qualified at AEC-Q100 grade 2, since it is expensive to use grade 1 qualification for applications that only require grade 2 (such as in-cabin electronics).
The automotive IP portfolio includes:
In order to support cost-effective automotive SoC designs, Cadence IP is area- and power-optimized for the AEC-Q100 Grade 2 temperature range, eliminating the need to carry Grade 1 power and area penalties into cost-sensitive automotive SoC designs. Cadence IP is designed to be ASIL-B ready and ASIL-C/D capable based on end users’ safety goals and safety requirements as outlined in the ISO 26262 standard.
Sign up for Sunday Brunch, the weekly Breakfast Bytes email.