Adaptive Test. 1.0 Adaptive Test definition

Transcription

1 Adaptive Test Adaptive Test use is increasing because of its ability to lower test cost, to increase yield, to provide better quality and reliability and to improve data collection for yield learning well beyond what has been possible historically with static optimization methods. Adaptive Test realizes these benefits by providing an infrastructure for continually optimizing IC test within the constraints of pre-defined rules. To fully exploit Adaptive Test, it is important to understand its general principles, as well as specific methods and skills required to use it. This document is intended to provide: 1) An introduction to Adaptive Test and a descriptions of emerging applications; 2) Specific examples of Adaptive Test applications that are in use today and others that will be in the future 3) A description of the challenges of Adaptive Test 4) The emerging requirements to ensure the industry is able to fully exploit Adaptive Test 1.0 Adaptive Test definition Adaptive Test is an industry term for the practice of going beyond the use of fixed limits and invariant test flows and operations, by using data that has been collected during the process of IC manufacturing to influence, change, or adapt how a device or system is tested, or to alter its manufacturing flow. Techniques such as Statistical Process Control (SPC) and Part Average Testing (PAT) are two well known methods, but there are many other techniques currently in use. (PAT is described in the AEC-Q001 documents at Adaptive Test is generally accepted as an advanced test strategy that can be used to achieve quality, yield, and cost goals that might not be reached by normal test methods. The intent of Adaptive Test is to increase the quality and reliability of products and to identify abnormal parts as early in the manufacturing sequence as possible (preferably at wafer test) and add tests or change test conditions to screen the riskier material. (There are also Adaptive test methods that may selectively skip test content on specific material to save costs.) Effective screening of riskier material can minimize costs related to customer support and failure analysis, and provide early feedback to prevent the occurrence of other quality incidents. Adaptive Test may modify a production test process in any of five ways: 1) Test Conditions (modifying voltage or clock frequency such as VDD) 2) Manufacturing Flows (adding or deleting test insertions such as burn-in) 3) Test Content (adding or deleting specific patterns or tests such as transition fault or IDDQ, respectively) 4) Test Limits (changing the pass/fail limits such as DC power or Vdd-min test specifications) 5) Test Outcomes (changing the binning of some die based on post-test analysis of the die s test results) In addition to rejecting the outright failing parts, manufacturing test is essential to meet the quality goals of outgoing manufactured parts. Adaptive Test offers new possibilities to detect and contain excursions and limit the effects of the excursion experienced by the customer. To do so, Adaptive Test must successfully navigate the risks associated with lower test times and higher yield by monitoring some of the manufactured parts with complete test flows. Adaptive Test applications can be categorized based on when the decisions to make one or more modifications listed and to which device(s) the modifications are applied. The four most common categories are in-situ, feed-forward, feedback and post-test. Figure XXX is a flow diagram depicting the relationships between these four categories. 1) In-situ: Data collected from the part being tested is used to modify the testing of the same device during the same test insertion. Speed grading is an example of the In-situ category where the data from the device is used to change the conditions of the test plan for the same device. Another example common to analog components would be trim and device calibration. 2) Feed-forward: Data collected from a previous test step stage (e.g. probe, hot probe, burn-in) is used to change how the same parts are tested at a future stage. An example of the Feed-forward category are statistical methods which identify risky dice or wafers and selects these components (only) for burn-in. 3) Feed-back: Data collected from a previous part (or parts) is used to modify the tests or limits of different devices yet to be tested. Skipping some test patterns on high yield wafers or adding more tests to low yield wafers, are examples of this category.

