How Software-Defined Vehicles Change Auto Chip Design

The shift to software-defined vehicles is changing nearly every aspect of automotive design, from what hardware is added into vehicles, when it gets added, and what gets left behind.

Moving key features to software rather than hardware allows carmakers to bring new features to market faster, at a lower cost, and to modify those features more quickly. It is also expected to drive up the value of automotive software, currently about $29 billion annually, by 15% per year through 2030. But it also will add significant complexity into vehicle design, requiring varying levels of integration between hardware and software and a deeper, ongoing understanding of how changes to one feature or system in a vehicle will affect others. On top of all of that, it will include a lot of guesswork about how future changes will affect that design.

“The software-defined vehicle will continue being an important trend, because if you can do things with software, it should be cheaper than hardware,” said Judy Curran, automotive CTO at Ansys. “If you look at the early Tesla Model 3s, the way they were able to get that vehicle to an affordable price was not because the battery for the Model 3 was that much cheaper. It was that you look at the big screen and all the buttons are gone. The instrument cluster is gone. Look at your key, which is a card. Part of the software-driven vehicle and the new electrical architecture will be less expensive from a hardware perspective, so the architecture is less about individual modules and more about a few, greater modules.”

That doesn’t imply designs will become simpler, though. Hardware, software, and firmware that are mission- and safety-critical must be able to handle software updates a decade or more into the future. For an industry defined by constant change and upgrades, predicting how software will evolve over a decade and how it can continue to work with today’s hardware architectures is a major challenge. The result is a lot of over-engineering.

Legacy software and hardware is only part of the problem. These systems must be simulated to a level that in some ways surpasses the capabilities of today’s digital twins. In effect, they will need to predict future trends, adapt to continual changes for security reasons, and still perform well enough to take advantage of still-undefined safety improvements and requirements. As a result, designers working on SDVs today find themselves in a unique environment in which going overboard on what a chip is capable of handling is acceptable.

“There are two approaches,” said David Glasco, vice-president of compute solution group at Cadence. “You can over-design it, and if you look at the cost of a vehicle, silicon is not cheap. But adding a few more processors or another GPU doesn’t significantly increase the cost. You start with eight CPUs and say, ‘Hey, why don’t we just put in 12,’ because at the end of the day, that area doesn’t really impact it. You’re always somewhat over-designing. But you also can think about having more of a field-replaceable unit. It’s similar to the days when PCs still had plug-in cards, or even like your GPU today. I can buy a GPU, I can upgrade it as my software demands become more intense. Another thing you’ll see is that automakers want a common architecture from top to bottom in their product lines, so they may over-design from the low end, but have the same architecture top to bottom. You can bring more and more features onto low-end cars over the years, too, just by enabling features that may not show up in in the initial release of the car.”

Demand for over-engineered chips originates with the OEMs, which increasingly require designer teams to plan for future compute needs.

“When we get the request from the customer, there’s a 20% buffer, but that is not enough anymore,” said Bill Stewart, vice president of automotive Americas marketing at Infineon. “The biggest change is the methodology of when we design these things. Usually, it’s a balance, because you don’t want to over-design them. But now, instead of having a 1 MB part for that, now we need a 2 or a 4 MB part to plan for that. The same goes with processing performance, and potentially what network technologies are used. There are a lot of these things where we have to plan for overhead. Let’s plan for extra space, because you can’t go and add memory later. You can’t add processing power later that doesn’t exist.”

That need for scalability starts with a baseline hardware platform for basic functions. “Depending on the vehicle type, whether it’s entry level or mass production, more functionalities will be added, which will add complexity to the hardware engineering,” said Adiel Bahrouch, director of business development for automotive industry at Rambus. “This means the hardware engineer needs to think about capabilities for all those types of vehicles for current requirements, while also thinking about the requirements that are potentially needed or coming in 5 or 10 years from now.”

Changing relationships between SW and HW
The intricate intertwining of hardware and software in automotive has a long history. “Traditionally, vehicles had hardware and software that were very tightly coupled,” Bahrouch noted. “Every single feature you would select for the vehicle would translate to a black box, which now translates to an ECU electronic control unit. You would have, let’s say, a simple processor or microcontroller with a piece of firmware that is implementing a particular function. Every time you chose a function or a feature, you would get yet another ECU. That obviously worked for many years, but it’s not scalable for SDVs. The value proposition of an SDV is being able to add features throughout the lifecycle of the car.”

The long term goal, however, is to decouple that relationship — especially in situations where an automaker isn’t producing its own hardware and software in-house.

“Everyone’s trying to follow the Tesla model, but that’s a huge burden, so it becomes fairly decoupled,” said Cadence’s Glasco. “I don’t know if it’s quite as decoupled as an Intel or an AMD CPU design team from somebody writing the latest game. But on the other hand, if you look at gaming, there’s pretty tight collaboration between GPU developers, the NVIDIAs of the world, and all the key gaming companies. It all depends on the organization that you’re in and how they’ve compartmentalized.”

