JP2005532671A - Manufacturing data analysis method and apparatus - Google Patents

Abstract

A method of data mining information obtained at an integrated circuit manufacturing factory ("factory"), comprising: (a) one of a system, tool, and database that generates or collects data from the factory Collecting data from further, (b) formatting the data, storing the formatted data in the source database, and (c) data for use in data mining according to a configuration file specified by the user (D) a step of data mining the extracted part of the data in response to the analysis configuration file specified by the user, and (e) storing the result of the data mining in the result database. And (f) providing access to the results.

Description

  One or more embodiments of the present invention include, but are not limited to, information obtained in, for example, an integrated circuit (“IC”) manufacturing or assembly plant (hereinafter “semiconductor manufacturing plant” or “factory”). The present invention relates to a method and apparatus for analyzing

  FIG. 1 shows a yield analysis tool infrastructure that exists in a prior art integrated circuit (hereinafter “IC”) manufacturing or assembly plant (hereinafter “semiconductor manufacturing plant” or “factory”). As shown in FIG. 1, the mask shop 1000 produces a reticle. As further shown in FIG. 1, a work progress tracking system 1020 (hereinafter “WIP (work-in-progress) tracking system 1020”) is used to manufacture (and test) ICs on a wafer or substrate. Track the wafer as it progresses through the various processing steps in the factory. In this specification, the terms “wafer” and “substrate” are used interchangeably and shall mean, for example, but not limited to, all types of semiconductor wafers, including glass substrates, or substrates. . The WIP tracking system 1020 includes, but is not limited to, an implant tool 1030, a diffusion / oxidation / deposition tool 1040, a chemical / mechanical planarization tool 1050 (hereinafter referred to as “CMP tool 1050”), a resist coating tool 1060, for example. (For example, but not limited to, a tool for coating photoresist), a stepper tool 1070, a developer tool 1080, an etching / cleaning tool 1090, a laser test tool 1100, a parameter test tool 1110, a wafer classification tool 1120, And tracking the wafer through the final test tool 1130. These tools represent most of the tools used in factories that produce ICs. However, these are merely examples and do not limit the present invention.

  As further shown in FIG. 1, the factory includes many systems for obtaining tool level measurements and for automating various processes. For example, as shown in FIG. 1, the tool level measurement and automation system enables tool level measurement and automation tasks such as, for example, processing tool management (eg, process recipe management) and tool sensor measurement data collection and analysis. A tool database 1210 is included. For example, but not by way of example only, the PC server 1230 downloads process recipe data to the tool (through the recipe module 1233) and receives tool sensor measurement data from the tool sensor (from the sensor module 1235). The process recipe data and the tool sensor measurement data are stored in the tool database 1210, for example.

  As further shown in FIG. 1, the factory includes a number of process measurement tools. For example, defect measurement tools 1260 and 1261, reticle defect measurement tool 1265, overlay defect measurement tool 1267, defect review tool 1270 (hereinafter referred to as "DRT1270"), critical dimension measurement tool 1280 (hereinafter referred to as "CD measurement tool"). 1280 ″), and a voltage contrast measurement tool 1290, which are driven by a process evaluation tool 1300.

  As further shown in FIG. 1, an application specific analysis tool drives a process measurement tool. For example, the defect manager tool 1310 analyzes the data generated by the defect measurement tools 1260 and 1261, the reticle analysis tool 1320 analyzes the data generated by the reticle defect measurement tool 1267, and the CD analysis tool 1340 is analyzed by the CD measurement tool 1280. Analyzing the generated data, testware tool 1350 analyzes the data generated by laser test tool 1100, parametric test tool 1110, wafer classification tool 1210, and final test tool 1130.

  As further shown in FIG. 1, the database tracking / correlation tool obtains data from one or more of the application specific analysis tools through a communication network. For example, the statistical analysis tool 1400 obtains data from, for example, the defect manager tool 1310, the CD analysis tool 1340, and the testware 1350 and stores the data in the relational database 1410.

  Finally, the yield management methodology is applied to the data stored in the data extraction database 1420. This data is extracted from the WIP tracking system 1020 and the tool database 1210 through a communication network.

  In the prior art, the yield management system used in a factory has many problems. FIG. 2 shows a prior art process used in a factory, which is hereinafter referred to as end-of-line monitoring. End-of-line monitoring is a process that uses a “trailing indicator” feedback loop. For example, as shown by box 2000 in FIG. 2, an end indicator such as, but not limited to, low yield, low quality, and / or device slowness is identified. The “bad lot” metric (ie, the measurement associated with the wafer lot that generated the end indicator) is then compared in box 2010 with the metric specification (hereinafter, the specification). If the metric is “out of spec”, the process proceeds to box 2030 where the action for the “out of spec” event is performed and feedback to correct the “out of spec” condition is provided to the process control engineer. On the other hand, if the metric is “in specification”, the process proceeds to box 2020 where the past history of plant knowledge for the failure is analyzed. If this is an already identified problem, the process proceeds to box 2040. If it is not an identified problem (ie, no prior knowledge exists), the process proceeds to box 2050. In box 2040, an operation is performed on a lot or tool comment associated with an already identified problem and feedback is provided to the process control engineer to perform the same type of operation as previously performed. As shown in box 2050, it is determined whether there is a correlation between the tool or device processing history data and the failure. If a correlation is found, the process proceeds to box 2060, and if no correlation is found, the process proceeds to box 2070. In box 2060, the “bad” tool or device process is “fixed” and feedback is provided to the process control engineer. In box 2070, a factory maintenance job is performed.

  There are several problems associated with the end-of-line monitoring process described above. For example, (a) low yields often occur due to some problems, (b) the “spec” limit is often reached due to theoretically unconfirmed reasons, and (c) knowledge of past product failure history is documented. Are often not documented, or even if documented, the document is not widely distributed, (d) data and data access are fragmented, and (e) work before performing correlation analysis Hypotheses must be generated, the number of correlations is very large, and the resources used to perform the correlation analysis are limited.

  For example, a typical engineering process for data feedback and problem fixing typically includes the following steps. (A) Define the problem (the typical time it appears is about one day), and (b) select key analysis variables such as, for example, yield percentage, defect percentage, etc. (Typical time of appearance is about 1 day), (c) form a hypothesis about the selected key analysis variable anomaly (typical time of appearance is about 1 day) and (d ) Rank hypotheses using various “gut-feel” methods (typical time for this to appear is about 1 day), and (e) develop experimental strategies and experimental test plans (Typical time for this to appear is about 1 day), (f) Perform experiments to collect data (Typical time for this to appear is about 15 days), (g) Fit the model (typical time for this to appear is about 1 day) (H) Diagnose the model (typical time it appears is about 1 day), (i) interpret the model (typical time it appears is about 1 day), ( j) Run a confirmation test to confirm improvement (typical time for this to appear is about 20 days), or if no improvement is seen, start the next experiment starting from (c) (Typically including 5 repetitions). As a result, the typical time to fix a problem is about 7 months.

  As line widths are reduced and newer technologies and materials (eg, copper metallization, and new low-k dielectric films) are used to make ICs, defects (its processing or induced contamination) are reduced. This is becoming increasingly important. Time to eradicate the cause is the key to eliminating the defects. These problems are less easily transferred to 300 mm wafers. Thus, yield ramping is becoming a major obstacle, with much converging at the same time.

  In addition to the above-mentioned problems, semiconductor factories are further challenged with investing large amounts of capital in defect detection equipment and defect data management software as part of their efforts to monitor defects and continue to reduce defect density. Current prior art in defect data management software includes the development of one or more of the following deliverables. (A) defect tendency (eg, paretos by defect type and size), (b) wafer level defect versus yield chart, and (c) special and manual kill ratio by type and size. The main flaw for each of these deliverables is that he / she must have prior knowledge of what the user wants to plot. However, since the data is too large, the probability that the user will try to eradicate the cause is low. Furthermore, even if charts are generated for each variable, it is virtually impossible for the user to analyze each of these charts if the number of charts becomes enormous.

  In addition to the problems described above, there is a problem that most of the data used in the semiconductor factory is “indirect measurement data”. “Indirect measurements” in this context are data collected with indirect metrics, which are related to the manufacturing process in the factory in a predictable manner. For example, after patterning metal lines on an IC, a critical dimension scanning electron microscope ("CD-SEM") is used to measure the width of the metal lines at various locations on a given set of wafers. Can do. One business value can be assigned to the metrology infrastructure in the semiconductor factory. This is related to how quickly the measurement data measurement is turned into information that can be actuated in order to stop the process of “towards the defect” in the factory. In practice, however, indirect measurements involve enormous potential problems, and these problems often lack an explicit relationship that specifies an “active” factory processing tool or processing tool processing state. The lack of a clear relationship between the processing toolset and most indirect measurements at the semiconductor plant requires significant investment in the engineering stuffing infrastructure and is required to establish the relationships in the causative data Significant “scrap” material costs result from unpredictable time frames.

  In addition to metrology, significant capital has been invested within the last few years to develop data extraction systems designed to record the operating status of semiconductor wafer processing tools during wafer processing times. Currently, time-based process tool data is available for at least some of the processing tools in some factories, but this is to optimize the performance of the processing tools for the ICs being produced. Use of data is restricted. This is due to the disconnect between how the processing tool time data is represented and how the IC performance data is represented. For example, there is no doubt that a data measurement for an IC is associated with a given batch of wafers (hereinafter referred to as a lot), or a given wafer, or a given subset of ICs on the wafer. On the other hand, data measurements from processing tool time data are represented as discrete operating states within the processing tool at specific points during wafer processing. For example, if the processing tool has an isolated processing chamber, the chamber pressure is recorded every millisecond while a given wafer remains in the processing chamber. In this example, chamber pressure data for any wafer is recorded as a series of 1000 unique measurements. Since IC data metrics are a single discrete measurement, this data format cannot be “merged” into an analysis table with a given IC data metric. The difficulty associated with “merging” processing tool time data into discrete data metrics limits the use of processing tool time data as a means of optimizing factory efficiency.

  In addition to the problems described above, there are other problems that involve the use of relational databases to store data generated at the factory. Although not limiting, relational databases, such as Oracle and SQL servers, need to organize and cite data that has a defined or assigned relationship between data elements. to cause. In use, users of these relational database technologies (eg, programmers) provide a schema that predefines how each data element is related to other data elements. After the database is created, the application user of that database makes an inquiry about the information contained in the database based on a pre-established relationship. Incidentally, the relational database in the prior art has two inherent problems that cause problems when these relational databases are used in a factory. The first problem is that before creating a specific schema (ie, relationships and database tables) for the data to be modeled, the user (eg, programmer) must be familiar with that data. . This schema essentially implements controls that safeguard data element relationships. Software that places data in the database and application software for retrieving data from the database must use a schema relationship between any two data elements in the database. The second problem is that when searching for small data transactions (eg banking, ticket sales, etc.), the relational database has an excellent TPS rating (ie transaction processing spec), especially in factories. When generating large data sets to assist decision support systems such as data warehousing and data mining, which are required to improve yield, the operation is insufficient. is there.

  In addition to the problems described above, there are problems as a result of prior art data analysis algorithms used in the semiconductor manufacturing industry to quantify production yield problems. These algorithms include linear regression analysis and manual application of a decision tree data mining method. These algorithms have the following two basic problems. (A) Although there is always a problem that impacts more than one yield in a given data set, these algorithms impact a separate set of yields in a given factory. Rather than quantifying the problems that give, it is best used to find “one” answer. (B) These algorithms cannot fully automate the analysis “handoff”. That is, linear regression analysis requires manual preparation and definition of variable categories prior to analysis, and decision tree data mining is used to define target variables within the analysis, as well as various variables for the analysis itself. This is because a “human user” is required to define the parameters.

  In addition to the problems described above, there is another problem due to data mining of fairly large data sets. For example, according to the prior art, some level of domain knowledge (ie, which field in the stream of data is “interested”) to filter the data set to reduce the size and number of variables in the analyzed data. It is possible to data mining a fairly large data set only after using certain “information representing” information. After generating a reduced data set, it is mined against known analysis techniques / models by experts defining value systems (ie, defining what is important) and drives the analysis system A “good question” should be inferred. In order to make this method effective, tools are typically manually configured and manipulated by those who ultimately evaluate the results. Usually these people need to have industry expertise, or more precisely, specific process knowledge, to collect data and form appropriate questions used to mining the dataset. Are the same people who are responsible for the process being evaluated. Making these industry experts accountable for the required data mining and correlation tasks makes their time use inefficient and the data mining process is driven largely by manual intervention Therefore, inconsistency will be brought about in the result obtained for each process. Eventually, even if successful, most of the “profit” is lost or reduced. For example, a time consuming process of manually processing and analyzing the data can be time consuming and expensive, and if the results are not achieved fast enough, there is not enough time to perform the discovered changes. .

  In addition to the problems described above, there are other problems as follows. An important part of the yield improvement and factory efficiency improvement monitoring efforts concentrates on end-of-line functional test data, in-line parametric data, in-line measurement data, and correlation between specific factory processing tools used to manufacture ICs It had been. To perform these correlations, the relationship between all the columns of the factory processing tool data and the specified “numerical sequence of data” (which processing tool data is pre-presented as a category attribute) It is necessary to decide. Good correlation means that a particular column of processing tools (ie, by category) that has one of the categories in that column is for the selected numeric column (ie, called the dependent variable or “DV”). Defined as correlating with an undesired range of values. The purpose of such an analysis is to identify the category (eg, factory processing tool) that is suspected of causing the undesirable DV reading, and to allow the engineer to confirm that the processing tool is operating correctly. Until that time, to eliminate it from the factory processing flow. The semiconductor factory database provides a huge number of tools and “tool-like” categorical data, making it difficult to isolate fault handling tools using manual spreadsheet search technology (called “commonality studies”) It is. Despite this limitation, there are technologies in the semiconductor industry for detecting defect handling tools or categorized process data. This can be done, for example, by performing a lot commonality analysis. However, this technique requires prior knowledge of a particular process layer and can be time consuming if the user does not fully understand the nature of the failure. Another technique is to use advanced data mining algorithms such as neural networks or decision trees. While these techniques are effective, data mining requires such extensive domain expertise, making them difficult to set up. Furthermore, these data mining algorithms are known to be slow due to the large amount of algorithm overhead required for such comprehensive data analysis techniques. Using the analysis techniques described above, users typically identify problems through basic or complex analysis that takes more time than finding the fault handling tool and actually spending it in place. To spend on an attempt to do.

  Finally, in addition to the above-mentioned problems, there are other problems as follows. Data mining algorithms such as neural networks, rule induction searches, and decision trees are more desirable methods when comparing correlation searches in large data sets with normal linear statistics. Many. However, there are some limitations when using these algorithms to analyze large data sets on low-cost hardware platforms such as Windows 2000 servers. The main among these limitations is the use of random access memory and extended CPU loading required by these technologies. Neural network analysis of large semiconductor manufacturing data sets (eg,> 40 Mbytes) often takes several hours or more and can even exceed the 2 Gbyte RAM limit for the Windows 2000 operating system. Furthermore, even if these large datasets are rule derived or decision tree analyzed (although not necessarily breaching the RAM limit for a single Windows process), it may take several hours to complete the analysis.

  There is a desire in the art to overcome one or more of the problems described above.

  One or more embodiments of the present invention advantageously satisfy the needs in the art as described above. More particularly, one embodiment of the present invention is a method for data mining information obtained at an integrated circuit manufacturing factory ("factory"). The method comprises the steps of: (a) collecting data from a factory or collecting data from the factory through one or more of systems, tools, and databases that generate data within the factory; and (b) formatting the data. Storing the formatted data in the source database; (c) extracting a portion of the data for use in data mining according to a user-specified configuration file; and (d) extracting the data. Data mining according to a user-specified configuration file, (e) storing data mining results in a result database, and (f) providing access to the results.

  One or more embodiments of the present invention may in particular establish (a) an integrated circuit (“IC”) manufacturing plant (“semiconductor factory” or “factory”) data feed (ie, multi-format data file streaming). (B) a database that indexes, but is not limited to, for example, 10,000 measurements in an Oracle file system (but not limited to, for example, 10,000 measurements such as a hybrid database); c) Decision analysis data feed with rapid export of multiple data sets for analysis, (d) Unsupported analysis automation with automated questions queried using a “data value system”, (e) Limited Although not multiple data such as neural networks, rule induction, and multivariate statistics. Taminening technology, (f) a visualization tool with multiple follow-on statistics to classify survey results, and (g) an application service provider ("ASP") for an end-to-end web delivery system that provides rapid deployment It is possible to improve the yield by providing one or more of the above. By using one or more of these embodiments of the present invention, an exemplary data feedback and problem fixing engineering process typically includes (a) an automated problem definition (the typical one in which this appears). (Time is about 0 days), (b) monitoring of all key analysis variables such as yield percentage, defect percentage, etc. (typical time for this to appear is about 0 days), (c) all Formation of hypotheses for key analysis variable anomalies (typical time for this to occur is about 0 days), (d) ranking of hypotheses using statistical confidence levels and fixability criteria (ie, Instructions supplied (eg, in a configuration file that can be based on experience), which include, but are not limited to, hypotheses that include weighting for some artificial intelligence, for example For example, the fixability criteria for categorical data such as tool data are different from the fixability criteria for numerical data such as probe data. (Note) (typical time it appears is about 1 day), (e) development of experimental strategy and experimental test plan (typical time it appears is about 1 day), (f) Performing the experiment and collecting data (typical time it appears is about 15 days), (g) fitting the model (typical time it appears is about 1 day), (h) model Diagnosis (typical time it appears is about 1 day), (i) interpretation of the model (typical time it appears is about 1 day), and (j) improvement without repetition Test confirmation to verify (this appears Typical time is about 20 days). As a result, the typical time to fix one problem is about 1.5 months.

  FIG. 3 applies factory data analysis system 3000 manufactured according to one or more embodiments of the present invention and data mining to one or more embodiments of the present invention for use with an IC manufacturing process. Fig. 2 shows an automated flow of data from raw unformatted input to data mining results in the case. According to one or more embodiments of the present invention, the process is manually data mined by automating each step of the analytical process and the flow from one phase of the analytical process to the next, and data The disadvantages of turning mining results into process improvements can be greatly reduced or eliminated. Furthermore, according to one or more further embodiments of the present invention, user or client access for data analysis setup is provided and via a commonly available existing interface such as an Internet web browser. It is possible to see the result. An application service provider (“ASP”) system distribution method (ie, a web-based data transfer method known in the art) is a preferred method for implementing such a web browser interface. Also, some that perform data collection and analysis on data from one or more factory sites by one factory that performs data collection and analysis on data from one or more factory sites May use one or more of the factory data analysis system embodiments shown in FIG. Further, in one or more of these embodiments, if the data is segregated by accounting method security, user or client setup and / or viewing results are from different departments of the same company. It can be different users or clients, or different users or clients from different departments of different companies.

  In one or more embodiments of the invention, (a) data is automatically retrieved, processed, and formatted so that the data mining tool can work with that data ( b) Since the value system is applied and the question is automatically generated, the data mining tool returns the relevant results, and (c) the results are automatically notified and remotely accessible, so the results The correction operation based on can be performed quickly.

As shown in FIG. 3, the ASP data transfer module 3010 includes, but is not limited to, for example, (a) lot equipment history data from MES (“measurement execution system”), (b) data from equipment interface, (C) Processing tool recipes and processing tool test programs from factory-prepared data sources, and (d) but not limited to, for example, probe test data, E test (electrical test) data, defect measurement data, remote A data collection process or module that obtains different types of data from any one or more of the different types of data sources in the factory, such as diagnostic data collection and post-processing data from factory prepared data sources is there. In accordance with one or more embodiments of the present invention, the ASP data transfer module 3010 includes, but is not limited to, a customer data collection database (e.g., storing raw data output from tools and / or direct data sources). Accept and / or collect data transmitted in a format dictated by customers and / or tools from centralized or otherwise). Further, such data acceptance or collection can be done on a schedule basis or on demand. Still further, the data can be encrypted or transmitted as an FTP file (eg, like secure email) through a secure network such as the customer's intranet. In accordance with one embodiment of the present invention, ASP data transfer module 3010 is a software application running on a PC server, and C ⁺⁺ , Perl, according to any one of many methods known in the art. And encoded in Visual Basic. For example, typical data generally available are: (a) typically about 12,000 items / lot (wafer lots are typically 25 wafers that typically run together during processing in a cassette. WIP (work progress) information (WIP information is typically accessed by process engineers), (b) of raw processing tool data typically including, for example, about 120,000 items / lot Equipment interface (previously, typically, nobody has accessed the equipment interface information), (c) process metrology information (process metrology typically containing about 1,000 items / lot) Information is typically accessed by a process engineer), (d) defect information typically containing about 1,000 items / lot (defect information is typically (E) typically accessed by a yield engineer), (e) E test (electrical test) information typically containing about 10,000 items / lot (E test information is typically accessed by a device engineer), and (F) Includes classification (with data logs and bitmaps) information typically containing about 2,000 items / lot (classification information is typically accessed by product engineers). It will be readily understood that these data can be rolled up to a total of approximately 136,000 unique measurements per wafer.

  As further shown in FIG. 3, the data conversion module 3020 includes the raw data received by the ASP data transfer module 3010 with keys / columns / data in any one of many ways known in the art. The data is converted and / or translated into a data format, and the converted data is stored in the self-adaptive database 3030. The data conversion process performed by the data conversion module 3020 includes, but is not limited to, raw data classification, for example, factory / test lot ID conversion (eg, useful for foundries), wafer ID conversion. (E.g., Sleuth and Scribe ID), and wafer / reticle / die coordinate normalization and transformation (for example, but not limited to, notches are used for coordinate normalization , Or depending on whether wafer reference measurement is used) and, for example, but not limited to, spec limits for E test data, bin probe data (eg, For end-of-line probe tests, there may be 10 to 100 failure modes), measurement data, and not limitation But it includes, for example, the lot, wafer, regions, and the data specifications, such as the calculated data types such as layer data. According to one embodiment of the present invention, the data conversion module 3020 is a software application running on a PC server and encoded with Oracle Dynamic PL-SQL and Pearl according to any one of many methods known in the art. Has been. According to one such embodiment of the present invention, the data conversion process performed by the data conversion module 3020 is in the art of converting a raw file into a “fully formatted” industry-friendly file. Including using one comprehensive set of multiple translation programs according to any one of a number of known methods (ie, data formats are "generalized" and thus data formats that can convert data) Only a few formats are used, no matter how many are present). According to one or more embodiments of the present invention, the converted file is (to enable subsequent processes to be “rolled up” to low granularity data into high granularity data). While maintaining the “level” information present in the raw data, it does not include industry specific information. After the raw data is in this format, it is supplied to the self-adaptive database 3030 for storage.

  According to one or more embodiments of the present invention, the generic file format for input data is Widget ID, where? ,What time? ,what? , And by using a value leveling scheme. For example, in the case of a semiconductor factory, these are specifically defined as follows. That is, the widget ID is identified by one or more of lot ID, wafer ID, slot ID, reticle ID, die ID, and sub-die x, y Cartesian coordinates. where? Are identified by one or more of process flow / assembly line manufacturing steps and sub-steps. What time? Is identified by one or more of the measurement date / time. what? Is identified as one or more of a measurement name “for example, but not limited to, yield”, measurement type / category, and wafer classification. value? Is defined as, for example, but not limited to, 51.4% yield. Using such an embodiment, any plant data can be represented.

  According to one or more embodiments of the present invention, the data conversion module 3020 comprehensively translates new types of data collected by the ASP data transfer module 3010. Specifically, the data conversion module 3020 creates an “on-the-fly” database “handshake” to allow new data to be stored in the self-adaptive database 3030, for example by creating a hash code for data access. To do. Finally, according to one embodiment of the present invention, data is stored in a self-adaptive database 3030 as it arrives at the factory analysis system 3000.

