How functional safety verification helps us build safer cars
All chip designers set out to develop chips without bugs, but the stakes are much higher for those working on automotive designs. A cell phone crash may cause a reboot, but a bug in an advanced driver assistance system, such as lane keeping, may cause another kind of crash – with much more serious consequences.
Although the functional verification requirements for automotive devices may be similar to those of mobile SoCs, the functional safety requirements are quite different – and much more critical.
Both functional verification and functional safety verification strategies set out to find systematic faults, caused, for example, by design bugs, so that they can be fixed before the devices are shipped. However, for random faults the goal is quite different – in functional safety verification the goal is to check that a device’s safety mechanisms deal with such faults without allowing hazardous situations to develop.
Automotive safety verification must work with functional verification, and requires new perspectives and approaches. Even if a feature has been implemented perfectly and thoroughly verified to meet its functional specification this does not guarantee that it is safe, because functional verification does not take faulty behavior into account.
Figure 1 IP-level safety verification (Source: Synopsys)
Have a look at Figure 1. A typical safety requirement for this IP block could be that “Port Y1 should never take on value A as long as port Y2 is going through sequence B”. The design logic may be implemented so that this situation is impossible, and any design bugs are found and fixed during functional verification. From a safety verification perspective, however, imagine that a hardware failure causes a stuck-at or random fault to appear in the logic cone of port Y1, causing it to take on value A and so create a hazard.
Designers can’t model these scenarios using traditional functional verification strategies, but must treat them as injected faults to be explored through a functional safety verification strategy. The design’s behaviors must also be verified to check it can diagnose and recover from such scenarios, in ways described in the safety requirements for the block.
Functional safety verification, therefore, is about testing what happens when external events force a design into illegal or unexpected states. Designs may be expected to continue working without a loss of functionality, or with reduced functionality, or to send out diagnostics information. This kind of fault-simulation methodology can be implemented using Synopsys’ Z01X fault simulation solutions, which can model a broad range of relevant faults and evaluate the effectiveness of the design’s safety mechanisms to manage random hardware failures.
This type of ‘what if’ testing is powerful, but faces a particular challenge because it is hard to know how much testing is enough – there’s always another scenario that could be checked. Fortunately, the ISO standards body has applied some intellectual rigour to this issue in its development of the ISO 26262 standard. It defines frameworks for an automotive safety verification methodology based on this type of fault simulation, to assess and eliminate unreasonable risk caused by such faults occurring in the design.
ISO 26262 is an adaptation of IEC61058, which sets out to define requirements and processes with which to verify the safety of electrical and/or electronic systems within automotive systems. ISO 26262 narrows its scope, defining the following issues:
- Automotive safety lifecycles, including management, development, production, operation, service and decommissioning
- Automotive-specific approaches to analysing risk and determining automotive safety integrity levels (ASILs) for the elements of the system
- An ASIL-based safety requirements specification to avoid unreasonable residual risk
- The necessary validation and confirmation measures
- Requirements for relationships with suppliers
This blog was inspired by an article authored by Brian Davenport, Prapanna Tiwari and David Hsu.
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 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 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.
Company infoSynopsys Corporate Headquarters 690 East Middlefield Road Mountain View, CA 94043 (650) 584-5000 (800) 541-7737 www.synopsys.com
Sign up for more
If this was useful to you, why not make sure you’re getting our regular digests of Tech Design Forum’s technical content? Register and receive our newsletter free.