2 4) Post-Test: Data sample statistics or other analysis is performed between test steps and is used to reclassify certain devices or to change future manufacturing flow and test conditions for these devices. Part Average Testing and outlier identification methods are examples of the Post-Test category. Figure XX 2.0 Example Applications Below is a list of example Adaptive Test applications. Each example is labeled by one or two categories outlined earlier. In addition to clarifying the categories, the examples demonstrate the shift from manual and static methods to automatic methods with little or no human intervention during test execution. Note that the use of electronic die/chip ID (e.g., a die-specific identifier such as wafer/xy coordinate that is fused on each die) is a key enabler for many of these applications. 1) Dynamic test flow changes (In-situ, Feed-forward): Die production data is monitored within the test program to add or remove tests, to selectively perform per die characterization for yield learning, or to collect data for later diagnosis. This application supports many common real-time Statistical Process Control methods. 2) Statistical screening (Post-Test, Feed-forward): After wafer or lot data collection, identify die which are outliers or mavericks as possible sources of Defects per Million (DPM test escapes ) spikes or reliability failures. Statistical screening is Feed-forward because results can be used to route target dies through test flows different from the main flow. 3) Single-step flow control (Feed-forward): Data from one test step is used to optimize testing at the next test step to focus subsequent screening on issues observed in the manufactured parts. For example, inline-test modifies wafer-test; wafer-test modifies package-test; burn-in modifies final-test; or package-test modifies card/system-test. 4) Off-tester optimization of test flows (Feed-back): Off-tester data analysis drives test flow changes for future devices (fully automated). For example, off-line analysis could optimize test flows, test content and test measurement routines using input from many sources including historical data, test capacity, required turnaround times, DPM requirements, expected yields and parametric data. 5) Production monitors and alerts (In-situ, Feed-forward, Feed-back): Data from multiple sources is merged for statistical analysis to control production test optimization beyond what has historically been possible. For example, subtle parametric shifts from marginal wafer probe contacting can be automatically identified and action taken. 6) Die matching (Feed-forward, Post-test): Production data from various sources is used to support the build/test process for multi-chip applications and many of today s board build process to match specific die

3 combinations during assembly. Note die-matching data transfer may require world-wide data sharing, across multiple companies and throughout the entire supply chain. 7) On-chip test structures and sensors (In-Situ, Feed-forward, Feed-back): Data collected from auxiliary onchip test structures such as ring oscillators, selected critical paths, on-chip voltage and thermal sensors, or onchip reliability monitors is used to modify the die s test content, test limits or future test flow. 8) On-chip configuration (In-situ, Feed-forward): Production test data (including test structure data) is used to adjustment features in the design to improve die s performance, power, margin or reliability. 9) Card/System configuration and test (Feed-forward, Post-test): Component test results (such as parametric data, yield characteristics or partial good data) are used to customize the card/system test flow or customize card/system test conditions. 10) Adaptive Diagnostics (In-situ, Feed-forward): need to described based on Franco s input. 3.0 Adaptive Test Architecture / Flows Figure YYY displays a model of the entire End-to-End flow of parts under test and Adaptive Test applications. Note that there are feed-forward, in-situ, feed-back and post-test dispositioning opportunities at each test step. Although this figure shows a simple view of the database, the actual database structure would probably consistent of 2-3 databases levels each with unique capacity and latency capabilities. FAB ETest Optical Inspection Other inline data Assembly/Build Data RT A/O stands for Real-Time Analysis & Optimization which includes In-situ, Feed-forward and Feed-back categories Wafer Probe RT A/O stands for Post-Test Analysis & Dispositioning Assembly Operations RT A/O (includes any level of build or assembly operation) Burn-in RT A/O Final Test RT A/O Fab data Design data Business data Customer specs Databases & Automated Data Analysis ( Databases may include multiple databases throughout the supply chain. Analysis stands for any of the four categories of adaptive test.) Card/System Test Field Operation Part Flow