In accordance with one or more embodiments of the present invention, the ASP data transfer module 3010 is a SmartSys ^™ database (the SmartSys ^™ application is a software application available from Applied Materials, Inc., such as sensor data. Collecting, analyzing, and storing data from processing tools in a factory). Further, the data conversion module 3020 includes a module that converts SmartSys ^™ processing tool sensor data into a data set prepared by a master loader module 3050 and a master builder module 3060 for data mining.

In accordance with one or more embodiments of the present invention, a data conversion algorithm may be used to establish a “direct” link between measured data metrics and an existing non-optimal factory (ie, factory condition). It is possible to use data based on time (hereinafter referred to as time-based) from a processing (ie factory or assembly line) tool. An important part of this data conversion algorithm is the method of converting time-based operating state data generated in a processing (factory or assembly line) tool during wafer processing into key integrated circuit specific statistics. This statistic is analyzed by the data brain engine module 3080 in the manner described below to perform automated data mining failure detection analysis. According to one or more embodiments of the present invention, the following steps are performed to translate such time-based processing tool data.
a. Creating a configuration file (using the user interface described below) that specifies the digitization granularity of the comprehensive time-based data format;
b. For example, without limitation, time-based processing tool data received by the ASP data transfer module 3010 from various file formats such as ASCII data is translated into a time-based data file format using a configuration file.

