Arm Automotive Update Stresses Prototyping for Software Development

If you were at all uncertain about auto OEM development priorities, the answer is becoming clear: to accelerate/shift left automotive software development and debug. At 100M lines of code and accelerating, this task is overshadowing all others. A recent Arm update from Dipti Vachani (SVP and GM for the Automotive Line of Business) led with their new emphasis on support for virtual prototyping for software development. Very interesting given Accellera’s recent update on Federated Simulation as an intended standard for whole-car software simulation (among other objectives). I have also written recently about increasing hardware complexity in zonal controllers and elsewhere, each requiring complex software services, further amplifying the software challenge. All our new tech goodies will amount to little if the software to coordinate the whole system cannot be developed in parallel.

Virtual prototyping solutions

Breaking with the standard Arm announcement flow, Dipti started her update here rather than on new cores (of which they have an abundance). I find this significant; not a token move to supporting software dev shift-left but the leading theme. Which is not surprising because to really shift left the whole automotive stack, firmware, middleware, and applications across all subsystems in the car must come together in parallel with the hardware.

Also of interest, Arm see this digital twin running in the cloud. I sense a trend. I would imagine that partners in the stack can more easily collaborate in this way against an evolving digital twin. But also, per Dipti, software developed in Arm-based cloud instances (Graviton or Ampere for now) will be automatically portable to the Arm-based hardware platforms in the car. Sneaky. Arm is leveraging its established strength in the cloud to push an Arm preference into cars. Even more so if the hardware architecture leverages CSS instances (more on that later) for high performance compute applications. As evidence that this isn’t just talk, she cites the AUTOWARE open autonomous stack (on the right of the above figure), containerized in Amazon AWS instances. Further she adds that this capability can shorten the OEM system development cycle by up to 2 years.

Pretty compelling, though we should remember compute in a car is not just based on Arm technology. In-vehicle infotainment may run on a Qualcomm chip. Sensing, object detection and sensor fusion for vision, lidar and radar will run on complex AI pipelines using a variety of DSP, AI accelerator, and GPU functions along with communications. A complete solution to prototype software for the full car system will likely still need something like the Accellera Federated Simulation standard connecting virtual models from multiple sources in addition to Arm’s initiatives.

New IP options for automotive

Plenty of new info here around extension to the Arm Automotive Enhanced (AE) family. Neoverse from the infrastructure product line has now been added to the AE portfolio as Neoverse V3AE, based on the high-performance V series already adopted in cloud datacenters. Applications are expected to be big in central controllers especially for software-defined vehicles. Arm has now announced that Nvidia Thor (aimed at the central controller) is based on this platform.

Cortex A720AE and 520AE add new few features in support of ASIL B and D certification, and provide cluster configurability between lock modes for safety and split modes for performance. Cortex R82AE extends real-time capability with 64-bit operation and 8 core clusters in support of safety islands while the Mali C720AE ISP adds more support and configurability for human vision and computer vision pipelines. All supporting ASIL B and D requirements and features of course (ASIL B and D seem to be the only ASIL standards mentioned these days. Whatever happened to A and C?)

The final important piece of news in this announcement is that the Arm automotive LOB is now working on CSS (compute subsystem) cores for the AE product line. If you don’t know anything about CSS, these are preconfigured subsystems of Arm cores developed as a customizable compute subsystem, verified, validated, and PPA-optimized by Arm. CSS was first introduced for Neoverse. Arm finds these pre-designed and optimized subsystems are attractive to system designers on a deadline who don’t feel a need to keep re-inventing compute subsystems. I would bet auto system designers feel the same way. Automotive CSS is expected to become available in 2025.

Takeaways

My first takeaway is building support for automotive digital twins, running in the cloud. Whether in a single container for Arm-centric platforms or in multiple containers orchestrated by a Kubernetes or similar will depend on how soon the Accellera standard may appear.

My second takeaway is that Arm has an interesting opportunity to extend its hegemony in cloud-based platforms to automotive platforms as well, simply by virtue of running on the same instruction set architecture in both domains.

You can read the press release HERE.