WHITE PAPER

Scaling Processor Performance and Safety

to Meet Requirements for Next-Generation
Safety-Critical Automotive Designs

Authors Introduction
Juergen Schaefer, Innovation in today’s automotive industry is accelerating in the pursuit of autonomous driving.
Dietmar Koenig, and Orders-of-magnitude increase in processing performance will be needed before an automobile
Konrad Walluszik can drive itself. Improvements in energy and area efficient processor architectures will also be
Infineon needed. As more control of the vehicles continue to move from the human to the vehicle’s Active
safety systems, more sensors are being added requiring more computational performance
Fergus Casey and from larger system-on-chips (SoCs) to process the extra data. Such automotive systems
Srini Krishnaswami are referred to as active safety systems including ADAS, motor control and eMobility. More
Synopsys sensors also result in higher costs of the systems. As a result, the complexity and cost of these
safety relevant automotive systems is growing at an unprecedented rate forcing the safety
requirements of these systems to also increase.

This white paper proposes a state-of-the-art processor architecture targeting automotive safety
systems that meets the requirements of such active safety systems delivering the required
processing performance, providing the highest automotive safety integrity level (ASIL) while also
significantly contributing to a reduction in overall cost of the systems through the use of artificial
neural networks (ANNs). The use of ANNs executing on the processor architecture provides
the ability to replace physical sensors with virtual sensors. This processor architecture is based
on a safety enabled vector DSP processor delivering up to 25X performance requirements over
standard RISC cores. The state-of-the-art architecture combination of DSP parallelism and
safety mechanisms avoids the need for brute force lockstep to achieve the required ASIL. It also
shows the justification for the increased safety requirements for applications needed in L2+
autonomous vehicles by analyzing the performance requirements of two example automotive
use cases, radar and electric vehicles/eMobility.

The paper will cover:

• The importance of safety within an SoC’s power, performance and area (PPA) triangle and
the safety impacts on PPA
• An introduction to the basic concepts of functional safety, relevant fault types
and safety levels
• An exploration into radar and eMobility use cases which require high-performance processor
capabilities achieved through vector DSP parallel processing engines
• The objective alignment of these use cases which requires safety levels as outlined in the
ISO 26262:2018 standard and the definition of the needed safety mechanisms to achieve
the safety goals

synopsys.com
Balancing Performance, Power, Area and Safety
Together with significant processing performance improvements, autonomous vehicle development demands the most energy
and cost-efficient designs combined with highest level of automotive safety. Cost efficiency has a direct correlation to the silicon
area required to achieve the processing and safety requirements and will affect costs for years as the designs typically remain in
production for some time.

For the next 10-15 years, the industry will develop cars for battery-powered electrical vehicles and hybrid cars with increasing levels of
controllability of the vehicle through improved ADAS capabilities. To offer improved active safety systems, delivering L2+ capabilities,
the industry demands significant improvements in a SoC and related safety system architectures that offer predictive system control
strategies delivered with ever increasing safety protection. Existing safety critical MCUs cannot deliver the required performance the
industry demands and therefore will require in the fusion of high-performance processor IP cores and new state-of-the-art safety
concepts. The following benchmark comparison between RISC and vector DSP architecture helps demonstrate this point.

Comparing RISC vs vector DSP Performance and Energy Efficiency

Traditionally, automotive MCUs have used RISC based architectures. However, to meet the performance requirements of the use
cases outlined in this white paper, a more efficient and higher performance processor architecture is required that provides an
optimum balance of performance, power and area.

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.

FFT Kernel
Energy efficiency RISC vs Vector DSP
35
25
20
Vector DSP
15
RISC
10
5
0
Cycle Energy
*Normalized and relative numbers to Vector DSP

Figure 1: The performance and power efficiency benefits of a vector DSP architecture vs RISC for FFTs

In these larger SoCs, the balanced combination of performance, power, area and safety results in a processor architecture with state-
of-the-art safety features described in this white paper. 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 2).

