ADAS Design Shifts Toward Hardware

Autonomous driving will challenge system-level designers like never before with the simultaneous integration of three critical areas: Supercomputing complexity, real-time embedded performance, and functional safety. To get there, developers will need to shift their focus from a software-centric approach toward custom hardware development to produce a system that meets the safety, cost, and power efficiency design constraints of passenger vehicles.

ADAS Lessons Learned
The Advanced Driver Assistance System (ADAS) teams that have made the shift from software-centric systems running on merchant semiconductors to custom system-on-chip overcame these barriers and introduced game-changing platforms. Autonomous driving developers could take a page from the ADAS playbook to meet some of their integration challenges.

Figure 1. The block diagram above shows the implementation of key hardware protection and fault detection mechanisms. These elements help the electronic system achieve functional safety standards more efficiently than a software-only approach.

What some ADAS engineering teams have learned is that silicon hardware can be fine-tuned to offload many of the tasks that are executed in software. A key element of this approach relies on extending functionality system-wide through the system-on-chip (SoC) communications infrastructure. The flexibility afforded by this method makes the system more responsive to real-world driving situations.

Let’s go back to the software-centric approach that engineers adopted for initial ADAS systems. At the beginning of the development timeline, new algorithms had to be created to tackle emerging safety, visual processing, and sensor fusion applications. Many of these tasks required multiple lines of code to execute, and that presented both scalability and performance issues

It turns out automakers are leery about adopting and continuously supporting systems that require hundreds of thousands or millions of lines of code. In addition to long processing latency, large code bases are more prone to introducing errors, especially as updates are made over the lifecycle of a car. These errors can lead to system failures and potential liability issues. It’s also difficult for OEMs and dealers to maintain large code bases deployed in the field.

SoC innovation is key to success
In response, ADAS teams shifted toward hardware acceleration to perform functions with greater efficiency and lower cost. One example is the safety mechanisms that automotive manufacturers require for all the electronic systems integrated into their vehicles. This ADAS evolution from software-focused to hardware-accelerated offers a template for creating hardware to achieve ISO 26262 compliance at the system level. The SoC infrastructure plays a huge role in this evolution because it supports performance, safety, efficiency and safety improvements at the lowest possible level.

An ADAS or autonomous driving SoC must execute all autonomous driving functions in a scheme that will detect, and in some cases, correct both errors and failures. This process demands additional system logic, which can steal processing power from the supercomputing functionality, especially if it is software-based. Leading ADAS teams discovered the need to analyze their system and selectively implement hardware-based fault detection and repair capabilities based upon the hazards and risks of various faults. They also found that implementing on-chip hardware-based functional safety mechanisms can greatly reduce software complexity as compared to software-only fault detection or correction approaches. Some of the most advanced ADAS teams realized that they could extend error detection and correction mechanisms throughout the SoC by implementing them within the interconnect, and increase system-wide diagnostic coverage.

Supercomputing, safety
For autonomous driving, safety and supercomputing requirements are incredibly complex and seemingly contradictory. They also pose obstacles to delivering the near real-time performance required. The performance will, therefore, suffer if functional safety mechanisms are added only in software. Fortunately, ADAS evolution offers a template for adding the functional safety mechanisms in hardware to achieve ISO 26262 compliance at the system level.

The ISO 26262 specification is enabling the development of more sophisticated autonomous driving SoCs. State-of-the-art embedded decision systems usually implement neural networks with multiple heterogeneous hardware accelerators to make it possible for more efficient vision processing, sensor fusion, and autonomous driving functions. This is supercomputer complexity in a car.

Additionally, integrating deep machine learning, neural networks, and real-time embedded processing bandwidth in individual SoCs will only increase the complexity. Imagine how hard it would be if these developers did not improve the on-chip communications infrastructure that links all these elements together.

Self-driving algorithm development will get the media attention in the early stages of this autonomous driving revolution because it is easier for investors to understand. However, it is the electronic system developers who must devise custom hardware that is finely tuned to execute these algorithms more efficiently. The lessons learned from the development of today’s ADAS could enable the future of autonomous driving, one where a cache-coherent SoC architecture supports deep machine learning and multiple heterogeneous processing elements.