The challenges of automotive functional safety verification
Engineers developing an SoC for the automotive market have to show that it doesn’t have functional safety issues – even if the SoC enters an unexpected state. Here’s how to tackle the safety verification task.
Developing SoCs for the automotive market demands a different verification approach to that used in markets such as consumer products. Whereas it may be enough to show that a consumer product doesn’t have any functional bugs, an automotive design also has to show it doesn’t have functional safety issues – even if the SoC enters an unexpected state.
A complete functional safety verification flow for automotive SoCs must ensure zero design bugs, using coverage-driven functional verification, and zero safety risks, using a functional safety verification strategy that complies with the ISO 26262 automotive safety standard.
Figure 1 A functional safety verification flow (Source: Synopsys)
An automotive verification flow therefore needs to combine a functional verification flow, which starts with a verification plan that specifies how the functional requirements for the design are met, and a safety verification plan, which describes the functional safety requirements of the design and how these are to be met.
Figure 2 shows the key safety verification tasks (in orange) that must be performed alongside the standard functional verification flow (in purple). The same safety verification processes must also be applied to all the IP blocks used in an automotive SoC, to ensure that they meet their assigned automotive safety integrity level (ASIL).
Figure 2 Functional (purple) and safety verification (orange) flows must proceed alongside each other
For consistency, the design and verification tools that make up an automotive functional safety verification flow must also comply with the desired safety level, so that they do not introduce their own risks. ISO 26262 allows tools to be used in such flows based on:
- Confidence from use
- Evaluation of the development process
- Validation of the software tool
- Development in compliance with safety standard
IP verification
IP verification needs to take into account the fact that the same IP block could be used in multiple target environments with varying safety goals, perhaps with different ASIL levels. The issue is further complicated when the IP is configurable.
A generalized approach to safety verification for IP is as follows:
- Assume that all inputs of the IP have valid values
- Identify output ports which are safety critical for the target application
- Verify that a fault in the cone of logic of these safety-critical outputs is managed as desired by the targeted application
- The way a fault is managed depends on the needs of the target application. Options include:
- – Detect and report the fault and the related diagnostics information
- – Recover from the fault before sending data outside
- – Engage in a handshake with the host to manage/mitigate the fault
- Produce a Failure Modes, Effects and Diagnostic Analysis (FMEDA) report and Safety Manual as part of the IP deliverable
IP developers who want to target the automotive market must make hypotheses about the safety requirements that will apply to their design in that context. This is known as developing a Safety Element out of Context (SEooC), and the ISO 26262 standard has specific requirements for assessing the quality of the IP’s safety mechanisms. Alongside the traditional IP deliverables, developers will also have to provide an FMEDA report and safety manual that show the steps taken to ensure the IP’s safety.
Traceability
The traceability requirement for functional safety adds another dimension to automotive systems verification. Traceability requirements mean that the expected behaviour of each subsystem has to be tracked, as does its verification, and how any changes to the design change the way it behaves –throughout the design hierarchy for all sub-blocks.
Traceability in verification shows that all safety requirements have been adequately tested and, where necessary, appropriate fixes have been made. As well as being able to trace safety requirements to individual test results and coverage goals, the verification team must also be able to map multiple regression tests to appropriate safety goal pass/fail conditions. All this evidence has to be collated in the FMEDA report necessary for ISO 26262 compliance.
Fault modelling, injection and simulation
Fault injection (Figure 3) enables verification teams to save time and effort when testing their designs’ safety requirements.
Figure 3 Fault modeling and injection can save time and effort (Source: Synopsys)
Traditional functional verification flows aim to ensure that the functional behavior of the RTL matches its specification and that the design will work correctly, assuming that no faults occur.
The functional safety verification process for automotive SoCs must also ensure that the chip functions correctly even if errors occur in real time – for example, if an alpha-particle strike flips a bit in a key register in an advanced driver assist system. Modeling such faults helps design teams understand their impact, and how the system can recover from them.
The ISO 26262 standard discusses the following types of fault: random, single point, multi-point, stuck at 0 or 1, stuck open, open or high-impedance output, shorts, transient and transition. The standard leaves a lot of the choice of faults to be applied to the functional safety engineer, who needs to have a deep understanding of the design’s functionality and its related safety requirements.
Experienced automotive teams become skilled at judging which areas of a design are most critical for the system, in a way that becomes part of their safety culture. Teams achieve safe designs by ensuring that every component, chip and change request supports the overall design goals and safety standards. A verification solution that injects faults with an awareness of the design’s safety requirements produces results that are easier to assimilate, and so should speed up functional safety verification.
Design for safety
Another important aspect of ISO 26262 is its concept of achieving safety through holistic thinking, rather than by working through checklists. Taking this approach may require a cultural shift in the organization with, for example, training in coding styles and guidelines that support safety throughout the design process. It also requires a change in the management of the verification process, with clear definitions of roles and dependencies throughout the organization. ISO 26262 dedicates a chapter to the standard’s expectations of the verification management process for automotive SoCs.
Design and verification teams should do everything they can to avoid introducing safety issues, for example by adopting early-stage coding guidelines that help avoid broad mistakes and make the RTL easier to work with in a traceable safety verification flow. Designers should also apply fault modeling early in the verification flow to identify potential bugs early, so avoiding costly debug later in the design cycle.
Emulation
A lot of functional safety management is handled in software, which plays a key part in implementing features that contribute to automotive safety such as image processing, threat detection and prioritization, risk mitigation, component redundancy management, and diagnostics.
Emulation can help verification teams implement functional safety verification by making it possible to bring up software on a design more quickly than is otherwise possible, to check that the software and the evolving hardware are working together correctly to implement the functional safety management protocols.
Without emulation, even if functional safety management verification is completed for the hardware, there is no guarantee that it will work correctly with its software in a car. Emulation makes it possible to test the software response to faults that may occur in hardware much earlier in the design process.
Synopsys automotive safety verification solution
Synopsys offers tools and flows that address the key challenges of functional safety verification for automotive SoCs and IP.
Figure 4 Synopsys automotive safety and functional verification tools (* in progress) (Source: Synopsys)
Synopsys’ VCS simulator, Certitude testbench quality analysis, and Verdi coverage, planning and debug products, together form an industry-proven and SGS-TüV Saar ASIL D-certified foundation for automotive functional verification.
Synopsys also offers the Z01X fault-simulation solution to identify and manage random faults and so assess the safety mechanisms of automotive SoCs and IP. This is a key requirement for meeting ISO 26262 ASIL C and D compliance requirements.
Verdi can be used for verification planning and coverage, so design teams can work with third-party requirements-management systems, tracing safety verification issues down to individual features and test cases for specific sub-blocks. It also enables users to create custom safety metrics that can be tracked across the whole design hierarchies. These can also be merged into debug views with the functional verification planning and coverage metrics.
Certitude handles RTL fault modelling and insertion, and is integrated with VCS. Certitude provides detailed information on the ability of the testbench or design circuitry to detect and react to systematic faults or inserted bugs. It also enables the calculation of key metrics such as diagnostic coverage, and documentation of how these mechanisms are verified.
Authors
Brian Davenport
Brian Davenport is a staff engineer in Synopsys’ Verification Group focusing on automotive functional safety solutions and technologies. He has 20 years of experience in the EDA industry, with over 12 years’ experience in fault injection as an applications engineer. Davenport was a founder of WinterLogic and served as the product manager for functional safety and security verification, with responsibility for adoption of the Z01X fault simulator into the automotive functional safety market. Davenport is also a member of the US Technical Advisory Group to the ISO26262 TC22/SC32/WG8 Functional Safety Working Group.
Prapanna Tiwari
Prapanna Tiwari is a senior product marketing manager in Synopsys for verification solutions. Tiwari has 15 years’ experience in the semiconductor and EDA industries in the areas of electromigration/IR drop, and low power, formal, and automotive safety verification. In addition to his current role in marketing, he has also worked in R&D and corporate applications engineering. Tiwari received his Bachelors in Computer Science from NITK (India) and an MBA from Wharton.
David Hsu
David Hsu is a director of product marketing in Synopsys’ Verification Group responsible for simulation, coverage, and automotive functional safety verification products. Hsu has a broad background in EDA and semiconductor marketing, including tools and solutions spanning implementation, verification and manufacturing test flows.