The following is an example format definition for a comprehensive time-based data file format. Advantageously, according to these embodiments, not all data fields need to be complete in order for a file to be considered “worthy”. Instead, as described below, some data fields can later be grouped by a “post processing” data filing routine that communicates with a semiconductor manufacturing execution system (MES) host.

<BEGINNING OF HEADER>
[PRODUCTID CODE]
LOTID CODE] (italic)
[PARNET LOTID CODO]
[WAFERID CODE]
[SLOTID CODE]
[WIP CODE]
[WIP SUB-MODULE]
[WIP SUB-MODULE-STEP]
[TRACKIN DATE] (italic)
[TRACKOUT DATE] (italic)
[PROCESS TOOLID]
[PROCESS TOOL RECIPE USED]
<END OF HEADER>
<BEGINNING OF DATA> (italic)
<BEGINNING OF PARAMETER> (italic)
[PARAMETER ENGLISH NAME] (italic)
[PARAMETER NUMBER] (italic)
[DATA COLLECTION START TIME] (italic)
[DATA COLLECTION END TIME] (italic)
time increment 1, data value 1 (italic)
time increment 2, data value 2 (italic)
time increment 3, data value 3 (italic)
...
<END OF PARAMETER> (italic)
<BEGINNING OF PARAMETER> (italic)
[PARAMETER ENGLISH NAME] (italic)
[PARAMETERID NUMBER] (italic)
[DATA COLLECTION START TIME] (italic)
[DATA COLLECTION END TIME] (italic)
time increment 1, data value 1 (italic)
time increment 2, data value 2 (italic)
time increment 3, data value 3 (italic)
...
<END OF PARAMETER> (italic)
<END OF DATA> (italic)

  According to this embodiment, items shown in italics (labeled italic) are necessary to allow the file contents to be properly merged with IC data metrics.

As described above, according to one or more embodiments of the present invention, the configuration file for time-based data conversion specifies a granularity that represents the time-based data as wafer statistics. According to such an embodiment, the configuration file further includes information regarding which time-based raw data format is processed by that particular configuration file, as well as one or more options for data archiving of the raw file. Can do. The following is an example of a configuration file.
<BEGINNING OF HEADER>

[FILE EXTENSHIONS APPLICABLE TO THIS CONFG FILE]
[RAW DATA ARCHIVE FILE <Y OR N>]
[CREATE IMAGE ARCHIVE FILES <NUMBER OF FILES / PARAMETER>]
[IMAGE ARCHIVE FILE RESOLUTION]

<END OF HEADER>

<BEGINNING OF ANALYSIS HEADER>

[GLOVAL GRAPH STARTS <ON / OFF>, N SEGMENTS]
[XAXIS TIME STARTS <ON / OFF>, N SEGMENTS]
[YAXIS PARAMETER STARTS <ON / OFF>, N SEGMENTS]

