Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Choosing an Embedded Processor for Safety-Critical Automotive Applications
By: Angela Raucher, Product Line Manager, Synopsys
The automotive market has evolved at a much faster rate in recent years. Hybrid and electric vehicles were on the drawing board for a long time, but now they are suddenly commonplace, and the race to introduce autonomous vehicles has heated up. When it comes to safety, components that now assist the driver may soon take control of the car and make decisions for the driver. Semiconductor manufacturers targeting this market must also adapt and accelerate their roadmap, acknowledging this rate of change with a good deal of future-proofing.
Developing system-on-chips (SoCs) for safety-critical automotive applications requires due diligence at every stage, from the selection and development of IP, to verification, to the creation of documentation. Functional safety standards, especially ISO 26262, assist project teams with this challenge. When selecting an embedded processor for a safety-critical design, it is important to know what aspects of the standard apply and to what extent the processor helps meet those requirements.
ISO 26262 Standard for Automotive Safety
ISO 26262 is adapted from the IEC 61508 functional safety standard and tailored to automotive electric and electronic systems. It defines functional safety and recommends a safety-aware approach to hardware verification for automotive equipment.
The standard provides requirements for validating and confirming that a sufficient level of safety is achieved. Annex A of ISO 26262-10:2012 defines the Automotive Safety Integrity Level (ASIL), an abstract classification of the safety risk in automotive systems. ASIL defines four safety integrity levels, A (the lowest integrity requirements on the product) through D (the highest integrity requirements on the product).
Some applications, such as braking and steering, clearly require ASIL D classification. However, other applications, like camera systems, may have been ASIL B in the past because they offer driver assistance, but in the time of autonomous vehicles may be reclassified as ASIL D. If you choose a processor that is able to meet ASIL D requirements, it will meet all of the standards, supporting the broadest target application space in the automotive market, and future-proofing the design.
Processor Requirements for ISO 26262 Compliance
Processors designed for ISO 26262 compliance incorporate specific features that detect and correct both random and systematic faults. If the features are not implemented by the processor IP vendor, they can be added at the system level. However, this will add to the design, verification, and documentation burden of the SoC vendor and can slow down the ISO 26262 certification process.
Key ASIL processor requirements:
- Error detection and correction logic
- Error correcting code (ECC): Detects single-bit and double-bit data and address errors with the option to correct
- Parity: Detects single-bit errors
- Hardware stack protection: Checks overflow and underflow of reserved stack space
- Code protection: Hardware support to block read and write to code space
- Programmable watchdog timer: Safety-related version of timer used to detect and recover from a deadlock situation
- Lock-step interface: Ability to create a redundant core with synchronization capability
- Memory protection unit: Defines variable regions and assigns access attributes. The different protection schemes may be combined to achieve several levels of protection against malicious or misbehaving code in critical applications
These features are all available for Synopsys¡¯ DesignWare? ARC? EM processors when configured for an automotive safety application.
Accelerating Safety-Critical IP Development
When selecting an embedded processor, it is important to know if it is verified to meet automotive safety requirements. Verifying safety-critical systems takes more time and expertise than consumer-grade IP because verification engineers have to test the fault tolerance of the design by injecting random faults, as well as validating the design functionality (Table 1). Annex A of ISO 26262 also provides guidelines and a list of examples of how to verify microcontrollers.
Table 1: Verification requirements for ISO 26262 processors
The verification team must measure both functional coverage and code coverage to verify the safety enhancement features. This requires the use of functional qualification tools within the verification flow, and the use of a test bench that can implement random faults. Using stuck-at fault tests can assist in determining the failure mode and diagnostic coverage. This information contributes to the failure mode, effects and diagnostic analysis (FMEDA) report, which is necessary to obtain ASIL A to D certification.
While adopting safety-aware design and verification flows is fundamental to complying with ISO 26262, the standard also sets certain expectations for a safety culture within the organization. For example, the company should define functional safety as a corporate objective and put company-specific policies and processes in place, such as how it intends to continuously improve upon its current practices.
Tools and Methodologies
Synopsys has always prioritized high quality and this has made it easier to create a safety culture with a rigorous design and verification methodology. Synopsys also has in-house functional qualification tools, such as Testbench Quality Assurance, which enhances functional verification by objectively measuring the overall effectiveness of the verification environment and prevents function bugs and other RTL issues from going undetected in the design. Testbench Quality Assurance also enables the insertion of random faults and provides the ability to activate, propagate and detect faults to significantly reduce the time to certify for ISO 26262. Moreover, Synopsys recently acquired WinterLogic, who is the technology leader in fault simulation for automotive safety and security environments.
To certify an SoC, the verification planning, methodology, and results must also be well documented in alignment with ISO 26262 standards, and delivered with other documentation such as the safety plan, safety analysis, and FMEDA reports. An SoC developer should expect the processor IP supplier to deliver the same comprehensive set of documents that are relevant to the processor. Otherwise, it could take months of effort to create the required materials for the processor portion of the design.
By using a processor that is certified ASIL D ready, you can accelerate your SoC level certification by ensuring in advance that the IP provider has met the stringent ISO 26262 standards for hardware, verification, and documentation.
ARC EM processors with Safety Enhancement Package (SEP) are certified by SGS T?V Saar, a respected independent ISO 26262 certification body. ARC EM processors are based on the ARCv2 instruction set architecture (ISA) and targeted at automotive safety applications requiring ultra-low power consumption and area efficiency (Figure 1). Designers can configure the core to implement instances that offer the optimum combination of performance, silicon area, power consumption and code density for their specific application. For safety, ARC cores can also be configured and extended to support the safety level required by the application, allowing the developer to make the correct trade-offs on efficiency, performance, and safety for the expected life cycle of the product. The cores are supported by the MetaWare Toolkit for Safety with ASIL D ready certified compiler to streamline development of ISO 26262 compliant software.
Figure 1: ARC EM processor with safety enhancement package
For more information, visit /dw/ipdir.php?ds=arc-safety-options