Subscriber
Index
Tool connectivity| thinfilmmfg.com
Subscriber
Index
Tool connectivity |
Data transfer protocols which evolved for wafer-centric applications like automation and defect detection are not well-suited to tool-centric applications like remote diagnostics and fault detection. Supplying data to both kinds of applications demands new interfaces and protocols.
Any large system can be viewed in many different ways. A gas system designer might view a semiconductor fab as a large network of interconnected pipes carrying various gases at various pressures. A lithographer might focus on exposure systems and resist processing systems, treating the rest of the fab as merely a source and sink for wafers.
Existing fab automation software typically takes a wafer-centric view. Wafers or lots move to and from tools, but tools themselves are essentially black boxes which accept a given number of lots and keep them for specified lengths of time. The inner workings of the tool are hidden from the automation system.
Existing defect control software takes a similar approach. Layers with specified properties appear on the wafer. The software makes sure each layer is the correct thickness, correct material, correct pattern, and so forth, but otherwise knows nothing about how the layer was created.
Applications with a wafer-centric view track the wafer's processing history, overlaid with defect maps, thickness measurements, and so forth. These applications can help improve fab productivity or pinpoint defect excursions. Combining data from several different wafers helps identify problem tools or track process drift. A wafer-centric application could demonstrate, for instance, a steady increase in the thickness of a layer on sequential wafers.
Another alternative, the tool-centric view, recognizes that process tools are not black boxes. They are immensely complex machines with performance that varies over time as consumables are used up, process kits wear out, and process by-products accumulate on chamber walls. Tool-centric applications might monitor such parameters over time, independent of a specific wafer or lot. For example, a tool monitor might report that a gas flow valve was staying open for longer periods, or that the flow through the valve had increased.
By combining the tool-centric and wafer-centric views, a process engineer might conclude that the layer thickness was increasing because the tool's mass flow controller was responding more slowly than normal. He could either take corrective action immediately, or adjust the length of a subsequent etch step to compensate. With more advanced software, the deposition system might actually warn the etcher of the increased thickness, allowing the etcher to compensate without human intervention.
This kind of integration is both the promise and the challenge of tool connectivity. Suppliers of connectivity software promise a world of seamless information flow between tools and within the organization as a whole. Tools will notify service engineers as problems arise, and the engineers will be able to make everything right from the comfort of their own offices.
It's a bright future, but how do we get there? The difference between the wafer-centric and tool-centric views is important because it causes profound differences in how the data is handled and stored.
The most commonly used data exchange format, the SECS/GEM interface, evolved to support the wafer-centric view. SECS supports a single connection between the tool and the fab's manufacturing execution system (MES). GEM defines the messages that can pass over that connection.
Tool-centric applications require different kinds of information, Brooks Automation's John Biasi explained. Some data, like tool logfiles, was never intended to go through a SECS/GEM-compliant port. Some applications introduce new messages that a SECS/GEM-oriented station controller can't understand. Others issue a steady stream of data requests that can interfere with the tool's processing operations.
There are several different ways to support tool-centric applications in this wafer-centric context. One approach focuses on extending SECS/GEM to accommodate new types of data. GW Associates, acquired by Asyst Technologies in May, falls firmly in this camp. Company president Jack Ghiselli wrote in Semiconductor Online, "All the 300 mm fabs have announced their intention to remain with SECS/GEM….Most of the past SECS/GEM effort need not be discarded, but becomes a foundation for the additional 300 mm features." The company supplies both interface software and integration services.
Startup Excelerate Technologies is also committed to the SECS/GEM interface. Baljit Singh, president and chief technical officer, notes that not every tool supports all GEM capabilities. He claims that existing data models can support most e-diagnostics requirements, citing video as one of the few data streams that would need to be outside the SECS/GEM interface. Excelerate's GEMCom protocol stack passes data between the equipment software and the host computer.
Another approach, embraced to one degree or another by Cimetrix, PRI Automation, Symphony Systems, and domainLogix, supports other data protocols in conjunction with SECS/GEM. This approach inserts a layer of interface software between the tool's internal messages and outside applications.
Keith Bennett, of Symphony Systems, uses the analogy of an office print server. The server makes sure that jobs from multiple users don't collide, keeps track of which paper size is in which paper tray, and so forth. User applications don't need to know such low level details as exactly which binary string corresponds to each printer function. When the office adds a new printer, only the server software needs to be modified. The server software can reside in the printer itself, in the user's desktop computer, or in between, in a specialized hardware module.
Similarly, an equipment server provides an interface between individual devices and applications. A mass flow controller (MFC) will have very different capabilities from a wafer transfer robot. An MES system and a fault detection package will interact with these devices in different ways. For example, the fault detection package might track the MFC very closely, while ignoring the transfer robot. The MES might keep track of each individual wafer move, while leaving interaction with the MFC to the local tool control software. The MES might expect SECS/GEM-compliant messages, while the fault detection package might expect tool log information.
The equipment server should be able to recognize messages from both the MFC and the wafer transfer robot, and should be able to format those messages appropriately for both the MES and the fault detection software.
Companies using the equipment server model implement it in several different ways. For instance, Cimetrix software interface tools translate machine-level data into SECS messages, while the architecture allows customers to add modules for new data formats as needed.
One format, Extensible Markup Language (XML), is designed to simplify data exchange, particularly over the Internet. A diagnostic application might use XML to display tool log files in a remote engineer's web browser. At the same time, Cimetrix views XML as an extension to SECS/GEM, not a replacement for it. Applications which can use SECS/GEM messages shouldn't be forced into an XML framework.
Similarly, PRI Automation's Tom Baum notes that each supplier will always interpret and implement standard messages and protocols differently. The connectivity architecture should be able to support a variety of messaging technologies and data exchange formats. PRI's FABuilder tool lets users build or buy ActiveX plug-in interfaces for new devices and new data protocols. The company supplies interface libraries for many common devices and protocols. Customers-both equipment OEMs and fabs-- can mix-and-match components depending on their needs.
Symphony Systems' core product, an equipment server, passes SECS/GEM messages through untouched for MES systems and cell controllers. For other applications, the server decodes and translates SECS/GEM messages into a set of network-accessible objects. Applications don't need to know the details of the original message.
Among the tool connectivity suppliers, domainLogix has been perhaps the most strongly critical of the SECS/GEM approach. The company prefers an object-based equipment model (OBEM) which, it claims, will eliminate expensive station controllers. According to the company, its software allows tool suppliers to decide which equipment resources are available on the fab network.
These competing approaches all claim to meet SEMI standards for tool connectivity. Keith Peden, of test suite vendor CCS Technology, differs with that assessment. He describes most connectivity vendors as in the middle to low end of the compliance spectrum. As the standards themselves become more stable, he expects suppliers to make rapid progress.
Moreover, the data exchange pipe is only part of the problem. Brooks Automation's Biasi points out that the true value of tool connectivity lies in the applications that use the data. Those applications, still in their infancy, motivate IC manufacturers and their suppliers to overcome the significant hurdles that still remain.
| This site is Copyright ©2001 by Thin Film Manufacturing. All Rights Reserved |