semi合集-English.pdf - 第1640页
SEMI E38-1296 © SEMI 1995 , 1996 29 A P PENDIX 1 AP P L I C AT I O N N OT E S NOT E: This a ppendix w as approve d as a part of SEMI E38 by full le tter ballot proc edure. A1-1 Factory Integration The Cl ust er Tool Modu…
SEMI E38-1296 © SEMI 1995, 1996 28
achieve the mission of the cluster tool, the
processing of material.
• Recipe management for storage, archival, and
editing of process module recipes (supported
through the Recipe Management services).
• Human interfaces for the attached process,
transport, and cassette modules (supported through
the Event Reporting and Object Service
definitions).
• Exception resolution services for making recovery
decisions on exception conditions within the
cluster (supported through the Exception
Management services).
SEMI E38-1296 © SEMI 1995, 199629
APPENDIX 1
APPLICATION NOTES
NOTE: This appendix was approved as a part of SEMI E38 by full letter ballot procedure.
A1-1 Factory Integration
The Cluster Tool Module Communications (CTMC)
Standard and its associated services define the
interactions of the cluster modules and the cluster
controller. The standard does not address the
communications between the cluster and an external
factory “host.” The SEMI standard which addresses the
equipment to host communications interface is SEMI
E30 (GEM).
The purpose of this application note is to discuss the
requirements and possible pitfalls of the factory host-
cluster tool interface. The bulk of the text will address
the use of the current (at this writing) version of GEM
(SEMI E30). However, some consideration will be
given to the possibility of direct access to the
components of the cluster through the cluster
communications environment.
A1-1.1 Direct Access to Cluster Modules — The
CTMC was designed to allow for interoperability
among the entities in a cluster. It is possible to add a
new entity to the cluster and share in this
interoperability. This means that a software application
that is “plugged” into the cluster communication
environment will have access to all of the cluster
modules via the standard message set. In this way, a
factory host computer can gain direct access to cluster
modules, by-passing the cluster controller.
While direct access to the cluster modules has some
advantages, intrusions into the cluster tool
communications environment can have a profound
effect on the system. Below are listed a few of the
positive benefits direct access can bring, followed by
some of the negatives of such an approach.
Positives:
• If the cluster controller does not have to act as the
intermediary in transactions between module and
host, it may be simplified.
• Direct access of the modules can be a more
efficient means of obtaining information.
• The factory host would have the flexibility to
perform scenarios which the cluster controller
suppliers had not imagined.
Negatives:
• A new, unplanned load on the cluster network may
have a negative impact on system performance. If
the delivered system’s network is highly loaded
and has been tuned for that load, added pressure on
the system may have unexpected results.
• Direct access of the cluster modules may have a
negative impact on system performance. The
cluster modules are performing the physical work
for the cluster. If they become busy answering
inquiries, it may detract from their speed of
processing. For example, a simple query, such as
temperature of chamber, may actually result in
messaging to the sensor itself along the same real-
time communication path used to open and close
valves, ect.
• System integrity of the cluster tool may be at risk if
an external entity (e.g., Factory Host) takes even
minor control actions. A changed equipment
constant may put the cluster controller out of synch
with its module. An external command to perform
an action may directly conflict with the cluster’s
current actions.
• The CTMC defines no access security to prevent
undesirable actions on the part of external entities.
If there is to be this sort of direct communication with
cluster modules, the implementer should exercise
extreme caution in the design of the add-on application.
It is recommended that no active control be attempted
and that no changes to the system configuration be
attempted (e.g., do not set attributes). If data is to be
accessed, it is best done by asynchronous event based
reporting, rather than by polling. Above all, it is
recommended that any plans to access the cluster
through the cluster communication environment be
discussed thoroughly with the system supplier.
A1-1.2 GEM Control of a Cluster Tool — This section
discusses the interactions between a cluster tool and
factory host. The basis for that communication is
assumed to be SEMI E30, the Generic Equipment
Model.
GEM was designed relative to the prevalent class of
equipment at that time: proprietary, single supplier, and
limited to a single process run at a time. The advent of
multi-chamber processing equipment and later of multi-
supplier cluster tools has changed the general
requirements set for the factory-equipment interface. In
the future, GEM may evolve to meet these new
requirements. Regardless, the point of this application
note is to explore how best to apply the existing factory
SEMI E38-1296 © SEMI 1995, 1996 30
host communication standards to cluster-based
equipment.
Below, each GEM capability will be addressed
separately, followed by a look at capabilities which
GEM does not cover. The capabilities are taken in
roughly the order given by SEMI E30 (GEM) table of
contents.
Communications State Model/Establish
Communications — The Communications State Model
is related to the ability to communicate. It is
independent of the functionality offered by the
equipment. There is no conflict with the cluster tool
supporting this GEM capability.
Control State Model — The control state model
assumes a single operator interface at the equipment. A
cluster tool is expected to supply such an interface
connected to the cluster controller.
However, there is a potential disconnect with attached
modules which supply user interfaces. Since CTMC
does not provide anything similar to the control state
model at this time, the cluster controller has no control
over access to these separate user interfaces, nor even
any knowledge of what might be happening. In this
situation, the cluster controller cannot guarantee
compliance to the control state model.
To assure GEM compliance, it is recommended that a
module request and receive closure of all control-
related service connections before allowing use of its
local operator interface in a control mode. This assumes
the use of the communication environment as defined in
SEMI E38.1.
Equipment Processing States — GEM specifies that
there be a processing state model. The model given in
the document is only an example, which shows the
approximate depth needed and suggests a form. The
example applies to the classic single chamber, single-
process machine. Thus, it may not be directly
applicable to a cluster tool. The cluster tool is required
to provide a processing state model, but the form should
match the cluster tool's function. The Plasma Etch
Specific Equipment Model (document available from
SEMI) suggested one way to model a multi-chamber,
multi-process job machine.
Data Collection — Data collection is a combination of
several different capabilities. Each will be discussed in
turn.
There is also a high-level issue with data collection.
GEM assumes a flat address space. That is, it assumes
that the smallest granularity of object is “equipment.”
The equipment has attributes. Some attributes are read-
only (Status Variables). Some have read/write access
(Equipment Constants). There are a few read-only
attributes which are valid only at certain times
(DVVALs).
Cluster tools do not fit this model well. The CTMC was
based on a model which includes a hierarchy of objects
which contain (or control) other objects. The CTMC
requirements are a subset of that model and include a
cluster controller (which does not have to be a single
entity), attached modules, transport module, and
specific objects associated with the services. Thus, to
request information about the processing of a wafer in a
process module, the attributes of the process job must
be accessed. The chain then includes Cluster
Controller->Process Module->Process Job->Job
Attribute. It is quite a challenge to present this attribute
as SVID #532678. And yet, this is what must be done.
The cluster controller should provide a flat name space
from which to access critical module data. Object
services with scopeing capabilities may also be
supported through the host interface, but if used, this
would be an extension to the host's GEM interface. The
data collection categories below give more detail on the
challenge and possible solutions.
Event Notification — Many of the events of interest to
the host actually occur at the attached modules (e.g.,
“Etch step complete for wafer x”). The cluster
controller is responsible for assigning each of these
events a unique CEID. There are two challenges: (1) to
assure uniqueness of events from duplicate modules,
and (2) to provide a scheme whereby the host can
determine the source of the event. Embedding a module
number within the CEID is one solution which has been
used to address both challenges. For instance, the
highest order byte of a four-byte integer might contain
the module ID.
Dynamic Event Report Configuration — The host must
be able to attach the information of interest to the event
notifications. The cluster controller is responsible for
providing access to the attributes of the cluster
modules. It is also responsible for assuring that the data
contained in the event reports is representative of the
state of the cluster at the time the event occurred.
There are three sources of data for the event reports.
1. Cluster Controller: Data which is local to the
cluster controller may be accessed directly.
2. Module (not source of collection event): This data
must be polled unless a data trace for the attributes
of interest is in progress.
3. Module (source of collection event): This data
tends to be most closely related to the event and
thus the most time-critical. While polling and data
trace may be used in this case, it is better to use the