Performance

Safety

Area Power

Figure 2: Microprocessor PPA Triangle with Safety Overlaid

2
To meet the performance requirements for an automotive real time application, e.g. eMobility and 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.

Foundations of Functional Safety for Embedded Processors

Functional safety refers to the integrity of the operation in an item composed out of electrical/electronic (E/E) systems that operate
in a safety critical domain, e.g. automobile. Functional safety is concerned with hazards caused by malfunctioning behavior in E/E
systems. Failures can result from hardware or software faults occurring in the hardware parts or software units of the E/E system.

In the automotive industry, functional safety is outlined in detail within the ISO 26262:2018 standard, which defines different 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 3 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.

Probability of Exposure Controllability by Driver Severity of Failure ASIL

E0 Combination of Very C0 Controllable in S0 No injuries C1 C2 C3

low Probabilities general
Very Low Probability Simply controllable E1 QM
S1 Light and moderate
(less often than once (99% or more of all
E1 C1 injuries
a year for the great drivers are usually able E2
majority of drivers) to avoid a harm) S1
E3 A
Low Probability Normally controllable
(a few times a year for (90% or more of all Severe and life- E4 A B
E2 C2 S2 threatening injuries
the great majority drivers are usually able E1
of drivers) to avoid a harm) (survival possible)
Medium Probability Difficult to control or E2 A
S2
E3 (once a month or more Uncontrollable Life threatening E3 A B
often for an average C3 (Less than 90% of all injuries (survival
driver) drivers are usually able S3 E4 A B C
uncertain), fatal
or barely able to avoid
High Probability injuries E1 A
E4 a harm)
(almost every drive E2 A B
on average) S3
E3 A B C
E4 B C D
QM ASIL A ASIL B ASIL C ASIL D
Figure 3: 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.

3
As shown in Figure 4, the relevant safety fault types are sub-divided within the ISO 26262 standard as follows:

• Systematic Faults
• Random HW Faults—Permanent and Transient

Functional Safety

Systematic Random
Faults Faults

Fault Type Definition

Systematic Faults Applicable to HW and SW, introduced through development

Random (Permanent) HW Faults
Random (Transient) HW Faults/Soft Errors
Occurs unpredictably during the lifetime of the product
Fault stays until removed or repaired
Occurs unpredictably during the lifetime of the product
Fault occurs once and subsequently disappears, e.g. bit flip in
SRAM or logic due to alpha radiation

Figure 4: Functional safety fault types

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.

Developing an SoC as a Safety Element out of Context (SEooC) that meets the requirements of ISO 26262 requires demonstrable
evidence (per metrics outlined in 26262) of fault coverage for all fault types. In the automotive world, the SEooC defined in ISO 26262-
10 is the method for using components in a vehicle that were not originally designed for that specific project. This allows IP vendors
and IP integrators to develop IP and SoC components that can cover many varying use cases within the automobile.

The evidence for an SEooC is demonstrable through various supporting work products of the IP, outlined in ISO 26262, referring to the
achievable single point fault metrics and latent fault metric of the design.

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 as a SEooC 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.

Metric ASIL B ASIL C ASIL D

Single point fault metric >= 90% >= 97% >= 99%
Latent fault metric >=60% >=80% >=90%

Table 1: Fault metrics for ASIL levels

When a specific IP component that is declared as safety relevant does not meet the ASIL metrics outlined in Table 1 for the SoC,
the IP integrator (SoC developer) must supplement the design using SoC based safety mechanisms to achieve the required ASIL
compliance for the entire SoC design.

4
For example, a processor that does not protect against transient faults pushes additional effort and argumentation to the IP
integrator at the SoC level to demonstrate evidence:

1. How transient faults are detected at the SoC or system level for SoCs that are designed as a SEooC, e.g., software redundant
2. How transient faults are not relevant for the defined automotive use cases of the SoC. Such use cases would need to be clearly
documented in the safety manual of the SoC

