Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • UVMF - One Bite at a Time
      • Introduction to UVM
      • Basic UVM
      • UVM Debug
      • Advanced UVM
      • UVM Connect
    • Featured Courses

      • Portable Stimulus Basics
      • Introduction to DO-254
      • SystemVerilog OOP for UVM Verification
      • Power Aware Verification
      • Power Aware CDC Verification
      • Assertion-Based Verification
      • Metrics in SoC Verification
    • Additional Courses

      • Clock-Domain Crossing Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal Coverage
      • Formal-Based Technology: Automatic Formal Solutions
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizon - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • MTV - Austin, TX | 12/9
      • Events Calendar
    • On Demand Seminars

      • UVM 1800.2 & Updated UVM Cookbook
      • Debug
      • FPGA Verification
      • All On-Demand Seminars
    • Recording Archive

      • DAC 2019 Session Recordings
      • User2User Silicon Valley 2019
      • Portable Stimulus from IP to SoC
      • Wilson Research Group - 2018 Results
      • All Recordings
    • Mentor Training Center

      • SystemVerilog for Verification
      • SystemVerilog UVM
      • SystemVerilog UVM Advanced
      • Instructor-led Training
    • Mentor Learning Center

      • SystemVerilog Advanced OOP
      • UVM Transactions and Sequences
      • UVM Monitors and Agents
      • Functional Verification Library
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - December 2019
      • Verification Horizons - June 2019
      • Verification Horizons - February 2019
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa® & ModelSim®
      • SystemVerilog
      • Functional Verification Library
  • Home /
  • Topics /
  • Functional Safety /
  • Getting ISO 26262 Faults Straight

Getting ISO 26262 Faults Straight

by Avidan Efody, Verification Architect, Mentor Graphics.

(If you’re looking for an executive summary of ISO 26262 random hardware fault analysis, check out the following blog post.)


ISO 26262 for automotive requires that the impacts of random hardware faults on hardware used in vehicles are thoroughly analyzed and the risk of safety critical failures due to such faults is shown to be below a certain threshold. For most hardware design and verification engineers this requirement is a passage into a strange world with which they’re not familiar: a world where logic could get corrupted anywhere and in any time, where results are probabilistic rather than absolute, and where common analysis techniques such as checkers and coverage need to be re-thought to be effective. In this article, the first of a series, we will explain where random hardware faults are coming from, how the probability for their occurrence is calculated, and how ISO 26262 requires that they’re classified. In upcoming posts we will look at how various advanced verification techniques could refine the impact analysis process and help in calculating ISO 26262 metrics to assess the efficiency of various safety mechanisms implemented in hardware.

Random hardware faults – i.e. individual gates going nuts and driving a value they’re not supposed to drive – are practically expected in every electronic device, at a very low probability. When we talk about mobile or home entertainment devices, we could well live with their impact. But when we talk about safety critical designs, such as automotive, aerospace or medical, we could well die from it. That is why hardware design and verification engineers working on applications for these domains find themselves having to prove not only correct functionality of normally operating designs, but also safe functionality of designs plagued by random faults. Don’t envy them.

There are many sources for random hardware faults, from production process to extreme operating conditions, electronic interference and cosmic radiation. There are even some bad people trying to trigger them intentionally in the hope of getting secret keys. Each of those sources comes with a more or less accurate “fault model” which describes how faults from that source should be modeled at RTL or, more often, gate level and below. For example, electronic interference faults are modeled as two signals assuming the same value (referred to as “bridging”), and should be applied only to high frequency signals that lie within close proximity to one another after place and route. Production faults are modeled as gates getting stuck-at a given value forever and faults caused by cosmic radiation or due voltage noise are often modeled as random gates getting a wrong value for a cycle (referred to as soft faults or single event upset/transient), or at much lower probability, getting stuck at a wrong value forever. Since some of these sources produce faults that behave in a similar way, there is usually no need to test all of them. At RTL or gate level, most of the relevant faults can be modeled as gates assuming the wrong value for a cycle or getting stuck at a given value forever.

