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 \u2013 with much more serious consequences.<\/p>\n
Although the functional verification requirements for automotive devices may be similar to those of mobile SoCs, the functional safety<\/em> requirements are quite different \u2013 and much more critical.<\/p>\n Both functional verification and functional safety verification strategies set out to find systematic<\/em> faults, caused, for example, by design bugs, so that they can be fixed before the devices are shipped. However, for random<\/em> faults the goal is quite different \u2013 in functional safety verification the goal is to check that a device\u2019s safety mechanisms deal with such faults without allowing hazardous situations to develop.<\/p>\n 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.<\/p>\nNo URL for image<\/em>\n Have a look at Figure 1. A typical safety requirement for this IP block could be that \u201cPort Y1 should never take on value A as long as port Y2 is going through sequence B\u201d. 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.<\/p>\n Designers can\u2019t 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\u2019s 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.<\/p>\n 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\u2019 Z01X fault simulation<\/a> solutions, which can model a broad range of relevant faults and evaluate the effectiveness of the design\u2019s safety mechanisms to manage random hardware failures.<\/p>\n This type of \u2018what if\u2019 testing is powerful, but faces a particular challenge because it is hard to know how much testing is enough \u2013 there\u2019s 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.<\/p>\n ISO 26262 is an adaptation of IEC61058<\/a>, 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:<\/p>\n This blog was inspired by an\u00a0article authored by Brian Davenport, Prapanna Tiwari and David Hsu.<\/p>\n Brian Davenport<\/strong><\/p>\n Brian Davenport is a staff engineer in Synopsys\u2019 Verification Group focusing on automotive functional safety solutions and technologies. He has 20 years of experience in the EDA industry, with over 12 years\u2019 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<\/a>.<\/p>\n Prapanna Tiwari<\/strong><\/p>\n Prapanna Tiwari is a senior product marketing manager in Synopsys for verification solutions. Tiwari has 15 years\u2019 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.<\/p>\n David Hsu<\/strong><\/p>\n David Hsu is a director of product marketing in Synopsys\u2019 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.<\/p>\n\n
Authors<\/b><\/h2>\n
Company info<\/b><\/h2>\nSynopsys Corporate Headquarters<\/i><\/address>\n 690 East Middlefield Road<\/i><\/address>\nMountain View, CA 94043<\/i><\/address>\n(650) 584-5000<\/i><\/address>\n(800) 541-7737<\/i><\/address>\n\u00a0<\/i>www.synopsys.com<\/a><\/i>\u00a0<\/address>\n
Sign up for more<\/b><\/h2>\n