4 Figure YYY Adaptive Test Architecture / Flow 4.0 Levels of Adaptation & Data Model Making the decisions to adapt any of the test attributes listed above first involves collecting the right data (which test programs already do well) and then organizing the data into a structured data model so the right data can be accessed when and where it is needed. At the appropriate time, data of the proper scope, that is data from a particular test run or data from a particular part, wafer, or lot, is accessed from the data model and processed by the applicable decision algorithms. Similarly, the test variables, such as limits, conditions, flow, content, must be changed at the right time to complete the adaptation decision. The data model can exist entirely in a server database apart from the tester, or be distributed between servers and the tester depending on the latency requirements and convenience. Latency is the time between when data is available and when it was requested. To branch a test flow for a particular part (a real-time decision) latency must be short, i.e. there can be no significant impact to test time. To support low latency requirements, the data needs to either be stored on the tester or rapidly pulled into the tester. To make an outlier decision such as re-bin some already tested parts, longer latencies are tolerated such as from the time of test until the time material is shipped. Longer latencies mean an off-line database can be used. Decisions to adapt a test are often based on comparing the variation observed on the sample of parts in question to a model of the expected variation. In outlier detection, parametric test limits are adapted to track expected variation so as to only discard parts with unexpected variation. Tests can be temporarily dropped from a test flow when their control charts show the manufactured material and test process is in control and within specification. If and when monitoring based on sample testing shows the material or test process has changed and gone out of control, the tests are reinstated on every part. Similarly, diagnostic tests can be added to a test flow when certain types of failures occur more frequently than expected. A simple example of an expected variance model is the Gaussian distribution (mean and standard deviation) which is often used to identify outliers in static PAT. In static PAT the two parameters are determined by characterizing an earlier sample of parts. Static PAT makes the assumption ) the characterization parts and the parts currently tested are samples from the same Gaussian distribution and current part outliers are similar to the characterization outliers. Similarly, control chart Cp and Cpk values track when manufactured parts have gone out of control and can no longer be sample tested. A variance model and the decision based upon it can have varying levels of adaptability depending on the understanding of the sources of change and the scope of the data needed to establish a change has happened. For example in static PAT, outliers are any parts with test values greater than a predetermined multiple of the standard deviation computed from the characterization sample even if they are within the design or use specifications. Should the process shift, static PAT will discard many more parts. To account for lot or wafer process shifts, the mean and standard deviation can be recomputed for each lot or wafer. Called dynamic PAT, the variance model has changed to track each lot or wafer. Computing the distribution parameters for each wafer means the outlier decision-making is delayed until after the entire wafer s test response has been collected. In this example, the scope is said to be wafer-level. In general data, scope is the minimum sample that must be acquired before adaptive decision-making is possible for a test or collection of tests. Generally, more adaptability means more frequent decision-making in the test flow with the goal of improving the trade-off between defect level from freeing the guilty and overkill from convicting the innocent or balancing test false negative error rates and test false positive error rates, respectively. Adaptability follows a bottom-up progression from the conventional static limit, to static parameter variance model (static PAT), to a variance model with variable parameters (dynamic PAT), to choosing variance model equations based upon well-grounded principles. Moving up this progression requires not only more data but also a better understanding of the processes that cause the test response to vary. This progression also means the decision-making generally moves from an off-line human activity to an on-line machine activity. The decision algorithms used for Adaptive Test fall into several categories. These can be applied to data over a range of data scopes from a single part, to a wafer or a lot or more. 1) Adaptive Limits (Outlier Detection) a) Statistical Distribution i) Univariate Distributions of variables taken individually.

