semi合集-English.pdf - 第1849页

SEMI E42-0704 © SEMI 1995, 2004 118 programs for vision system s) , but this restriction may be removed when the tec hnology a dvances. Editing on the equipment may st ill be desirable, particularly in a Development Fab.…

SEMI E42-0704 © SEMI 1995, 2004 117

R1-3 Background

The material in this section provides a context for the

Recipe Management Standard and is intended for

background information only.

In a complex environment, equipment and host become

relative terms indicating roles of two independent

agents with respect to each other. In general, both

equipment and host may provide services to one

another, and some services may be provided by both. In

certain cases, one may provide services to its partner

that the other does not. With respect to recipes,

equipment refers to the recipe’s executor, whereas host

represents a supervisory agent who may delegate

recipes which will be executed by the equipment.

For clusters, cells, and local-area stations, where a mid-

level controller communicates both to lower-level

components and to a higher level factory system, that

controller may alternately take the role of host to its

components and of equipment to the factory system.

Where role is significant, the terms equipment and host

are used in this section to indicate the relationship of

the two agents to one another.

R1-3.1 Traceability — A main management objective

in both a Development Fab and a Production Fab is

traceability of manufacturing conditions to the final

device characteristics. This traceability is required in a

Development Fab to support the analysis and

characterization of the process under development.

Certain customers of a Production Fab require this

traceability in order to do business. Even without such a

customer requirement, traceability is important for

process control and postmortem analysis of unexpected

device characteristics.

The recipe is the primary specification of

manufacturing conditions to the equipment; therefore,

the management of recipes is critical to this traceability.

R1-3.2 Recipe Life Cycle — The lifetime of a recipe in

a Fab typically has several phases, as illustrated in

Figure R1-1. While being developed, it may contain

errors, or it may not produce the desired results. The

recipe may be edited several times during its initial

development. At some point, the recipe enters the test

phase, where it will be executed and its results

evaluated. A check for syntax correctness occurs at or

before the time the equipment prepares it for execution.

Still further changes may be made to fine-tune the

process to achieve a particular result. During this

process, it is still desirable to be able to protect it from

inadvertent change or deletion. Finally, the recipe is

ready for production and goes through a series of

signoffs which constitutes a formal authorization

procedure. In many factories, only recipes which have

been approved as production-worthy may be used in

production runs.

Figure R1-1

Typical Recipe Life Cycle

Also, because results may vary between different

installations of equipment, an additional level of

authorization may be required that certifies individual

equipment for a given approved recipe.

A factory change control system must accommodate

different levels of protection for recipes in different

phases of their life cycle. To accomplish this,

equipment must recognize and support the different

requirements for each phase.

R1-3.3 Recipe Editing — Traditionally, recipes are

developed on the equipment that runs them. Besides

requiring time on the target machine (a potentially

scarce and expensive resource), this requires the person

defining the recipe to be inside a clean area. A potential

solution is for equipment manufacturers to provide

versions of their dedicated recipe editors that can be

integrated into the factory manufacturing systems.

Aside from the difficulty of the equipment

manufacturer supporting the variety of platforms

currently in use internationally, even in a distributed

factory environment, a proliferation of different

dedicated recipe editors required for the different types

of equipment is not considered a good solution.

A better solution is to permit editing external to the

cleanroom and then to transmit the completed recipe to

the equipment for verification. This can be achieved by

providing a text

form of the equipment manufacturer’s

recipe language which can be created and modified

with any standard text editor. This may not be possible

with some types of recipes (e.g., pattern recognition

SEMI E42-0704 © SEMI 1995, 2004 118

programs for vision systems), but this restriction may

be removed when the technology advances.

Editing on the equipment may still be desirable,

particularly in a Development Fab. When the equipment

permits a recipe to be changed, the equipment must

provide reporting mechanisms that inform the host of

changes and allow the host’s change control system to

operate.

R1-3.4 Recipe Sharing — A Fab may have several

installation of the same type of equipment (equipment

with the same functionality and the same recipe

language). Therefore, where possible, the same recipe

should be able to be shared between different

equipment of this same type.

R1-3.5 Protection and Process Control — The primary

goal of process control is to ensure that the final result

of the manufacturing process does not change over

time. This may be accomplished by both feedback and

feedforward methods. These methods modify the

settings used in the process. This requires two

capabilities that seem to be in conflict:

• The definition of the process settings (the recipe)

should not change.

• The process settings should change to counter the

drift inherent in real processes.

The first capability is particularly important in a

Production Fab. Most Fab policies prohibit processes

from changing after they have been approved for

production. This is easy to build into a change control