<END OF ANALYSIS HEADER>

  The configuration file parameters described above will be described below.

  File extension: This line in the configuration file is a file extension that indicates that a given raw generic time-based data file should be converted using the parameters defined in the given configuration file. Lists naming convention keywords.

  Raw data archive file: This line in the configuration file specifies whether an archived copy of the original data should be retained. By using this option, the file is compressed and stored in the archive directory structure.

  Image archive file creation: This line in the configuration file stores the “first” view of the data, and the raw data files (these files can grow, totaling 10-20G each month for a single processing tool Whether the raw time base data file should be graphed in standard xy format so that it can be archived and searched quickly without repeated plotting. specify. The number of image options makes it possible to store multiple snapshots of the various key areas of the xy data plot, thus also making a “zoomed in” view of the data available.

  Image archive file resolution: This line in the configuration file defines what level of standard image compression is applied to the xy graph captured by the image archive file option.

  Global graph statistics: This line in the configuration file specifies the generation of global statistics for all file formats processed by the configuration file. How these statistics are generated will be described later.

  X-axis time graph statistics: This line in the configuration file directs the system to generate X-axis time range defined statistics for all file formats processed by the configuration file. How these statistics are generated will be described later.

  Percent data graph statistics: This line in the configuration file directs the system to generate percent data statistics for all file formats processed by the configuration file. How these statistics are generated will be described later.

  In accordance with one or more of these embodiments of the present invention, the following statistics, also referred to as X-axis time graph statistics, are generated for each time-based data graph on a parameter-by-parameter basis. For example, for a given time base data set and given parameters, the data is divided into a plurality of segments defined in the configuration file. An X-axis time graph segment is defined by taking the full width of the x-axis (from the minimum x value to the maximum x value) and dividing it into multiple (N) equal increments of the x-axis range. Statistics are generated and recorded for each segment. To understand how this works, reference is first made to FIG. FIG. 5 shows a graph of processing tool beam current as a function of time, in particular, an example of raw time base data. 6 shows how the raw time base data shown in FIG. 5 is divided into segments, and FIG. 7 shows the raw time base data corresponding to segment 1 of FIG.

The following are typical segment statistics (eg, segment statistics for multiple (N) segments, 10 statistics for each segment).
1. Area within the segment 2. Average Y-axis value of the data in the segment 3. Standard deviation of the Y-axis value of the data in the segment 4. Slope of the segment Minimum Y-axis value of the segment 6. Maximum Y-axis value of the segment 7. Percent change in Y-axis average value from the preceding segment 8. Percent change in Y-axis average from next segment 9. Percent change in Y-axis standard deviation value from the preceding segment Percent change in Y-axis standard deviation from the next segment

  FIG. 8 shows an example of the dependency of the Y range in the segment 7 on the bin_S. By using the information described above, the process engineer can adjust the recipe in the processing tool (processing tool settings) to have a range corresponding to the low bin_S failure.

According to one embodiment of the present invention, the following 29 statistics are global statistics calculated from data that has not been tukey data cleaned.
1. 2. Total area under the curve 2. Number of Y-axis gradient changes of 10% or more. X-axis 95% data width (ie starting from the center of the data and moving left and right until 95% of the data is picked up)
4. Y-axis average of 95% X-axis data width 5. Y-axis standard deviation of 95% X-axis data width 6. Y-axis range of 95% X-axis data width 7. X-axis 95% area under the curve X-axis leftmost 2.5% data width 9. 10. X-axis leftmost 2.5% area under the curve X-axis rightmost 2.5% data width 11. X-axis rightmost 2.5% area under the curve 12. X-axis 90% data width (starting from the center of the data and moving left and right until 90% is picked up)
13. Y-axis average of 90% X-axis data width 14. Y-axis standard deviation of 90% X-axis data width 15. Y-axis range of 90% X-axis data width 16. X-axis 90% area under the curve 17. X-axis leftmost 5% data width 18. 18. X-axis leftmost 5% area under the curve X-axis rightmost 5% data width 20. 21. X-axis rightmost 5% area under the curve X-axis 75% data width (starting from the center of the data and moving left and right until 75% is picked up)
22. Y-axis average of 2.75% X-axis data width 23.75% X-axis data width Y-axis standard deviation 24.75% X-axis data width Y-axis range X-axis 75% area under the curve 26. X-axis leftmost 12.5% data width 27. X-axis leftmost 12.5% area under the curve 28. X-axis rightmost 12.5% data width 29. X-axis rightmost 12.5% area under the curve

  The percentages used in the examples are 90, 95, 75, etc., which are common percentages, but if you are interested in expanding the range of the “core” of the data, for example, these percentages are intermediate values. There are further examples that can be changed to:

  There are further examples of calculating global statistics as described above using 5000% Turkey Data Cleaning, and yet another example of calculating global statistics as described above using 500% Turkey Data Cleaning. Exists.

  According to one embodiment of the present invention, the percent data statistic is the same as the 10 statistic for the X-axis time graph statistic. The difference between the percent data statistic and the X-axis time statistic is in the way the segment is defined. In the case of X-axis time statistics, the segment is based on N equal parts of the X-axis. However, in the case of percent data statistics, the segment width on the X-axis varies because the segment is defined by the percentage of data contained within the segment. For example, if the percent data segment is adjusted to “on” with 10 segments, the first segment is the first 10% of the data (if the X axis is used as a reference, 10% on the left).

  As further shown in FIG. 3, the master loader module 3040 is formatted from a self-adaptive database 3030 (eg, data file 3035) (whether triggered by a time-generated event or triggered by a data arrival event). The retrieved data is retrieved and converted to an intelligence base 3050. The intelligence base 3050 is realized as an Oracle relational database known in the art. According to a further embodiment of the present invention, the master loader module 3040 has a sufficient amount of data to retrieve and transfer to the intelligence base 3050 as the data “trickles” from the factory. To determine if it has arrived, it polls the directory in the self-adaptive database 3030.

  In accordance with one or more embodiments of the present invention, the master loader module 3040 and the intelligence base 3050 comprise methods and apparatus for managing, referencing and extracting large amounts of unstructured relational data. According to one or more embodiments of the present invention, the intelligence base 3050 is a hybrid database comprised of intelligence-based relational database components and intelligence-based file system components. According to one such embodiment, a relational database component (eg, schema) uses a hash index algorithm to create an access key to discrete data stored in a distributed file base. To do. Advantageously, this allows unstructured raw data to be quickly converted to formal structure, thereby bypassing the limitations of commercial database products and storing structured files in disk arrays The speed obtained can be used.

  According to one embodiment of the present invention, the first step in the design setup for the intelligence base 3050 includes defining the applicable level of discrete data measurements that may exist. However, according to one or more of these embodiments of the invention, there are many levels of that discrete data to initiate the process of building an intelligence base 3050 for a given discrete data. There is no need to predict. Instead, at some point in the intelligence base 3050, it is only necessary to define the relationship between the new level (either sub-level or super-level) and the early level. To understand this, consider the following example: A common level within a factory would be a collection of wafers. This can be indexed as level 1 in the intelligence base 3050. Each specific wafer in the collection of wafers can then be indexed as level 2. Next, any particular subgrouping of chips on the wafer can be indexed as level 3 (or multiple levels depending on the consistency of the subgrouping category). Advantageously, this flexibility of the intelligence base 3050 allows any data type to be stored in the intelligence base 3050. The requirement is that the property can be indexed to the lowest level of existing granularity applied to the data type.

  Advantageously, according to one or more embodiments of the present invention, the data loading process for the intelligence base 3050 is easier than the data loading process for a traditional relational database. Because in the case of the intelligence base 3050, it is only necessary to rewrite each new data type in a format that shows the relationship between the discrete manufacturing level and the data measurement (or data history) for that particular level of ID. It is. For example, in a factory, a given data file must be rewritten into a line containing a “level 1” ID, “level 2” ID, etc., and then measurements must be recorded for that set of wafer combinations. Don't be. It is this property of the intelligence base 3050 that allows any applicable data to be loaded without defining a specific relational database schema.

  Advantageously, according to one or more embodiments of the present invention, the intelligence base 3050 is automated by using a hash and join algorithm to quickly accumulate and combine large amounts of data. It is designed to support data analysis jobs (details will be described later) and to output a large database. In conventional relational database design, outputting such large data sets usually requires large “tables / joins” in the database. As is well known, when using relational database tables and joins, the output process of such large data sets makes the CPU very busy, but advantageously, to output large data sets from the intelligence base 3050 This is not the case with the “hash-join” algorithm used.

  FIG. 4 illustrates the logical data flow of a method according to one embodiment of the present invention for structuring unstructured data events into an intelligence base 3050. As shown in FIG. 4, factory data is retrieved from the factory data warehouse 4000 in box 4010. This factory data can be any one of many different shapes, and is not limited to, for example, historical data from a database, but not limited to, for example, sensors. Any one of many different sources, including real-time data from processing tool monitoring equipment, can be generated. The unformatted data is then provided to the data parser 4020. It should be understood that the manner and frequency of retrieving data from the factory warehouse 4000 does not affect the behavior of the data parser 4020, database loader 4040, or intelligence base 3050. Next, the data parser 4020 outputs a formatted data stream 4030. This formatted data is in a format that can be accepted by the database loader 4040 (this is only about formatting issues, ie how the data is laid out, and does not have any “knowledge” about the data. Will not be introduced). The database loader 4040 then reads the formatted data stream 4030. Database loader 4040 uses a hash index algorithm to generate index keys between the data elements and their location in file system 4050 (for example, but not limited to, hash index algorithm Generate an index key using the data level ID of the element). The data is then stored in the file system 4050 for future reference and use, and a hash index key that references the file system 4050 is stored in the relational database 4060. In one or more alternative embodiments of the present invention, the intelligence base 3050 is created by loading data into an indexed table, partitioned by level in the Oracle 9i data mart.

  Returning to FIG. 3, the master builder module 3060 accesses the intelligence base 3050 and uses the configuration file (generated using the user edit and configuration file interface module 3055) as an input to the data mining procedure. Is constructed (described later). The user editing and configuration file interface module 3055 allows a user to create a configuration file of configuration data used by the master builder module 3060. For example, the master builder 3060 obtains data (such as but not limited to a specific type of data within a specific parameter value range) from the intelligence base 3050 specified by the configuration file and places it in the configuration file. Combined with other data from the specified intelligence base 3050 (for example, but not limited to, another specific type of data within another specific value range). To do this, the intelligence-based file system component of the intelligence base 3050 is referenced by the intelligence-based relational database component of the intelligence base 3050, allowing different data levels to be quickly merged into a “vector cache” of information (This "vector cache" is changed to data for use in data mining). The configuration file allows the user to define a new relationship using a hash index, thereby creating a new “vector cache” of information (this “vector cache” is a data Converted to data for use in mining). This data is hereinafter referred to as “Hypercube”. According to one or more embodiments of the present invention, the master builder module 3060 is a software application running on a PC server, and Oracle Dynamic PL-SQL and Perl according to any one of many methods known in the art. It is encoded with.

  In operation, the master builder module 3060 receives and / or extracts a hypercube definition using a configuration file. Next, the master builder module 3060 creates a vector cache definition using the hypercube definition. Next, the master builder module 3060 follows the vector cache definition, (a) a list of files and data elements identified or designated by the vector cache definition from the intelligence base relational database component of the intelligence base 3050, Search using a hash index key, (b) retrieve a file base file from the intelligence base file system component of the intelligence base 3050, and (c) data identified in the vector cache definition Create a vector cache of information by grouping elements. Next, the master builder module 3060 generates a hypercube from the vector cache information using the hypercube definition by a method described later. These hypercubes are assigned IDs for use in identification analysis results as they travel through the factory data analysis system 3000 and for use by clients in reviewing analysis results. The master builder module 3060 builds the hypercube and removes data that adversely affects the data mining results according to any one of many methods known in the art to clean the hypercube data and make many different Combine hypercubes to allow analysis of variables and convert bin and parametric data into shapes for use in data mining (for example, but not limited to event driven data Includes submodules (by converting to binned data).

In accordance with one or more embodiments of the present invention, the master builder module 3060 is a data cleaner and scrubber (eg, pearl and C ⁺⁺ software manufactured according to any one of many methods known in the art). Application). This data cleaning can be performed according to criteria described in the configuration file, or on special criteria upon receipt of user input.

  In one or more embodiments of the present invention, the master builder module 3060 includes, but is not limited to, a spreadsheet (e.g., SAS (a database tool known in the art), .jmp (xy). JUMP plots known in the art for use in visualizing and analyzing data, .xls (a Microsoft Excel spreadsheet known in the art), and .txt (a text file known in the art) Export to the user in various file formats such as In one or more embodiments of the present invention, the master builder module 3060 includes a module that receives as input the user generated hypercube and forwards the vector cache to the data brain engine module 3080 for analysis.

  According to one or more embodiments of the present invention, the data conversion module 3020, the master loader module 3040, and the master builder module 3050 are respectively a self-adaptive database 3030, an intelligence base 3050, and data output for data mining. It operates to perform continuous update.

  As further shown in FIG. 3, the web commander module 3070 forwards the data output from the master builder module 3060 to the data brain engine module 3080 for analysis. Once the dataset file formatted by the master builder module 3060 is available for data mining, the automated data mining process analyzes the dataset against the analysis template (designed as an association within the analysis template. While monitoring to maximize or minimize the variables, consider the relative importance of these variables). The data brain engine module 3080 provides an analysis configuration preparation and template builder module (provides user-defined configuration parameter values for use with the data brain engine module 3080, a user interface for building data mining automation files). Includes user editing and configuration file interface module 3055. The data brain engine module 3080 performs an automated data mining process using a combination of the statistical properties of the variables and the relative contributions of the variables in the self-learning neural network. A statistical distribution of the contribution of a variable to a given defined “important” variable (per analysis template) or, for example, but not limited to, the structure of a self-organizing neural network map (“SOM”); We generate criteria whose magnitudes can form relevant questions and present them to a wide range of data mining algorithms that are best suited for a particular type of a given data set.

  In accordance with one or more embodiments of the present invention, the data brain engine module 3080 provides flexibility in large unknown data sets by exploring statistical comparisons in unknown data sets to obtain “handoff” operations. Generate automated repeated data mining. Such algorithm flexibility is particularly useful in the exploration process where the data consists of numeric attributes and categorical attributes. Examples of algorithms required to fully explore these data include, but are not limited to, specialized variance analysis (ANOVA) techniques that can correlate categorical and numerical data, for example. Furthermore, more than one algorithm is typically required to fully explore statistical comparisons in these data. These data can be found in modern discrete manufacturing processes such as semiconductor manufacturing, circuit board assembly, or flat panel display manufacturing.

  The data brain engine module 3080 includes a data mining software application (hereinafter referred to as a data brain command center application) that uses the configuration files and analysis templates included in the data set to perform data mining analysis. In accordance with one or more embodiments of the present invention, the data brain command center application invokes the data brain module to use one or more of the data mining algorithms listed below. They are SOM (a data mining algorithm known in the art), rule induction ("RI": a data mining algorithm known in the art), MahaCu (numerical data by category or attribute data (limited) Although not, for example, a data mining algorithm that correlates to a processing tool ID), and inverse MahaCu (category-specific or attribute data (for example, but not limited to, processing tool ID) data that correlates to numerical data Mining algorithm (described later), data mining is performed using SOM, and output from SOM is used to perform data mining using (a) RI and (b) MahaCu. Multi-level analysis automation, Pigin: Inventive data mining algorithm Zum), inventive data mining algorithms to be described later defective brain (details) and Selden (Selden: a known predictive model data mining algorithm) in the art.

  According to one or more embodiments of the present invention, the data brain command center application uses a central control application that allows the use of multiple data mining algorithms and statistical methods. Specifically, a centralized control application according to one or more of these embodiments allows the results from one data mining analysis to be sent to subsequent branched analysis or run inputs. As a result, the DataBrain Command Center application provides an automated and flexible mechanism for exploring data using the logic and depth of analysis governed by user configurable system configuration files. Enables unbounded data exploration without being limited by the number and type of analysis iterations.

  Factory data analysis system 3000, in its most common form, analyzes data received from multiple factories (all of which need not be owned or controlled by the same legal entity). As a result, different data sets can be analyzed simultaneously in a parallel data mining analysis run and reported to different users. Furthermore, even if the received data is obtained from a single factory (ie, a factory that is owned or controlled by the same legal entity), different data sets can be analyzed by different groups within the legal entity in parallel data mining analysis runs. Can be analyzed simultaneously. In these cases, these data mining analysis runs are efficiently performed in parallel on the server farm. According to one or more of these embodiments of the present invention, the data brain engine module 3080 acts as an automated command center and includes the following components: They are: (a) the data brain command center application (branch analysis decision and control application), which calls the data brain module, and (i) a set of distributed slave queues in the server farm (they A data brain command center queue manager (manufactured according to any one of many methods known in the art), including (ii) one in the server farm, A data brain command center load balancer application that balances distribution and job load (manufactured according to any one of many methods known in the art), and (iii) creates and manages customer accounting and related analysis results , And data that allows status monitoring (B) a user editing and configuration file interface module 3055 that allows the user to supply analysis template information used for data mining in the configuration file. Manufactured according to any one of many methods known in the art).

  According to this embodiment, the data brain command center application is primarily responsible for managing data mining job queues and automatically distributing jobs to an array of networked Windows servers or server farms. The data brain command center application interfaces to the user editing and configuration file interface module 3055 to receive input for system configuration parameters. According to one or more of these embodiments, a data mining job is defined as a set of analysis runs consisting of multiple data sets and analysis algorithms. Jobs are managed by a data brain command center queue manager application, which is a master queue manager residing on an individual server slave queue (queue). The master queue manager logically distributes data mining jobs to the available servers (performed by the data brain module) so that the jobs can run simultaneously. The results of the branched analysis runs are collected by the data brain command center application and then, if necessary, they are directed by the job configuration file and fed to subsequent runs.

  In addition, the data brain command center application controls server farm load balancing. Balancing is useful to obtain the efficiency and control of available server resources within a server farm. Proper load balancing is achieved by monitoring the server queues of individual farms and other relative run time status information in real time according to any one of many methods known in the art. .

  In accordance with one or more of these embodiments of the present invention, the data brain command center account administrator application provides a customer for automated analysis performed according to any one of many methods known in the art. Enable accounting creation, management, and status monitoring. Management and status communication provides control feedback to the data brain command center queue manager application and the data brain command center load balancer application.

  According to one or more embodiments of the present invention, one step of data mining analysis can be used to analyze numerical data to find a cluster of data that appears to be correlated (this step). Can include several data mining steps that attempt to analyze the data using various types of data that can provide these correlations). This step is driven by the type of data specified in the configuration file. In a next step, the correlated data can then be analyzed to determine parametric data that can be associated with the cluster (this step can be performed using various types of data that can provide these associations). May include several data mining steps to attempt the analysis). This step is also driven by the type of data specified in the configuration file. In the next step, the parametric data can then be analyzed against categorical data to determine processing tools that can correlate with the associated parametric data (this step can be done with various types that can provide these correlations). Can include several data mining steps that attempt to analyze the data using the processing tool Then, in the next step, the processing tool sensor data can be analyzed against categorical data to determine which aspects of the processing tool can fail (this step can be done with various types of correlations that can give these correlations). It may include several data mining steps that attempt to analyze the data using sensor data). According to this one embodiment, the hierarchy of data mining analysis techniques will use SOM, followed by rule induction, followed by ANOVA, followed by statistical methods.

  FIG. 9 shows a three-level branch data mining run as an example. As shown in FIG. 9, the data brain command center application is not limited (under the command of the analysis template portion of the configuration file generated by the user), but for example, yield (yield is not limited) Perform SOM data mining analysis to cluster numerical data on (but not for example, defined in relation to the speed of ICs manufactured in the factory). Next, as further shown in FIG. 9, the data brain command center application (under the command of the analysis template generated by the user) (a) performs map matching analysis (described later) on the SOM data mining analysis output. Perform cluster matching if it is related to parametric data such as, for example, but not limited to, electrical test results, and (b) rule guidance for SOM data mining analysis output A data mining analysis is performed and a rule description of the cluster is generated if it is related to parametric data such as, but not limited to, electrical test results. Next, as further shown in FIG. 9, the data brain command center application (under the direction of the user-generated analysis template) (a) reverse MahaCu and / or ANOVA against the rule guided data mining analysis output. Perform a data mining analysis, for example, but not limited to, correlate categorical data to numerical data if it relates to processing tool settings for measurement measurements made in the processing tool; and (B) Perform MahaCu and / or ANOVA data mining analysis on the map matching data mining analysis output, for example but not limited to processing tools for sensor measurements. For example, numerical data is correlated with categorical data.

  FIG. 10 illustrates a distribution queue creation performed by a data brain command center application according to one or more embodiments of the present invention. FIG. 11 illustrates an analysis template user interface portion of a user editing and configuration file interface module 3055 that is manufactured in accordance with one or more embodiments of the present invention. FIG. 12 illustrates an analysis template portion of a configuration file that is manufactured in accordance with one or more embodiments of the present invention.

  According to one or more embodiments of the present invention, an algorithm, hereinafter referred to as “map matching”, is used to achieve automated and centralized analysis (ie, to provide automatic definition of problem statements). Is used. That is, according to one or more embodiments of the present invention, the SOM creates a map of a cluster of wafers having similar parameters. For example, if you create such a map for each parameter in the data set, they can be used to determine how many unique yield problems exist for a given product at a given time. can do. These maps can also be used to define good “questions” and query for further data mining analysis.

  Since it is possible to automate the analysis from the essence of self-organized maps, users of the inventive SOM map matching technology will be able to “relevant” in-factory variables to achieve full “handoff” automation. You only need to maintain a list of name tags. SOM analysis automatically organizes the data and identifies isolated and dominant (ie, impacting) data clusters that represent different “factory issues” within the data set. According to this SOM clustering combined with the map matching algorithm described below, what is known to impact each “interesting” variable on the behavior of the “interesting” variable per cluster. It is possible to describe it with the expression of such history data. Thus, using SOM combined with map matching algorithms, factories use fully automated “handoff” analysis techniques for many issues (or other important issues) that impact yield. Can be dealt with.

  Before a SOM analysis of a data set can be performed, a self-organized map must be generated for each column in the data set. In order to generate these maps, a hyperpyramid cube structure as shown in FIG. 13 is constructed. The hyperpyramid cube shown in FIG. 13 has four layers. According to one or more embodiments of the present invention, all hyperpyramid cubes are grown so that each layer is 2 ^ n * 2 ^ n, where n is a layer number based on 0. . Furthermore, each layer of the pyramid represents a hypercube. That is, each layer of the hyperpyramid cube represents a column in the data set. The layer shown in FIG. 14 is layer 2 (based on 0) of a 16-column data set. According to one or more of these embodiments, as the depth of the hyperpyramid cube advances, the width of the hypercube (2 ^ n × 2 ^ n) increases, and the depth of the hypercube pyramid is the data Stays constant in the number of columns in the set.

  FIG. 15 shows a hypercube layer (self-organized map) that is from a hypercube extracted from the second layer of the hyperpyramid cube. As shown in FIG. 15, the neurons (ie cells) in each layer represent an approximation of the actual record in that column. As the depth in the pyramid goes down by one, the hypercube becomes larger and the neurons in the cube increase and converge to the actual value of the record in the actual column represented by each layer of the data cube. Due to memory constraints and included computation time, it is impractical or infeasible to grow pyramids until they converge to the real values that the neurons represent. Instead, according to one or more embodiments of the present invention, the pyramid grows until a certain threshold is reached or until a predetermined maximum depth is reached. Then, according to one or more embodiments of the present invention, SOM analysis is performed on the last stratified cube to generate a pyramid.

  After the SOM for each column of the data set is generated, the following steps are performed to achieve automated map matching data analysis.