5 (1) Simple distribution parameters e.g., mean and standard deviation of Gaussian. (2) Robust distribution estimators e.g., IQR or Gaussian. (3) Difference methods e.g., adjacent rank delta. ii) Multivariate Distribution of multiple variables taken collectively. (1) Functional dependence e.g., linear regression. (2) Joint variation e.g., principal or independent component analysis. b) Spatial (Geographic) i) Single wafer same wafer as die in question, e.g., nearest neighbor & location averaging ii) Wafer stack same x, y location as die in question, e.g., compare values across wafers for same x, y iii) Combined same wafer and wafer stack e.g., unit-level predicted yield (ULPY) 2) Adaptive Flow or Test Content a) Control charting Probability of sequential occurrences b) Cluster (commonality) analysis c) Bayesian methods Another classification is between continuous variables (parametric tests) and discrete variables (pass/fail tests and yields). 5.0 Adaptive Test Infrastructure (data exchange, databases, etc.) Adaptive Test involves making decisions throughout the manufacturing process with algorithms of varying complexity using data of varying detail from multiple sources. Therefore it requires structuring more data in new ways for new uses compared to traditional testing. Adaptive Test data processing happens at various levels, as indicated in Figure YYY. Local processing in the test cell requires low latency. ) For example access latency should be in a few milliseconds, if data is to be retrieved on a per device level (Real-Time Analysis & Optimization (RT A/O). Post-Test Analysis & Dispositioning () applications may have latency requirements of a few seconds to a few minutes. Normally data volumes for these steps would be relatively small. Processing in a central database (e.g., The Cloud ) has more relaxed timing constraints (minutes, hours), but typically deal with much larger data volumes Since Adaptive Test decisions affect the quality of shipped goods, data retention requirements depend on specific market requirement (which may exceed 10 years in some cases). While we grow to be increasingly more comfortable with cloud based solutions in many areas, the test cell integration of Adaptive Test algorithms may prove to be one of the most challenging applications. Historically, decisions made local to the test cell (such as clean probe-card now) were mainly designed to guarantee the test cell health, hence were under the sole responsibility of the test floor. Adaptive Test changes this paradigm in a number of ways: Algorithms will be owned by multiple involved parties, including wafer fab, design house and test floor. Some algorithms may originate from commercial providers, others from the involved parties themselves. They all need be executed smoothly next to each other in a real-time environment. Data collection as well as data access (e.g., to upstream data in case of data feed-forward) becomes a mission critical task of a test operation as well as the entire supply chain. This challenges the reliability of the underlying infrastructure, which likely spans multiple companies, geographic areas and cultures. Likely, one wants to simulate the impact of algorithms on historical databases to understand how to maximize the value of Adaptive Test without creating adverse side effects. This requires the exact same algorithm to be executed in as diverse environments as a cloud database and a test cell measuring real-time data. As a consequence, industry needs to develop APIs to allow algorithms to plug into a diverse set of environments. Data exchange formats which are flexible, compact and standardized so that only minimal extraction and translation effort is required. A common set of indices is required, such that data remains identifiable and traceable even across heterogeneous supply chains.

6 Recipe management systems which can handle a diverse set of recipe origins, check for (likely un-intended) interactions and maintain consistency across non-synchronized update cycles from the various origins. Version control systems for these recipes are also required. Execution systems must be enabled to monitor the health of Adaptive Test algorithms (are basic assumptions met?) and escalate errors to the right entities in an actionable format. 6.0 Implications for ATE and the Test Cell Historically test cells have been little more than pass fail filters with the ability to log test results. With the emphasis on test cost the innovations in test have been focused on reducing necessary tests, testing more devices in parallel and reducing the capital cost of equipment. Even with these efforts the reduction in the cost of test has not kept pace with the cost reductions seen elsewhere. For Adaptive Test to be seen as a viable addition, the test cell needs to change to support its needs without additional test cost while at the same time reducing overall costs. Much like memory test, it is expected that future devices will include redundant sections, repairable subsystems and software-driven calibrations. With these options available, Adaptive Test will be needed to optimally configure and test these parts. At the same time precision measurements will be needed for feed back to prior process steps enabling end to end process optimization. This will force a move from statically determined tests and flows to dynamic (per device) flows. We see future test cells which can perform the following: Per device test flows based on external inputs, the device itself, and dynamic business rules Zero cost logging of data for use in the Adaptive Test process in a database like format A move from being the entire cell controller to a test engine with a standard API Support for asynchronous and distributed (multi-insertion) test flows For analog & mixed-signal devices -- the ability to perform structural (model-based) testing over functional Status The CAST group within SEMI is in the process of developing standards for data collection and test cell control. ( ) There are many devices which currently use software driven calibrations. There are some examples of model based testing as a faster alternative to functional testing It is generally left to the test programmer to adapt existing test cells to support these features. 7.0 Test results driving Adaptive Designs More and more designs are being reconfigured during testing. Examples include partial goods (on-chip redundancy), VDD/frequency adjustment and local clock tuning. In most cases this product personalization will be based on either test measurements or data feed-forward from other operations. In some cases, this reconfiguration will be based on application demand. 7.1 Testing resilient features Resilient features are on-chip structures which can be used to configure the product to work around hard defects or confer tolerance to latent defects. These structures span a wide range of circuits and architectures, including fuses, redundant memory elements, architectures capable of operating on reduced numbers of logic elements like CPU cores or graphics components, error-detection and -retry schemes for hard and soft errors, and the sensing and control circuitry for adaptive designs. Like every other circuit, these structures must be themselves tested and characterized, though these circuits present unique testing challenges beyond standard logic and memory elements, including temporary configurations (for fuses), soft-repair vs. hard-repair validation (for memories), combinatorial explosion of down-cored variants of redundant features, the need for error injection to test recovery circuits, and analog stimulus for sensors (such as voltage or aging monitors). 7.2 Non-deterministic device behavior: test and run time availability Non-determinism is incompatible with traditional cycle-accurate automated test equipment, but is nonetheless becoming typical on modern SOCs. Several new I/O protocols are non-deterministic, as are the standard methods to avoid metastability in clock-domain crossings (which are commonplace in highly integrated devices). Fine-grained power gating and power-state management can change the configuration of a device and its execution profile during test and

7 normal operation. Adaptive designs take this notion even further with architectural features which can perform state rollback and pipeline retry based on events at arbitrary times during execution. The result is that test patterns, particularly functional patterns which execute in mission mode, must either prevent or be tolerant of non-deterministic response. The former raises coverage questions, the latter pattern and ATE interface challenges. 7.3 Testing adaptive designs For adaptive designs, establishing the operating point and electrical margin of an SOC, or portions thereof, is no longer an event done once on the test floor. Instead, on-chip sensors are used to detect the workload, voltage, temperature, and timing margin of the chip as it operates and dynamically adjusts power supplies, clock frequencies, thermal control, and even the instruction stream. Not only does this approach require careful testing of the (interrelated) feedback control system components, it also runs counter to the traditional ATEcentric method of measuring at fixed corners to verify performance parameters and could introduce a much larger space over which the device must be tested. The adaptive features of a design make it much harder to define (and thus characterize) both typical and worst-case use models, which in turn makes it more difficult to test appropriately. Furthermore, the removal of excess margin represented by traditional guardbanding increases the risk of exposure to subtle defects, necessitating both higher coverage and better correlation between structural and functional test modes. An emerging direction is to apply Adaptive Test techniques (which modify the parameters or content of a test program based on information collected about the device under test from the current or previous test insertions) to adaptive designs (which modify their own operating point or execution flows based on internally generated feedback). The proclivity of an adaptive design to compensate for the environment in which it is being (functionally) tested will present challenges for data gathering by the Adaptive Test process. Possible solutions involve disabling the adaptive design features and treating the device as if it were static or allowing adaptation by the design, but always monitoring and logging the adaptations as part of the data supplied to the adaptive test process. 8.0 Adaptive Manufacturing An emerging direction is using test results to drive other IC production steps such as packaging multi-chip products. ) For example, the card/board assembly operation may require that specific dies or types of dies to be used on specific boards based on previous test results. Given the emergence of multi-chip packages (such as 3DICs) and power constraints, specific bare dies will need to be selected for assembly based on parametric data collected at test such as IDD or power/performance measurements. Key challenges of End-to-End data feed-forward for assembly operations include: Cross company data management Robust data availability Data security Full traceability Data format standardization 9.0 Implications of Adaptive Test for Card/System/Field Adaptive Test methodologies described in this document for IC level testing can be equally extended and applied to board and system testing and even field usage. While ICs have traditionally been tested standalone in an almost noisefree ATE environment and/or tested with limited structural tests to see whether they perform to their specifications, the board/system environment can be quite different in terms of noise, timing margin, voltage and functional test trigger conditions that structural tests were unable to produce. Improved board yield and IC DPM can be improved significantly where adaptive test that includes the board/system level performance is able drive enhanced screening both at the IC suppliers test and/or board/system manufacturing test. The four types of Adaptive Test described in Section 1 (In-situ, Feed-forward, Feed-back and Post-test) can all be extended to include the board and system manufacturing. Some examples of adaptive test methods for board and system include: The feed-forward application could be where specific fabrication process and component test parameters (e.g. Vdd-min or wafer x,y location) are included in the board test program to make decisions on whether to add in specific extra coverage to test for marginality.

