New Techniques for Failure Analysis and Test Program Design Part I

By Charles Hymowitz, Lawrence Meares, Bill Halal Intusoft

Contents
• A Robust Approach To Analog And Mixed-Signal Test
• Configurable Schematics
• Failure Definition
• Measurement Definition
• Running The Failure Analysis

Fault checking of analog and mixed signal devices is tricky at best. But there are options to help you find your way in this testing maze. A new technique called the sensitivity analysis technique for analog fault checking is used to perform analysis, diagnosis, and isolation of failures in analog as well as mixed-signal circuits and systems.

Figure 1 A diagram of the software system providing automated failure analysis and test program set development.

The reasons for improving the analog and mixed-signal test program set-design, and Failure Mode Effects Analysis (FMEA) are many (see references 1 through 7). Several functions that could benefit from simulation software for example, are: identification of chronic production faults, improved safety and reliability through the analysis of difficult to test failure modes, investigation of circuit failure mechanisms, and excessive part stress. Yet few specialized software products currently exist to help define a structured approach to analog and mixed-signal circuit test procedures.

A specialized software tool is useful if it can identify failure modes that aren't tested. This would help the designer find unnecessary parts or flaws in the acceptance test.

Another important task is the tracking of component quality during production. Frequently, a product will evolve as new revisions are introduced and the product's performance will drift away from its design center. This deviation is observable from the acceptance test results, but software could also allow the designer or test engineer to track the nearby failures, including parametric failures. Lastly, a common design and test development tool would be useful in bridging the link, and frequently the information gap, between the design and test engineering departments.

A Robust Approach To Analog And Mixed-Signal Test
Test design demands a large database of faulty circuit behavior. The only practical method of gathering the data in a reasonable time frame is via simulation. With this in mind, a failure analysis and test development tool has been created based upon existing technology from two areas; the analog and mixed-signal world of SPICE simulation [references 11 and 12] and inference modeling [references 5 and 6]. This new tool is tailored to the specialized needs of the test and reliability engineer, but is also useful for the design engineer who must initiate the test development process. The tool provides an interactive design environment for the synthesis of diagnostic tests, generation of fault dictionaries, and the building of diagnostic fault trees.

Since the category of analog and mixed-signal test synthesis and sequencing software is relatively new, a number of techniques were developed to solve key parts of the FMEA and test program set design process.

The software, outlined in Figure 1, provides these benefits. The schematic entry program holds the entire design database, including part and model values and tolerances, and all part failure mode characteristics. It also contains a description of the various test configurations and measurements for each test.

The failure analysis process begins by simulating the circuit's or system's behavior with a single failure mode inserted. The schematic builds the required netlist for IsSpice4, a SPICE 3/XSPICE based analog and mixed signal simulator [references 13 through 15], using Windows-based ActiveX communication.

The simulation output data is processed using the Berkeley SPICE 3 Interactive Command Language (ICL) to automatically extract the desired measurements from the simulation results. This process is continued automatically, one fault at a time, until all of the faults are simulated. The measurements are then parsed into various report forms that contain user-defined test limits. This database becomes the fault dictionary. Finally, using the fault dictionary data, tests are sequenced into a fault tree.

Return to contents

Configurable Schematics
A long-standing problem in electrical and mechanical circuit design has been the conflict between the needs of the designer and the needs of production and manufacturing. The main vehicle for conveying the circuit specification is the schematic diagram that is used to describe the circuit topology as well as the details of how production will build the hardware.

The designer is concerned with creating a circuit that meets specifications. This is done chiefly through various EDA tools, but mainly with circuit simulation. The designer must build multiple test configurations, add parasitic components and stimuli, and even include system elements in the simulation. A top-down design methodology, where different levels of abstraction are inserted for different components, is commonplace. Modeling electrical behavior often results in different representations for different test configurations. In general, the schematic becomes so cluttered with circuitry and data, that it must be redrawn for production, greatly increasing the probability of a transcription error.

It should be noted that simulation can and should be used to check out the test setup. Using simulation to evaluate and design test jigs speeds up the overall process and doesn't consume precious time on the Automatic Test Equipment (ATE).

The need for a reconfigurable schematic capability becomes even more mandatory when we analyze the needs of the test program development engineer. In order to be effective, the simulation process can not become burdened with the bookkeeping intricacies of multiple test fixtures and settings. The designer must have a way to connect various stimuli and loads to core circuitry and to group the desired SPICE analyses and test measurements with each schematic configuration.

Until now, the best approach has been to hide these special configurations within subcircuits. While this approach works for hierarchical schematic entry, it doesn't solve the problem of adding test equipment, different stimulus inputs, or dealing with multiple simulation scenarios in a reasonable fashion.

