Web Exclusive: Yield Loss: It’s Not All Process Defects

A comprehensive approach to test data management, which ensures the integrity of the data, maintains consistent test rules and identifies tester-specific problems, can eradicate product loss caused by the test process itself.

John Bearden, OptimalTest, Nes-Ziona, Israel -- Semiconductor International, 11/1/2007

Test has become a very critical process in the competitive world of deep submicron device manufacturing, where extremely small particulates can cause random fails. Systematic fails are on the increase as well. Therefore, test is no longer just thought of as a back-end process used to sort good devices from bad devices. Test is a driving force in the closed-loop IC improvement cycle (Fig. 1), the place where all available data regarding the behavior of the device can be brought together to isolate root-cause failure modes and locations. The success of this loop is the key to rapid yield and reliability learning, which is so important to time-to-profit.

1. Rapid yield and reliability learning depends on proper management of data at all points in the process to directly isolate the cause of failures.

Generally speaking, those in the semiconductor industry are familiar with major yield detractors that occur in the various fabrication process steps, as well as in design marginalities. However, the test process itself can also be a yield detractor. The negative impact of test can go undetected no matter where you are on the yield curve. Many IDMs and fabless companies do not realize that they are losing up to 5% of good product in their test operations. With today’s evolution away from vertically integrated IDMs, this yield loss can become not only more hidden, but also a more significant drag on profitability. Loss of product does not occur on just one or two products, but across the board. In the past, this loss of good product was thought to be extremely low and considered “collateral damage.” In other words, losing some good parts was thought to be unavoidable, considering the volumes, product mix, various test recipes/rules, retest/lots on hold, and number of insertions and handling.

But today there is no excuse for such yield loss. Although subtle issues at test can cause false rejections, yield loss is controllable. State-of-the-art test management software can help control yield loss by providing a clear picture of all aspects of the test floor, tracking what is happening to each device, and helping engineers make real-time decisions driven by accurate data.

Enterprise approach to yield loss detection

Closed-loop yield and reliability learning has been successfully practiced for decades. However, given modern IC technology and end markets, learning must happen more quickly with more accurate results. But because random and systematic defects are becoming much more subtle and difficult to detect, test results alone are inadequate to isolate some failure modes. Data must be used from the entire enterprise to get to the root-cause failure mechanism to provide corrective action to the fab. The difficulty increases with today’s business model of having chip design, fabrication, test and failure analysis partitioned across different companies in different regions of the world. An integrated network is critical to quick, precise data management and communication.

IDMs and fabless companies need to see yield/reliability learning as the key to effective, comprehensive test management. What’s more, test management must be viewed as a strategic initiative to collect, manage and leverage the massive amounts of data from the fab, electrical test, various test/burn-in insertions, data logging, diagnostics and failure analysis, as well as final assembly and distribution. It cannot be done piecemeal; it has to be a coordinated automated process with both real-time and offline capabilities.

This article will look at the specific situations where these data exchanges occur. Most important for the test manager is having real-time accurate data that can be trusted. This is not easily accomplished because, typically, software applications are developed at different times by different teams internally and externally. Differences in design techniques, architectures, technology and data formats are compounded by the “let’s keep modifying what we have” syndrome — cheaper in the short term, but more costly in the long term. Obtaining better yield can be a daunting task given an existing infrastructure, various software tools in use, multiple sources of data with format differences and customized applications throughout the operation. The good news is that several yield points are available in the short term while a comprehensive test management system is implemented across the enterprise for longer-term strategic benefit.

Opportunities lie on each test floor — by revealing process errors that were previously inaccessible and pinpointing the root-cause failure so it may be quickly addressed. Test centers, staffed by specialized engineers, have been continuously improved, becoming more effective, efficient and robust. Nonetheless, world-class test floors can reject several points of good yield available from the fab because of process errors in test operations.