system on the host. However, if the equipment allows

local editing, then it must also enforce this policy.

Wholesale changes in a recipe are never necessary for

the second purpose. Usually only a few parameter

values are modified in small increments to effect

control of the process. A well-defined process specifies

the parameters that vary and their range of variation.

For any given recipe, it must be possible for the host to

specify different values of such parameters for each

piece of equipment so that the recipe may be “tuned”

for that equipment to produce uniform results. In

addition, the process control agent, on the equipment or

the host, may need the ability to calculate the parameter

value changes for each run and to inform the equipment

of the new values. Mechanisms are provided to support

such interactions.

R1-3.6 Recipe Selection — Typical operation of

equipment requires an operator or the host to initially

select the recipe to be run. Recipe selection may be

specified implicitly within the definition of a higher

order “process job”. In either case, the specification of a

recipe is accomplished by referring to its recipe

identifier (i.e., the identifier used by the change control

system) and, where needed to resolve ambiguity, its

location. Once selected, a recipe is initiated by an

appropriate start command, which may be explicitly

given by the operator or host or implicitly given by the

equipment when executing a higher order process job.

Repeated runs of the same recipe may be accomplished

via subsequent start commands without the necessity of

formal recipe re-selection.

R1-4 Example of a Factory Implementation of Approval Levels

A factory might implement different levels of approval by regulating the following levels of recipe approval on the

equipment:

Approval Level

FACTORY POLICY

Level 0 “Unapproved”

Level 1 “In Test”

Level 2 “Non-Production”

Level 3 “Ready for Release”

Level 4 “Released for Production”

with

RecipeReadOnlyLevel = 2 Level 2 = read-only

R1-5 Examples of Variable Parameters

The recipe body may have statements that allow parameters to be changed within fixed limits. For example, recipe

BAKE;2.3 may contain statements such as:

Parameter BakeTime of TIME default = 200 seconds

minimum = 100 seconds

maximum = 300 seconds;

TIME BakeTime • (200,100,300,”s”) /* default,min,max,units */

that define the process parameter “BakeTime”, its initial value and restrictions. The BAKE;2.3 recipe may use the

BakeTime parameter in further internal statements to determine the length of time a wafer is processed, such as:

wait for TIME BakeTime;

This parameter may then be set by a parent recipe as in Example (1) below or from the EqpSpec_PARAM attribute

(see 5.3.1.4) or with a “Select Recipe” command from the host or operator.

For example, a recipe “BAKE;2.3” may define a variable “BakeTime”, while a recipe “RAMP;1,0” may define a

variable “RampSetPoint”. A parent recipe “XYZ” might contain external references in the text of the source form

such as:

(1) RUN RAMP;1 // use default for RampSetPoint

RUN BAKE;2.3 with BakeTime=10 // bake for 10 seconds

(2) set RampSetPoint to 500; /* ramp up to 500 degC */

do RAMP(RampSetPoint);

set Baketime to 120; /* 120 sec (2 min.) bake */

do BAKE;2.3(BakeTime);

(3) RAMP(RampSetPoint:=500)

BAKE;2.3(BakeTime:=Time_A) /* 1st bake time may vary */

RAMP(RampSetPoint:=650)

BAKE;2.3(BakeTime:=Time_B) /* 2nd bake time may vary*/

RAMP(RampSetPoint:=800)

BAKE;2.3(BakeTime:=Time_B+50) /* 2nd bake plus 50 sec */

where “Time_A” and “Time_B” were both formally defined within XYZ.

In example (1), no initial value is specified for RampSetPoint. In this case, when the main recipe is selected, the

initial value specified either in EqpSpec_LinkParam

or in Gen_LinkParam (that is the same as the definition in

RAMP;2.3) is used. However, in this example, the parameter BakeTime is assigned a value by the parent recipe,

and this supersedes any value from a recipe attribute or a “Select Recipe” command from the host or operator. In

the example given, BakeTime is assigned a value outside of the declared domain. This should create an error when

the recipe is verified.

Examples (2) and (3) illustrate how subrecipes RAMP and BAKE may be referenced multiple times by a parent

recipe, and the parent may provide different values with each reference (Example 2) or may define new parameters

to use with different references (Example 3).

In the above examples, PARAMETERS (set when each individual recipe is verified) and Gen_LinkParam (set when

XYZ is linked) will contain parameter definitions as follows:

Recipe

PARAMETERS n_LinkParam

XYZ;0.8 Time_A Time_A

Time_B Time_B

RampSetPoint

BakeTime

RAMP;1.0 RampSetPoint undefined for unlinked recipe