Examining the differences between systematic verification and safety-related verification and how IP deliverables can help meet integration requirements.
By Shivakumar Chonnad and Vladimir Litovtchenko
Today’s SoCs for automotive safety-related systems integrate numerous IP blocks. At the system level, the Hardware Software Interface (HSI) between these IP blocks needs to be verified in simulation and validated in prototype. However, the scaling of the scope and effort to verify or validate is not linear based on the growing complexity of SoCs and their components such as IP. In a systematic verification, the emphasis is on the scenarios and defects in the logic. In a safety-related verification, the emphasis is on a fault, which is an abnormal condition that can cause a component to fail. While the IP blocks that are internal to the SoC have an independent set of safety-related logic and their associated work-products, the safety concepts and metrics of these independent components need to merge with the hierarchies of the various IP blocks in the SoC, constituting a safety integration. The SoC implementors require work-products or documents that describe safety-related features, as deliverables from the IP providers for integration of all safety-related blocks into the SoC and insuring completeness and correctness of the SoC safety concept.
Safety within systematic verification flows
When numerous IP blocks are integrated into an SoC, the nominal functionality of the interaction between the IP blocks is addressed by verification. These are methodical steps from the concept phase including specifications and requirements definitions to the hardware and software verification and prototype validation of the intended functionality of the SoC. The focus is to verify and validate the SoC with a high degree of confidence that the SoC integration is complete and free of all known defects.
Similarly, for safety-related SoCs, it is important that safety concepts of each safety-related SoC blocks and implementation are considered from the very beginning at the requirements phase. The starting points and implementation flows can be executed in parallel as shown in Figure 1. The IP development flows should be aware of the SoC paradigm in all stages and phases of development in both nominative and safety perspectives.
Figure 1: Example of safety and nominal functionality development flow
Measurable metrics
For the systematic verification of the IP blocks and SoC, there are well-defined flows that have measurable goals, like functional coverage and code/line/toggle/condition/fsm coverage. Analogous metrics exist in the analog, custom, and RF designs.
Similarly, the safety-related flows also have qualitative and quantitative measurable metrics. The key goal for the safety-related IP blocks is the Automotive Safety Integrity Level (ASIL) based on its defined values for metrics.
Reaching the target ASIL involves a qualitative analysis of systematic faults using Design Failure Mode Effect Analysis (DFMEA). The DFMEA captures the failure modes and their effects of the element at the IP and SoC levels. This is followed by a quantitative analysis of failure modes to arrive at the Diagnostic Coverage, which is a function of the faults detected by the safety mechanism versus the total faults in the design. The results of this quantitative analysis are fed into the Failure Modes Effects and Diagnostics Analysis (FMEDA). These analyses apply to the IP and SoCs.
The IP provider must deliver sufficient documentation, safety argumentation and evidences that verify the failure mode or diagnostic coverage metrics. For ASILs C and D, the ISO 26262 standard requires a quantitative analysis of the key variables. It is important that the IP providers delivers sufficient proof through fault injection results, ensuring the IP meets the safety standard.
Key aspects of safety integration
The safety case of a product is determined through a set of work-products or documents that depict evidence of the various safety related activities. The following sections describe some of the key aspects and documents of safety integration at the SoC level.
Technical safety concept to meet safety requirements
The functional safety concepts of an IP are indicated in the Functional Safety Requirements (FSR’s). Since the IP is typically developed as a Safety Element out of Context (SEooC), the safety requirements at a functional level can be reviewed by the IP integrator to ensure the FSRs relevant to the SoC are met at the IP level. Technical Safety Requirements (TSR) are defined when the IP implements the FSRs at various levels of hierarchies. More detailed properties of safety measures are defined by the Hardware Safety Requirement (HSR) and the Software Safety Requirements (SSR) specifications of the IP blocks. Figure 2 shows a typical technical safety flow at the IP or SoC levels.
Figure 2: Technical safety flow at IP or SoC levels
The reason IP blocks need to capture FSRs as work-products from the very beginning of the design phase is to provide sufficient details to the overall safety concept of the IP. This will help the IP integrator analyze the IP block’s safety implementation to mitigate any risks at the SoC level.
Safety manual
One of the important deliverables from a safety-related IP is the safety manual, which captures the all safety-related aspects of the IP block that indicate safety-related logic, safety goals, safety mechanisms that monitor the safety-related logic inside the IP and outside of it, hardware/software interface (HSI), reaction of safety mechanism to a fault occurrence, diagnostic coverage, and fault detection time.
The safety manual from the IP provider gives the IP integrator all necessary details to know about the IP block’s application assumptions and reaction to the various failure modes through their safety mechanisms and if there is sufficient time budget to prevent a reaction to a fault before it turns into a failure. Accordingly, the integration of the IP block’s ports and software interface can help make system level decisions on how to react to a fault.
Safety mechanism
A safety-related logic needs to have safety mechanisms that are self-monitoring and detect systematic and/or random hardware faults. Safety mechanisms are required to achieve or maintain a safe state through detection, indication, and control of faults. The choice of safety mechanism is specified in a Technical Safety Concept and depends on the failure mode, and it helps define and implement any warning/error indicators and the degradation strategy for the SoC. While some active safety mechanisms like Error Correcting Code (ECC) can detect and perform single error correction, other safety mechanisms only perform detection and reporting.
The safety mechanism in a safety-related IP can either be internal or external to the IP. The safety mechanisms that are internal to the IP are validated as part of the systematic verification built in the IP block’s test plans. External safety mechanisms need to be verified through models to ensure the intended use and context of the safety element.
In case of both internal and external safety mechanisms, the IP providers need to supply the documentation in the safety manual, including what safety function the internal and/or external safety mechanisms are monitoring, what the interfaces are, handshake protocols, timing relationships, how the SoC is indicated through the diagnostic points, and any programmability considerations.
Assumptions of Use (AoU)
Given that most IP blocks are developed as an SEooC, it is important to document the assumptions of how to use IP in an SoC for safety operations. This will help the IP integrator to know the various IP assumptions and whether these assumptions are valid and can be met. This compatibility check eventually decides the safe/unsafe operation of the integrated IP blocks. Eventually the system needs to be informed of the occurrence of a fault, take appropriate actions, and prevent a failure by transitioning to a safe state to a fail-safe or fail-operation condition.
The AoU information is validated at the SoC or the system level to ensure the assumptions specified at the IP level are acceptable. Documentation of the IP block assumptions serves as a key reference during safety related verification activities at the SoC.
Traceability
One of the key challenges for the IP integrator is to ensure that the compliance with the safety goals and relevant safety goal violations can be addressed by lower level refining of the functional safety requirements. This needs to be traceable in a bidirectional way, from the requirement to an implementation and back. The bidirectional traceability needs to be present in all stages starting from the requirements phase going to production, delivery, and up to the field use. For more details read the ‘Best Practices for Traceability of Functional Safety Requirements In Automotive IP & SoCs’ white paper.
Safety integration at the SoC level
The following sections describe some of the key system level integration requirements and strategies that can help with safety-related verification at the SoC level. The sections also describe how the IP deliverables can help meet integration requirements.
Assimilating the IP collaterals
Since many IP blocks are developed independently as an SEooC, they are pre-configured prior to integration into the SoC. A review at this stage ensures the IP block’s safety features are compatible with the SoC’s safety features and shows how the different IP blocks interact with one another as well as with the SoC’s software. The functional safety requirements of the SoC are reviewed against the functional safety requirement of each individual IP. The IP integrator indicates any incompatibilities in the IP requiring a change via a change management activity through impact analysis. The tailored IP collaterals that are reviewed prior to SoC integration are shown in Figure 3.
Figure 3: Tailored IP collaterals for SoC integration review
Safety verification
Once the review of various IP safety documentation is complete, the various IP blocks are then integrated into the SoC which is ready for safety verification. The objective of safety verification at the system level is set at a higher abstraction to provide evidence that each IP interacts correctly and complies with the technical and functional safety requirements at the SoC level. Specific integration tests ensure the IP blocks are interfacing correctly and are free from any unintended behaviors that could violate a top-level safety requirement.
To help with SoC integration, some of the key IP deliverables that can assist in the SoC activities are the following:
Summary
Since automotive IP blocks are developed as a Safety Element out of Context (SEooC), any IP deliverables that can help in the SoC integration efforts are essential to ensure unintended behaviors that could violate a safety goal are non-existent. Some of the key IP deliverable are Failure Modes Effects and Diagnostics Analysis (FMEDA), Safety Manual, Assumption of Use (AoU) report, and safety verification documents which comprise of testcases, fault injection flows, and hardware-software integration validation analyses. Safety in automotive is a vast topic, and there are many more considerations that may not have been covered in this article. However, the key considerations in this article will help verify that the defined safety measures, resulting from safety analysis at the system architectural level are properly implemented. It also helps to provide evidence that the integrated system elements fulfill their safety requirements according to the top-level safety requirements.
Synopsys offers a broad portfolio of pre-designed, pre-verified, reusable automotive IP that are ASIL Ready ISO 26262 certified for advanced driver assistance systems (ADAS), connected vehicles and infotainment, gateways, and mainstream MCUs.
Click here to read the entire white paper: Aligning Automotive Safety Requirements Between IP and SoCs.
Vladimir Litovtchenko is a senior manager, Functional Safety and Quality Engineering at Synopsys.
 |
 |
 |
 |
 |
 |
Leave a Reply