I. Generate snapshot (repeated) :
Given a numerical dependent variable ("DV") (data string (column)), it detects the neural map in the data cube referenced by this DV. This neural map is used to generate all possible color region combinations detailing the three regions. These three regions are the high (hill), low (pond), and central regions, and any cell on the neural map falls within one of these regions. To simplify these embodiments for ease of understanding, a green color is assigned to the high region, a blue color is assigned to the central region, and a red color is assigned to the low region. The first step is then to determine the deltas that need to be moved at each interval in order to generate a snapshot of the color area needed to be used as a basis for automated map matching analysis. There are two threshold markers that need to be moved to get all the snapshot combinations (ie, a marker representing the threshold for the low region and another marker for the high region) Note that it exists. By changing these two markers and using deltas, all desired snapshot combinations can be generated.

  The delta value is calculated as [delta = (percent of data distribution-this is a user configured value) x 2 sigma]. The high and low markers are then moved to the average of the data in this column. In this initial state, all cells in the neural map fall into either the green or red area. Next, move the low marker to the left by delta. All cells are then scanned and appropriate colors are assigned to them based on the following steps. If the associated cell value is [(average −1.25 sigma) <cell value <low marker], it is assigned a red color. If the associated cell value is [(high marker) <cell value <(average + 1.25 sigma)], it is assigned a green color. If the associated cell value is [(low marker) <cell value <(high marker)], it is assigned a blue color.

