Functional safety is critical for the automotive systems-on-chip (SoCs) that are the technology backbone for advanced driver assistance systems (ADAS), infotainment equipment, and other in-car systems. However, meeting the various safety standards can be time-consuming and labor-intensive, involving voluminous amounts of data that changes as the standards evolve.

Following certain methodologies can make it more efficient for designers to ensure an automotive system will behave as anticipated, even if something unplanned or unexpected occurs. A set of design and verification technologies that automate fault injection and result analysis for intellectual property (IP), SoC, and system designs can reduce automotive ISO 26262 compliance efforts by up to 50 percent.

What does functional safety involve?

Functional safety is the concept that a system will remain dependable and function as intended even in the face of an unplanned or unexpected occurrence. If a system is functionally safe, then it is assumed that the system is able to avoid unacceptable risk of physical injury or damage.

There are two foundational requirements of a functionally safe system:

• Redundancy provides multiple processing paths that limit the risk that any one error will disrupt the system
• Checkers monitor the systems and trigger error response and recovery features when needed

As SoCs move into smaller process nodes they become more susceptible to errors. For example, phenomena including radiation sources, magnetic fields, and internal wear can all be disruptive to an advanced-node SoC. To assure that an SoC is functionally safe, a designer would typically need to establish a functional verification environment where errors (faults) could be injected into the system. Redundant logic would vote on the correct data to eliminate errors and maintain continuous operation. Checkers would monitor the erroneous data within specified time periods and apply error corrections.

Meeting the ISO 26262 safety standard

ISO 26262 addresses the functional safety of electrical and electronic systems installed in series production passenger cars. An adaptation of IEC 61508, ISO 26262 affects all systems with software- or hardware-based electrical, electronic, or electromechanical components. The standard covers many aspects of safety-related automotive software production, including the qualification of tools used in the development process.

Complying with the safety integrity level outlined in ISO 26262 involves collecting and analyzing a voluminous amount of data. By voluminous, we’re talking about potentially tens of person-years in the development cycle for an automotive product line.

With competitive and time-to-market pressures, designers can’t afford to spend years addressing functional safety. Yet, for the sake of the end customers, corners can’t be cut. However, there are some methodologies that can make it more efficient to comply with functional safety standards.

Classifying faults to set ASIL

The safety verification process involves classifying faults into the safe, dangerous, and dangerous-detected categories; codifying this classification into the safety plan; and executing a verification program to determine the ratio of dangerous-undetected to dangerous faults. The result of this sets the Automotive Safety Integrity Level (ASIL).

In many ways, functional safety verification mirrors functional verification. Typically, in a functional verification methodology, the design under test (DUT) is held as a control while a wide range of stimulus is applied. In a typical safety verification methodology, the stimulus is controlled to a few typical sequences while a wide range of faults are applied to the DUT.

What’s challenging about safety verification is that the DUT logic can’t actually be changed – changing this logic would invalidate the concept of verifying faults in the actual design. This kind of change would also invalidate the ISO 26262-required tool confidence level (TCL) assessment of the verification tools used. Given these scenarios, safety verification must share both testbench and DUT code and the flow must execute concurrently with the functional verification flow.

The set of monitoring points for the fault detection circuits provide the starting point for safety verification. These points are strobed during the actual design execution, so the same effect must be modeled in safety verification. A small set of functional test sequences stimulate the DUT during safety verification. Once this environment is established, the design nodes must be automatically discovered and then collapsed to create a fault dictionary for safety verification.

The safety verification methodology then iterates over the fault dictionary, injecting permanent and single event upset (SEU) faults. Through this process, a detection condition for each fault is reported. Faults that are reported as undetected or potentially detected require additional debug before they can be classified, as they may be dangerous.

Including safety verification in a functional verification flow

For a small design, it could be feasible to run safety verification using sampled input for the testbench and then analyze the results manually. However, with more complex systems, it makes sense to integrate safety verification as part of the functional verification flow. With this approach, designers can use sophisticated testbenches to control the fault injection and support the debug process. For similar reasons, it also makes sense to use the same simulator for both processes. Doing so would eliminate the efficiency loss that results from debugging result differences that occur when a modified DUT or different simulation engine are used.

A safety simulation process could involve as many as hundreds of thousands or even millions of temporal faults. That’s why automated regression verification, as established by metric-driven verification, can increase the efficiency of identifying the undetected and potentially detected fault simulations as well as automatically aggregate the safe faults from the unsafe faults. By applying this approach, safety verification efforts can be reduced by up to 50 percent.

An end-to-end functional safety solution that reduces the automotive ISO 26262 compliance effort is available based on the Cadence Incisive functional verification platform. It includes the Incisive Functional Safety Simulator and a functional safety regression capability in the Incisive vManager solution. Figure 1 shows a screenshot of the Incisive vManager solution, which can help highlight potential and undetected fault runs for debugging. Overall, the functional safety solution automates fault injection and result analysis for IP, SoC, and system designs. For safety requirements tracing, it integrates permanent and transient fault simulation.

 

(Click graphic to zoom)

 

The Incisive Functional Safety Simulator simulates the unaltered DUT. Faults are injected during simulation and can propagate through SystemC, analog transistor or behavioral models, and assertions. Engineers can reuse their functional and mixed-signal verification environments to speed up the time to develop safety verification. With Incisive vManager, its functional safety analysis capability automatically generates a safety verification regression from the fault dictionary created by the simulator. The solution can then track millions of detected, potentially detected, and undetected faults introduced into simulation to verify a design’s safety systems. Figure 2 shows a functional safety verification flow based on the Incisive environment.

 

(Click graphic to zoom)

 

Creating safer automotive systems

Ensuring that an automotive SoC is functionally safe also gives drivers and passengers confidence in their vehicles. Integrating safety verification into the functional verification flow can be an effective way to speed up the process and manage the effort of complying with standards such as ISO 26262. Using functional verification and fault simulation technologies can also minimize your safety verification effort. With these methodologies and technologies, companies can spend more time creating safe and unique automotive designs.

Adam Sherer is Project Management Group Director at Cadence Design Systems.

Cadence Design Systems

www.cadence.com