Customer Solutions

Process Module Emulation using LabVIEW

Author(s):

Chris Thorgrimsson, Lam Research Corporation

Industry:

Semiconductor

Product:

Data Acquisition, LabVIEW

The Challenge:

Develop a method for accurately reproducing and identifying both real-time control system and user interface software errors encountered by end users of Lam etch process equipment.

The Solution:

Create models, using LabVIEW, that represent the different components and aspects of etch process equipment, then, combine these models to form a highly configurable equipment emulator that utilizes DAQ, MXI-2, and LabVIEW.

Introduction
There is an acronym in the semiconductor industry called MTTR, which stands for "Mean Time To Repair". MTTR represents the average time it takes to repair a piece of equipment once it fails. When the MTTR clock starts, the quickest method to resolve the failure is needed. However, when software is the cause of the failure, a quick resolution can sometimes be difficult.

System complexity can often hinder software troubleshooting. Lam Research, a leading supplier of etch equipment, has systems that consist of considerable amounts of centralized input and output (I/O). These I/O signals can be found in a VME bus enclosure, often referred to as the VME rack. Central to the equipment control system, and housed in the VME rack, is a real-time embedded controller. The VME rack also contains multiple I/O cards, called ADIO boards, which contain analog input, analog output, digital input, and digital output. In some applications, additional serial VME devices may also be used. Using both requests from the operator interface and input signal status, the real-time component will coordinate and control the output signals. I/O point status is also passed to the operator interface for display, manipulation, or storage. Unfortunately, the combination of high I/O signal count and the complex nature of the real-time control system software actually contribute to the difficulty in identifying errors while adding time to the MTTR clock.

System Description
The solution to this problem was to develop a highly programmable etch equipment module emulator to aid in troubleshooting these complex software issues. The emulator needed to have enough I/O to interface with the existing VME control rack while providing programmable, seamless emulation of any signal that may affect real-time control. The emulator also had to be configurable in order to match Lam’s various etch equipment configurations, often referred to as process modules (PMs).

The use of National Instruments VXI data acquisition (DAQ) products satisfied the demand for a device that could provide the high number of I/O signal needed to emulate a complete PM. To simplify the system and keep the system cost low, an off-the-shelf personal computer (PC) utilizing MXI-2 technology was chosen as the VXI system controller. Finally, LabVIEW was chosen as the development environment. LabVIEW allows the emulator software to leverage off of the extensive library of DAQ virtual instruments (VIs) resulting in faster development time. A conceptual view of the entire PM emulation system can be seen in diagram 1.
The PM emulator is divided into 4 functional blocks, illustrated by diagram 2. A simple explanation of each functional block, starting with "Models", is provided:

Models
The most central concept, and the key to flexibility, is the use of models. Each model represents some component or aspect of an etch PM. Based on the input, it is the responsibility of each model to mimic the actual component or aspect of the PM, resulting in an output that the VME system controller believes to be real. Using this approach implies that the only limitation to the overall accuracy of the emulator is the individual accuracy of each model. In total, 14 models were used to represent a PM. Flexibility is obtained by selecting the appropriate model for the given equipment configuration.

Input Handler
Each model requires input in order to perform its action. The input handler has the responsibility of scanning all analog and digital input channels on the VXI-DAQ cards. It then arranges the values returned by the scan into model order, then creates one complete package for delivery to the next functional block, the scenario engine.

Scenario Engine
To give the emulator programmability, a scenario engine was developed. The scenario engine has the ability to provide "false" input to each model, regardless of the actual input signal value. It does this by decoding the package sent by the input handler and comparing the value of each scanned signal against a user defined script. If a conditional match is found, the signal is modified according to the script. Finally,any modified input value is substituted for the original, then repackaged and delivered to all the models.

Output Handler
The final functional block is the output handler. The output handler receives all the output from each model. It then decodes the information and updates each analog and digital output channel on the VXI-DAQ cards with an appropriate value.

One of the challenges faced when development began was determining a method for each functional block to communicate its data to the next block. It was decided that each functional block would be a separate virtual instrument that utilized LabVIEW’s Notification sub VIs. Using these, the software is able to synchronize each functional block VI. Data packages are then transferred using the message capability of the Notification sub VI. This approach also has the added benefit of a modular design. Function block VIs, mainly the different models, can be improved or changed without concern of incompatibility with the other functional block VIs, providing that the data package format remains the same.

Finally, what ties the entire emulator together is an interactive user interface. This interface provides a general overview of the emulator performance, through the use of a PM graphic. The emulator interface also provides access to each model, allowing the user to see real time I/O point status. This user interface design also allows for some degree of manual control over each model's state.

Conclusion
The true measure of success for this, or any, development project is to meet the requirements of the challenge. The emulator has proven it worth in multiple software troubleshooting efforts at Lam by providing a very rapid turnaround from the problem identification stage to the delivery of a solution, resulting in lower MTTRs. Engineers are constantly finding new applications for the emulator, making it an invaluable tool in the on-going pursuit to make better products.

thorgrim.pdf

View the entire user solution in Adobe Acrobat PDF format.