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:
- 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).
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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%
If the above conditions are not met, debug the DUT and verification environment.
- Code Coverage goal:
- Code Coverage must be 100%, with approved exclusions
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.
- Creating a single point fault model (EFFM)
- Creating a latent fault model (SFFM)
- 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.
- Single point fault simulation
- 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.
- 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
- 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.
- 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
- 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%
- 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%
- 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
