As we've said often (to anyone who will listen) in the last few months, circuit reliability is not a new-node problem, and circuit reliability challenges are applicable in varying degrees of criticality and complexity to many different industries.
This time, let's talk specifically about the automotive industry, some of the circuit reliability challenges it must overcome to meet industry quality standards and consumers' expectations, and the tasks it faces when implementing a verification strategy to identify sources of possible electrical circuit failure before they happen.
What about the average consumer's attitude toward automotive reliability? You know the answer, because you're a consumer yourself. Consumers don't really care how product reliability is achieved, as long as everything in their car works the first time, every time. That's true even when the car includes heated seats, remote engine controls, power windows and locks, satellite radio, wireless communications, automated traction sensing controls, and the other myriad electronics-based features present in today's cars and trucks.
And as the flip side of this attitude, consumers will readily abandon brands that experience public failures. Auto manufacturers face a long hard road to recover consumer confidence and marketshare after a catastrophic or widespread malfunction.
Now, let's look at the automotive designer's attitude toward automotive reliability.
Automotive components must operate reliably in the face of high voltages, high temperatures, and large currents. Automotive industry design standards, such as ISO 26262, emphasize the fact that circuit reliability requirements of automotive components lead to very strict design processes to ensure designs comply with these standards. An automotive component's design process almost always has some stages where each design implementation step must have a corresponding verification step. I always hear the question "How can I comply with both fast turnaround times and quality assurance?" Another question I hear frequently is "How can my designers be successful in situations where experience with proven components is not always applicable?"
The simple answer to these questions is to employ an automated solution for circuit reliability that has the functionality needed to identify and analyze the elements that are crucial to automotive reliability standards compliance. Of course, simple does not always mean easy. Automotive designers always use well-defined design constraints to describe design intent and design limits for the technology of interest. These constraints vary based on the design type. For example, digital designs have different constraints from analog designs. Generally, these constraints can go through different hierarchy levels, so any verification process must be able to assess these constraints in that context.
Automotive application designers must also verify their design constraints beyond just the physical verification of design rule checking (DRC). Unlike DRC, constraint verification requires knowledge of object relationships, or "groups" and "members." Members are instances or groups (e.g., other constraints) located on or below the checked hierarchy level. The implemented checks must be generic and technology-independent. Moreover, parameters can be set globally (as part of the process design kit) or locally (for specific constraints).
We have worked with our customers to establish an efficient, comprehensive approach for constraint derivation and verification that ensures generic analog-focused constraints in hierarchical IC designs, and we have verified the practicality of this approach on large industrial automotive IC designs. Using the techniques we defined, several critical constraint violations were identified that would have otherwise been missed.
I am curious to learn if any of you are incorporating techniques for the verification of hierarchical analog design constraints for automotive ICs. What techniques are you using? What are your results? Are there any best practices you would advocate?
This article was originally published on EBN's sister publication EE Times.