In each of these snapshots (repeated), all the high and low regions are tagged and SOM automated analysis (described later) is performed. The low marker is then moved delta to the left and another snapshot is created. All high and low regions are then tagged and SOM automated analysis is performed. This process is continued until the low marker is less than (average -1.25 sigma). When this happens, the low marker is reset to the initial state, then the high marker is advanced delta to the right and the process is repeated. This is continued until the high marker is greater than (average +1.25 sigma). This is shown in the pseudo code below.
Set High Marker = Mean value of column data.
Set Low Marker = Mean value of column data.
Set Delta = (Percent of data distribution this is a user configurati
on
Value) * 2sigma.
Set Low Iterator = Low Marker;
Set High Iterator = High Marker

Keep Looping when (High Iterator <(mean + 1.25 sigma)
Begin Loop
Keep Looping when (Low Iterator <(mean−1.25 sigma)
Begin Loop
Go through each cell and color code the cells based on the procedure a
bove
and using the High Iterator and Low Iterator as threshold values.
Capture Automated Map Matching analysis (see the next section below)
on this snapshot.
Set Low Iterator = Low Iterator−Delta.
End Loop
Set High Iterator = High Iterator + Delta.
End Loop

  FIG. 16 shows a self-organizing map having high, low, and central regions, with the high and low cluster regions tagged for subsequent automated map matching analysis.

II. Automated map matching analysis of snapshots (repeated)
Each of the three color region snapshots generated in step 1 is analyzed as follows. Region of interest (user specifies whether he is interested in a pond (low) region or a hill (high) region of the selected DV (column) neural map). This region of interest is called the source region, and the other opposite region is called the target region. The premise for obtaining an automated SOM ranking of other independent variable (“IV”) maps, ie columns in a data cube that is not a DV column, is to project rows (records) of the same data set through the data cube as is. Is based on the fact that Thus, if row 22 of the data set is located 10 rows and 40 columns of a given DV neural map, its cell location (22, 40) is the data set of all other IV neural maps. Would include line 22. Specifically, FIG. 17 shows the projection of a cell through a hypercube. As is apparent from FIG. 17, a “best fit” record is established so that when it is projected through each layer of the hypercube, it best fits the predicted value for each layer. Simply put, the purpose is to analyze the records consisting of the source and target areas and to determine how different they are from each other. Since the records that make up each group are the same across the neural map, each neural map can be ranked based on how much the source group differs from the target group. This score is then used to rank the neural map from highest to lowest. A high score means that the two groups in the neural map are very different from each other, whereas a low score means that the two groups are very similar to each other. The goal is therefore to find an IV neural map with the greatest difference between the two groups. Below are the steps used to achieve this goal.
a. Rank source clusters from highest to lowest according to impacted scores. The impacted score for each cluster is calculated according to [Impacted Score = (Actual Column Average-Neural Map Average) x (Number of Unique Records in Cluster) / Total Records in Column]. .
b. Start with the highest ranked source cluster and tag its target cluster neighborhood based on the following criteria: Each of the following criteria is weighted accordingly, and the resulting score actually assigned is the average of the weights.
1. How close is it to the source cluster? This is calculated as the centroid distance from the target cluster to the source cluster (the centroid cell is the cell occupying the center of the cluster). After determining the two cells, the centroid distance is calculated using the Pythagorean theorem.
2. Number of unique records in the cluster.
3. The average of the surrounding cells compared to the average of the surrounding cells.
This gives one and many relationships. That is, one source cluster is associated with its many target cluster neighbors.
c. Label all records in the source cluster with population 1, and label all records in the target cluster with population 2. This is used to determine how different the two groups are based on:
d. A scoring function is used to calculate an IV “score” using population 1 and population 2. This scoring function includes, but is not limited to, for example, a modified T test scoring function, a color contrast scoring function, an IV impact scoring function, and the like.
The “modified T test scoring function” is performed as follows:
The modified T test is based on a regular T test that compares two population groups. The difference is scored after the T test and the final score is calculated by multiplying the T test score by the reduction ratio. That is,
Modified T test = (reduction ratio) × T test reduction ratio is calculated by counting the number of records in the target population that is greater than the average of the source population. This number is then subtracted from the number of records in the target population that is less than the average of the source population. Finally, the reduction ratio is calculated by dividing by the total number of records in the target population. That is,
Reduction ratio = (absolute value of target records less than source average−number of target records greater than source average) ÷ total number of records in target area This score is stored for later ranking of the IV neural map.
The “color contrast scoring function” is performed as follows:
The color contrast between population 1 and population 2 on the IV neural map is compared.
The “IV impact scoring function” is performed as follows:
The color contrast determined as described above is multiplied by an impact score based on the DV neural map.
e. Step d. For each IV neural map in the hypercube. repeat.
f. Rank the IV neural map according to the modified T test score. If the modified T test score approaches zero before all IVs are used or before the user specified threshold is reached, the remaining IV neural map is ranked using the general T test score. Attached.
g. Store the top percentage IV neural map specified by the user configuration settings.

III. Select the top X% of IVs (with the highest total score; specified in the configuration file by the user) that generates the results and sends the results to other analysis methods . In accordance with one or more embodiments of the present invention, the following automated results are generated for the user to see for each winning snapshot.
a. A winning IV neural map is displayed. The independent variable SOM map is a background map with dependent variables “hill” and “pond” clusters outlined at the top, with a clear outline color and a clear cluster label. The map legend is indicated with three distinct colors (eg, green, red, blue) combined together with the actual value of the color boundary threshold.
b. The actual result will run for this particular winning DV. This is the actual result of how IVs are ranked against each other for a given selected DV.
c. A smaller data set is written that contains only the records that make up the source and target regions. This smaller data set is a reference for further analysis by other data analysis methods. For example, to obtain an automated “question”, this smaller data set is fed back into the rule-derived data analysis method engine with the appropriate region outlined from the map matching run. These areas form the “questions” that the rule induction analysis explains. Rule derivation generates rules that describe the interaction of variables with statistical validity. It searches the database to find a hypothesis that best fits the generated question.

IV. Repeat steps I-III for all DVs :
Repeat steps I through III for all DVs specified by the user in the configuration file. Perform integrated housekeeping tasks, prepare automated map matching results report generation, and send these run responses to other data analysis methods.

  In accordance with one or more embodiments of the present invention, the data brain module includes an inventive data mining algorithm application, hereinafter referred to as “Pigin”. Piggin is an inventive data mining algorithm application that determines which other numeric variables in a data set contribute (ie, correlate) to a specified target variable for a targeted numerical variable. is there. Piggin does not analyze categorical data (in that sense, it is narrower in scope than some other data mining algorithms), but it analyzes faster and more efficiently than other standard data mining algorithms. Use to carry out. This algorithm handles targeted variables (ie, variables described by data mining exercises—hereinafter referred to as the dependent variable (“DV”)). The algorithm operates according to the following steps: Step 1: Process DV numeric distribution as a series of categories based on user configurable parameters that determine how much data is placed in each category. Step 1 is shown in FIG. FIG. 18 shows that the “virtual” category is defined from the numerical distribution. Step 2: After DV groups (or splits) are defined in Step 1, based on data matching that category for other numeric variables in the data set (hereinafter referred to as independent variables, or “IV”) A series of confidence distribution circles is calculated for each DV category. Step 3: Based on the overall spread of the confidence circle for each IV, it is used to determine which IV is most highly correlated with the “targeted” DV by the analyst at a later time. A diameter score and a gap score are assigned to the variables. A high value for the diameter score or gap score often indicates that DV and IV are “better” correlated. Steps 2 and 3 are shown in FIG. FIG. 19 shows the calculation of these scores, calculated as [Gap score = sum of all gaps (not in any circle)] and [Diameter score = DV average diameter of 3 circles]. The Here, the DV category is based on a numerical distribution for the DV. In summary, FIG. 19 shows a confidence such that each diamond represents a population and the end points of the diamond are plotted on the right side of the diagram (these circles are referred to as “95% confidence circles”). It is a plot. Step 4: Repeat. After the scores have been assigned to all IVs based on the DV definition in step 1, the DV is redefined to slightly change the split definition. After this redefinition is done, the scores for all IVs for the new DV category definition are recalculated. The process of refining the DV category definition continues until the number of iterations specified by the user in the analysis template is reached. Step 5: Overall score. When all iterations are complete, there will be a series of IV rankings based on the various definitions of DV as described in steps 1 and 4. These lists are merged to form a “master-ranked” list of IVs that are most highly correlated to the target DV. When calculating the master score for a given IV, three factors are taken into account. That is, the size of the gap score, the size of the diameter score, and the number of times IV appears in the DV scoring list series. These three factors, combined with some basic “junk result” exclusion criteria, form the most highly correlated list of IVs for a given targeted DV. This is shown in FIG. While one or more of these examples have been described using gap scores and diameter scores for each IV encountered, the examples of the present invention are not limited to these types of scores, in fact, It should be understood that there are further examples that use other scoring functions to calculate a score for IV.

  In accordance with one or more embodiments of the present invention, the data brain module can correlate numeric data with categorical data or attribute data (such as, but not limited to, processing tool IDs). including. This application allows (a) fast statistical output ranked on qualitative rules, (b) ranked scoring based on diameter score and / or gap score, and (c) less expressed tool ID. The scoring threshold used to eliminate, (d) the ability to select the number of top “findings” to be displayed, and (e) the results from “findings” (tool ID) Provide the ability to perform reverse runs, which can be dependent variables and parameters (numbers) affected by allowing these “findings” (tool IDs) to be displayed.

  FIG. 21 shows an example of a subset of a data matrix that is an input to the data brain module correlation application described above. In this example, end-of-line probe data (BIN) is shown relative to a lot, along with a processing tool ID (Eq_Id) and processing time (Trackin). Similar data matrices can be created based on wafers, sites (reticles), or dies.

  FIG. 22 shows an example of a number (bin) vs category (tool ID) run. Using bins (numbers) as a dependent variable, the data brain module correlation application described above creates a similar plot for each Eq_Id in the data matrix. The diamond width in the left plot represents the number of lots run through the tool, and the circle diameter in the right plot represents the 95% confidence level.

  To classify many plots, the sum of the gap space between circles (ie, the region not surrounded by circles) and the total distance between the top of the top circle and the bottom of the bottom circle is expressed as “gap Used as part of the formula to calculate what is called "score" or "diameter score". As described above, the data brain module correlation application classifies the plots in order of importance based on a relative weight that can be selected by the user in favor of the score type.

  According to another aspect of this embodiment of the invention, the data brain module correlation application described above sets a scoring threshold. There are many processing tools that are typically used for specific processing layers of an IC, but only a subset of them is used in the normal criteria. Unused processing tools often skew data regularly and cause unwanted noise during data processing. The data brain module correlation application described above can use user-defined scoring values so that less-represented tools can be filtered out prior to analysis. For example, if the scoring threshold is set to 90, XTOOL3 will be filtered because XTOOL1 and XTOOL2 in the three tools shown in Figure 23 contain more than 90% of the lot. Eliminated.

  In accordance with one or more embodiments of the present invention, the data brain module correlation application described above provides a “number of top scores” option. By using this feature, the user can determine the maximum number of results that can be displayed for each dependent variable. Thus, the data brain module correlation application described above performs an analysis on all independent variables, but only the number of plot entries in the “number of top scores” field is displayed.

  In accordance with one or more embodiments of the present invention, the data brain module correlation application described above makes a category (for example, but not limited to, a tool ID) a dependent variable, and a numerical parameter that is affected by the category. It also performs a reverse run (reverse MahaCu) that displays (but not limited to, for example, bins, electrical tests, measurements, etc.) in order of importance. This importance (score) is the same as that performed during the number versus tool ID run. These runs can be “daisy chained” where tool IDs detected during normal runs can be automatically made dependent variables for reverse runs.

According to one or more embodiments of the present invention, it includes an application called a defect brain module that ranks defect problems based on scoring techniques. However, in order to perform this analysis, the defect data must be formatted by the data conversion module 3020 as described below. FIG. 24 shows an example of a defect data file generated by, for example, a defect inspection tool or a defect review tool in a factory. Specifically, such a file typically includes information about the x and y coordinates, x and y die coordinates, size, defect type code, and image information for each defect on the wafer. According to one or more embodiments of the present invention, the data conversion module 3020 converts the defect data file into a matrix of die level sizing, classification (eg, defect type) and defect density. FIG. 25 shows an example of a data matrix created by the data conversion algorithm. According to one embodiment of the present invention, the defect brain module comprises an automated defect data mining fault detection application that ranks defect problems based on scoring techniques. According to this application, the impact of a particular size bin or defect type is quantified using a parameter referred to below as the “kill ratio”. The kill ratio is defined as follows:
Kill ratio = number of defective dies with defect type ÷ total number of dies with defect type

Another parameter that can also be used is% loss, which is defined as:
% Loss = number of defective dies with defective mold ÷ total number of defective dies

  A defective die within the above definition is called a nonfunctional die.

  FIG. 26 shows a typical output of a defect brain module application. In FIG. 26, the number of dies containing a particular defect type (in this example, microgauge) is plotted against the number of defects of that type on the die. Because there is functional (ie good) and dysfunctional (ie bad) die information in the data matrix, determine which die, including the specific defect type, is good or bad It is easy to do. Therefore, good and bad die frequencies are plotted in FIG. 26, and the ratio of bad dies to the total number of dies including defects (ie, kill ratio) is shown as a graph. In these graphs, the gradients of the graphical segments are extracted and compared with the gradients of the graphical segments from all other plots generated by the defect brain module application, and they are ranked from the highest gradient to the lowest gradient. The The graph with the highest slope is the most important slope that affects yield and will be valuable to yield improvement engineers.

  One important feature of these plots is the ability of the defect brain module application to adjust the maximum number of “number of defects” bins on the x-axis. If this cannot be used, the slope ranking will be incorrect if there are an unusual number of defects on a die, such as in the case of harmful or false defects.

In accordance with one or more embodiments of the present invention, the data brain module can be, for example, a data cleaner (eg, Pearl and C ⁺⁺ software created according to any one of a number of methods known in the art). Applications), data conversion programs (eg, Perl and C ⁺⁺ software applications created according to any one of many methods known in the art), and data filters (eg, many known in the art) Utilize utilities such as Perl and C ⁺⁺ software applications created according to any one of the methods. These data cleaning, data conversion, and / or data filtering can be performed according to the criteria described in the configuration file section or special criteria upon receipt of user input. In accordance with one or more embodiments of the present invention, the data brain module is a software application that runs on a PC server and is encoded in C ⁺⁺ and SOM by any one of a number of methods known in the art. It has become.

According to one or more embodiments of the present invention, the output of the data brain engine module 3080 is a results database 3090 implemented as a Microsoft FoxPro ^™ database. Further, in accordance with one or more embodiments of the present invention, the WEB commander module 3070 is secure ftp transmission software created according to any one of a number of methods known in the art, such as a user or client Can use this secure ftp transmission software to send data to the data brain engine module 3080 for analysis.

  The results of the data mining process described above are themselves “important” as a Boolean rule that responds to the questions imposed on the data mining algorithm (as in the case of rule derivation) or by a template in the configuration file. Often expressed as a relative ranking, or statistical contribution, of variables targeted or indicated. Depending on which specific data mining algorithm was used, the type of data consisting of “results” (ie numeric data or categorical variable types) generated by the data mining algorithm was A set of predefined statistical output graphs that can be defined by a user to accompany a data mining analysis run. According to one or more embodiments of the present invention, such automated output may include a “raw” data matrix of data used for the first pass of data mining, and / or a complete data mining process. It can be accompanied by a smaller “result” data set containing only a column of data consisting of “results”. All such information is stored in the results database 3090 after the automated data mining analysis run is completed.

Results Distribution : As further shown in FIG. 3, according to one or more embodiments of the present invention, the WEB visualization module 3100 accesses a results database 3090 created by the data brain engine module 3080. For example, but not limited to, a graphics and analysis engine 3110 that generates an HTML report stored in the WEB server database 3120 is run. In accordance with one or more embodiments of the present invention, the WEB server database 3120 is not limited to routing reports according to any one of many methods known in the art, For example, it can be accessed by a user using a web browser on a PC. In accordance with one or more embodiments of the present invention, the WEB visualization module 3100 can generate a powerpoint file for repeated reporting of results, charts, reports, and exports enabled by a web browser, configuration file. Enable multi-user access to enable creation and modification, accounting management, results email notification, and information sharing. Further, in accordance with one or more embodiments of the present invention, the WEB visualization module 3100 can be used by multiple users (with sufficient secure access) to view and modify a Microsoft Power Point (and / or Word) Allows multiple users to create online collaborative documents. In accordance with one or more embodiments of the present invention, the WEB visualization module 3100 is a software application that runs on a PC server and encodes using Java Applets, Microsoft Active Server Pages (ASP) code, and XML. Has been. For example, the WEB visualization module 3100 runs on a management module (eg, a PC server, which can be set up by a new user (for example, but not limited to, specifications for protected access to various system functions). Access to user privileges (including but not limited to data analysis results, configuration file setup, etc.), including software applications encoded with web Microsoft ASP code according to any one of many known methods Including). The WEB visualization module 3100 also allows a user to view the analysis results and create a report (eg, running on a PC server and any of a number of methods known in the art). Software application encoded with web Microsoft ASP code). The WEB visualization module 3100 also provides a charting module that allows users to create special charts using their web browser (eg, running on a PC server, many known in the art). Software application encoded with web Microsoft ASP code) according to any one of the methods. The WEB visualization module 3100 further includes a combined cube module (e.g., running on a PC server, allowing users to combine data sets prior to data mining and / or hypercube formation in the art). Includes software applications encoded with web Microsoft ASP code according to any one of many known methods. The WEB visualization module 3100 also runs on a filter module (eg, running on a PC server that allows the user to filter the data collected in the hypercube before performing data mining on the data. Such filtering is performed according to user-specified criteria, including software applications encoded in web Microsoft ASP code according to any one of many methods known in the art. The WEB visualization module 3100 further runs an online data tool module (eg, running on a PC server, which allows users to perform data mining on a special basis using their web browser, Software application encoded with web Microsoft ASP code according to any one of many known methods. In accordance with one or more embodiments of the present invention, the user may allow the WEB visualization module 3100 to use a statistical process control ("" that allows the user to track a predetermined data matrix using a web browser. A configuration file can be configured to prepare the SPC ") chart.

  Those skilled in the art will appreciate that the above description is merely illustrative. Also, the above description is not intended to exclude or limit to those other than the precise shapes describing the present invention. For example, although certain dimensions have been described, various designs can be implemented using the embodiments described above, and the actual dimensions for these designs are determined according to circuit requirements, so these Is just an example.

FIG. 1 illustrates a yield analysis tool infrastructure that exists in a prior art integrated circuit (“IC”) manufacturing or assembly plant (“semiconductor factory” or “factory”). FIG. 2 illustrates a prior art process (referred to herein as end-of-line monitoring) utilized in a factory. A factory data analysis system manufactured according to one or more embodiments of the present invention, and raw formatted when applied to one or more embodiments of the present invention for use in an IC manufacturing process. FIG. 6 is a diagram illustrating an automated data flow from no input to a data mining result. FIG. 4 illustrates a logical data flow of a method for configuring unconfigured data events on an intelligent basis in accordance with one or more embodiments of the present invention. FIG. 4 is a diagram illustrating an example of raw time-based data, more specifically, a graph representing processing tool beam current as a function of time. FIG. 6 is a diagram showing how the raw time base data shown in FIG. 5 is divided into segments. FIG. 7 illustrates raw time-based data associated with segment 1 of FIG. It is a figure which shows the example of the dependence of the Y range in the segment 7 on bin_S. It is a figure which shows a 3 level branch data mining run. FIG. 6 illustrates a distribution queue creation performed by a data brain command center application in accordance with one or more embodiments of the present invention. FIG. 5 illustrates an analysis template user interface portion of a user editing and configuration file interface module manufactured in accordance with one or more embodiments of the present invention. FIG. 6 illustrates an analysis template portion of a configuration file manufactured in accordance with one or more embodiments of the present invention. It is a figure which shows a hyper pyramid cube structure. FIG. 4 is a diagram showing a hyperpyramid cube, with one layer highlighted. It is a figure which shows the hypercube layer (self-organizing map) from the hypercube extracted from the 2nd layer of the hyperpyramid cube. FIG. 4 shows a self-organizing map having high, low, and central regions, each of which is tagged for future automated map matching analysis. It is a figure which shows the cell projection through a hypercube. It is a figure which shows defining a "virtual" category from numerical distribution. Gap score (gap score = (sum of all gaps (not in any circle)), and diameter score (diameter score = DV average diameter of 3 circles) when the DV category is based on DV numerical distribution It is a figure which shows calculation. FIG. 6 illustrates the calculation of a master score for a given IV, taking into account three factors: the size of the gap score, the size of the diameter score, and the number of IVs that appear on the DV scoring list series. It is a figure which shows the example of the subset of the data matrix which is the input to a data brain module. It is a figure which shows the example of a number (bin) vs category (tool ID) run. FIG. 6 illustrates the use of scoring thresholds for three tools. It is a figure which shows the example of the defect data file which the defect inspection tool or defect review tool in a factory produces | generates. It is a figure which shows the example of the data matrix produced by the data conversion algorithm. FIG. 3 is a diagram illustrating a typical output of a defective brain module.

Claims (21)

A method of data mining information obtained at an integrated circuit manufacturing factory (“factory”),
(A) collecting data from one or more of systems, tools, and databases that generate data in the factory or collect data from the factory;
(B) formatting the data and storing the formatted data in a source database;
(C) extracting a portion of the data for use in data mining according to a configuration file specified by the user;
(D) data mining the extracted portion of the data in response to an analysis configuration file specified by the user;
(E) storing the result of the data mining in a result database;
(F) providing access to the results;
A method comprising the steps of:   The method of claim 1, wherein collecting the data comprises collecting in real time through a network on demand or on a scheduled basis.   The method of claim 1, wherein providing access comprises providing access through a network.   The method of claim 3, wherein providing access through the network includes providing access using a browser.   The method of claim 1, wherein collecting the data occurs in real time, and formatting the data and storing the formatted data in a source database occurs in real time. .   The method of claim 1, wherein collecting the data includes collecting data transmitted in a format commanded by a customer and / or commanded by a tool.   The method of claim 1, wherein collecting the data comprises collecting encrypted data.   The step of formatting the data is that the data is a widget ID, where? ,What time? ,what? And a leveling scheme including a value level.   9. The method of claim 8, wherein the widget ID is identified by one or more of lot ID, wafer ID, slot ID, reticle ID, die ID, and sub-die x, y Cartesian coordinates.   Where? 9. The method of claim 8, wherein the method is identified by one or more of a process flow / assembly line manufacturing step and substeps.   What time? 9. The method of claim 8, wherein is identified by one or more of a measurement date / time.   The step of formatting includes the step of converting time-based operational state data generated in a processing tool in a factory during wafer processing into key integrated circuit specific statistics according to a configuration file. The method according to 1.   The storing step further includes a step of extracting data from the source database, and a step of storing the extracted data in a hybrid database comprising a relational database component and a file system component. The method of claim 1.   The method of claim 13, wherein the relational database component uses a hash index algorithm to create an access key to discrete data stored in the file system component. .   The method of claim 14, wherein the extracting step comprises using a hash and join algorithm to accumulate data from the hybrid database.   The extracting step includes obtaining a hypercube definition using the configuration file, creating a vector cache definition using the hypercube definition, and creating a vector cache of information. The method of claim 14, wherein:   Creating a vector cache of the information comprises: (a) retrieving a list of files and data elements identified by the vector cache definition from the relational database component using a hash index key; (B) retrieving the file from the file system component; and (c) grouping the vector cache with data elements identified in the vector cache definition. The method of claim 16.   The method of claim 17, wherein the extracting step further comprises generating a hypercube from the vector cache information using the hypercube definition.   The data mining step includes self-organizing map data mining, rule-derived data mining, data mining for correlating numeric data with categorical data or attribute data, and converting the categorical data or attribute data into numeric data. The method of claim 1, comprising using one or more of data mining for correlation.   The data mining step includes a step of self-organizing map data mining to form a cluster, a step of performing map matching by performing map matching analysis on an output from the SOM data mining, and an SOM data mining analysis. Generating a rule description of the cluster by rule-derived data mining of the output of the data, correlating the category-specific data with the numerical data of the output from the rule-derived data mining, and numerical data as the map matching data mining The method of claim 1 including the step of correlating to categorical data of output from the ning.   The SOM data mining step automatically organizes the data and identifies separate and dominant data clusters that represent different “factory issues” within a data set, and the map matching analysis 21. A method according to claim 20, characterized in that a "variable" is described by some historical data known to impact the "interesting" variable behavior on a cluster-by-cluster basis.

Images