Meeting New Safety Standards

Driven by the increase in safety requirements for automobiles, automotive designers are aligning behind Global New Car Assessment
Programs (NCAPs). To meet NCAP safety levels, the cars must offer new safety capabilities. Although NCAPs do not mandate one
specific technology, vehicle manufacturers rely on cars outfitted with extensive sensors for support and safety.

One example of a safety system with sensors is radar-based adaptive cruise control and lane centering. Another example of a sensor-
based system can be seen in electric vehicles relying on voltage and temperature monitors to track the overall battery state of the car.
The safety requirements of a radar system that can control L2+ vehicle movements are intrinsically related to the safety requirements
of an eMobility system where a battery is required to move a vehicle safely. Increasing safety levels results in increased cost of the
systems, e.g. inclusion of physical sensors to meet these standards.

By using Kalman Filter and ANNs in system controllers, some physical sensors can be replaced with virtual sensors to help balance
the system costs while maintaining required safety levels. The virtual sensor is driven through predictive modeling of an actuator or
system environment that uses ANNs and state-space-based observers. These virtual sensors expand the capabilities of the system
while reducing the overall bill of materials (BOM).

Generally, virtual sensors improve the accuracy of an overall application function. To reduce system costs, virtual sensors enable the
calculation of non-measurable system states. Virtual sensors are mathematical models of plants and environment conditions. To
increase accuracy of virtual sensors, designers enable computationally intensive linear algebra functions such as ANN graphs.

Automotive Use Case: Radar

Radar applications play a crucial role in the safety of future automotive applications. NCAPs define detailed test scenarios to increase
passenger safety and overall road safety. To secure a high NCAP rating, 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.

As more and more radar systems are out on the street, the probability of interference with other radar systems is increasing dramatically.
The potential for interferences introduces the requirement for new processing of raw sensor data to detect and correct interference
problems. To avoid interference, designers can select from multiple different methodologies. Therefore, an implementation using a flexible
processor allows the designer to select from the best methodology for their use case, as outlined the RADAR system architecture below.

• Signal Generation
Comms • FlexRay Radar • Pre and Post Signal Radar and Transmission
Safety

Safety

Safety

Interfaces • CAN Microcontroller Processing Transceiver Receivers, Signal

Vehicle – DSP Acceleration • Conditioning RF Channel
• Ethernet
and Digitization
Safety

PMIC with Safety Watchdog

EV71FS

Figure 5: Overview of a radar system

5
The radar system includes the radar transceiver, the radar microcontroller, the communication interface modules to other systems
within the automotive as well as a power management unit.

The radar transceiver interfaces to the radar sensor where the data provided by the radar sensors is used in applications such as
blind-spot detection, autonomous emergency braking, and adaptive cruise control, to increase safety by enabling vehicles to identify
and avoid potentially dangerous situations.

The radar transceiver processes data on a per frame basis. Specific to fault protection, the embedded vision processor with vector
DSP capabilities that is responsible for radar data processing in the transceiver (represented by EV71FS in Figure 4) needs to protect
against stuck at faults. The radar transceiver will be less prone to transient faults (but not entirely) causing a safety failure as a
transient fault that occurs while processing a frame will not be present in the subsequent frame. However, a transient fault in the
DMA engine of the processor could cause an erroneous operation to output to the system bus leading to a safety fault.

FMCW RADAR, Sequential Processing Steps

Direction
• Data Cube Complete data set is a cube os samples, with 3 dimensions:
– Range
– Velocity
– Direction of arrival

Ve
Could be more than 1 dimension, e.g.azimuth and evaluation

lo
ci
ty
Range

Pre-Processing Post-Processing

Raw Interference Direction Processing Kalman

Data Detection and 1D-FFT 2D-FFT 2D-CFAR of Arrival Clustering Tracking
Mitigation 3D-FFT Filtering