A test setup provides loads, voltage and current stimuli and instrumentation connections at specific points on the Unit Under Test (UUT). When viewed in a broader context, the combination of the test setup circuitry and the UUT can be considered to be a circuit configuration in and of itself. Indeed, for simulation purposes, the test setup circuitry must be included as part of the circuit. Most Test Program Sets (TPSs) implement multiple setups during the testing sequence. This increases the simulation burden because it requires a separate schematic for every test setup.

Click here to see Figure 2.

The system described by Figure 2 addresses the multiple test setup. It allows the user to assign each setup/UUT combination with a different configuration name and simulates the stand-alone configurations in a batch operation.

The setup/UUT combination, defined during the schematic entry process, is called a "circuit configuration". Every circuit configuration is composed of one or more schematic layers. The active layer can be thought of as a transparency that overlays other transparencies, so that as you view them, you see the complete circuit configuration schematic.

Circuit nodes on the top layer connect with nodes on underlying layers as if the drawing were created on a single page. The schematic allows mixing and matching of layers to form the required circuit configurations. Any circuitry, elements, or documentation can be placed on any layer.

PCB layout software has had a similar feature for quite some time, but no known configurable schematic has been implemented. This is the first known graphical entry method which is capable of solving the Test-Simulation bridge using a reconfigurable layered schematic approach.

Return to contents

Failure Definition
Each component is defined by a set of nominal device and model parameter attributes, as well as parametric tolerances. Each component also has a set of defined failure modes. Component failures are well characterized by a finite number of catastrophic failure modes.

The unusual failure modes, however, get a lot of attention. For example, it is unusual to find a PNP transistor die in an NPN JANTXV package. Although these things do happen, they are very rare.

If acceptance testing detects only 99% of all failed parts, then the quality of the product increases 100 fold after the acceptance tests are performed. For many products, the increased quality guarantees that products with undetected failures will not be delivered to the customer.

Process faults could cause the shift of many parameters simultaneously. When this is a consideration, as is usually the case for ICs, the process parameters are monitored separately. If the process fails, the unit is rejected before the acceptance test is performed. Therefore, acceptance testing does not need to account for multiple parametric failure modes.

Initially, parts include the catastrophic failure modes that are defined in the Navy's CASS (Consolidated Automated Support System) Red Team Package.¹⁶ However, a simple interface is included that lets users edit the predefined failure modes or add their own catastrophic or parametric failure modes (for example, trace shorts, IC bridging or interconnect failures, solder splashes, low beta, and device coupling). The characteristics (open/short/stuck resistance) of each failure mode can be defined by the user.

Failure modes are simulated by generating the proper SPICE 3 syntax to describe the failure. Any node on a part can be shorted opened, or stuck to any other node. The stuck condition allows the user to attach a B element expression. The B element is the Berkeley SPICE 3 arbitrary dependent source that is capable of analog behavioral modeling ^11,12. The expressions can refer to other quantities in the design such as nodes and currents, thus creating an unlimited fashion in which to generate a stuck node. A series of examples are shown in Table 1.

All the failure mode definitions are carried out in a graphical manner. No script writing or programming is necessary in order to define or simulate a fault. There is no need for the user to write or know the required SPICE syntax, and the schematic is not altered when a fault is inserted.

Return to contents

Measurement Definition
In order to create a test, the user must combine a circuit configuration with a set of SPICE simulation directives. A desired measurement is made from the resulting data. Therefore, the simulator, or a data post-processing program, must be available to extract and store information from each desired test point waveform. The former was chosen for this tool and implemented using ICL that is available in SPICE 3.

The software uses the IsSpice4 simulation engine to perform the failure analysis. IsSpice4 engine includes and expands upon the standard Berkeley SPICE 3 ICL. ICL is a set of commands that direct SPICE to perform various operations such as running a particular analysis or changing a component value. The commands, which look and act like Visual Basic scripts, can run interactively or in a batch mode. IsSpice4 contains ICL functions that allow SPICE 3 plots, or sets of vectors (that is, waveforms) to be scanned and measured with imaginary cursors. In contrast to traditional SPICE "dot" statements, ICL commands are performed in order, one at a time. This makes ICL scripts perfect for describing test procedures.

A variety of functions are available for setting the cursor positions and for measuring and processing simulation results. In Figure 2, these measurement scripts are combined with traditional SPICE analysis directives and a test configuration description to form a simulatable IsSpice4 netlist. Virtually any measurement can be recorded on any voltage, current, or power dissipation waveform such as a maximum value, peak-peak value, rise/fall time, propagation delay, Iddq values, and Fourier coefficients.

Return to contents

Running The Failure Analysis
Before the failure analysis can begin, the test engineer will have to decide which tests to perform, how to set up each test, and the test limit boundaries. This last step can be time-consuming, especially if design specifications are not available. Therefore, special methods are available for setting limits on groups of tests using default tolerances, Monte Carlo simulation results or a unique "Expand to Pass" feature which pushes out the test limit boundaries. This last method allows the designer to easily account for variations in the environment or test equipment that might otherwise cause false failures on tests with tight tolerances.