1. Insufficient data integrity throughout the test sector
2. Mismanagement of test process rules
3. Subtle errors in the hardware/software of the various test cells

This article will identify some of the hazards in each of these areas and suggest opportunities for improvements.

Ensure the data's integrity

Data integrity starts with having a solid handshaking process for the transfer of all data. A look at the big picture of data flow and communications on the test floor (Fig. 2) shows that this is not easy because there are so many software applications (Table) active on the test floor, which interface to the rest of the enterprise, creating countless opportunities to lose or corrupt data. 

2. A solid handshaking process for the transfer of data from one area to another is crucial to the maintenance of data integrity.

Because the programs supporting these operations and data exchanges are often independently developed by different sources either internally or through third parties, the data formats can be unique for many applications. Often, there is no standardized handshake process for the data movement. For instance, sending data to failure analysis may require someone checking to see if the data arrived without corruption. Moreover, this process is repeated many times, multiplied by having thousands of active product part numbers. If all of these data exchanges were within one company at one location, the situation would be complicated enough. But today, operations are spread around the globe with locations constantly changing. Fabrication may occur at one or more locations; wafer test may or may not be done at the fab; chips are shipped to one or more assembly houses; testing may be done at the assembly house or a different location; and, finally, the product is sent to one or more distribution centers for delivery to multiple customer locations (Fig. 3). Along the way, the test results, data logging, diagnostics, failure analysis and quality monitoring must still happen, each with their own set of risks. For example, different test equipment will use different data references, which will require additional data transformations. These factors significantly escalate the risk of data integrity issues.

3. A chip can visit 16 or more unique geographical or company locations.

To avoid these compounded risks, test management solution should provide 100% data integrity no matter how many times and no matter where the data transfer occurs. When making decisions that will affect yield, there must be confidence that the analysis is based on accurate data. At this point, you may be thinking, “I don’t hear about data inaccuracies being an issue.” Unfortunately for your operation, this is probably true. As the saying goes, “You only get what you measure and only find what you look for.” If the test team knew where good product was rejected because of inaccurate data, it would be fixed. The reality is that exposure to data integrity issues needs to be explored by every company. The scope and breadth of the data management operations (the Table implemented across Fig. 3) demand tighter control. This is not about consistently missing data, but about subtle cases where data exchanges drop bits or certain conditions where the data is intermittent. This may cause a “hang-up” or “freeze-up.” All too many times the solution is basically a “reset” or “skip and continue” because it is not obvious where the real problem occurs. The solution lies in the software, which needs to monitor and flag errors in data exchanges and data management. The software must execute in a fully automated mode so that it can immediately take corrective action when pinpointing the problem.

Test rules play key role 

With all of these handoffs, it’s very easy to see how good devices are rejected when false information surfaces caused by data corruption.This can easily happen in the creation and execution of device-specific test rules. These include company-wide rules, as well as ones tailored for individual products. The rules can be developed according to the specifics of the device, the particular test insertion and the test program. As part of a new product introduction process, these rules are designed and developed via a rule-set generator. Some rules are used in real time at each test insertion; others are used offline after the test is completed. 

An important role of these rules is to provide control of the test process. Some rules enable test time reduction, improved quality via statistical process control (SPC) reliability screening or disposition of the product. Creating rule sets depends on the test engineer’s collaboration with the process engineer to use data from the fab (for example, from lithography, defect monitors and electrical test). This data can beoverlaid with test results from all insertions. This can be used in real time or data can be brought in from other devices, wafers and/or lots for offline analysis.

Importantly, these rules are running silently in the background and make automatic decisions that affect yield in real time. Test rules are absolutely necessary to run an efficient test area with hundreds of different products. They not only exert control over the test process, but can also leverage knowledge for yield and reliability learning. 