Range
Velocity
Direction

Figure 6: A summary of a typical radar data processing flow

Typically, the radar processing chain can be grouped into pre-processing and post-processing algorithmic steps, as shown in
Figure 6. The pre-processing steps often include several layers of FFT processing to compute range and velocity information.

The post processing steps include a third stage FFT that can be used to determine the direction of arrival with a limited
accuracy. The direction of arrival (DOA) denotes the direction from which a propagating wave arrives at a point, where usually
a set of sensors are located. Put another way, the DOA estimates the angle of signals arriving at the sensor array. Often a
higher angular accuracy is needed to take accurate and safe decisions. Algorithms like MUSIC and ESPRIT can determine
high resolution direction of arrival. While the traditional pre-processing can be done in fixed point format, post-processing
linear algebra algorithms heavily rely on floating point computations to simplify algorithm development. For many algorithmic
steps, half precision floating point offers enough precision; however, especially iterative computation steps need to use single
precision floating point to successfully converge. Having a vector DSP hardware that supports both formats in an optimal way
can lead to great performance advantages. For example, the parallel processing of a single instruction, multiple data (SIMD)
vector can include twice as much data elements in half precision. Combining flexible conversion options between 32-bit
floating point (FP32) and 16bit floating point (FP16) offers the SoC programmer the possibility to switch the data formats even
within one algorithm.

6
To prepare the extracted data for object based fusion steps, the detections need to be clustered to physical objects, tracked
from one frame to the next, and classified in terms of higher level of automated driving. Kalman Filter computations is a classic
example for tracking objects within a radar frame. Besides the traditional algebra computations, more and more attention is
given to neural network (NN) type of algorithms. NNs are already used with image processing classification tasks, but research
shows promising results for their use in direction of arrival estimation or interference mitigation. The computational building
blocks that NNs and traditional signal processing algorithms have in common are matrix/matrix or matrix /vector operations
that can be mapped efficiently on vector DSPs. Vision processors with NN engines, like the EV7xFS processor, can support the
trend for neural network execution. Vision processors can offer enough flexibility to implement linear algebra computations that
are often considered as the basis for safe decisions, as the algorithms are fully deterministic and reliable. (Nondeterministic
algorithms may return different results each time they are run, making them very difficult to test and debug.)

Automotive Use Case: Battery Management in Electric Vehicles

Another example of a safety-critical automotive system is a battery management system (BMS). Realization of virtual sensors
is achieved through prediction and non-linear models (function approximation) of the battery cell and the related battery stacks.
The current-voltage characteristic of a lithium-ion battery cell is non-linear, temperature dependent, and changing over lifetime.
From overall car perspective, the battery state of charge and state of health (SoH) must be calculated to provide an optimized
electrical driving distance, time efficient charging, and operation inside a safe operating area (SOA). To support energy efficient
automated driving, the battery state is used in the central vehicle controller to plan the related driving and charging strategies.
These driving and charging strategies are updated synchronously to the perception rate of the sensor fusion. Therefore, the
condition of lithium-ion battery must update accordingly. That means, the state of charge and SoH calculations must execute
under a real-time condition of 10ms to be within the fault tolerant time interval for this use case, as shown in Figure 6. The
direction towards deep learning based virtual sensors fulfill the accuracy and real-time requirements of energy efficient
autonomous electric vehicles. Deep learning based virtual sensors algorithms allow modelling of non-linear characteristics with
a significantly higher accuracy than heuristic methods like lookup tables.

Host CPU EV7x

V.I.T
Monitoring

SoC
KF/EKF/NN
Estimation

SoH KF/EKF/NN
Estimation

Mathematical Mathematical
implementation implementation
of NN of EKF/KF

Figure 7: eMobility Algorithm Analysis to Processor Mapping

