Challenges Of Logic BiST In Automotive ICs

The electronics in passenger cars continues to grow, and much of it is bound by the strict functional safety requirements formalized in the ISO 26262 standard. The ICs that drive the electronics systems in automobiles are also increasingly complex, designed to execute artificial intelligence algorithms that govern emerging self-driving capabilities.

Designers are quickly adopting comprehensive test solutions to address the quality and reliability metrics mandated by the ISO 26262 standard. One approach to ensuring the reliability of a vehicle’s electronics is to perform periodic testing during functional operation. This is done for logic and memories with built-in-self-test (BIST). Logic BIST is an ISO26262 recommended mechanism for implementing diagnostic tests that target latent faults. It involves the on-chip generation of random patterns that are applied to scan chains.

But implementing logic BIST for automotive ICs is not free of challenges.

Challenges in implementing in-system logic BIST
Among the top challenges of logic BIST for ISO 26262 safety requirements are:

• Meeting the diagnostic test time interval (DTI) constraints
• Architecting the logic BIST so it meeting the test scheduling without breaking the test power budget
• Establishing application-level access to all the on-chip logic BIST
• Enabling diagnosis of field returns

Meeting the ISO 26262 ASIL requirement
ISO 26262 says the diagnostic test time interval (DTI)—how much time is available to run a diagnostic test—must fall between 100 ms to few microseconds. Meeting the diagnostic coverage requirement within that DTI can be quite challenging, especially for the highest automotive safety integrity level ASIL-D application. In a previous article, we presented a technique using a new type of test points to improve logic BIST test coverage by more than 15%, which is often enough to ensure compliance  with the ASIL-D requirements.

Design architecture and test scheduling
ISO 26262 defines time-spans from when a fault happens to when the hazardous consequences of that fault materialize. The relevance to logic BIST implementation is the requirement for a maximum time allowed to handle that fault and bring the device to a safe state (Fig. 1).

To meet the DTI, tests have to run in parallel. Running parallel test is an architectural challenge and can potentially break a design’s power budget. More importantly, running parallel tests can over-stress the circuit under test, becoming a new concern to IC safety and reliability. Managing the test power through a power-aware testing and architecting the design to use decentralized in-system test controllers helps the in-system test to meet the designated DTI ‎[1].

Fig. 1: Safety-relevant time intervals.

Test access
All functional safety monitoring and in-system test activities are typically driven by software/firmware routines running on a dedicated or shared CPU in a given safety island.  Accessing the test mechanism directly from the software level eases the development process and reduces test latency, which directly impacts the DTI. Mentor addresses this challenge with the Tessent  MissionMode product, which provides easy software-based access to any test IP or any IJTAG complaint IP distributed throughout the design (Fig. 2). Tessent MissionMode is completely application and CPU agnostic. The interface between the software and the test IP can be based on CPU data bus, register file access, serial interface, or predefined memory storage.

Such architectures has been shown to be useful for test access during field return diagnosis and system maintenance, where many custom test cases can be developed using software for higher-level testing^{1, 2}.

Fig. 2: Accessing test IP in automotive ICs.

Field return diagnosis
Being able to identify the failing circuitry is extremely important, especially for field returns that might involve some legal responsibility. The in-system test solution must be capable of running the same tests, but collecting more test details, similar to a manufacturing test log file. This way a circuit can be diagnosed to identify the root cause of a given failure. Moreover, it should be capable of running more customized tests in order to verify the failure and its root cause. Field returns can disrupt the whole product lifecycle, so being able to reduce the turn-around time for diagnosing a field return is a significant business advantage. One solution is to automate the testing and diagnosis of field returns.

Meeting the quality and reliability requirements of the ISO 26262 standard becomes more difficult as device sizes and complexities continue to grow. The design-for-test activities should be considered early in the IC design process to allow for the implementation of new test architectures. Adopting logic BIST in an advanced DFT flow helps semiconductor manufacturers achieve their quality and reliability metrics and differentiates their products by delivering embedded test capabilities that can be leveraged by their customers at the system level and in the field. DFT for automotive safety-related ICs is aided by comprehensive, ISO 26262 certified automation from EDA suppliers (Fig. 3). Any automotive DFT flow should address the four challenges we’ve described: diagnostic test time interval, architectural scheduling, application level test access, and diagnosing field returns.

Fig. 3: Integrated DFT for automotive safety applications.

For more information, download our whitepaper “Meeting ISO 26262 Requirements Using Tessent IC Test Solutions.”

References

1. Karthik Subramanian, Et. al., “A Scalable Design for Test Architecture for In-System Test and Manufacturing Test for Large Automotive ICs,” ITC poster and ART workshop 2018.
2. Tal Kogan, Et. al., “A Hierarchical DFT Architecture for Automotive Designs,” ITC ART workshop 2017.