An Expert Advisor for Photolithography

Introduction

An integrated circuit fabrication line, like many manufac­ turing lines, is organized around a sequence of stations manned by technicians. Most stations process a wafer once or twice before it is finished, but for the photolithography step (placing a pattern on the wafer similar to photography) each wafer is processed up to 15 times. When a photolithog­ raphy problem arises, this step becomes the bottleneck for the whole line. Wafers continue to be processed at other stations, causing a stockpi le to build while the process en­ gineer is called in to fire fight (diagnose and correct the problem).

When fire fighting, the process engineer's first priority is to get the line up and running again as quickly as possible. Fire fighting consumes about half his day, conflicting with his main responsiblities of coordinating line personnel and monitoring and controlling the process to meet specifica­ tions on uniformity of pattern thickness, develop, exposure, baking, and many other variables. Under these circum­ stances, temporary solutions usually result, with no time left for designing long-term solutions to recurrent problems.

An expert system, like the Photolithography Advisor , can help alleviate fire fighting, monitor and control the process, record process data that can help determine what the re­ current problems are, and provide information needed to coordinate line personnel on different work shifts.

The complex procedures needed to produce correct pat­ terns by photolithography are many and varied. For an overview, see (Thompson, et a!, 1983). In addition, the number of ways a defective pattern can be produced is very large . When armed with this knowledge, the Advisor can help the technician focus on the data pPrtinent to isolating frame database. In this sense, the Advisor uses a blackboard architecture (Erman et. al., 1980).

Any specialist can ask for more information when need­ ed. This allows the consultation to be focused, eliminates asking for extraneous or irrelevant information that may be expensive in time and effort to gather, and results in a more human-like interaction.

The basic diagnostic strategy is to work with visual symptoms first. A visual inspection revealing no symptoms does not mean the wafer is free of defects. It only means that no gross defects can be detected by the naked eye. In such cases, the Advisor requests the user to examine the wafer under the microscope at low magnification. If symp­ toms are found by this inspection, they must be verified using high magnification.

The user interface has turned out to be one of the most important components. Initially, we were more interested in problem-solving performance than ease of use, so a sim­ ple glass tty interface was used. This was unsatisfactory. In response, we implemented an interface which required very little typing (all questions being asked through pop­ up menus) and recorded all interaction in a transcript win­ dow. The user could then answer most quest ions by using either a single-key command, pressing a softkey, or select­ ing with the mouse. The consultation could be reviewed by scrolling back in the transcript window. We are now build­ ing another interface that implements a virtual advisor's notebook. It uses graphical representations of the wafer and processing equipment, sophisticated browsers for ex­ amining the knowledge-base, and a laser-disc database of symptom and defect images. While being as easy to use as the current interface, this interface will use more cogni­ tively stimulating media to provide considerably more ex­ planatory power.

Performance and Evaluation

The first version of the Photolithography Advisor was in­ stalled in a low-volume research lab and was used for about a year. At the time of this writing, we have just installed a second version of the program in a manufacturing line for additional testing.

The test in the research lab helped us debug the knowl­ edge base and obtain useful ideas on what was needed in the user interface. Overall, the program was considered quite useful and generally diagnosed problems as well as the available process engineers (the same ones who helped us build the program).

Some of the benefits of the program were:

• Substantial time was saved in processing wafers. If a process error is not detected, reprocessing could take up to 8 hours; whereas running the program required less than 10 minutes .
• The Advisor was always available, even during the night shift. Process engineers like to sleep at night.
• The hardware emitted less particles than an engineer and could be installed in the clean room where it was convenient and available.
• The hardware cost was less than $35,000; cheaper than a full-time engineer.

Some of the needs uncovered during this informal test were:

