semi合集-English.pdf - 第3623页

SEMI E139-0705 © SEMI 2005 47 o The settings for all Module Parame ters of t his process module. R2-8 Recipe Security R2-8.1 The use of the universally uni que identifier and checks um provide significa nt protection a g…

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.

 supplierInfo — Again, good information for an extended display.

R2-10.2 In general, a display of the name, groupName, type and createDate should be adequate to support a recipe

selection in most cases. An extended display should be available when more help is needed.

R2-11 Optimizing getPDEdirectory() Service

R2-11.1 A poor implementation of the getPDEdirectory() service may be inefficient. It is clear that some

getPDEdirectory() requests may require the RaPnode to return information from the header of all the recipes stored

at this node. Reading bits of information from hundreds of potentially large files can be time consuming. It is

suggested that steps be taken to optimize this implementation. For instance, if key parts of the header from each

PDE on the RaPnode are stored separately (for example, in a database), then retrieval of this information can be

very fast. However, this cataloging of all recipes requires careful management of the PDEs and some overhead to

maintain. The software designer should consider all these factors when implementing this service.

R2-12 PDEeditor Identification

R2-12.1 Not all PDEeditors are EditorNodes. There may be standalone editors that create PDEs that are moved to

the equipment (or to the Recipe Management System) by other means – email, floppy disk, or other transport

mediums. Some recipes may originate from the supplier. It is important that all PDEeditors embed meaningful

nodeID’s that identify the source clearly to the eventual user of the recipe. It is recommended that all nodeID’s

contain URN strings as defined in Internet standards.

NOTICE: SEMI makes no warranties or representations as to the suitability of the standards set forth herein for any

particular application. The determination of the suitability of the standard is solely the responsibility of the user.

Users are cautioned to refer to manufacturer's instructions, product labels, product data sheets, and other relevant

literature, respecting any materials or equipment mentioned herein. These standards are subject to change without

notice.

By publication of this standard, Semiconductor Equipment and Materials International (SEMI) takes no position

respecting the validity of any patent rights or copyrights asserted in connection with any items mentioned in this

standard. Users of this standard are expressly advised that determination of any such patent rights or copyrights, and

the risk of infringement of such rights are entirely their own responsibility.

International), 3081 Zanker Road, San Jose, CA 95134. Reproduction of

the contents in whole or in part is forbidden without express written

consent of SEMI.