semi合集-English.pdf - 第3621页
SEMI E139-0705 © SEMI 2005 45 RaP PDEparameter class includes a name attribute. This name value can be s upplied in the Steam 16 messages as the value of an RCPPARNM param eter. R2-3.4 Support for SEMI E30 works diffe re…
SEMI E139-0705 © SEMI 2005 44
RELATED INFORMATION 2
NOTICE: This related information is not an official part of SEMI E139 and was derived from the North American
Information and Control Committee. This related information was approved for publication by full letter ballot on
December 10, 2004.
R2-1 Implementation Suggestions
R2-1.1 This related information is included to supplement the specification with some suggestions about the use of
RaP and its capabilities. Its purpose is a) to promote more uniform application of RaP and b) to share some insights
of the creators of RaP that may lead to improved results from its use.
R2-2 Combining RaPnodes
R2-2.1 ¶8.5.2.3 mentions the possibility of combining RaPnodes. This section will briefly discuss this topic to
outline when and why this might be appropriate.
R2-2.1.1 In general, when multiple nodes are combined, efficiency can be gained by:
Coding the individual services only once (since most are common to all RaPnodes)
6
.
Sharing the computing platform where the software is run.
Eliminating the communication between the two separate RaPnodes by designing them to be a single entity.
R2-2.1.1.1 Not all RapNode combinations are practical. In particular, the combination of EquipmentNode with
FICSnode is not commercially feasible due to the many different suppliers’ equipment that must communicate with
one FICS. The other two combinations may be useful in the some situations.
R2-2.1.1.2 Combining the EquipmentNode and the EditorNode mirrors the traditional equipment “on-tool” editing
capability. This approach might provide the easiest transition to RaP for some equipment suppliers. It also ensures
that the equipment will function “out of the box” without integration. Since multiple PDEeditors are allowed, the
“off-tool” version could be provided later or as an add-on.
R2-2.1.1.3 The combination of FICSnode with EditorNode might represent the integration of an off-tool editor with
an off-tool recipe management capability. In the long term, there might be a movement to general PDEeditors that
are compatible with many suppliers’ equipment recipes. Integrating a recipe management capability with that
general editor would be a logical next step.
R2-2.1.1.4 If the implementation for messaging is SECS-II only, then any equipment with an on-tool editor must
combine the EquipmentNode and EditorNode. This is necessary since multiple SECS-II sessions are not well
supported.
R2-2.1.1.5 When two RaPnodes are combined, they are expected to act as a single entity with a union of the
capabilities of the two types of RaPnodes. The combined RaPnodes are expected to share resources, including the
recipe storage area. Messages to the combined RaPnodes will not differentiate which node type is being addressed.
R2-3 RaP Support For SEMI E40 and SEMI E30
R2-3.1 RaP can be used in conjunction with SEMI E40 Process Job Management or with SEMI E30 GEM. This
section discusses how to map the key recipe-related parameters from those two standards to the RaP attributes. In
both cases, the management of the recipes uses RaP services. This section discusses how the recipe is specified for
the processing activity and how the Variable Parameters are communicated.
R2-3.2 In SEMI E40, recipe information is specified as part of the job specification in the Stream 16 messages as
RCPSPEC (recipe identifier - text) and RCPPARNM (recipe variable name - text). To satisfy RCPSPEC, a RaP
implementation should supply the identifier (uid or gid) of the Master PDE.
R2-3.3 The Variable Parameters defined in RaP were intended to correspond directly with the RecipeVariables
7
defined in SEMI E40. The PDEparameters of the Master PDE should be mapped directly to RecipeVariables. The
6 Note that even if the RaPnodes are not combined, a single body of code could be created, with internal switches to enable the proper services
for the particular type of RapNode.
SEMI E139-0705 © SEMI 2005 45
RaP PDEparameter class includes a name attribute. This name value can be supplied in the Steam 16 messages as
the value of an RCPPARNM parameter.
R2-3.4 Support for SEMI E30 works differently. In this case, there is no concept of a process job. Instead, it is a
two step process: 1) the recipe is “selected” for execution, and then 2) a START command is given to begin
execution. Both of these requests are made using the S2,F49 message (Enhanced Remote Command – see SEMI
E5). The Remote Command message accepts parameter values (called CEPVAL’s). Each CEPVAL has a
corresponding identifier called CPNAME.
R2-3.5 In the first step, the RCMD (remote command) is RCP-SELECT. The identifier of the recipe is contained
in a CEPVAL. The uid (or gid) of the Master PDE is supplied as the CEPVAL to identify the recipe. The supplier
determines the CPNAME of this parameter.
R2-3.6 In the second step, the S2,F49 message requests the START remote command. In this message, the
CEPVAL’s contain parameters that apply to the activity. The equipment may have some pre-defined parameters.
The PDEparameter values may also be specified here as CEPVAL’s. The name of the PDEparameter should be
specified as the CPNAME.
R2-4 Factory Assigned Recipe Attributes
R2-4.1 Some factory systems track various attributes of specifications within their factory. Recipes are one type of
specification and often have important attributes associated with them. For example, a recipe may need to undergo
certain tests before it is qualified to use in production. Also, there may be some sort of management sign-off
process. These and other such attributes are used by the factory to help determine what recipe can be run in a given
situation.
R2-4.2 The definition of recipe management practices of the factory is beyond the scope of RaP. However, a place
has been provided within the PDEheader for the factory to store (and later retrieve) such information. The userInfo
attribute provides a list of text strings that the factory can use for this purpose.
R2-4.3 Any attribute that can be represented as a text string can be included. Using common text formatting
approaches (for example, comma separated values), both simple and complex attributes can be stored. For example,
one userInfo field might contain a name/value pair something like this: “Approved, True”.
R2-4.4 It is expected that the userInfo will not be used for very large data structures, such as photographic images.
An attempt to include data much larger than the original PDE might cause unexpected results.
R2-4.5 Since the equipment will not try to interpret these values and undocumented changes to the recipe are not
possible, this provides a secure place to store these values.
R2-4.5.1 Some examples of userInfo strings include:
Comment — The user can enter a detailed explanation of the need for this PDE, the conditions that led to its
creation, etc. This can help when transfer of duties to a new engineer occurs.
Approval Level — is the recipe approved for use?; what use is it approved for?
Version — what version number will the host assign to this PDE for tracking purposes?
Classification — there are many ways to classify recipe components – the factory area of use, which step in the
process, which process (or process version), etc.
R2-5 Supplier Assigned Recipe Attributes
R2-5.1 The equipment supplier may need to provide information about each PDE that is not standardized. The
supplierInfo attribute is provided to allow the supplier to include this information. The format is the same as for
userInfo – a list of text strings.
7 SEMI E40 also uses the term “Recipe Variable Parameters” to refer to RecipeVariables.
SEMI E139-0705 © SEMI 2005 46
R2-5.1.1 Here are some examples of potential uses of supplierInfo:
formatVersion — Supplier assigned string that documents the version of the format or language used to create
this PDE. This can help the user determine whether the PDE is compatible with a particular equipment.
version — Version of the PDE. This represents the supplier-assigned version value. If equipment-based recipe
management is used, a versioning scheme may be helpful. The equipment supplier should document its
versioning strategy.
R2-6 Parameterization Notes
R2-6.1 Parameterization of equipment recipes begins with the setting of Module Parameters according to Variable
Parameters entered at run time. There are other uses of parameterization that may be very beneficial.
Parameterization can also help with complex control situations. This section discusses such opportunities.
R2-6.1.1 Selection of ExecutionTarget — The recipe documents which ExecutionTargets are allowed to execute
each PDE. At execution time, it is possible that more than one specified ExecutionTarget will be available (for
example, identical processing modules in a cluster tool). The selection is made by the equipment, in accordance
with any instructions in the recipe. However, there may be times when one of the processing modules is not
operating within specifications for certain products. In such a situation, how can the factory force the equipment to
exclusively choose the other process module? One answer would be to provide an input parameter to the recipe for
selection of process module for this PDE. The default might be “use both” with the opportunity to select one or the
other exclusively.
R2-6.1.2 Process Control For Multiple ExecutionTargets — There are situations where multiple, equivalent
processing modules are available on the equipment and are all identified as ExecutionTargets. If wafers are sent to
the next available process chamber, it would not be possible to predict which process module a given wafer might
use. When process control is being applied to this equipment, this can cause complication. Each of the process
modules can have very different control responses. So each would have different control settings for a specific
material/job situation. To serve the user’s needs in this case, it should be possible to define one set of
PDEparameters for each possible ExecutionTarget. These parallel parameter sets would all need to be set. The
PDE would select the proper parameter set based on the choice of process module for a given wafer.
R2-6.2 The reverse issue may also exist in this situation of multiple equivalent ExecutionTargets. Some
ModuleParameters should take on the same value, no matter which ExecutionTarget is chosen. The implementation
should allow for the specification of a single PDEparameter whose value will be applied correctly for any of the
specified ExecutionTargets.
R2-6.2.1 So, the user should have the option to specify different values per ExecutionTarget or a single value to be
used for all.
R2-7 Traceability
R2-7.1 Proper traceability of processing should include recording enough information to determine exactly what
was done in any instance of processing. An important part of this information set is a record of the instructions
provided to the equipment. This includes the specific PDEs used and the external setting values provided to satisfy
the Variable Parameters.
R2-7.1.1 It is recommended that the equipment supplier create data collection parameters that allow the user to
collect the following:
The identifier of the Master PDE specified for the process job,
The PDEmap provided to resolve the recipe structure,
A list of all the PDEs actually used during processing,
All Variable Parameter values supplied for the process job, and
The PDE(s) used for each instance of processing (for example, when a wafer is processed in a process module.
o Also include the PDEparameter settings that affected that instance of processing.