As the amount and complexity of automotive safety-critical functions continues to expand, the need for regular in-line monitoring of electronic systems will grow as well. Here is an example of a chip-level test architecture supporting system-wide monitoring.
By Stephen Pateras, Product Marketing Director, Tessent Group – Mentor, a Siemens Business
The accelerating march toward autonomous vehicles is driving a fundamental change in the nature of automotive semiconductor parts. Gone are the days where automotive devices had the luxury of being developed and manufactured using mature and robust processes. Nor can competing brands or their suppliers afford the automotive industry’s traditionally long product renewal cycles.
Automotive devices are no longer only for simple functions like controlling windows or light signaling but are now required for complex functions related to advanced driver-assist systems (ADAS) and increasingly for autonomous driving applications. The processing power required for these advanced functions results in the need for very large and complex devices manufactured in the most advanced process nodes. This, coupled with the need for these devices to meet the notoriously stringent safety requirements defined by the ISO 26262 standard (a standard for functional safety of electrical and electronic components in road vehicles up to 3500 kg.), is resulting in a perfect storm for automotive device and systems manufacturers. Solutions are needed to ensure new complex automotive electronic systems operate safely at all times throughout the life of the vehicle.
An emerging approach that is gaining broader adoption is to make use of a set of embedded monitoring functions distributed throughout each semiconductor device and tied together through a global communication infrastructure that enables rapid detection and reporting of random failures anywhere in the system. The monitors must operate without interfering with normal functional operation and have the flexibility to provide varying degrees of failure coverage based on the end-application of the semiconductor device and the associated Automotive Safety Integrity Level (ASIL) classification defined by the ISO 26262. There are four ASILs identified by the standard: ASIL A, ASIL B, ASIL C, and ASIL D. ASIL D dictates the highest integrity requirements and ASIL A the lowest. The intervening levels are simply a range of intermediate degrees of hazard and degrees of assurance required.
An example chip-level test architecture supporting distributed system-wide monitoring is illustrated in Fig. 1.
A standard IEEE 1149.1 test access port (TAP) provides a portal to all on-chip test resources for manufacturing test. The TAP connects to a reconfigurable serial access network based on the IEEE 1687 standard (often referred to as the IJTAG standard). This IJTAG network is made up of switches called segment insertion bits (SIBs). Each SIB allows a sub-network to be switched-in or bypassed, allowing for optimized access to any test resource within the network. The IJTAG network is also accessed by an In-System Test (IST) controller. The IST controller communicates to the outside world through a CPU interface and performs the parallel to serial and serial to parallel data conversion necessary to transport information between the external CPU bus and the internal IJTAG network. This IST controller enables a system-level communication architecture as illustrated in Fig. 2.
A service processor can access each chip’s IST controller and hence any on-chip test resource through whatever backplane vehicle bus implemented such as CAN (Controller Area Network) or I2C (Inter Integrated Chip).
The effectiveness of this distributed systems depends on the test resources implemented within the various devices. Probably the most common form of on-chip test resource is Memory Built-In Self-Test (BIST). An MBIST engine fully tests an embedded memory by algorithmically generating a sequence of read and write operations that covers the entire address space. A major difficulty in running such a memory test during vehicle operation is that the memory must first be taken offline to allow the BIST engine to take control. It may also be necessary to back up the memory contents before running the test and restoring the contents afterwards as the memory test will destroy any pre-test memory content. Another complication is that taking the memory offline will also likely degrade the system’s performance, which may not be acceptable in some applications.
A new non-destructive MBIST technique has been developed to avoid all of these problems. In this approach, the MBIST engine tests the memory using a series of short sequences of transactions, often referred to as bursts. A burst will typically only last for a small number of clock cycles (perhaps 20 to 30) and targets different memory locations each time. The entire memory is therefore tested over a large number of short MBIST sessions. The approach is non-destructive because the memory locations that are modified by a burst are saved and restored during each burst by the MBIST engine. Functional performance is not significantly affected because the bursts are only initiated when arbitration logic implemented between the MBIST engine and the functional logic determines the memory is free.
Logic BIST is another popular form of in-system test resource that can be accessed through the IST controller. This test solution involves the on-chip generation of random patterns that are applied to scan chains to test the logic portion of a chip. The circuit responses to all of the random patterns are accumulated into a signature, which is examined at the end of the test for a pass/fail result. The test coverage achieved by applying an increasing number of random patterns grows logarithmically as shown in Fig. 3A.
A common challenge in using this approach is achieving a high enough test coverage within a given time budget. A solution to this problem is to break up the test into multiple sessions as shown in Fig. 3B, above. Each successive session is applied during an available break in the functional operation. For example, in an image processor used to process visual data, each test session could be applied in between processing individual image frames. Implementation of the multiple test session solution requires careful coordination between the IST controller and logic BIST engine. The IST controller must keep track of which test session is to be applied next, initialize the logic BIST engine to have it generate the correct set of random patterns, and then retrieve and compare the intermediate signature to determine pas or fail status.
A distributed monitoring capability as described above enables any number of system level safety-related functions to be implemented. Key-on and key-off tests can easily be accomplished by sending out commands to all IST controllers to have all test resources run their most comprehensive tests. Any test failures can be reported back to the system software, which can use the results to drive some form of corrective action from something as simple as displaying a warning message on the dashboard to powering down the vehicle for further service. The IST controllers can also be instructed to run intermittent tests while the vehicle is operating on portions of the electronic system that are involved in safety-critical functions. Failing results from these tests would likely drive immediate actions that would place the vehicle into some safe operational state.
The need for regular in-line monitoring of automotive electronic systems will no doubt continue to grow as the amount and complexity of safety-critical functions continue to expand. Some commercial solutions to address this need have already been introduced and no doubt will continue to evolve over time.