草榴社区 Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Table of Contents
The Case for Functional Safety
Automotive functional safety (FuSa) is defined by ISO 26262 as the “absence of unreasonable risk due to hazards caused by malfunctioning of electrical and electronic systems.” It’s a broad and deep topic, but in the spirit of “” series of articles by Joe Convey and Bryan Dickman, let’s focus on the verification challenges as seen through the lens of the verification engineer and in the context of both finding and avoiding bugs. Automotive is a sector where the need for functional safety requires very little explanation, even more so given the escalating sophistication and complexity of both hardware and software in modern vehicles, especially with the emergence of electric vehicles (EVs) and autonomous driving. Let’s face it, lives are literally at stake here. Hence, this is why FuSa is a key consideration for semiconductor companies targeting the automotive industry, causing them to spend an additional 30% in development effort on top of the pure functional aspects of the system. Understanding the implications and requirements of ISO 26262 is essential.
Challenge #1: Find Systematic Failures in the Design Affecting Functional Safety Requirements
For a safety-critical device, it goes without saying that all bugs (be it functional, or non-functional) are generally bad news, especially if they impact the safety requirements of the device. This is the standard set of verification challenges, and all of the established strategies, tools, processes, and methodologies apply in the same way they would for a non-safety-critical design. The big difference is the need to follow stringent requirements workflows (specification, tracking, and traceability) using approved requirements management platforms, and also the need to use certified design and verification workflows and best practices. 草榴社区 tools are certified to ISO 26262 ASIL D to accelerate quality and functional safety qualification.
Both dynamic and static approaches are valid. For obvious reasons, formal verification is a good choice when it comes to safety. In VC Formal? Formal Testbench Analyzer, 草榴社区 Certitude? technology is integrated with VC Formal to provide meaningful property coverage measurements as part of formal signoff and identifies any weaknesses such as missing or incorrect properties or constraints. The native integration delivers 5-10x faster performance compared to stand-alone fault injection methods.
Challenge #2: Hitting Fault Detection/Fault Correction Targets for Random Failures
Functional safety verification explicitly models faulty behaviors caused by random defects and verifies that the safety mechanisms built into safety-critical automotive SoCs properly manage these behaviors. Random hardware failures arise from random events that cause hardware faults and they can be permanent (stuck-at faults) or transient (single event upsets (SEUs) or sometimes referred to as “soft errors”).
Safety-critical designs aim to mitigate against random hardware faults by adding safety mechanisms that give the device the desired level of fault tolerance appropriate to the Automotive Safety Integrity Level (ASIL) your system is targeted at. All safety mechanisms aim to detect faults, and the more sophisticated ones can correct some classes of faults also; for example, error correction code (ECC), roll-back, and retry mechanisms. Even when faults are not correctable, detection means that the system can take appropriate action, such as resetting the system or putting the system into a safe state and maybe illuminating a warning light on your vehicle dashboard. Nowadays modern vehicle systems will automatically send an alert to the vehicle manufacturer. They then inform you about the problem before you know anything about it!
Adding safety mechanisms to your design can be a balancing act. After all, you are adding more logic and more complexity, which in itself is an opportunity to inject more systematic design bugs and might change the power and performance characteristics of the design. Complex safety mechanisms can generate complex corner-case scenarios that you will need to systematically search for. Start by capturing and enumerating all of your safety mechanisms in the verification test plan. Are you sure that each mechanism is fully validated with stimulus and coverage? That will depend on both your ability to dynamically simulate the device with meaningful stimulus and at the same time inject faults to exercise safety mechanisms.
Challenge #3: Executing an Efficient and Effective Fault Injection Campaign
At the heart of functional safety verification is the fault injection/fault simulation campaign. The objective is to simulate all faults, classify them into the standard categories such as safe faults, single-point faults, multi-point faults, residual faults etc., and then generate the ISO 26262 safety metrics in the form of the required FMEDA report. This report will demonstrate how the device scores against the ASIL (A, B, C, or D) requirements and determines compliance to the target safety integrity level.
Modern fault simulators like the 草榴社区 Z01X? solution deliver powerful, concurrent, and distributed fault simulation, enabling the fault model to be fully simulated with fault injection in the shortest possible time.
Its unique testability-based fault optimization and support for very large designs and fault lists have made it a proven technology in the industry. Combined with formal filtering techniques, 草榴社区 VC Formal? FuSa App, which formally identifies and classifies faults based on observability or detectability criteria, provides functional safety verification engineers the ability to boost the percentage of fault coverage and accelerate fault classification.
For longer fault scenarios and software-based safety mechanisms, the 草榴社区 ZeBu? solution is the industry’s fastest emulation system enabling the fault campaign to explore system validation payloads under fault injection/fault emulation. The ZeBu system supports unified fault database integration for smooth interoperability with other 草榴社区 FuSa tool chains.
Challenge #4: Avoid Injecting New Bugs into Non-Trivial Functional Safety Mechanisms
As noted, safety mechanisms can get quite complicated, and while trying to mitigate against random transient faults, it’s a bit of a backwards step if in so doing you inject a serious systematic functional bug. The usual adage of “if it’s not tested, it’s broken” still applies. You will need to stimulate the safety mechanisms, check for correct behavior, and analyze coverage. Your stimulus requires that faults are injected to invoke the safety mechanism under test, so you will need a methodology to inject random faults into your testbench. More complex safety mechanisms might change the event sequencing over many cycles, e.g., a safety mechanism that attempts to correct a random failure by retrying a memory access for a limited number of times. This in turn implies an analysis of the detection and correction time for the failed access known as the fault reaction time, to ensure that performance remains within specified operational parameters.
草榴社区 has developed the first and most unified functional safety verification solution for companies developing IP and SoCs requiring ISO 26262 certification. This unified approach to functional safety verification helps developers of ISO 26262-compliant products to meet schedules and quality targets and win design slots in a highly competitive market segment.
Now drive safely!