Balancing Programmability And Performance In Cars

The rate of change in the automotive industry is accelerating with the shift toward software-defined vehicles and ongoing advancements in algorithms and chip architectures. The challenge now is to figure out the best way to prevent rapid obsolescence, improve safety, and keep the cost of these changes to a minimum.

Today, updatable automotive hardware is typically achieved through FPGAs, but changing hardware on the fly could be expensive, and it can impact how the software works.

“This is changing in the era of SDVs,” said Robert Day, director of automotive go-to-market at Arm. “The functions of the ECU will ultimately be controlled by software, with updates coming from the cloud to the car.”

Arm works with automotive partners through initiatives like SOAFEE to simplify cloud-native approaches to automotive system development, taking advantage of environmental parity between the cloud instances and vehicle hardware to allow a more seamless approach to updating vehicle functions.

And while there is always room for programmability in SDV ECUs, it’s not always straightforward.

“Performance-wise and cost-wise, [FPGAs] are not going to be competitive to say, another solution, whether it’s an SoC or a multi-die chiplet in a single package,” said David Fritz, vice president, hybrid and virtual systems at Siemens Digital Industries Software. “We have consumer expectations driving the need for higher, complex solutions, whether it be a car, AI in an HPC server, or even a smartphone. They’re all going through the same kind of transition where they need more performance and more intelligence. As soon as you put an FPGA in there, it becomes a fantastic sort of intermediate fidelity solution, but not one that’s going to be production-worthy in markets where the margins are shrinking. This gets us back into the methodology we’ve been professing for a long time, where you start with a virtual representation of the hardware, even if the hardware exists, because everything exists in the cloud now. You can replicate it 1,000 times, crank up to 2,000 overnight for regression testing, but as soon as you get that next phase of fidelity — which could be emulation, it could be an FPGA implementation — all of a sudden you have the limitation of what’s available in a physical world. And we see the need for that intermediate step.”

Fritz said FPGAs can be used there, but not at the volume needed. “You can’t have 1,000 of those. You may have a dozen or two dozen, because they’re a couple hundred thousand dollars a pop. Of course, in the end, you want to be able to take all or part of what you had in the lower fidelity and start connecting it up to the physical end product, and that completes that whole cycle. To me, that defines SDV, plus all the DevOps and everything that goes with it. You can see the fidelity progression. So there is a role for programmability, but it is sort of an intermediate, limited role. I don’t see that as being in high-volume production, and I don’t think anybody really does.”

As the design of vehicles move to software-defined vehicles, the amount of processing tasks being handled by electronic control units (ECUs) will increase dramatically making real-time programmability essential for managing overall functions. Ray Notarantonio, senior director of vehicle user experience at Infineon Technologies, said, “Functions ranging from infotainment, safety and vehicle experience— to overall vehicle software — will be reliant on programmability.”

Automotive microcontrollers by Infineon and others will enable programmability with smart hardware features to ensure zero defects and real-time software updates.

Rehan Tahir, senior automotive product and marketing manager at AMD agreed today’s automotive-grade FPGAs, adaptive SoCs and other programmable devices are ideal for software-defined vehicle (SDV) platforms and will play a significant role in this evolution in the automotive industry. “The shift to SDV is rooted in enabling faster innovation and greater flexibility, while transitioning from a hardware-centric approach to one that emphasizes software as the primary driver of functionality and innovation. The ability to reprogram and customize adaptive computing devices like FPGAs and adaptive SoCs is critical in delivering the real-time data processing required in advanced driver assistance systems (ADAS) applications by offering ultra-low latency hardware-level connections without compromising computational power. This low latency is critical for ADAS applications, enabling near-instantaneous decision-making based on sensor data, which is essential for safety-critical functions like collision avoidance and emergency braking.”

Also, the flexibility offered by FPGAs and adaptive SoCs enable enhanced security and functional safety by allowing for custom security protocols, which can be continually updated to combat emerging threats. “The ability to adapt and strengthen security measures is a necessity for protecting against cyberattacks in the complex, connected systems within SDVs,” Tahir noted. “Adaptive computing devices are also able to perform deterministic operations in real-time which are suitable for safety-critical applications. FPGAs and adaptive SoCs are also driving increased flexibility and scalability in SDVs by enabling manufacturers to tailor vehicle platforms while simplifying upgrades and customization. Complementing this, domain controllers and zonal architectures provide the computing resources needed to separate the hardware and software development timelines – a key aspect of SDVs.”