Once the test limits are set, failure mode simulation can proceed one fault mode at a time or in an automatic fashion until all of the fault modes are simulated.

References

[1] Larry Meares, "Designing Tests Using Simulation", Evaluation Engineering Magazine, Parts I&II, April-May, 1998

[2] Charles Hymowitz, Larry Meares, Bill Halal, "New Techniques for Fault Diagnosis and Isolation of Switched Mode Power Supplies",1997 PCIM Conference

[3] Sharon Goodall, "Analog/Mixed Signal Fault Diagnosis Algorithm and Tool Review",1994 AutoTestCon Proceedings, pp. 351-359.

[4] W.R. Simpson and J.W. Sheppard, "Fault Isolation in an Integrated Diagnostic Environment, "IEEE D&T, Vol.10,No.1,Mar. 1993, pp52-66.

[5] C.Y. Pan and K.T. Cheng, "Test Generation for Linear, Time Invariant Analog Circuits, 3rd IEEE Intl. Mixed-Signal Testing Workshop, June 3-6, 1997.

[6] Harry H. Dill, "A Comparison of Conventional and Inference Model Based TPS Development Processes", AutoTestCon '95 Proceedings, pp 160-168.

[7] Harry H. Dill, "A Comparison of Conventional and Inference Model Based TPS Development Processes", 1997 AutoTestCon Proceedings.

[8] Jiri Vlach, Kishore Singhal, "Computer Methods for Circuit Analysis and Design", 2nd Ed., Van Nostrand Reinhold, 1994

[9] N.B. Hamida, K. Saab, D. Marche, B. Kaminska, and G. Quesnel, "LIMSoft: Automated Tool for Design and Test Integration of Analog Circuits", 2nd IEEE International Mixed Signal Testing Workshop, Quebec City, Canada, May 15-18, 1996.

[10] N.B. Hamida and B. Kaminska, "Analog Circuit Fault Diagnosis Based on Sensitivity Computation and Functional Testing", IEEE Design and Test of Computers, March 1992, pp.30-39.

[11] L.W. Nagel and D.O. Pederson, Simulation program with integrated circuit emphasis, ERL Memo No. ERL-M520, University of California, Berkeley, May 1975.

[12] B. Johnson, T. Quarles, A.R. Newton, D.O. Pederson, A. Sangiovanni-Vincentelli, SPICE 3F User's Guide, University of California, Berkeley, Oct. 1992.

[13] "IsSpice4 User's Guide", Intusoft, P.O. Box 710, San Pedro, CA 90733-0710, 1997.

[14] Fred Cox, W. Kuhn, J. Murray, S. Tynor, "Code-Level Modeling in XSPICE", Proceedings of the 1992 Intl. Syp. on Circuits and Systems, May 1992, IEEE 0-7803-0593-0/92.

[15] "XSPICE Users Manual", Georgia Institute of Research, Georgia Institute of Technology, Atlanta GA 30332-0800.

[16] CASS Red Team Package data item DI-ATTS-80285B, Fig. 1 - SRA/SRU Fault Accountability Matrix Table, pg 11.

[17] Intusoft Newsletter, Various Issues #51 Nov. 1997, #52 Feb. 1998, #53 April 1998, Copyright Intusoft 1986-1998

Author Biographies
Charles Hymowitz is the vice president of product development for Intusoft, a developer of analog and mixed signal simulation tools. He received his B.S. degree in Electrical Engineering from Rutgers University. He has done post graduate work at CSULB and UCLA. Mr. Hymowitz is the author of several books and numerous papers on SPICE, test program development software, and device modeling. He is the Editor in Chief of the industry standard SPICE publication, the "Intusoft Newsletter" and an avid circuit simulation enthusiast.

Lawrence Meares founded Intusoft in 1985 and currently leads the software development team responsible for the Test Designer, ICAP/4Windows and Magnetics Designer products. He has a software patent pending for his work on the ICAP/4 schematic capture program. Previously, Mr. Meares worked at McDonnell Douglas as a manager for a circuit design team and principal investigator for custom IC research. He received a B.S.E.E degree at the University of Santa Clara and completed graduate studies in electrical engineering at Seattle University and UCLA.

Bill Halal is a senior applications engineer for Intusoft. He received his B.S. degree in Electrical Engineering from California State University, Long Beach. He has more than a decade of hardware and software experience in the electronics industry; he has designed consumer audio electronics and has written test program development software for the aerospace industry. In addition to providing technical support and developing simulation models, Bill is responsible for much of Intusoft's user documentation, and has contributed to other publications related to SPICE simulation.

Intusoft P.O. Box 710, San Pedro CA 90733-0710. Phone: 310-833-0710.