OCR strategy for successful 100% single-wafer tracking
01/01/2003
overview
Increasingly, semiconductor manufacturing is migrating toward fully automated all single-wafer processing because it provides improvements in cycle time and yield. Even for established fabs with some combination of automation and single-wafer processing, 100% single-wafer tracking throughout a fab can be a basic requirement for reaching high yields. This is the case at AMD's microprocessor fab in Germany, where engineers have created a solid OCR concept based on reliable wafer-scribe recognition, high read rates, throughput, and failure tolerance.
Single-wafer tracking in combination with randomizing, which is essential for yield analysis, requires a wafer-ID read at many different process steps. We have installed more than 50 wafer-sorters that perform randomization, verification, and split and merge operations. The sorters are almost exclusively used in remote mode. The cassette ID and slot map, as well as the ID of every wafer in the lot, is verified for every single sort. The whole lot is put on hold if there is a mismatch with the production database.
In implementing this approach, our No. 1 problem was the effect of process overlay on scribed OCR marks (Fig. 1). The level of degradation changes quite frequently along with process tweaks, new products, and technologies.
Standard or default OCR camera set-ups provided limited assistance in reading problem wafers. In addition, we found that it was not helpful to send scribe-images to OCR-system developers and it was not possible to send whole wafers. In practice, we had the final job of fine-tuning and selecting correct settings for a great variety of features. We found that software options (e.g., special filters, acceptance levels, thresholds, tuning algorithms, etc.) were not always adequate. Illumination system adjustments, such as correct camera focus, system dependent centering of bright and dark field LEDs, the correct aperture and camera lens, and pre-aligner notch location accuracy, have a very significant impact on the end result.
 Figure 1. Wafer-scribed OCR marks degraded by process overlay. |
