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)

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

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • 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-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • 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 Horizons - 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

      • Creating an Optimal Safety Architecture  - February 9th
      • The ABC of Formal Verification - February 11th
      • Events Calendar
    • On Demand Seminars

      • I'm Excited About Formal...
      • Visualizer Coverage
      • Formal-based ‘X’ Verification
      • 2020 Functional Verification Study
      • All On-Demand Seminars
    • Recording Archive

      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • All Recordings
    • Mentor Training Center

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

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • Questa Simulation Coverage Acceleration Apps with inFact
      • View all Learning Paths
  • 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
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Verification Horizons - March 2020
      • Issue Archive
    • About Us

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

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
  • Home
  • Verification Horizons
  • July 2020
  • Effective Validation Method of Safety Mechanism Compliant with ISO 26262

Effective Validation Method of Safety Mechanism Compliant with ISO 26262

Verification Horizons - Tom Fitzpatrick, Editor

 | Verification Horizons - July 2020 by Toshiyuki Hamatani, Verification Technology, Inc.

The metrics to measure the effectiveness of Safety Mechanisms include code coverage rate, SPFM (Single- point failure metric) and LFM (Latent failure metric). Especially in SPFM and LFM, if the specified value is not reached on the Fault Injection Simulation (using Gate Level) at the end of verification, it will cause iterations, which will cause a significant increase in time and cost compared to consumer LSIs.

A method for efficiently performing a logic simulation of the Safety Mechanism will be described.

QUANTITATIVE GOALS OF LSI VERIFICATION FOR ISO 26262

In an ISO 26262 compliant LSI, it is required to achieve the quantitative target value of hardware metrics for each ASIL (Automotive Safety Integrity Level). The hardware metrics include PMHF (Probabilistic Metric for Random Hardware Failures) and hardware architecture metrics. The combination of SPFM and LFM is called the hardware architecture metric. In terms of design quality, the target value of code coverage is 100% for circuits that include the Safety Mechanism. PMHF still depends on the failure rate of the LSI.

The quantitative target values of SPF and LPF for each ASIL are as follows.

Table 1 - Possible source for the derivation of the target ”single-point fault metric” value

ASIL A: Does not target “single-point fault metric” value

Table 2 - Possible source for the derivation of the target ”latent-fault metric” value

ASIL A: Does not target “latent-fault metric” value

SPFM and LFM in an ASIC/ASSP are calculated using Fault Insertion Simulator for Functional Safety using Gate-Level; however, if the target value is not achieved, the Safety Mechanism must be modified/revised. When carrying out revisions, it is necessary to comply with the change management regulations of the standard. Compared with ordinary consumer products ASIC/ASSP, this can take an enormous amount of time, which significantly extends the development period and increases costs for safety-critical designs.

With RTL verification of the logic circuit, including the Safety Mechanism by improving the verification completeness, the risk of failure occurring during Fault Insert Simulator for Functional Safety can be greatly reduced.

Definitions:

  • Single-point fault: A hardware fault in an element that leads directly to the violation of a safety goal and no fault in that element is covered by any safety mechanism
  • Latent fault: A multiple-point fault whose presence is not detected by a safety mechanism nor perceived by the driver within the multiple-point fault detection time interval
  • Random hardware failure: A failure that can occur unpredictably during the lifetime of a hardware element and that follows a probability distribution
  • Element: A system, components (hardware or software), hardware parts, or software units

CAUSES AND COUNTER MEASURES FOR DETERIORATION OF HARDWARE ARCHITECTURE

If a safety mechanism cannot detect when a fault occurs, the hardware architecture metric is degraded. A fault occurs due to transistor destruction, breakage of aluminum wiring, or the like. To verify the safety mechanism, we model a fault outbreak and use the model in simulation to ensure that the safety mechanism works properly. There are two types of models to create: Single Point Fault Model and Latent Fault Model. To check the operation of two types of Fault Models, we must check the Functional Coverage of the output of the Fault Models. In the verification for improving the hardware architecture metric, it is necessary to confirm the functional completeness of the safety mechanism by functional coverage using the created model. The configuration image is shown in figure 1. Verify and debug using Questa® Advanced Simulator using the environment pictured below.

Figure 1 - Image of configuration


Creating a Verification Environment and Executing Verification

