Creating a Signal Bin Filter to Remove Erroneous Data

Michael Davis – Semiconductor Application Engineer, Delaware OH

Problem Statement

Tool: 200mm Chemical Mechanical Polish (CMP)

General: The polish head spin speed Status Variable ID (SVID) in revolutions per minute (RPM) is intermittently reported as “zero” during the main processing step of a tool recipe. The complication is that the tool is actually reporting a number, zero, and not reporting an empty value when data is dropped. Because the tool is reporting zeroes, subsequent statistical calculations are incorrect and produce false processing failures. We need to develop a filter that will eliminate the incorrect data points and produce valid statistical calculations. This filter is easy to create and propagate using the Signal Bin interface of FabGuard.

Solution

Head RPM Filtering
When the Head RPM variable is noticed to be reporting zeroes instead of real data, the first activity performed was to verify in the communication log that the tool was returning zero values from Status Variable Identification (SVID) 208. As expected, the tool was responding with zeros during this time of the process (Figure 1.)

Additionally, two other parameters were also reporting zeros and were part of the same SVID, just different elements in the string, Platen RPM [index1] and Inner Tube State Set Point [index2] (Figure 2.)

The filter was created using a Signal Bin in FabGuard. There are four conditions that need to be met in order to determine if the data can be ignored. If all four conditions are met, then a “0” is placed on the Signal Bin stack, if not, then a “1” is placed on the stack (Figure 3.) Setting rigid conditions reduces the chance that valid readings of zero will be eliminated. The four conditions are:

1. Head RPM must equal exactly ZERO.
2. Platen RPM must equal exactly ZERO.
3. InnerTube State Set Point must equal exactly ZERO.
4. Step Number must NOT equal ZERO (This makes sure the tool is processing).

A Drop Out Filter Counter was also created to see how often this issue was occurring during a run. The count increases every time the RPM Drop Out Filter passes through a level of 0.5 (Figure 4.)

Figure 5 shows a report of the RPM Drop Out Filter counter. The interesting fact is that only tools 403, 404, and 405 have this issue and it happens quite frequently. Although this article does not address the issue of root cause, this problem could result from a specific tool software revision or hardware configuration. The report also highlighted an additional problem where the Drop Out filter was being triggered at the end of a process run. This is the reason for the trim of the last two points at the end of the Drop Out Filter’s Signal Bin (Figure 6.)

Once the RPM Drop Filter logic was validated, it was implemented through simple logic to pass only the RPM data if the filter was equal to 1. Four Signal Bins were created, one for each Head RPM data Bin (Figure 7.)

Tool Platen Recipe Consolidation Using FabGuard’s Acquisition Dictionary
After the filter Signal Bin development was complete, the next issue was how to populate these Filtered Head RPM Signal Bins to all platens on all tools. The challenge was that each platen on each tool had its own recipe, 15 data collection recipes in total. Through the use of FabGuard’s Acquisition Dictionary, the runs were imported from each tool to create the Alias Bins for each Platen (Figure 8.) Not only did the Acquisition Dictionary consolidate from 15 recipes to 5 recipes, one platen recipe for each of the 5 tools, the variable names used in the recipes were standardized into a single naming convention (Figure 9.) After testing the current consolidation, these 5 tool recipes could be further consolidated to 1 recipe used by all platens.

Report Results
The Signal Bin filter had a significant impact on the statistics calculations for the Head RPM data (Figure 10.) The Report limits do not need to be artificially wide in order to prevent false failures from erroneous data.

Conclusion

Using FabGuard’s Signal Bin and Acquisition Dictionary interfaces allowed us to quickly and easily develop and deploy a filter that would eliminate bad data when the tool reported the data value incorrectly. The calculated statistics became more reliable and the factory FDC was improved.