Embedded programmability
Where programmability is essential once a vehicle is in the field, and while programming discrete FPGAs is still up in the air, embedded FPGAs may be a more attractive option.

“This is particularly valuable, given the inherent re-programmability of the vehicle architecture,” said Jayson Bethurem, vice president of marketing and business development at Flex Logix. “Reconfigurable hardware allows for adaptable control of critical interfaces like sensors and user inputs, enabling the platform to adapt to new sensors, protocols, and algorithms, including those for compression and signal processing. Most importantly, reconfigurable hardware enables crypto-agility by securely implementing and storing security keys, as well as accelerating emerging cryptography algorithms.”

Technically speaking, ECUs need to be programmed at the factory level during deployment, but they can receive software updates over-the-air (OTA) as needed.

“To ensure the stability, reliability, and performance of an ECU, it undergoes a rigorous validation and verification process, often requiring the device to be programmed or reprogrammed with software code developed prior to ECU programming,” said Amit Kumar, product management director at Cadence. “While traditional methods allow for programming in the field using CAN ports or OBDII, newer SDVs utilize cloud connectivity for OTA updates.”

And with the advent of virtualized ECUs (vECUs), Tier-1 suppliers can conduct tests to validate new software and hardware configurations in safe, controlled environments, enabling them to run corner cases that later can be flashed as software updates to physical units. “Each ECU will have a separate storage area for software updates, which must go through processes like matching security certificates before the device is programmed with the latest update,” Kumar said. “In short, programming each ECU involves remapping and flashing software, which necessitates programmable devices onboard.”

This is especially important for self-driving vehicles. “[Autonomous taxis] are a scary proposition until they get it absolutely right,” said Rich Goldman, director at Ansys. “Today, OTA updates for software for the ECUs are routine in these cars. Sometime in the future, if you’re going to reconfigure FPGAs over the air, why not? It sounds a little scary now, but engineers are clever. They always solve things, and every morning you may wake up and wonder if your car’s a new car, and if you have to figure out how to drive it again.”

AI’s role in SDV ECUs
AI is integral to the development and operation of SDVs, making them faster, safer, more efficient, and capable of autonomous decision-making in complex environments, AMD’s Tahir observed. “Adaptive SoCs with integrated AI engines or NPUs are well-suited for efficient processing a broad range of AI algorithms and can be updated and optimized over time. In SDVs, as a result, AI-driven features such as object detection and segmentation can be continuously improved to enhance the personalized driving experience.”

And as AI/ML use breathes new life and features into automotive applications, the proper software compilers will be needed to bring hardware up to date. Automotive OEMs do not know today what features can and will be added down the road.

Software-defined vehicles are intricately tied into those changes. “You buy a car these days, you expect it to last a decade,” said Steve Roddy, chief marketing officer at Quadric. “It’s not the 1950s where it rusts out after four years and you buy something new. This is developed now in 2024. It rolls off the assembly line in 2028. So come 2038 when there’s the latest and greatest AI network that does better at avoiding running over people, you’ve got to find a way to deploy that network into the old car. If you were managing the ADAS systems software teams at one of these Tier-1 OEMs — Bosch or Denso or Aptiv — you have your cadre of data scientists inventing better algorithms.”

This fans out to dozens of different platforms of vehicles that the systems have been deployed into over the years. “Comparing the 2020 model year vehicles with the 2030, and 2032 vehicles, the level of compute horsepower is increasing manyfold,” Roddy said. “What’s in a 2028 car versus what will be in a 2035 car will have a10X delta in compute capability. You have to find a way to take a network and retarget it through compilers. It’s got to be compilers. It can’t be human sweat equity. It can’t scale. If you’re running the Bosch ADAS safety team, you can’t have 24 teams of people who retrain networks and squeeze them to fit the latest thing because you’ve come up with the latest and greatest algorithm. It works fabulously on the top of the line Mercedes S Class, which has gobs and gobs of horsepower, but there’s a 12-year-old Chinese vehicle that was sold by the millions and that has your system. And maybe from a regulatory standpoint it has to have the ability to do over-the-air updates and stay current with new things. So you’ve got to find a way to target everything in between.”

In addition, there may be a bunch of targeted changes, but developers are not going to employ teams of people constantly updating things.