To improve the hardware architecture metric, the steps for creating the verification environment and the verification execution, including the goals to be achieved, are described in the following lists.

Steps for creating the verification environment:

  1. Creating a base verification environment: Create a verification environment that does not consider the verification of functional safety as the base. The Safety Mechanism is built in the DUT (Device Under Test).
  2. Creating a Single Point Fault model: Create an element failure functional model (EFFM) for the intended failure based on the results of FMEA (Failure Mode and Effect Analysis). A Single Point Fault is a Fault that occurs only once in the element. The EFFM needs to create a model that works for all FMEA items. Acquire functional coverage of the output of the behavior model in order to confirm that all the intended behaviors have been verified.
  3. Creating a Latent Fault model: Conduct a safety analysis on the safety mechanism. A safety-mechanism failure function model (SFFM) is created for the intended failure of the Safety Mechanism from the safety analysis results. A Latent Fault is a fault that occurs in the Safety mechanism. A Latent Fault occurs in the Safety Mechanism during a Single Point Fault. However, only one occurs. This must be integrated with the Single Point Fault model. The SFFM should be modeled for all intended behavior for safety analysis. Acquire functional coverage of the output of the behavior model in order to confirm that all the intended behaviors have been verified.
  4. Creating a verification environment: Incorporate the EFFM and the SFFM into the verification environment. When incorporating, the functional coverage of the EFFM and the SFFM is output to Scoreboard. Output the Functional Coverage of Safety Mechanism input/output to the Scoreboard.

Steps for executing verification and goals:

  1. Verification when functional safety failure does not occur: No malfunction occurs in normal operation without the Fault Model. The safety mechanism does not operate unless functional safety failures occur. If the output of a Safety Mechanism is activated with EFFM or SFFM inactive, there is a problem in the verification environment or the Safety Mechanism. Functional coverage is 100% in the absence of functional safety failures. Also, it is exactly the same as the expected value of the DUT.Deactivate the EFFM and the SFFM and execute verification.
  2. Verification goal when functional safety failure does not occur — the goals are:
    • It exactly matches the expected value of the DUT
    • Functional coverage is 100% under the condition that no functional safety failures occur
    • The output of the Safety Mechanism must not be active
    • The Functional Coverage of the input of Safety Mechanism is less than 100%

If the above conditions are not met, debug the DUT and verification environment.

  1. Verification when a single point fault occurs: This is an SPFM test. For each test where a functional safety failure does not occur, EFFM causes one fault in the element. This test does not cause a Latent Fault. Activate the EFFM and deactivate the SFFM and execute verification.
  2. Verification goal when a single point fault occurs — the goals are:
    • It exactly matches the expected value of the DUT
    • The output of the Safety Mechanism must be active
    • The Functional Coverage of the input of Safety Mechanism is 100%
    • The coverage that is a function of the EFFM is 100%

If the above conditions are not met, debug the DUT and verification environment.

  1. Verification when a Latent Fault occurs: This is an LFM test. Latent Fault occurs in Safety Mechanism after Single Point Fault occurs for one test in which functional safety failure does not occur. Latent Fault requires a combination of Single Point Fault tests. Only one Latent Fault occurs in the Safety Mechanism. Activate the EFFM and the SFFM and execute verification.
  2. Verification goal when a Latent Fault occurs — the goals are:
    • It exactly matches the expected value of the DUT
    • The output of the Safety Mechanism must be active
    • The Functional Coverage of the input of Safety Mechanism is 100%
    • he coverage that is a function of EFFM is 100%
    • The function coverage of the SFFM is 100%
    • The cross coverage of EFFM and SFFM is 100%
  3. If the above conditions are not met, debug the DUT and verification environment.

  1. Code Coverage goal:
    • Code Coverage must be 100%, with approved exclusions
  2. If the above conditions are not met, debug the DUT and verification environment.

SUMMARY

The following is a summary of the four items for logical verification of an ISO 26262 compliant LSI.

Verification Environment

An ISO 26262 compliant LSI must meet the goal of the hardware architecture metrics (SPFM, LFM). In order to verify the hardware architecture metric, a hardware architecture metric verification environment must be created. The contents added to the construction of the verification environment for consumer products LSI are described below.

  1. Creating a single point fault model (EFFM)
  2. Creating a latent fault model (SFFM)
  3. Incorporation of single point fault modeland latent fault model into the verification environment

