Meeting Processor Performance And Safety Requirements For New ADAS & Autonomous Vehicle Systems

By Fergus Casey and Srini Krishnaswami

Innovation in today’s automotive industry is accelerating as companies race to be the market leader in safety and autonomous vehicles. With vehicle control moving from humans to the vehicles’ active safety systems, more sensors – cameras, radar, lidar, etc. – are being added to automotive systems. More sensors require more computational performance from larger SoCs to process the extra incoming data and to do so with minimum chances of failing. Therefore, autonomous vehicles require an orders-of-magnitude increase in processing performance and safety requirements. These larger SoCs require a state-of-the-art processor architecture that delivers required processing performance with the highest automotive safety integrity level (ASIL).

One example of a safety system with sensors is radar-based adaptive cruise control and lane centering. Increasing safety levels results in increased cost of the systems, e.g., inclusion of physical sensors to meet these standards. Radar applications play a crucial role in the safety of future automotive applications. An L1 autonomy radar system must demonstrate detailed understanding of the environment, including side traffic, to react according to the situation. Autonomous driving functions with higher-level degrees of autonomy (e.g. L2+, L3, …) need to have a complete surround view which results in the need for multiple corner and side radar in addition to front and rear radar sensors. Both examples show the need for more and more information to be extracted out of a given sensor signal. More sensors are required and more information must be extracted (calculated) on each sensors data requiring more and more processing capabilities.

Traditionally, automotive MCUs in these larger SoC have been RISC based architectures. However, to meet the performance requirements systems like radar-based active safety systems, a processor architecture with state-of-the-art safety features that balances a combination of performance, power, area, and safety results is needed. This combination sets the foundation for future advanced safety designs within the automotive industry and likely other future life-essential safety applications, e.g., robotics and drones in your neighborhood involving potential for human interactions (figure 1).

Fig. 1: Microprocessor PPA triangle with safety overlaid.

Functional safety requirements and ISO 26262

In the automotive industry, functional safety is outlined in detail within the ISO 26262:2018 standard, which defines different Automotive Safety Integrity Levels (ASILs). ISO 26262 includes the concept of acceptable failures in time (FIT) for random hardware failures and also defines the systematic process requirements that shall be followed for hardware, software, and the combined system development to be compliant to the automotive standard.

To help align the ASIL with the automotive use case and its safety criticality, the ISO 26262 standard is broken into 3 specific areas:

• Probability of exposure – how often this event is likely to occur in a typical drive
• Controllability of the driver – how likely is the driver able to counter the failure
• Severity of the failure – If there is a failure, the probability of an accident

Figure 2 shows how to calculate the appropriate ASIL safety level using an example of a vehicle’s forward collision warning system which needs increasing needs for safety, resulting in the need for ASIL D.

Fig. 2: Probability (E4), controllability (C3), and severity (S3) of forward collision warning systems result in an ASIL D requirement.

For a forward collision warning system use case, the probability of exposure is high as a car will likely meet another car on the road. The controllability of the driver is reduced for this use case as the purpose of the system is to inform the driver of a potential collision before the driver sees the safety issue. In addition, with increasing levels of autonomous driving, the controllability by the driver is reduced. And the severity of failure is high as a failure in the system could lead to a collision.

The relevant safety fault types are sub-divided within the ISO 26262 standard are:

• Systematic Faults
• Random HW Faults – Permanent and Transient

Systematic faults are applicable to hardware and software, introduced through the development of the hardware and software modules. Permanent hardware faults are caused by the wear and tear of the hardware device where the failure persists indefinitely (or at least until repair) after their occurrence, e.g., a short circuit. The fault metric for random faults is a hardware architectural metric that measures the coverage by the safety mechanisms within the SoC. The higher the fault metric the lower the risk from the fault in the hardware architecture.

ASIL compliant IP developed for automotive SoCs needs to demonstrate protection for all fault types, including stuck-at-faults and transient faults. Specifically, for random hardware faults, the ASIL levels are defined as shown in table 1.

Table 1: Fault metrics for ASIL levels.

