semi合集-English.pdf - 第3622页
SEMI E139-0705 © SEMI 2005 46 R2-5.1.1 Here are som e examples of potential uses of supplierInfo : formatVersion — Supplier a ssigned st ring that documents the v ersion of t he format or language used to create this P…
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.
SEMI E139-0705 © SEMI 2005 47
o The settings for all Module Parameters of this process module.
R2-8 Recipe Security
R2-8.1 The use of the universally unique identifier and checksum provide significant protection against
misprocessing due to the use of the wrong recipe. However it is not completely secure from intentional tampering.
R2-8.2 It is possible for someone to modify an existing PDE without changing the uid. To complete the deception,
a new checksum would need to be calculated and included in the PDE. A PDE changed in this way might not be
detected in some factory systems.
R2-8.3 There is a way to address this problem and ensure that only the correct recipes are used. This assumes that
there is a factory level recipe management system where the known-good PDEs are all logged and their
authorization for use is recorded. This system should log the uid of each PDE, along with its checksum.
R2-8.4 Recall that the equipment will check each PDE against its internal checksum value when the PDE is
transferred to the equipment and most will check it again before execution. This ensures that each PDE is self-
consistent.
R2-8.5 Whenever a recipe is to be used for processing, the FICS can perform a getPDEdirectory() service to list the
PDEs to be used and their checksums. It can then compare the stored (known-good) checksum for that PDE with
the current checksum value. In this way, the FICS can detect any changes and ensure that the correct PDEs are
being used.
R2-9 PDEeditor/Equipment Synchronization
R2-9.1 RaP defines services in support of an off-tool recipe editor. When the editor is a separate entity, there arises
a potential problem of synchronization. Any modifications to the equipment software may require a corresponding
change to the PDEeditor. If these updates are not done in a coordinated way, then significant problem could
develop. RaP does not offer a solution to this problem. It provides only this warning of the potential problem. It is
the responsibility of the users to put a process in place to ensure that their suppliers maintain synchronization of the
equipment and editor software.
R2-10 Human Involvement In Recipe Selection
R2-10.1 RaP is designed to work well in an automated factory system. In some situations, however, humans must
be involved in the process. Unfortunately, the UUID format is not user-friendly.
R2-10.1.1 When a system must rely on a human to select a recipe, there must be enough human-recognizable
information to ensure the correct choice is made. This is a recommendation of how to support such a human
selection of PDEs.
uid/gid — It is not recommended that the uid and gid be displayed to the user. They are long strings with no
human-parsable information.
name — Name should be the most useful information to the user. However, it depends on the users defining a
meaningful naming convention for PDEs. This is an important consideration.
groupName — This can give the user a good idea of the intended use of this PDE. Again, it depends on a
meaningful naming convention from the users.
type — This allows the user to distinguish, for example, between a sequence recipe and a module recipe or
between etch and clean recipes. The use of type may vary, but it will typically help make important
distinctions.
createDate — Allows a user to get a sense of the chronology.
description — If the users enter appropriate information, this can be very helpful. However, it can also be very
long. This is good for an extended display about a PDE.
author — Who created a PDE is a very strong clue about what it is to be used for.
userInfo — More good information for an extended display.