Verification Flow

An ISO 26262 compliant LSI must meet the goal of the hardware architecture metrics and metrics must be verified. The processes added to the consumer product LSI verification flow are described below.

  1. Single point fault simulation
  2. Latent fault simulation

Single point fault/Single point fault model and the Latent fault/Latent fault model

The features of the Single point fault / Single point fault model and the Latent fault / Latent fault model are described below.

  1. Single point fault / Single point fault model. The detection rate of Single point fault is Single point fault metric (SPFM). The single point fault model is for testing the single point fault metric; and, the generation behavior of the single point fault is modeled.

Feature

  • The cause of the single point fault is transistor breakdown or aluminum wire disconnection
  • It is necessary to create a single point fault model that models transistor breakdown and aluminum wiring disconnection
  • Single point fault is a fault that occurs only within the element
  • Only one single point fault occurs in one test
  • The safety mechanism is a module that finds a single point fault
  • In FMEA, all the high-risk features need to be modeled
  1. Latent fault / Latent fault Model. The detection rate of Latent fault is Latent fault metric (LFM). The latent fault model is a model for testing the latent fault metric; and, the generation behavior of the latent fault is modeled.

Feature

  • The cause of the latent fault is transistor breakdown or aluminum wire disconnection
  • It is necessary to create a latent fault model that models transistor breakdown and aluminum wiring disconnection
  • Latent fault is a fault that occurs only within the safety mechanism
  • Latent fault is a fault that occurs when a single point fault occurs
  • Only one latent fault occurs in one test
  • Even if a latent fault occurs, the Safety Mechanism must detect a single point fault
  • It is necessary to perform a safety analysis of the Safety Mechanism and model the analysis items based on the analysis results

Verification Goal

Each verification and verification goal is summarized below.

  1. Verification goal when functional safety failure does not occur.
    • It exactly matches the expected value of the DUT
    • Functional coverage is 100% under the condition that no functional safety failure occurs
    • Safety Mechanism output is always non-active
    • Safety Mechanism does not have 100% functional coverage
  2. Verification goal when a single point fault occurs.
    • It exactly matches the expected value of the DUT
    • The output of the Safety Mechanism must be active
    • The Functional Coverage of Safety Mechanism is 100%
    • The Functional Coverage of Single Point Fault Model is 100%
  3. Verification goal when a Latent Fault occurs.
    • It exactly matches the expected value of the DUT
    • The output of the Safety Mechanism must be active
    • The Functional Coverage of Safety Mechanism is 100%
    • The Functional Coverage of Single Point Fault Model is 100%
    • The Functional Coverage of Latent Fault Model is 100%
    • The cross coverage of Single Point Model and Latent Model is 100%
  4. Code Coverage goals.
    • Code Coverage must be 100%

Perform each of the above verifications and debug using Questa® Advanced Simulator so as to achieve the above stated goals.

Back to Top

Table of Contents

Verification Horizons Articles:

  • What do Grubhub®, Doordash®, and Verification Technology Have in Common?

  • Formal Is The “New Normal” - Deploy These FV Apps In Your Next Project

  • Understanding the SVA Engine Using the Fork-Join Model

  • Bridging the Portability Gap for UVM SPI VIP Core Reuse From IP to Sub-System and SoC Using Portable Stimulus

  • PCIe Simulation Speed-Up Using Mentor QVIP with PLDA PCIe Controller for DMA Application

  • Extending SoC Design Verification Methods for RISC-V Processor DV

  • Addressing VHDL Verification Challenges with OSVVM

  • Effective Validation Method of Safety Mechanism Compliant with ISO 26262

Siemens Digital Industries Software

Siemens Digital Industries Software

##TodayMeetsTomorrow

Solutions

  • Cloud
  • Mendix
  • Siemens EDA
  • MindSphere
  • Siemens PLM
  • View all portfolio

Explore

  • Digital Journeys
  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Newsletter
  • Customer Stories

Contact Us

USA:

phone-office +1 800 498 5351

See our Worldwide Directory

  • Contact Us
  • Support Center
  • Give us Feedback
©2021 Siemens Digital Industries Software. All Rights Reserved.
Terms of Use Privacy Cookie Policy