However, rules can negatively impact yield. Different engineers create rules at different times. Many are carried forward from one product family to another and combined. If rules are not created with a common template, they must be validated and checked as a set to make sure there are no conflicts between rules. They must also be executed in the proper priority. Many companies rely on manual intervention for rule validation and problem resolution, which is slow, prone to errors and inconsistent, as it depends on the engineer’s experience, thoroughness and skill set (for example, fluency with scripting languages). In addition, thousands of part numbers pass through a test center with a variety of routings and different technical and business requirements.

A comprehensive test management solution must have the flexibility to handle these variations and signal when human intervention is required. In production, the rule sets that execute in real time must have real-time reaction and control. It is very easy for conflicting rules to go unnoticed, resulting in conditions that reject good product. The risk is that, although the test operation seems to be running fine for periods of months, for instance, some good devices can be dumped into the reject bin because rules are not adequately validated or viewed as a complete set for that part number. Examples include:

• Retesting of die exceeding allowable number of touchdowns at probe
• Excess number of devices rejected in Parts Average Testing
• Rejecting die because of bad contact on a probe card

The longer these problems go undetected, the more false rejects occur and the root cause proliferates until the failure mode becomes obvious. At that point, the floor manager must figure out how long the problem existed and how much material needs to be retested. At wafer probe, retesting a couple of wafers is not unreasonable. But at high-volume final test, retesting is very time consuming and inefficient. The better alternative uses automated real-time software to detect and flag problems in their infancy

The rule set needs to be seen as a living, evolving collection of software guidelines. A common occurrence is to put the test rules in place and then assume that nothing happens to them. Simulating and validating the rules prior to publishing them is a necessary first step. During production ramp, the rules should also be frequently checked to assure they are doing what was expected. Then, as an ongoing quality check, these rules must be periodically validated. Because a change can be made that on the surface would seem to be correct but may conflict with another rule in the set causing a false rejection criteria, there needs to be an automated process to manage and control the rule sets, along with an auto-release process to copy results to all locations that use the rules.

Role of the test cell

The tester hardware is another source of subtle errors that can falsely reject good product. For example, an instrument in the tester causes an intermittent failure where measurement bits get stuck (“freeze”) and a measurement repeats itself with data that is not true. The stuck bit can cause a good chip to look like a fail. This random problem can go undetected unless the test management software is specifically looking for this pattern.

An advanced real-time (SPC) capability can monitor for a parametric consecutive bin limit. This involves monitoring each tester and testing each product with a full suite of SPC capabilities. This monitoring is made easier with test management software that can track the entire tester fleet’s performance. Tester problems can be isolated by comparing the bins and measurements across several testers processing the same product. Monitoring test equipment on all test floors, including outsourced facilities, provides a way to quickly tell if there is a problem with the hardware, program or process rules.

Customized hardware, such as probe cards and contactors, also require monitoring to ensure no unnecessary yield degradation. The comprehensive test management software has access to the tester data in real time and performs its analysis automatically. It immediately provides the resulting information to the appropriate personnel via dashboard, email or pager notification

Conclusions

The overall goal of effective test management is reducing false rejections caused by processes, procedures, data management and automated test equipment errors. There are potential sources for these false rejections anywhere there are marginalities in the testing process. This approach helps guarantee that test processes are accurate, repeatable and reliable. It allows development of a sophisticated, automated expert system that is capable of real-time decision-making across all operations, with built-in data mining and analysis that uses process and test knowledge to identify problems.

This article has explored only a few of the major sources of false product rejection. Unfortunately, there are others. In addition to the issue of yield as a test management challenge are the issues of test time reduction, utilization, reliability and quality. Best-in-class test management solutions offer innovative, proprietary methods and algorithms that, when properly implemented, offer significant returns on investment.

John Bearden supports U.S. business development efforts for OptimalTest. Previously, he was with IBM for 33 years, holding various test engineering and management positions. Bearden has a bachelor's degree in electrical engineering from Northeastern University (Boston) and an MBA from St. Michael’s College (Colchester, Vt.).
Email: john.bearden@optimaltest.com