8 The feedback and post-test applications might be where a pareto of the board level failures per Electronic Chip ID of a specified component type are sent to the supplier, so they can analyze whether certain fails correlate to any of the fab and test parameters. If so, then the supplier can adjust their tests or bins. In-situ test could be where the reading of an on-chip sensor for voltage or temperature might enable more or less stressful board conditions to be applied to check for margin and performance. On-chip sensors can also be read during field usage to monitor aging, and data can be sent back to the suppliers to adjust their test limits. One of difficulties to extend the chip-level adaptive test to board/system or even in-field test is to track their test trigger conditions and be able to convert between them. For example, chip-level scan-based logic gate test may not be always applicable for board/system/in-field tests due to the difficulties or impossibilities to control the scan chain data, clock pulse, non-stoppable in-field online function executions, etc. Similarly, a functional execution, which can be treated as a functional test may be hard to convert to a chip level ATE test because the function execution could involve memory contents, their transactions, logic and I/O data flow, etc. Therefore, tracking the test/failure conditions and the capability to convert between them is the key for adaptive test extension to board/system level. IEEE provides guidance here; the new update enhances for Adaptive Test by standardizing infrastructure needed for tracking and in-situ board level test of an IC. Tracking is performed by the standardization of the Electronic Chip ID in the standard. In-situ board level test of an IC is supported by the standardization of IC reset control necessary for internal IC initialization (via IC_RESET instruction) and I/O isolation (via CLAMP_HOLD) such that the I/O are isolated from noise and system level activity while IC level test patterns are applied. The architecture is such as to mitigate false failures which would exacerbate the problem of good data collection for Adaptive Test. While all the above examples are useful and feasible, they require extensive data infrastructure, analysis, exchange and security. Companies providing ICs, board design and test need to openly collaborate on a technical and business level to be successful. Table - Implications of Adaptive Test ) Challenge IT Infrastructure Traceability Real-Time Communications Development of Improved Models & Algorithms Required Direction Infrastructure to enable the Adaptive Test flow End-to-end supply chain data integration including data from Fabs, Test Houses and other Subcons. Develop supply chain data integration and processes which automatically detect supply chain issues and implement corrective actions in near real-time. Integrate multiple databases, flexible logistics system, and full part tracking at each test step, and feed-forward/feed-backward data flows. Enable full traceability of Adaptive Test parameters (limits, content, flows, and rules) for each die. (accessible anytime in future) Electronic chip ID is a key enabler of traceability Develop tester-to/from-data analysis engine communication without significantly impacting test time. Development of methods where the models are not fixed instead the models are dynamically adjusted based on DUT responses. Develop peripheral coverage metrics and associated quality impact of dropped or modified tests. More encompassing fault coverage metrics are required particularly for analog circuits.