The various fault sources usually also come with some numbers that describe their probability of showing up under given conditions. The number of faults one can expect within a given chip depends obviously on the number of gates in the design, but also on other parameters such as production process and packaging, which might make some gates more vulnerable than others. This number can be determined by using scientific measurement documents such as IEC 62380 for stuck-at errors and JESD89 for soft errors, as detailed in section 10-A.3.4 of the ISO 26262 specification. Some of the numbers are contested so choosing the right source is important.

In order to determine the probability of a fault causing a safety critical failure ISO 26262 requires that they are analyzed and classified into six different bins: “safe”, “single point”, “residual”, “detected multi-point”, “perceived multi-point” and “latent multi-point”. I’ll Keep the joy of some of the more gory details of this classification for future posts in the series, and try to explain each of those classifications as concisely as possible for now. “Safe” faults are faults that can’t impact safety critical logic either because they luck physical connection, or they’re masked by some logic along the way. “single point faults” are faults that can get to a safety critical logic, and when they get to it, there isn’t any safety mechanism such as CRC, to detect or correct them. For ASIL C/D such faults are out of the question. “Residual” faults happen in an area that is buffered from safety critical functionality by some safety mechanism, but are still exactly like single point faults because, and this is where it starts to get funny, this safety mechanism can’t catch them. Cynics might see this category as a tax break for ASIL C/D designs, allowing them to have some “single point faults” without calling them that. Multi-point faults get the prize for the most confusing name, as they are actually faults that are detected or corrected by the safety mechanism. The reason why ISO prefers to look at the half glass empty and call them multi-point-faults is because in order for them to break anything, they would need another fault in the safety mechanism itself. “Detected multi-point” faults are the ones that are corrected & detected by the safety mechanism, “latent multi-point” faults are the ones that are corrected but there’s no indication they ever existed, and “perceived multi-point” faults are faults that are not detected, but have some noticeable impact on the driving experience. This category usually doesn’t apply to digital IC, as it is very unlikely that anything happening in a digital IC in the car will have a direct impact on the driver.

Determining the probability of a given fault to be of a specific type is usually done by taking a large enough sample of faults and measuring their distribution between the various types. Abstracting from details yet again, the end result of this process would be concrete numbers for “safe fault probability”, “single point fault probability”, “residual fault probability”, etc. With these numbers it is now possible to go ahead to the next step and calculate a few ISO 26262 metrics such as PMHF, SPFM, LFM and Diagnostic Coverage, the formulas for which are given in section 5 of the specification. The higher your ASIL, the higher you need to score on any of those metrics. If you're above target then the smiling face at the bottom of the diagram below is most probably yours.

What happens if your hardware doesn’t score well enough for your ASIL? Well, there are two options you can take. The obvious one is to try to modify your hardware so that more faults fall into the good “safe” or “detected” bins. This could be done either by better decoupling non-safety-critical logic from safety-critical one, or by improving/adding safety mechanisms. We can call this option the “expensive” one, as it will have a significant cost not only in re-design, re-verification and time but also in gate count – as a rule of thumb, the stronger the safety mechanism, the more gates it will take. The less obvious alternative, is to improve the fault analysis and classification flow, so that more and more “worst case” assumptions which increase the “single”, “residual” or “latent” fault count, are replaced by realistic assumptions which increase the “safe” and “detected” bin count. This can boost your ISO 26262 metrics without modifying a single gate, and prevent overdesign and schedule delays. We shall go into great detail about this option, which we prefer to refer to as “smart” rather than “cheap”, in our next article on this topic.

Back to Top

© Mentor, a Siemens Business, All rights reserved www.mentor.com

Footer Menu

  • Sitemap
  • Terms & Conditions
  • Verification Horizons Blog
  • LinkedIn Group
SiteLock