7
Safety Assessment of the RADAR and eMobility Systems
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 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. The E/E systems in the item and its components either
move the item to a higher level of safety (higher level of system integration), or an ASIL decomposition in the E/E system is required
to divide the ASIL among multiple systems/components (lower level of system integration). 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.

For the electric vehicles and eMobility use case, the battery management systems in L1 systems is typically not higher than ASIL B
where the controllability of the car is entirely with the driver.

For assistant or autonomous driving that requires L2+ and L3 systems, state prediction of the high voltage battery must meet ASIL
C or ASIL D safety levels where the L2+ systems see the fusion of safety between systems. The safety requirements of the radar
system that can control the L2+ vehicle movements is intrinsically related to the safety requirements of the eMobility system where
the battery is required to power the vehicle to make the safety maneuver, as shown in Table 2.

ASIL

Probability of Controllability Resulting ASIL

Use-Case Severity of Future
Exposure of the Driver Level
Forward Collision
E4 C2 S2 to S3 ASIL-B
Warning (FCWS)
Forward Collision
E4 C3 S2 to S3 ASIL-C/D
Warning (FCWS)
eMobility E4 C3 S3 ASIL-D
eMobility E4 C3 S3 ASIL-D

• E4 refers to highest probability of exposure, (almost every drive on average)

• C3 refers to the difficultly level to control the vehicle or Uncontrollable. (Less than 90% of all drivers are usually able or barely able
to avoid a harm)
• S3 refers to the highest level of severity of failure. Life threatening injuries (survival uncertain), fatal injuries
Table 2: Resulting ASIL Levels of FCWS and eMobility Use Cases

EV7xFS Processor IP Overview

DesignWare ARC EV7xFS Embedded Vision Processors for safety (Figure 8) 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
family integrates up to four high-performance 32-bit scalar cores and 512-bit vector DSPs.

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

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 processor is developed as an SEooC. Thus, it is developed independent of a defined context related to a specific item or system
(e.g., vehicle, vehicle sub-system, or OEM-defined item). DesignWare ARC EV7xFS IP is developed based on defined functional
requirements, non-functional requirements, safety requirements, and assumptions of use.

8
 MetaWare EV Development Toolkit

OpenCL™ C, C/C++ OpenCV, OpenVX™ Simulators,

Development Tools Libraries and Runtime NN SDK Virtual Platforms

Synopsys DesignWare EV7xFS Processor

Vector Engine DNN Accelerator
1, 2 or 4 VPU configurations 880 to 3520 MAC configurations

32-bit32-bit512-bit
32-bit 512-bit
512-bit 512-bit Convolutions 2D
32-bit scalar
scalarscalar
vector DSPvector
vector DSP DSP

VPU 4
vector

VPU 3
scalar

VPU 2
DSP

VPU 1
Cache
CacheVCCM VCCM Fully Connected Layers
Cache
Cache VCCM VCCM
VFPU Activations

Coherency Closely Coupled

DMA Memories DMA

Safety Bus

Shared Memory

Sync and Debug Power Mgmt. Trace Safety Features

AXI Interfaces

Licensable

Figure 8: Synopsys DesignWare EV7xFS Embedded Vision Processor

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.

The DesignWare® ARC EV7xFS Processors and the VPX5FS DSP Processors both 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. Both 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.

Balancing PPA + Safety for High Performance Processors

Brute force processor logic lock-step approaches used in many of today’s safety designs do not scale for complex vector DSP
and ANN processors. The impressive energy and area efficiency per function that can be achieved using the vector DSP engine
architecture is immediately halved using the traditional dual-core lock-step approach to achieve safety levels above ASIL B.

As a result, a ground-up approach to vector DSP processor architecture that meets the required ASIL for the use cases outlined in this
white paper requires the latest state-of-the-art safety concepts for complex processors, resulting in an ideal balance of performance,
power, area and safety .