“This is why there’s got to be this more compiler-driven software in the hands of the data scientist — more of a closed loop thing where they can write it, run through compilations, have a development target somewhere in their lab to see if it worked, and in 24 hours get the cycle done,” he explained. “Then they can see they had to dumb it down a little bit for the cheap car, but it still works better than the previous one. So all of this has to be much more software-driven, and it has to be completely within the control of those algorithms and software people, not reliant upon some IP vendor who 10 years ago sold a core. We’ve got to find a way to unencumber the data scientist and not ask the 23-year-old data scientist to think about the limitations of the embedded hardware. There’s too many of them, and it’s too easy for them to say, ‘I don’t want to do that. I don’t want to be an embedded guru.’ At the same time, you’re not going to take all the embedded engineers who exist and somehow turn them into data scientists. Those folks struggle with getting an algorithm from some GitHub repository, and they say, ‘Make this run on the embedded chip that we have.’ If they have to start mucking around with the network and changing operators, as ‘Our chip only does three by three convolution, so let me take out this five-by-five dilated convolution that exists and plug in what I can support. How do I retrain this? I don’t have all the data sets.’ It’s very difficult to bridge that gap between mathematician at one end and embedded programmer at the other end.”

One of the ways to solve that is to make the embedded platform much more programmable. “That way you don’t have to do cosmetic surgery to every single network in order to try and get it to land on silicon,” Roddy said. “If a new mathematical approach gets you 1% better accuracy on recognizing grandma in the crosswalk, well, that’s a good thing. It starts with a mathematical abstraction. You want to give the freedom to those developers to find those better representations. If we’re ever going to have autonomous cars, they’ve got to be 99.9% accurate at recognizing things. It’s not good enough to say it was 87% accurate at finding pedestrians.”

Accelerating development and deployment
The pace of development in the automotive industry is accelerating quickly, and AMD’s Tahir believes programmable logic or FPGA fabric is essential to rapid prototyping, iteration, and continuous integration and continuous deployment (CI/CD). ”The ability to customize and reprogram devices like FPGAs and adaptive SoCs allows automakers to deploy updates or enhancements without needing to redesign hardware. This supports the dynamic nature of SDVs, where software updates often introduce new features or improve upon existing capabilities over the vehicle’s lifecycle.”

Finally, auto-grade FPGAs and adaptive SoCs also allow for both hardware and software to be upgraded over the air (OTA). This extends the usable life of the vehicle’s electronic systems, aligning with the long-term vision of SDVs and helping to future-proof investments, Tahir added.

Designing ECUs in an SDV setting
For automotive ECU architects, the biggest challenge for designing into SDVs today is the ecosystem.

“Ecosystem is number one, number two, and number three,” said Siemens’ Fritz. “The Tier-1 suppliers are fighting for their lives, and they want to drive this in a direction where they have control and can provide a solution up to the OEM. At the same time, the OEM is trying to drive top down in that direction. The OEM is saying, ‘You’re proposing a six-ECU solution for me, which is going to cost me X dollars. Our research tells us that could be one ECU, which cost us 1/20 of that, and still have better functionality, lower power, and lower maintenance. Everything is lower. That’s what I want.’ That’s not what the Tier-1 is proposing, because they want to take pieces of that, as a supplier, and sell it to multiple OEMs. And the reason the OEM wants to control it is so they can differentiate. The suppliers want the opposite. ‘We don’t want you to differentiate because we want you to use the same thing multiple times,’ which is akin to what’s happening on the chiplet side of the semiconductor industry. There are people who want to control it, which is the opposite of the direction it needs to go. Behind that, and under the hood, we’re saying that ideally you would consolidate for power, performance, cost, reliability, and all other things that automotive companies care about — consolidate as many of those ECUs together as possible. But that’s counter to the cultures and most of the suppliers that develop the ECUs.”

However, this will change because it has to, Fritz said. “The Chinese companies are starting with a blank slate, going back, and doing it right. We give a talk about how it ought to be done, and they say, ‘Great, when can we have it?’ You do that in Detroit, and it’s, ‘Come back in five years when we’re ready to think about that.’ The difference is shocking, and it’s going to change the whole industry during the next few years. There’s no option.”

Conclusion
As the automotive ecosystem continues its evolution toward higher levels of autonomy, the debate over which aspects of the vehicle architecture and chip hardware should be programmable, and to what degree, will continue. Many aspects of vehicle architectures are in the process of being worked out now, and however it unfolds ultimately will have a big impact on the ability of vehicles to do more, to do it better, and to stay current for longer periods of time.

Related Stories

The Uncertainty Of Certifying AI For Automotive