null
Our second problem was that at AMD, we use more than one specified wafer ID location. Reprocessed test wafers have crossed out marks and new marks at another location. Further, "new technology" wafers are being started in parallel to existing wafers: these typically have marks that are incompatible with long-established ID locations.
These variations meant that we had to change the set-up of sorter OCR systems to follow a given pre-defined sequence of possible locations, stopping only when a valid ID was found. The set-up change itself was not a big problem, but it definitely caused a throughput hit because the read sequence was "hard-coded." Consider that OCR reading starts with a specified location at 180° from the wafer's notch, then looks at 0°, and finally at 22° (the reclaim wafer location). Assuming 50% of wafers have a valid scribe at 0°, the sorter starts reading half of the wafers at the wrong position.
Consider also the unsuitability in this case of the standard auto-tuning mode (i.e., the system's ability to tune light and other settings to find the best read result); at the beginning of the read sequence — 50% of the time in this case — the OCR would try to tune in on an ID that was not actually present. This creates a tremendous throughput decrease. (Auto-tune is a must-have feature because it helps with heavily degraded OCR marks.)
null
Real solutions
We have used different approaches to address OCR mark quality. First, we try to eliminate any layers on top of OCR strings. One can imagine that changing a yielding, fine-tuned process just to clear a scribed mark caused understandable resistance from operations. We also dealt with the OCR system itself, looking at several options to increase the OCR read-rate.
Finally, analysis of read-fail data and patterns in combination with lot integrity and verification rules used by the host controller reduced read-fails at least by half; we applied a simple probability rule. Here, a key capability involved accessing the data-and-image pool via web access; this helped us obtain the attention of operations personnel in a fab environment where wafer ID-related issues are far from the main focus of product and integration engineers.
OCR performance database
Our error, alarm, and performance tracking database (Fig. 2) includes OCR read-fail images that provide the required level of detail for effectively improving the system, facilitating troubleshooting, and providing for monitoring and continued improvement.
This set-up includes two different data sources: remote information and local data of interest. The wafer-sorter equipment interface (EI) sends alarm and error messages that include error category, date and time, lot, wafer ID, cassette, and several other data categories specific to our operation. This information is e-mailed to a general technician account for immediate corrective action. A separate database loader puts this information into the sorter-tracking database where all types of errors and alarms are stored, not just OCR-related issues.
Periodically, a second loader automatically downloads local machine alarm and error messages and scribe images that have been automatically stored from all sorters. These images are converted to JPEG files for web compatibility. To make sure both remote and local information are synchronized, we have activated WinNT time service on all wafer sorters, and the remote-host controller is connected to the same time server.
 Figure 3. Sample SQL query result with read-fail images and remote information. |
null
Web-based OCR image table
To enable simple access to sorter OCR data, we implemented a web-based SQL reporting system. This allowed access to needed information from almost every terminal in our offices or from the production floor. By default, the web GUI displays an SQL statement to generate a read-fail report with associated images and remote information such as lot, product, cassette, etc. (Fig. 3). With access to read-fail images, engineers at their desks can remotely diagnose problems (e.g., perhaps a given read-fail is related to a notch find or alignment error where the scribe is not completely inside the camera's window).
To keep the report flexible, and to incorporate images easily,the picture itself is not stored in the database. The report makes a link to the JPEG file including the HTML image tag notation. The default SQL statement joins the two tables containing remote and local data. Our SQL syntax ensures that the correct read-fail image is placed next to the remote information. This works because both systems are connected to the same time server; we allow an interval to accommodate for network or processor load delays and inaccuracies from machine times, which, depending on the time service setting, may fluctuate by a few seconds.
OCR configuration success rate tool
In our work, we found that once it is fairly clear that a read-fail is not related to hardware failures, such as a misaligned wafer or a wafer with an out-of-specification scribe, we had to work with the OCR software to find more suitable settings (e.g., lights, filters, etc.) that were able to read the degraded scribe. Since there are multiple products with different process flows and all kinds of test wafers in our production line, it is typical to have more than one OCR configuration to cope with different scribe conditions on wafers. The caveat here is to avoid the time consumption you need to limit the number of active configurations — too many means that the OCR software may sequentially try all configurations until it succeeds or runs out of options and reports a failure to read and saves the image to hard disk.
Our system generates a configuration success rate report (see table), which is also accessible via the web. The report is based on the local OCR software log file that keeps a record of every read-try together with other parameters and values of the corresponding configuration. A server script takes this log file as input and generates a table with one line per configuration and calculates how often each configuration was selected and successful.
The data in the table show that configurations 2, 3, and 4 are not very successful; configuration 5 is even worse. Analysis of these data reveal that it would make sense either to adapt configuration 5 to suit the current read-fail or to remove it from the list to increase throughput. In addition, it is prudent to change 2 or 3. On the other hand, configuration 0 should be left unchanged since it seems to be the top performer for that tool.
 Figure 4. Overall OCR read-rate including test wafers. |
null
Automatic read-fail recovery
We know that 100% single-wafer tracking in combination with randomizing requires every wafer to be verified. In addition, the database must be updated with actual slot position (in particular immediately after randomize) more than 60 times during the manufacturing process. To consistently realize verified 100% single-wafer tracking, every lot with a mismatch or unknown wafer is put on hold and cannot be processed further until the problem has been resolved via technical assistance.
In our development, we realized that perhaps too many lots would be put on hold. After further analysis of the read-fail data, we found that many lots that went on hold were caused by only one unreadable wafer. So, we established a rule in the host controller to automatically recover one wafer in a lot provided the remaining wafers were read correctly and that the slot map of all wafers in that cassette matched the database entry. (More than one wafer/lot means that slot information is most likely compromised.) This rule helped to reduce read-fails and technician recovery callsby more than 50%.
Intelligent wafer ID location
When we addressed the several possible scribe locations on a wafer, we found that the standard software did not allow us to change the search order
ecipe; specifying 180° as the angle to start with, the sorter always looked first for a scribe at 180° before moving on to the next hard-coded location, no matter where the real scribe position was.
To provide flexibility for our multiple scribe-locations, we asked the supplier of the wafer sorters to implement a software feature that reports — via the SECS communication interface with storage in the host database — a number (i.e., wafer model) that represents the location of the successful read-wafer scribe. In addition, this feature also accepts a sequence of numbers (wafer models) as part of the remote recipe (on the fly) on a single-wafer basis via SECS communications.
In operation, the host controller always queries the database for the scribe location attribute of every wafer in a lot waiting to be sorted. So, based on the number reported by the database, a different optimized "start at this location" sequence can be downloaded. A sorter always starts with a fixed OCR setting on that location because that is the fastest way and usually it is successful. If it still fails, a tuning configuration is used next. If tuning cannot read the scribe, we try the remaining possible locations (in case the WIDS entry was wrong) and finally if all previous steps fail, we tell the sorter and OCR software to take a picture of every possible location and mark the scribe as unread.
With this concept, we observed a noticeable increase in sorter throughput and an improvement in read-rate, even when wafer starts were increasing.
Current results
Now, our read-rates, including test wafers and wafers automatically recovered, have reached acceptable levels (Fig. 4). These data include our introductory period of the "intelligent wafer location" concept and the transition to the new wafer material with the scribe at a different location. We anticipate that the read-rate will continue to improve once the new scribe location has been fully established and we phase out wafers with the old location. The new location is much closer to the wafer's edge — within the edge exclusion zone — and therefore process-wise much more controllable.
 |
For the future, we would like to have all sorter and OCR-related parameters and values remotely accessible at a tool (e.g., as ASCII files, XML based, or in a small local database like MS Access). This would facilitate maintenance by enabling us to change settings remotely on all or selected tools right from the office desk, which is particularly helpful with a large install-base, and definitely the right step toward e-diagnostics.
Olaf Zimmerhackl received his Diplom-Ingenieur in electrical engineering from Dresden University of Technology. He is senior automation engineer at AMD Saxony, mailstop E21-AU, Postfach 11-01-10, D-01330, Dresden, Germany; ph 49/351-277-3244,fax 49/351-277-9-3244, [email protected].