• Most users were naive computer users. The inter­ face must eliminate most typing and make correcting errors easy when typing is needed. We dealt with this in the next version by extensively using popup menus and customized softkeys, eliminating most typ­ ing. Where typing was still needed, customized editor modes were designed that limited the number of ways a user could get into trouble.
• Questions asked by the Advisor used jargon to de­ scribe wafer defects. Menu items could easily be mis­ interpreted. We dealt with this terminology problem by adding alternate definitions for defects and col­ lected photographs to illustrate defects. By showing a photograph of the defect we were trying to describe, we avoided misinterpretation of the text.
• Experienced users were frustrated having to answer questions about visual symptoms when they knew a high-power inspection was needed. We accomodated them by structuring the menus to have default an­ swers that provided an express-lane to more detailed inspection.
• Desp ite our attempt to make the problem-solving knowledge generic, most fabrication lines wi ll want to customi:>:e for local practice. Domain experts (with training from us) can now edit the knowledge base us­ ing a sophisticated set of browsing tools that do not require knowing the syntax of either HP-RL or LISP.
• The program's problem-solving ability was inade­ quately tested. Measuring this ability was difficult since the research processes were continually modi­ fied.

Primarily because of the last point , we have started an extensive field test on a production line to more fairly and completely test it in its target environment than could be done in a research facility. This evaluation consists of an in vivo use of the program on a negative resist fabrication line, a user survey, and a comparision of key process statistics using before and after data.

The user survey has two parts. The first is administered with each consultation. Here we are trying to ascertain the program's accuracy and obtain detailed comments about the wording on menus, of advice, etc . The second survey is administered every month to collect more general com­ ments about the friendliness and usefulness of the system.

Statistics measuring process performance include yield histories, rework rates, process hold times, and equip­ ment downtime. Many of these are collected automatically by existing process management software. Thus, a large database of data on past performance of the process line exists. In cases where the necessary data is not logged by existing software, the Advisor' automatically collects it so that it can be compared with manually reconstructed past data.

Conclusions

Developing the Photolithography Advisor has been a useful experiment in building an industrial strength expert system. As with other such systems, the experiment may never be completely finished, but some valuable insights about the process have already been gained.

We have found that people not trained in AI can quickly learn to modify an expert system in their domain of exper­ tise if given the right tools. But we have also found that they are limited if they are not an experienced AI program­ mer.

Domain experts tend to introspect about their problem­ solving strategies in terms of plans. Even simple planning constructs are useful in helping them articu late their ex­ pertise.

Building an expert system has much in common with other types of software engineering. The programming paradigm is different, but experimentation, iteration, and testing are as important here as in other types of program­ ming.

Meta-level rules can be useful initially to capture an ex­ pert's problem-solving heuristics. Once the problem is bet­ ter understood, however, they can usually be replaced by specific object-level rules that solve the problem much bet­ ter (and more efficiently).

Experts disagree. It helps to sample a lot of them. In our application, many problems can be solved several ways. Which solution is used often depends on personal preference or on established local procedures. Vocabulary can also be a problem. Different people will call the same thing by different names. This problem becomes acute when trying to design the user interface.

We are enhancing the Advisor in several ways. The knowledge-base is now being extended to include positive resist processes, which are gaining popularity for fabricat­ ing smaller patterns on wafers. The user interface is being redesigned to better reflect our model of the program as a team of cooperating specialists using graphics, anima­ tion, and video display media. The problem-solving strat­ egy used by the program is really quite generic to a wide variety of fault-diagnosis problems important to us. We are restructuring the knowledge representation to better sepa­ rate the problem-solving knowledge (and control) from the domain-specific knowledge so that a fault-diagnosis shell can be extracted.

Acknowledgements

Christopher Clare, David Liu, and Wayne Pratt served as domain experts for the first prototype Advisor. Douglas Lanam programmed much of this version. Mike Walker helped program the current version and Pat Pandolfi de­ signed the surveys being used in the evaluation and is edit­ ing the video slide database. The TRC Photolithography Team headed by Jeff Hintzke created and photographed many of the defect photographs. The work described here was made possible by the support and cooperative environ­ ment provided by the management of the Application Tech­ nology and Technology Research Centers of the Hewlett­ Packard Company.