You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!
Welcome to the newest forum on SemiWiki: Silicon Test and Yield Analysis! We’re all glad that you stopped by. Our hope is that this forum can be place for product engineers, test engineers, yield engineers, failure analysts, and process engineers to come together and ask and answer questions of each other. Our measure of success will be that members can come here, ask questions, get answers, and do their jobs better as a result. Our belief is that everybody already knows a lot about something that somebody else is currently struggling with. In the words of William Gibson: “The future is already here — it's just not very evenly distributed.”
This leads us in to our first question: What does Silicon Test have to do with Yield Analysis?
Ultimately, test is the ultimate arbiter of yield. If a die on a wafer fails testing by the ATE, it will not be shipped to a customer. As such this means that it’s a great jumping off point for yield learning. The least sophisticated and most common test metric used in yield learning is the die’s hardbin. On the other extreme are bleeding edge electrical fault isolation methodologies like bitmap classification and scan-based Diagnosis Driven Yield Analysis (DDYA). In any case, data about the chip is collected from the ATE and considered offline in an effort to understand why the silicon isn’t behaving the way it’s expected to.
Interestingly, regardless of the sophistication of the data collected by the tester, everybody downstream depends on this data to do their jobs. The test engineer uses hardbin data to optimize the test program ordering. The yield engineer uses the results from the bitmap classification to track issues. The failure analyst uses results from scan diagnosis to localize the defects. What makes this interesting is that the richer the data coming off the tester, the better everybody can do their respective jobs.
So my question is, on a daily basis do you require test data to do your job, and if so do you believe that richer data can improve your results?
In my circuit design days I worked at Intel and did DRAM design, so yield was a huge motivating factor in becoming profitable and getting to volume. In fact the yield was so important that management even considering eliminating the five locations on the wafer where we placed test chips to help us measure where the process was on that wafer. Through a process of Low Yield Analsysis we identified a 5% loss caused by electromigration failures on the DRAM however we never really understood the mechanism that was causing the EM failure, then Intel eventually exited the DRAM business entirely because the Japanese had a much superior product with higher densities, faster access, and longer refresh periods. We presumed that the Japanese memory companies were simply doing a much better job of testing their parts and therefore had fewer failures in the field.
I say Yes, richer data does improve your results and may be the only reason that you stay in business.
Chin Wong • You look for two kind of failures, parameter and castro. Sometimes, bitmap would reveal what cause of the failure by inspecting its pattern.
The quality of the test data definitely makes a difference in the likelihood of sucess. Binning information only gives a small part of the story, since failures are generally binned into the first failure type. There are sometimes test program errors attributing a test failure to an inappropriately named bin. Having a process in place that saves and processes data logs is invaluable for any product not consistently attaining its yield goals. (Continue-on-fail data logging gives better data than stop-on-fail because the correlation of failures or distributions gives insights into the root cause.) You'll want to correlate the test failures with the wafer PCM data as a first step. This can be a labor intensive statistical analysis requiring a lot of knowledge about the design and the process steps because so many process related variations are highly cross-correlated. Work with fab process engineers and circuit design engineers to develop hypotheses on root cause and corrective alternatives. Often a DOE in the process or design space will be required before you settle on the best corrective action. On a good day you find out you just had a test-related problem that is easily corrected at minimal cost. On a bad day you find a mismatch between your design topology and fab process capabilities, which requires a redesign. Better luck next time.
The quality of the test data definitely makes a difference in the likelihood of sucess. Binning information only gives a small part of the story, since failures are generally binned into the first failure type. There are sometimes test program errors attributing a test failure to an inappropriately named bin. Having a process in place that saves and processes data logs is invaluable for any product not consistently attaining its yield goals. (Continue-on-fail data logging gives better data than stop-on-fail because the correlation of failures or distributions gives insights into the root cause.) You'll want to correlate the test failures with the wafer PCM data as a first step. This can be a labor intensive statistical analysis requiring a lot of knowledge about the design and the process steps because so many process related variations are highly cross-correlated. Work with fab process engineers and circuit design engineers to develop hypotheses on root cause and corrective alternatives. Often a DOE in the process or design space will be required before you settle on the best corrective action. On a good day you find out you just had a test-related problem that is easily corrected at minimal cost. On a bad day you find a mismatch between your design topology and fab process capabilities, which requires a redesign. Better luck next time.
What you've written is very insightful. You specifically mention the limitations of the fact that everyone performs stop-on-first-fail for test time reasons. I've seen many cases where a systematic defect was observable in the bin data of memory test and the logic test, but only 1 of the 2 were known initially because the testing didn't was stop-on-first-fail (so you couldn't build a Venn diagram) and only the first test in the test program was binned. Is there is a major advantage to having a Venn diagram of all failing tests, or is it sufficient to know that it fails once and chase down correlations from there?
cost-benefit, continue-on-fail versus stop-on-fail
Hi, Chris.
The additional information from a continue-on-fail testing data log will not only help you isolate the problem during debug, but can help in estimating the payback of a fix, as the next failure mode in the Pareto diagram of failures becomes predominant. The uncertainty and variability of the failures may shift you more to a "fuzzy-logic set theory" approach than a Venn diagram, but your point is still valid in the debug process. It boils down to a cost-benefit analysis on your yield improvement efforts. Part of the prioritization of effort depends upon how much the low yield is impacting your profits. The yearly cost of low yield on a product could be estimated as (Yield Goal% - Achieved Yield%)*(Sales Volume $)*(1- Sales Margin %) For a low volume product run infrequently, it will speed up your improvement efforts to run continue-on-fail, else you may wind up waiting for months for your next opportunity to investigate. For a product that runs all of the time, it's easier to run stop-on-fail until you hit a low yield lot, and then implement continue-on-fail as part of your investigative effort.
The quality of the test data definitely makes a difference in the likelihood of sucess. Binning information only gives a small part of the story, since failures are generally binned into the first failure type. There are sometimes test program errors attributing a test failure to an inappropriately named bin. Having a process in place that saves and processes data logs is invaluable for any product not consistently attaining its yield goals. (Continue-on-fail data logging gives better data than stop-on-fail because the correlation of failures or distributions gives insights into the root cause.) You'll want to correlate the test failures with the wafer PCM data as a first step. This can be a labor intensive statistical analysis requiring a lot of knowledge about the design and the process steps because so many process related variations are highly cross-correlated. Work with fab process engineers and circuit design engineers to develop hypotheses on root cause and corrective alternatives. Often a DOE in the process or design space will be required before you settle on the best corrective action. On a good day you find out you just had a test-related problem that is easily corrected at minimal cost. On a bad day you find a mismatch between your design topology and fab process capabilities, which requires a redesign. Better luck next time.
I am stealing your words to add to mine at a client site who has taken 3 years to get IT priority to start saving datalogs and loading critical parameters and limits and bin definitions into a yield management DB. Since they started, problem solving has accelerated, but only on the products that management prioritized for this effort. So they are picking up steam....but your comments added to mine may give them renewed energy.
Correlating PCM to ATE Test parameters - Not an easy task!
Dear Glenn,
I am new to this site, but I am impressed on your post as you had summarizes most and toughest part of the "Yield Improvement" initiatives; I believe all test/products engineers have this Key Performance Index in their annual performance review! To really zoom into correlating PCM with ATE test parameters is not an easy task, can you please share some tips on where to start and perhaps some white paper or technical write-ups will be very helpful! Thanks in advanced.
The quality of the test data definitely makes a difference in the likelihood of sucess. Binning information only gives a small part of the story, since failures are generally binned into the first failure type. There are sometimes test program errors attributing a test failure to an inappropriately named bin. Having a process in place that saves and processes data logs is invaluable for any product not consistently attaining its yield goals. (Continue-on-fail data logging gives better data than stop-on-fail because the correlation of failures or distributions gives insights into the root cause.) You'll want to correlate the test failures with the wafer PCM data as a first step. This can be a labor intensive statistical analysis requiring a lot of knowledge about the design and the process steps because so many process related variations are highly cross-correlated. Work with fab process engineers and circuit design engineers to develop hypotheses on root cause and corrective alternatives. Often a DOE in the process or design space will be required before you settle on the best corrective action. On a good day you find out you just had a test-related problem that is easily corrected at minimal cost. On a bad day you find a mismatch between your design topology and fab process capabilities, which requires a redesign. Better luck next time.
