Changing standards, stringent requirements and a mix of expertise make this a tough market to crack.
The introduction of advanced electronics into automotive design is causing massive disruption in a supply chain that, until very recently, hummed along like a finely tuned sports car.
The rapid push toward autonomous driving has changed everything. This year, Level 3 autonomy will begin hitting the streets, and behind the scenes, work is underway to design SoCs for Level 4. But how these chips get built, by whom, and using what IP isn’t always so obvious.
In the past, the automotive supply chain was simple to explain. OEMs purchased systems and modules from Tier 1 suppliers. From there, Tier 1 suppliers procured semiconductors from chip companies. And for decades, very little changed.
“Everyone in the food chain knew exactly what the design requirements were and the limitations of the available technology,” said Tom Wong, director of marketing, design IP at Cadence. “Automotive quality and reliability are well-known amongst the incumbents. Nowadays, it’s a different situation due to the rapid change in requirements to support applications like in-vehicle-infotainment, wireless connectivity, various forms of ADAS and ML/AI SoCs that provide the computational needs of image processing, object detection and recognition, sensor fusion, etc. We are witnessing OEMs building out SoC design teams, or outsourcing to ASIC design services, or procuring semiconductor IP directly from IP vendors including CPUs, GPUs and DSP cores as well as security solutions.”
Along with those changes, new players have emerged. And all of them are struggling to gain their footing in a century-old industry that is undergoing some radical changes.
“There’s everything from startups to century-old OEMs thinking about doing their own IP and/or their own SoCs to go with that,” said David Fritz, senior autonomous vehicle SoC leader at Mentor, a Siemens Business. “We see the whole gamut. We see companies that are extremely naive about the complexity, all the way to OEMs who are still thinking that the technology as it was last time they tried this back in 1982.”
Add to that a wide range of approaches to technology, and a spectrum of sophistication. Some startups come from the chip world and are using Agile methodologies to develop IP and UVM to verify it. Others are struggling to add electronics expertise, but have a deep understanding of automotive manufacturing.
For the traditional automotive supply chain, decomposing vehicles into little problems that are easy to solve used to be standard operating procedure. But that approach is rapidly running out of gas. “When you take an automobile and decompose it down in the brake controllers and engine controllers, and that sort of thing—that methodology works,” Fritz said. “But when you start throwing in ADAS functionality, autonomous vehicle functionality, AI inferencing after machine learning, that whole paradigm breaks down.”
OEMs have made significant strides to build their own internal system development teams, but significant roadblocks still exist. And on the tech industry side, the situation is equally challenging.
“The OEMs have to take a cleanroom approach because they can’t have the new team that they’re building interface with the people who are working with their suppliers, or they may get sued down the road for IP contamination,” he said, noting that tech companies have their own issues to resolve. “The problem with Silicon Valley is this whole concept of ‘minimum viable product’ works when nobody’s life is at stake. It doesn’t work so much when it’s mission-critical. People can die, and we’re seeing that in Tesla. We’re seeing situations like Uber just barely getting off by a technicality when the company was sued over a wrongful death in an AV in Arizona. This is because they’re saying, ‘Let’s just put it out there.’ This bears resemblance to the Microsoft paradigm that says, ‘We can’t test it all. It’s too complex. Let’s throw it out there and let our customers test it.’ But here we’re talking about the thing that kills more people than guns.”
Other variables
There are other dynamics at play here, such as the readiness of 7nm technology. Carmakers want to design automotive SoCs using the most advanced foundry processes for AI, in-vehicle-infotainment, in-vehicle networking. This is partly due to the performance and power benefits of these advanced finFET devices, and partly due to the long design cycle. So rather than using a 28nm chip that will be outdated in five years, many of these designs are starting at the bleeding edge.
It’s not clear how those chips will fare under harsh road conditions. It’s also not clear how any of these designs will be affected by the upcoming 2nd Edition of ISO 26262 Functional Safety Standards, which includes Part 11 to specifically address the needs for semiconductors and IP.
The challenge, according to Wong, is achieving quality, reliability and functional safety, which are the three pillars of automotive design.
Subject to change
That’s just the starting point, too. Automotive requirements are constantly changing as more electronics are added into vehicles. For example, ML/AI chips likely will interface with GDDR6 memories as opposed to LPDDR4. Camera interfaces likely will stay at MIPI DPHY v1.2 for some time, but will likely migrate to newer MIPI A-PHY standards by 2021/2022. And sensor fusion likely will drive on-vehicle networking speed to above 1Gbps, so even Gigabit Ethernet performance may not be enough. Some designs are using 40Gbps speeds to support the bandwidth requirements needed for L3/L4 systems.
Also, L4/L5 SoCs for automotive likely will migrate to 7nm, while less complicated ADAS subsystems will remain in 16nm for awhile. Infotainment applications will require a migration from 28nm to 16nm, especially when the applications will move to full 4K display.
With the automotive semiconductor landscape going through rapid changes due to the disruptions taking place in the automotive industry, Wong expects traditional applications such as engine control unit (ECU), power electronics, ABS and active suspension to stay at more mature semiconductor process nodes. However, newer applications such as vision subsystems (e-mirror, forward camera, blind spot detection, automated parking, etc.), sensor fusion and other autonomous driving chips will require more advanced processes. Chips for autonomous driving (ML/AI) will require the most advanced and bleeding-edge process nodes, and designers will gravitate to the next finer geometry as soon as it becomes available.
This means that IP designed in 16nm will have to migrated to 7nm a lot sooner than in the past, and deployment of newer IP protocols will also be a lot quicker than in the past.
“All new high-performance ML/AI SoCs will have GDDR6 memory interfaces or HBM2 interfaces,” Wong said. “LPDDR4 will be replaced by LPDDR4x, and soon after that with LPDDR5. On top of that, automotive SoCs will remain in production for many years, and IP vendors will be expected to archive design bases for 10+ years and keep good documentation for that period of time to maintain design traceability. This is very different than designing IP for consumer applications. Your smartphone may last two to four years, but your car is expected to last at least 10 years. It may no longer be your car, but it will be someone else’s car. Currently, the average age of an automobile in the U.S. is 11.6 years.”
IP issues
Choosing IP adds its own set of problems. There are companies like Baidu developing their own chips, traditional semiconductor vendors, as well as Tier 1 companies such as Bosch.
“One of the things that all of these guys deal with is having evidence that the specifications are being followed, both from a process standpoint of how the IP is designed,” said Kurt Shuler, vice president of marketing at Arteris IP. “And then, does the IP meet the technical safety requirements that are being claimed?”
This requires the IP customer to look closely at their different IP providers. “If I’m licensing some IP, I want to understand in pre-sales what do you have, how did you build it,” said Shuler. “What evidence and work products do you have to prove any claims that you make? Things may go quiet for a while until the design team gets closer to the end of the chip design project and starts doing the work where they have to calculate the diagnostic coverage and FMEDA, maybe some fault injection to validate, some of the assumptions they make in the FMEDA, among other activities.”
It is imperative for the IP consumer to make sure the right people are having those early conversations.
“If our customer or prospect has somebody who doesn’t understand functional safety or the specification, and is just going blindly through a checklist, it slows things down,” Shuler said. “So the right subject matter experts must be there.”
Also needed is a willingness to share information about diagnostic coverage during verification and schedules. IP integrators, meanwhile, need to understand the assumptions for using IP, because unless it’s custom that IP is considered a safety element out of context (SEooC).
“Whether it’s Arm or Imagination or Synopsys or Cadence or Arteris IP, when we deliver some IP that has functional safety claims, we have assumptions of use for the customer,” Shuler said. “For example, with a piece of soft IP — like a network on chip (NoC) — it generates RTL with an assumption of use that says, ‘You’re going to calculate your own FIT rate.’ It sounds obvious, but we don’t know what semiconductor you’re going to use.”
That kind of detail is essential. Automotive OEMs want to see specifics about what they are buying for their systems.
“This goes through the whole food chain and it’s all controlled through ISO 26262, in which they’ve already established all the rules and the documentation,” said John Swanson, Ethernet product line manager for Synopsys IP. “The first automotive chips I worked on, nobody even asked about this stuff. They had to certify the chip, but they didn’t have to certify the IP. That’s obviously changed. You put more and more IP on the chip and it makes sense.”
Hard vs. soft IP
The OEMs only go so far, though. They don’t distinguish between hard and soft IP, for example.
“That’s the semiconductor company’s problem,” Swanson said. “They give requirements to the Bosches and the Densos and companies like that, and some of them are very involved in driving standards. Take Continental, for example. They’ve been pushing the high speed networking, so I don’t think [the OEMs] care. It’s a question for the semiconductor provider of whether they can certify all the different pieces.”
Nevertheless, there are different requirements for hard IP and soft IP. “I would argue hard IP is easier because it’s not configurable, but it’s still a lot of work to make an ASIL-D-ready PHY, for example,” Swanson said.
This is a significant issue for the IP provider, Shuler noted, because if you’re providing hard IP, “you have the option to provide more information. For example, FIT rates. This is impossible to do with soft IP. You can provide all the ingredients required, and if you’re delivering a hard IP, you also can provide assumptions of use for how this particular block is going to be placed. For instance, if I have a rectangular block and it’s a hard macro and somebody is going to duplicate it, I can put in the assumptions of use such that if you do duplication, you’re going to have the skinny end running east-west for one of them, and the skinny end for the other one running north-south. All those things go into assumptions of use.”
The SEooC approach grew out of the use of soft IP, Swanson said. “Bosch or Denso, or whoever would invent some sort of basic infotainment system with software features, wanted to put that in as many different cars as possible so they could certify it in a system as a SEooC such that, ‘We know it’s basically going to go in and do this, but we don’t know details, and you as the manufacturer have to certify the details.’ That’s still true of IP. We certify the IP, and the semiconductor companies have to certify the chips. The Tier 1s have to certify the systems, and the OEMs have to certify the cars, and ISO 26262 documents the whole process. So if something does go wrong, you can go back and trace it, find out where it went wrong, and fix it.”
Related to this is the interaction of different pieces of IP integrated into an automotive SoC. According to ISO 26262, the individual pieces would be certified, and when integrated into a subsystem, that subsystem would need to be certified, as well.
Fortunately, the description for exactly how to do this is covered in the second edition of ISO 26262. “Realizing that you are going to have IP from a whole bunch of different vendors, and it’s not just your own created IP, from a micro level, there’s guidance for the individual IP vendors,” Shuler said. “At the macro level, that integrator is responsible for looking at things from the system level. They need to make sure that each IP is implemented according to the assumptions of use, because we’re not going to know what the system level is and the functionality that they’re trying to go after. One of the things that is important, coming from a technical standpoint, is that IP at the RTL level connects through transactional interfaces.”
More complexity
All of this adds cost and complexity. “They have to match the stringent specifications from the OEM, which sits on top of the tiered structure of suppliers, in addition to meeting the different functional safety aspects and the reliability standards,” said Ranjit Adhikary, vice president of marketing at ClioSoft. “Companies targeting the automotive industry have to be prepared to invest 30% to 40% more R&D cost toward creating the SoCs and IPs.”
On top of that, auto IP developers need to meet standards that will help in shortening the SoC design cycles, and ensure that it works in subsystems, and software the OEM is bringing in. That includes considerations such as latency, power dissipation, area, high reliability and continuous operation, along with process-related design challenges for advanced nodes, Adhikary said. “The IPs developed specifically for the automotive industry also need to be able to withstand the extreme conditions such as higher voltages, higher temperatures, higher electrostatic discharge, and higher test coverage targets.”
Keith Witek, senior vice president of corporate development & strategy at SiFive, said that IP blocs and SoCs need to be tested an analyzed at each design step and phase, including architecture, RTL, netlist, physical design, validation, place-and-route-and tapeout for faults. If there fault, it also has to be determined how dangerous that fault is.
“As these defects in the design are detected, they must be iterated, fixed, and documented. This is needed to get ASIL ratings and comply with ISO 26262,” Witek said. ” The problem with this certification is that ‘after the design,’ testing and compliance is often not possible. The process has to start with auto grad qual/validation/verification in mind and cannot often be fixed at the end at the component level (although a software or system level compliant fix can sometimes be applied). These procedures have been known to add up to two years to some semiconductor designs.”
Fundamentally, from the perspective of both IP vendor and IP consumer, it is imperative to track the usage of the IPs and ensure all the design collateral is maintained, Adhikary said. “For an IP developer, keeping track of the IP and its variants, associated issues for each variants and their resolutions, environments used for testing, and results, becomes a necessity. For an IP consumer, they need to keep track of where the IP was used, identifying equivalent IPs if needed for substitution, process nodes used to develop the IP, and open issues, if any. For both the IP developer and the vendor, it becomes necessary to have an exhaustive IP ecosystem which can manage a complex matrix of design information and attributes.”
Conclusion
Developing IP in the automotive industry is a complex and arduous undertaking. Standards are changing, buyers are from mixed backgrounds, and even then it’s not certain how quickly that IP will be adopted or where it will be used.
This is not a trivial undertaking, and while the auto market can pay significant dividends for companies that get it right, it’s not always clear how to get there—or what it will take to stay there.
Related Stories
Autonomous Vehicle Design Begins To Change Direction
It’s unrealistic to road-test every corner case, so the automotive supply chain is shifting gears.
Making Autonomous Vehicles Safer
What needs to be tested, and what’s the best way to make that happen?
Connected Cars: From Chip To City
Tomorrow’s vehicle-to-infrastructure network will require a coordinated effort between standards bodies, infrastructure providers, and technology developers.
AV Testing Advances Without Standards
While U.S. struggles to make rules for self-driving cars, industry works on streamlining validation.
Who Will Regulate Autonomous Vehicles Best?
How one state is approaching regulation of driverless cars—without addressing whether they are safe.
 |
 |
 |
 |
 |
 |
Leave a Reply