The resulting processor configuration of the EV7xFS family to meet Infineon’s PPA & Safety requirements where silicon area and
power were key product indicators within the Infineon Aurix TC4XX platform resulted in the EV71FS processor configuration with a
single core up-to 512-bit vector DSP pipeline achieving ASIL C level safety mechanisms with ASIL D systematic compliance which
achieve by the integration into the Infineon Aurix3G platform safety concept ASIL D on random hardware faults.

9
State-of-the-Art Safety Concepts using EV7xFS Processor IP
The safety architecture of the EV7xFS can be broadly divided into control plane protection and data plane protection. The distinction
can be rationalized thus: In applications that the EV7xFS will be deployed in, decisions based on data are rarely made on a single
frame, as explained in the radar use case above. Decisions are averaged over multiple frames of sensor data. The control plane,
however, is the correct program sequence execution—this is the most fundamental functional safety requirement (or top-level
safety requirement).

Functional safety on the EV7xFS processor can been implemented with very 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.

Hence, in the EV7xFS processor IP, parts and sub-parts of the component that execute program sequences or implement control flow
are lock-stepped using dual core lockstep schemes. The DesignWare ARC FS series of processors are architected with the ability
to selectively lockstep portions of the design. As the control plane occupied a significantly small portion of the complex vector DSP
processor logic, significant area optimizations can be achieved without compromising the integrity of the SEooC processor.

Designers who are evaluating processor IP for safety should confirm their design requirements are fully met by the IP. The Synopsys
EV7xFS processor IP supports a wide range of stuck-at-fault safety mechanisms, including:

• Software Test Libraries (STLs)—State-of the Art Development

– STL is an external SW-based HW safety mechanism for processors designed to
– detect stuck-at type of hardware faults at runtime
– As per ISO26262:2018, part 5, clause 7.4.3.3, periodic execution is required
– State of the art STL is designed together with HW safety mechanisms to meet ASIL C
– (97% DC) requirements for non-lockstep cores with minimal extra hardware and minimal software overhead
– STL requires Single Point Failure Metric (SPFM), proving process built on top of EDA tools and matching ISO26262:2018 criteria
– STL needs to be certified as per ISO26262 Part 5 requirements as a hardware safety mechanism and Part 6 requirements as
software library
– STLs shall be designed using fault injection to validate coverage
– STLs shall be designed to run at boot and periodically—Hence, run time and memory footprint are extremely critical
• Memory ECC
– ECC schemes shall support Single Error Correct, Double Error Detect (SECDED) schemes with All 0/1 codeword detection
– Protection of address and data line shall be included
• Bus Protection Schemes
– Interface busses to and from the component shall be protected and NoC interfaces shall be plug and play
– ECC schemes on busses shall follow schemes used by memories
• Transient Protection
– Control plane: Dual-core lock-step (DCLS) with time diversity to mitigate common cause failures (CCFs)
– Date plane: Register level detection schemes to meet very high diagnostic coverage and offer low fit rates without requirement
for Dual Interlocked Storage Cell (DICE), Triple Mode Redundancy (TMR) or hardened elements
– Transient protection scheme scalable from QM to ASIL C at boot
• Diagnostic Measures for Latent Fault Detection
– The most common measure is logic BIST (Built-In-Self-Test) (LBIST): LBIST often has long run times due to the serial nature
of scan and LBIST is also destructive and not suitable for mission mode execution (ISO 26262 requires latent checks to be run
once per driving cycle).
– Hardware-based BIST schemes: The EV71FS offers integrated BIST engines that can test safety mechanisms in a few
hundreds of cycles. This scheme is designed to be run during mission mode without consuming significant CPU cycles.
Running latent checks periodically provides a more robust core.

10
 • Safety Bus
– The safety bus concept was introduced and is supported by DesignWare ARC FS processors. This is a low speed sideband
interface that can be connected to a safety island ARC FS processor to periodically monitor the health of the component and to
perform second level diagnosis on errors.

