Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Easing Smart Automotive Design and Certification with High-Performance Processors for Safety-Critical Applications
By: Michael Thompson, Sr. Product Marketing Manager
We are not far from the point where our cars will be better drivers than we are. Automotive capabilities for advanced driver assist systems (ADAS) are evolving rapidly because of the potential that they offer to enhance safety and simplify the driving process. These capabilities are being enabled by the growing volume and complexity of the electronics in cars, and advances in high-performance microprocessors. As we refine processor architectures and move down the process curve, performance capabilities are increasing rapidly, enabling the creation of sophisticated systems that can analyze conditions in and around the vehicle and make accurate decisions based on those conditions. Ensuring the proper operation of ADAS systems is crucial to the safety of the occupants in the car, and to anyone else in the vicinity, which is why the ISO 26262 functional safety standard for electrical and/or electronic systems in automobiles was developed. The ISO 26262 standard, when applied to the microprocessors and systems in cars, can control or avoid systemic failures and control or mitigate random hardware failures and their effects.
ADAS: A Requirement for the Changing Automotive Market
While ADAS is being developed to enhance and automate vehicle systems for safety and driver convenience, it will undoubtedly lead to autonomous vehicles. Today, ADAS systems alert drivers to potential problems (for example blind spot warning) and taking over control of the vehicle in some situations (collision avoidance). As these systems automate tasks, they are indirectly reducing the stress that drivers face, which is being favorably received by drivers. Adaptive cruise control and lane keeping assist are available in cars today to reduce driver stress. As these capabilities advance, they will take over more and more of the operation of cars until the driver is no longer needed. The availability of fully autonomous vehicles is not far away, and this will mean the deployment of thousands of processors in each car within just a few years.
Automotive ADAS Design Challenges
Electronics in cars today account for 35% of the cost to build the vehicle. By 2030 this will rise to 50%, and an average car will have more than 300 million lines of code running in its various processors. The increase in electronics will also enable the vehicle to have more, or even autonomous, control over the driving function, making the safety of the occupants in the vehicle dependent on the proper functioning of the electronic systems. The increasing levels of electronics for functional safety need to be balanced against cost.
To this end, the ISO 26262 functional safety standard for electronic systems in cars was established in 2011. The standard defines four Automotive Safety Integrity Levels (ASILs) based on the hazard analysis and risk assessment that a system in a vehicle exposes the occupants to in the event it malfunctions. An electronic steering system would carry an ASIL D classification (the highest level) while a rear-view camera might carry an ASIL A classification (the lowest level). If the steering system fails, the results for the occupants or anyone near the vehicle could be catastrophic, while the failure of a rear-view camera would be annoying but not life threatening. The goal of ASIL classification is to minimize susceptibility to random hardware failures by defining functional requirements and then taking the necessary design measures, including fault injection and systemic analysis and metrics reporting during the design process, to prevent them or minimize their impact if they occur. Implementing systems that meet the required ASIL is not without cost and, as more electronic systems in cars take over more critical operations, the costs due to functional safety will increase.
Support Required for ASIL Classifications
The goal of implementing ISO 26262 is to analyze the risk early in development, determine the appropriate safety level, establish how this level of safety will be met, and determine how it will be tested throughout the process. Devices developed under the ISO standard must meet specific goals for testing the hardware and the safety mechanisms implemented in that hardware, as well as in the software that run on it. The goals and ASIL certification level established early in the development process lead to the appropriate safety requirements and levels of testing. The level of ASIL support required can add significant cost to implement the product in terms of design time, silicon area and testing. Fault injection testing is recommended for ASIL A and B, and is highly recommended for ASIL C and D. For ASIL B, single point fault detection coverage of 90% is required and multi-point latent fault coverage of 60%. For ASIL-D single point coverage of 99% and multi-point coverage of 90% is required. Achieving the higher coverages needed for ASIL D support requires more hardware and test circuitry. For example, using a parity bit per word will support 90% coverage for the memories while full error detection and correction is needed to achieve 99%. Timeout monitoring, a watchdog, or information redundancy can be used to reach 90% coverage, but all three will be needed to reach 99%.
ASIL D Implementation for Critical Systems
As systems in automobiles become more important for functional safety, they require higher levels of ASIL certification. Semiconductor and system developers can ease their certification efforts by using processor IP (and other IP in their design) that is either ASIL certified or ASIL ready for the level of ASIL certification that they need to meet for their product. An ASIL D implementation using ARC? HS processors that was used in a vision application is shown in Figure 1. An HS38x4 quad-core processor configuration was used to meet the application¡¯s very high-performance requirement. To meet the ASIL D coverage requirements, the HS38x4 was lock-stepped with an HS38x4 shadow core. This pair was connected via a safety monitor to a safety manager that is outside the HS38x4 core. The safety manager monitors the core and other processors on the device and reports any problems to the host processor. The HS38x4 also included error injection hardware for safety testing.
Figure 1: ARC HS quad-core ASIL D Ready implementation
Error correction support is included for all the internal memories: L1 cache, L2 cache, close coupled memory, and the MMU Joint Translation Lookaside Buffers (JTLBs). The error correcting code (ECC) also protects the interface buses to the rest of the SoC. The ECC capability can detect and correct single-bit errors, and can detect a double-bit error. A double-bit error that can¡¯t be corrected is handled by system exception, which can lead to a controlled condition within the system. The ECC logic is non-intrusive to the processor pipeline, so performance is maintained.
The lockstep monitoring on the HS38x4 is implemented with a shadow secondary core that is used for comparison to the main core. The operation of the shadow core can be delayed from the main core to avoid duplicate common-cause facilities. The safety monitor that is connected to both the main and shadow cores continuously runs diagnostics with compare logic to verify functionality and report errors to the system. The implementation supports all of the standard features of a single core, including debugger access to the main core and verification of the access in the shadow core.
The safety manager that is outside of the HS38x4 core (shown to the left of the core in Figure 1) gets input from the safety monitor in the HS processor and from other sources in the SoC and reports these to the host processor. The safety manager is implemented with dual-core lockstep processor to protect against problem conditions in the manager. It also has full ECC and its own watchdog timer. The safety manager controls the HS38x4 cluster ¡°safety¡± bring-up and the boot-time LBIST and MBIST control. The safety manager can be implemented with either an ARC HS or ARC EM processor, depending on the speed that it needs to be clocked.
Adapting IP Processor Designs for ISO 26262
ASIL capabilities were added to the HS processor during the initial development of the processor, as shown in Figure 2. An ISO 26262 safety plan was developed at the time that the core specification was written. The design team established the hardware safety requirements and safety goals, and designed the required hardware safety features into the HS processor RTL. The safety features are fully documented and included in the safety documentation for the core. Full ISO 26262 support for the processor requires module design verification and validation with fault injection/coverage analysis resulting in an FMEDA report that is also included with the safety documentation.
Figure 2: Adapting IP Processor Designs to ISO 26262
The HS processor needs to be programmed by the user for their application. This can be done using the MetaWare Development Toolkit that includes a C/C++ compiler, a debugger and an instruction set simulator. The MetaWare compiler is ASIL D Ready certified, which simplifies the development of ISO 26262 compliant code. The compiler includes a MetaWare Safety Manual and MetaWare Safety Guide with the software tool creation evaluation report and software tool qualification report.
Adding these capabilities (lockstep, ECC, watchdog timer, safety monitor) into a processor would be difficult for an IP user. They would need full access to and an expert understanding of the RTL to add the required hardware features. Beyond this, generating an FMEDA report would be close to impossible, and certifying the compiler would be impossible. As such, when semiconductor designers license processor (and other IP) for an SoC that will require ISO 26262 certification, they need to make sure that they can get all of the hardware support, documentation and tool support that they will need for certification or they may find that their product can¡¯t be certified.
Summary
Automotive capabilities for advanced driver assist systems are advancing rapidly because of the potential they offer to enhance safety and simplify the driving process. ADAS systems are being enabled by advanced high-performance processors like Synopsys¡¯ ARC HS family, which supports the ISO 26262 standard, and can be used to obtain the appropriate level of ISO certification for the systems into which they are built. By offering a range of ISO 26262 certified and certifiable IP and tools, Synopsys is making it easier for SoC designers and automotive OEMs to implement the full range of automotive products needed for advanced ADAS and autonomous applications.