DfR Solutions' Insights

Are GPUs reliable enough to be an autonomous vehicle’s brain?

The technologies currently available to or being developed for the automotive industry are staggering. With these advancements comes the need to examine the types of processing units appropriate to power the autonomous vehicle electronics functionality.

CPU v. GPU: What’s the difference?

Processing units are, essentially, a computer’s “brain” wherein calculations and commands are carried out. Their configuration and logistical capabilities determine if the processing unit is a Central Processing Unit (CPU) or a Graphics Processing Unit (GPU).

Central Processing Units (CPUs)

CPUs can have up to 24 main cores and multiple motherboards that each house anywhere from 8 to 16 CPUs to perform integer calculations, floating point calculations and other advanced features consistent with traditional Intel x86 instruction sets.

CPUs are linear. They process information in a single instruction methodology of “if/then” serial scenarios, and typically exist in static environments with no exposure to outdoor elements, temperature swings or vibration.

Graphic Processing Units (GPUs)

GPUs are computer chips typically used in personal computers to perform rapid mathematical calculations associated with rendering 3D images. GPUs can contain thousands of main cores, and even cores within cores, to speed concurrent performance of a variety of small calculations, as in nVidia’s CUDA instruction sets.

These characteristics are common among advanced autonomous vehicle components, as demonstrated in increasingly prevalent driver assists, like lane detection/lane departure warnings, active parking features, adaptive cruise control and automatic/pre-crash braking.

But, modern vehicles depend on computers for more than the “extras.”

High Bandwith Networks

It’s not uncommon for one automobile to have up to 100 microprocessors actively monitoring various states of vehicular health and need.

All distributed or centralized data processing occurring within a vehicle has to be real-time capable, meaning all information must reach its intended destination before an appropriate action can be identified and implemented (e.g., the vehicle must recognize impact before “deciding” to deploy airbags). Information aggregation of this magnitude requires high bandwidth networks and falls more squarely under “big data” – something associated with datacenters, not automobiles.

It’s an important distinction, because vehicles using high bandwidth networks face the challenge of data guzzling. For example, one 8-Beam LIDAR (light) sensor using 864,000 3D points per second with 144 bytes of data per point = 125 Mbps, requiring nearly 1Gpbs Ethernet. Multiply that out by the sensors required for autonomous vehicles, and the problem evidences itself.

These systems commonly use 28 nm leading-edge lithography to fabricate high performance consumer off the shelf (COTS) integrated circuits, like GPUs. This provides best performance in the short term, but there is a very limited amount of data collected for technology nodes below 50 nm. Couple this with new lithography processes being introduced for automobiles before previous generations are mature, and it’s easy to overlook the potential long-term issues.

What might the performance level be after one, 5 or even 10 years of driving? It’s understood performance degradation will happen – and with smaller feature sizes, it happens in a big way.

Qualification Testing

Rigorous automotive qualification testing addresses long-term reliability of leading-edge commercial technologies, especially those rapidly evolving in the automotive industry. It is imperative to develop a reliability-based culture in product design.

Sherlock Automated Design Analysis™ software is the fast and accurate solution. With Sherlock, a finite element analysis (FEA) model of your circuit board can be constructed in minutes, and Physics of Failure (PoF) is applied to thoroughly and quickly test GPUs and every other PCB component. Reliability is assured, product confidence soars, and engineers can dedicate the time otherwise earmarked for repeated test cycles and data entry to pursuing new innovations.