As ADAS systems advance from passive to active assist capabilities, e.g., forward collision warning system turned into collision avoidance system (CAS) through the use of advanced radar systems, the level of controllability or “active assist” is moving from the driver to the vehicle safety systems. Thus, where a radar system supporting a lane forward collision warning system was previously rated to ASIL B, ISO 26262 based on probability of exposure, controllability of the driver, and severity of failure, the CAS systems move the item to a higher level of safety due to change in controllability. This conclusion is further validated through recently reported vehicle collisions where such ADAS system capabilities are resulting in reduced driver attentiveness to the road with the indirect consequence of increasing the safety requirements for these systems.

Processor selection requirements

Existing safety-critical MCUs cannot deliver the required performance to deliver L2+ capabilities and therefore will require the fusion of high-performance processor IP cores with new state-of-the-art safety concepts. The following benchmark comparison between RISC and vector DSP architecture helps demonstrate this point. Such an architecture can be realized with a safety-enabled vector DSP delivering up to 25X performance requirements over standard RISC cores. This architecture combination of DSP parallelism and safety mechanisms avoids the need for brute force lockstep to achieve the required ASIL. Such an architecture combined with the ability to execute artificial neural networks (ANN) can reduce costs by replace some physical sensors with virtual sensors.

Comparing the standard RISC architecture with the 512b wide vector DSP architecture for a standard FFT kernel, we can see the significant benefits of the vector DSP architecture from performance and power perspective vs the RISC architecture.

Fig. 3: The performance and power efficiency benefits of a vector DSP architecture vs RISC for FFTs.

To meet the performance requirements for an automotive real time application, e.g. radar, similar computationally intensive algorithms to the FFT Kernel benchmark above, are executed on high performance processor architectures like Synopsys DesignWare ARC EV7x Processor IP with tightly integrated deep neural network (DNN) engine.

DesignWare ARC EV7xFS Embedded Vision Processors for safety (figure 4) are fully programmable and combine the flexibility of software solutions with the high performance and low power consumption of dedicated hardware. The DesignWare ARC EV7xFS Processors integrate up to four high-performance 32-bit scalar cores and 512-bit vector DSPs. They are fully programmable and configurable IP cores that utilize a very long instruction word (VLIW)/single instruction-multiple data (SIMD) architecture with optimized execution units for floating point and linear algebra/math computation. The EV7xFS processors are optimized for high-performance embedded signal processing or vision applications that require functional safety. The EV7xFS Processor IP includes an optional integrated deep neural network (DNN) accelerator for fast, accurate execution of convolutional neural networks (CNNs) or batched RNNs/LSTMs.

To provide greater flexibility to automotive design teams and address evolving requirements, the ARC EV7xFS Processors offer an ASIL-Ready “hybrid” option that enables users to select required safety levels up to ASIL D post-silicon, in software.

The DesignWare ARC EV7xFS safety package is based on the following points.

• Integrated and configurable safety features up to ASIL D
• Detailed IP safety documentation enables certification of EV7xFS based systems up to ASIL D

The processors are developed as Safety Element out of Context (SEooC) meaning they can demonstrate evidence (per metrics outlined in 26262) of fault coverage for all fault types. As an SEooC, the processor IP is developed independent of a defined context related to a specific item or system (e.g., vehicle, vehicle sub-system, or OEM-defined item). ARC EV7xFS Processors are developed based on defined functional requirements, non-functional requirements, safety requirements, and assumptions of use.

Fig. 4: Synopsys DesignWare EV7xFS Embedded Vision Processor.

Functional safety on the EV7xFS processor can been implemented with rich set of state-of-the-art hardware safety mechanisms and a very comprehensive, fault injection validated, and FMEDA back-annotated, software test library (STL). The STL development methodology is another innovative state-of-the-art-process.

DesignWare ARC Functional Safety (FS) Processor IP supports ASIL levels up to ASIL-D to simplify safety-critical automotive SoC development and accelerate ISO 26262 qualification. The portfolio includes the ARC EM22FS, SEM130FS, HS4xFS and EV7xFS and VPX5FS safety processors with integrated hardware safety features to detect system errors.

Conclusion

A high-performance safety enabled vector DSP architecture is required to achieve the combination of performance, design cost efficiencies, and highest ASIL required for next generation vehicle active safety systems. Since developing an SoC as a SEooC to meet ISO 26262 standards requires demonstrable evidence of fault coverage for all fault types, built-in safety features must include protection against both systematic and transient faults. This will streamline the IP integrator’s efforts and argumentation for showing SoC level demonstrating evidence.

Srini Krishnaswami is a senior manager for ASIC digital design at Synopsys.