A tight relationship between software and hardware presents several problems. “Some of them are going to be mission critical, some not so much,” said David Fritz, vice president of hybrid and virtual systems at Siemens Digital Industries Software. “Then you have to say things like, ‘If I’m streaming video to the kids in the back seat, but it’s raining and I need more processing power to stop before I run into a deer on the road, how does that work? How do I make sure that the chip running the software workload under these corner case scenarios is going to perform to meet the requirements?’ The chip designer has no clue. The software designers have no clue. But a system-level requirements manager knows that. You need to be able to derive these extremely detailed SoC requirements from high-level scenarios that are run to test these corner cases using an actual software workload.”

This means a digital twin of the entire vehicle’s electronic system is needed because the things being simulated are interdependent. Before the simulations can be run, one team needs to write the software to fit hardware that hasn’t yet been finished, while their counterparts must complete the hardware to fit software that doesn’t yet exist.

While one solution has been a tighter relationship between software and hardware development, another has been a focus on different levels of simulation.

“There are a lot of different companies working on these simulation tools, and different OEMs have implemented different levels of that,” said Infineon’s Stewart. “One level is a high-level simulation that’s very fast, and we can clarify high-level functionality all the way down. In other cases they are asking, ‘Do we get rid of our hardware-in-the-loop systems and do all our validation in virtual?’ We’re working with different partners to create different virtual prototypes of our devices to support those activities. For instance, for all of our microcontrollers, there’s a virtual prototype where you can do full software development, and it’s beyond even the digital twin. You can inject faults. You can say, ‘I want to understand what happens if this failure occurs, or this rare condition happens.’”

Security is a must
Alongside of all of this, security must be enabled and continually updated in all devices. “Security is always a moving target,” Stewart said. “The upgradability of security features, what crypto libraries you can support, and how you’re encrypting your network traffic is always going to be subject to updates. Finally, is functional safety, and having a good understanding of potential failure modes is needed because they’re going to occur, whether it’s a chip, the software, or an external event to the module. There are going to be things that impact functional safety. How do you measure, detect, and prevent those failures so you take the appropriate action? These are all things we’ve been doing for a long time. SDVs make all of those much more important.”

But given that a single car can contain chips from a variety of suppliers, establishing a secure environment can be a daunting task. Conversely, suppliers can send their chips to a variety of OEMs at the same time. Mike Borza, a Synopsys scientist, noted that the OEMs “carry the big stick,” and have been the driving force at establishing universal security standards through organizations such as the SAE.

“Mercedes Benz, for example, can have a root of trust that authorizes the issuers of identities for all of the parts of their car, and they all trace back to one or a small set of Mercedes Benz roots of trust,” Borza said. “Or they know of a supplier’s root of trust for their supply chain, so they can track individual parts back to the suppliers who were supposed to supply them. They can establish — through things like manifests and what equipment is on board — who should be there, who shouldn’t be there, what they’re willing to authorize if they choose to. They can make admission to the network dependent on that being something that’s in the manifest, and they define the way that they build the manifest for the bill of materials.”

Designing for ruggedness
A final element that needs to be considered when it comes to SDVs is designing the components to hold up over time. On a system level, designers need to approach the average family sedan in much the same way they would a tank or other piece of military hardware. Unlike a data center server, which will spend its lifespan in a curated, state-of-the-art controlled environment, a car’s electronics must function properly in blazing summer heat and frigid winters. To ensure proper functioning, designers must ensure their devices meet the strict requirements laid out by the Automotive Electronics Council’s Q100 standard, which outlines proper stress testing for automotive components.

“There’s a lot of work that goes into how you heat up the system quickly,” said Cadence’s Glasco. “If you have a battery in your car, you have this problem that you have to almost continuously heat and cool it to keep it in the steady state of temperatures. From a silicon perspective, that’s a well-understood problem in terms of how to build silicon that can run in very cold to very hot settings. Because you always have that in automobiles, you always have the requirement of the rearview camera popping up within half a second. So you have to manage the fact that the car may be very cold, but it needs to start and almost instantly be able to be operating. That has all been well appreciated in automotive silicon design for a long time.”

Conclusion
Software-defined vehicles are an emerging and growing part of the booming automotive industry. While chips have long been an integral component in cars, the emergence of SDVs requires designers to adopt new considerations to address the unique challenges.

Those challenges include designing hardware capable of running software updates that will come far into the future, which can necessitate a degree of over-designing. While software and hardware teams have had to work closely together in automotive contexts, the rise of SDVs necessitates a degree of decoupling, but with a deep knowledge of how the pieces interact.

In addition, designers must keep security requirements in mind, along with the varied environments that cars operate in while designing their systems.