As with most processor IP, functions are either safety relevant or non-safety relevant based on whether they are required in mission
mode. Functions that are non-safety relevant must be isolated to prevent interference during mission mode. For example, a non-
safety relevant debug single-step function can be is invasive due to a permanent hardware error or transient upset if the fault occurs
in mission mode. Hence, functions such as JTAG and trace must be isolated to provide freedom from interference.

The EV71FS processor IP provides hardware-based isolation with checking as a safety mechanism, as shown in Figure 9.

Software Test Libraries STLs

• ASIL-C Diagnostic coverage
Synopsys DesignWare EV7x Processor • Mission Mode Stuck at
fault detection
EV71
ASIL-B Scalar Core
• HS Class Scalar core always
in lock-step Scalar DCLS
• Allows localized ASIL-D
Safety decision processing

Safety Monitor
Vector Unit Data-Plane
With EDC Protection

Data-Plane EDC Protection

(ASIL-B)
• Protects against transient
errors in the pipeline
Cluster Lockstep
• Configurable lockstep Cluster Lockstep
cluster logic to optimize
Software BIST mission
mode cycles

AXI Interfaces
Safety Bus

Figure 9: Hardware-based isolation with checking as a safety mechanism on the EV71FS

Depending on the processor IP use case, e.g., radar pre- or post- processing or eMobility, the EV71FS processor can be configured
and programmed to the specific ASIL level and fault type protection, enabling the required safety mechanisms to the use case of the
safety system.

For the radar pre-processing example above, the safety system may not require transient fault protection within the data plane. When
the assumption is that the vector DSP data plane incurs a “soft reset” per radar frame, the soft reset reduces/removes the impact of a
transient fault in the data plane causing a detrimental failure in the system.

However, a transient fault is always considered critical in the control plane of the vector DSP. For example, if the scalar processor,
vector register file, program counter, and other state relevant pipeline uses dual-core lockstep, a bit flip in the logic could cause
an erroneous instruction to execute. The bit flip could change the application code execution leading to a detrimental failure
in the system.

For the eMobility use case executing Kalman Filter algorithms, the need for both stuck-at and transient fault protection within both
the control plane and the data plane is critical and requires all safety mechanisms of the ASIL C EV71FS processor IP to be enabled
to achieve the Infineon Aurix3G platform safety concept up to ASIL D on random hardware faults.

11
Summary
In conclusion, a state-of-the-art high performant 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. Synopsys DesignWare ARC EV7xFS processor IP and VPX5FS DSP IP
cores meet these demands for the next generation automotive designs.

References
• On a Formal Model of Safe and Scalable Self-driving Cars—Mobileye, 2017
• https://www.traffictechnologytoday.com/features/the-revolution-automotive-radar-is-having-in-mobility.html
• https://www.ti.com/lit/wp/sszy019a/sszy019a.pdf?ts=1602267103486&ref_url=https%253A%252F%252Fwww.ti.com%252Fsolu
tion%252Fautomotive-long-range-radar
• https://www.ti.com/lit/wp/spry312/spry312.pdf?ts=1602267754543&ref_url=https%253A%252F%252Fwww.google.com%252F
• Automotive Radar—An Overview on State-of-the-Art Technology https://www.youtube.com/watch?v=P-C6_4ceY64
• https://mtt-tcc.org/
• https://www.am-online.com/news/latest-news/2020/12/16/euro-ncap-and-thatcham-call-for-standard-adas-on-vans
• https://www.autocar.co.uk/car-news/new-cars/new-assisted-driving-grading-aims-reduce-safety-tech-confusion
• White paper: Driving Change—The Importance of ASIL Compliant Certified IP in Automotive Systems
• https://www.design-reuse.com/articles/41357/configurable-microprocessor-for-life-essential-devices.html

©2021 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks is available
at synopsys.com/copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners.
09/14/21.CS728354189-Infineon on ARC EV7x for Automotive-wp.
Pub: July. 2021