SoC Safety Mechanism Fault Detection With Shared Test Patterns
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for achieving high fault coverage in Safety Mechanism (SM) logic of silicon system on chip (SoC) devices to meet ISO-26262 Automotive Safety Integrity Level D (ASIL-D) standards are costly in terms of area, design, validation efforts, and CPU resources, with insufficient fault coverage and high computational overhead.
Innovation Solution
A method involving a combination of hardware and software, utilizing an automatic test pattern generator to generate safety mechanism test patterns offline, loading them into a pattern buffer, and using a controller to sequence and compare test points, reducing silicon cost and computational resources by sharing the pattern buffer among multiple SMs and optionally using hard-wired pattern generators for specific types.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If Logic Built-In Self-Test (LBIST) circuitry is added to detect faults in Safety Mechanisms, then fault detection capability is improved, but silicon area cost and design complexity increase significantly
Solution Approach 1:
The patent extracts the test pattern generation function from the main Safety Mechanism logic and places it in a separate Pattern Generator module. This separation allows the SM to be tested without requiring LBIST circuitry integrated within the SM itself, thereby reducing the silicon area overhead while maintaining fault detection capability.
Solution Approach 2:
The patent introduces a Pattern Buffer as an intermediary component between the Pattern Generator and the Safety Mechanism. This buffer stores pre-generated test patterns and supplies them to the SM during testing, eliminating the need for complex integrated LBIST circuitry within the SM and reducing overall silicon area requirements.
2Reliability
If dedicated error injection registers are added around Safety Mechanisms to enable test software to drive test patterns, then fault coverage is improved, but device complexity and validation effort increase
Solution Approach 1:
The patent extracts the error injection functionality from the Safety Mechanism and implements it in a separate Pattern Generator module that can be controlled by test software. This approach achieves the required fault coverage without adding dedicated error injection registers around each SM, thereby reducing device complexity and validation effort.
3Reliability
If test patterns are generated and transmitted through software (STL) to Safety Mechanisms, then fault detection is achieved, but CPU resources are considerably consumed
Solution Approach 1:
The patent implements a hardwired Pattern Generator that autonomously generates test patterns without requiring CPU intervention. The Pattern Generator and Pattern Buffer work together to automatically supply test patterns to the Safety Mechanism, enabling fault detection while minimizing CPU resource consumption.
Data Source
AI summary
Safety mechanisms are embedded into a System on a Chip (SoC) and are operable to detect faults present in the logic circuitry in the SoC. Various types of faults in logic circuitry can occur, for example, a bit stuck at 0 or 1, or a transient or temporary fault due to radiation impacting the SoC. SoC devices are required to meet certain automotive safety integrity standards. The most stringent automotive safety integrity level requires that 90% of random latent faults are detected in all relevant logic, including all safety mechanism. Examples disclosed include hardware based checkers and hardware or software based pattern generation methods that achieve high online fault coverage in safety mechanism circuitry used for functional safety. A hardware based safety mechanism monitors the logic circuitry during operation. Any time the safety mechanism detects any faults in the logic circuitry, a fault notification is propagated to upstream logic.