semi合集-English.pdf - 第3589页

SEMI E139-0705 © SEMI 2005 13 7.12.2.4.3 Any PDE reference that contains a gid can be satisfied with any memb er of that grou p. When a PDE is changed, it can keep the same gi d , even as the uid chang es. There fore, th…

SEMI E139-0705 © SEMI 2005 12

7.12.2 Recipe Structure

7.12.2.1 When a recipe has multiple components, RaP documents the relationships among these components (see

¶7.12.1.5). This results in a hierarchical recipe structure as illustrated in Figure 5.

7.12.2.2 The recipe hierarchy must have a single PDE at the apex. This PDE is called the “Master PDE”. It is this

PDE that will be referenced when a job is specified. So, for example, in SEMI E40/Processing Management, the

RecID (or RCPSPEC) will contain the uid of the Master PDE. See Related Information §R2-2 for more discussion

of RaP support for SEMI E40 and SEMI E30. As an alternative, a gid may be supplied and later resolved to a uid.

MasterPDE

Referenced

PDE’s

PDE

PDE PDE

PDE PDE PDE

PDE PDE

ProcessJob

{

PDE’s referenced

either

UID or GID

RCPSPEC/PPID = UID or GID

VariableParameters

o GIDUID Map

o PDEparam1

o PDEparam2

o etc…

MasterPDE

Referenced

PDE’s

PDE

PDE PDE

PDE PDE PDE

PDE PDE

ProcessJob

PDE

PDE PDE

PDE PDE PDE

PDE PDE

ProcessJob

{

PDE’s referenced

either

UID or GID

RCPSPEC/PPID = UID or GID

VariableParameters

o GIDUID Map

o PDEparam1

o PDEparam2

o etc…

Figure 5

Recipe Structure Illustration

7.12.2.3 The recipe structure implies that the Master PDE is the first PDE to be executed. Beyond the Master PDE,

the recipe structure does not document the order of execution of PDEs or the flow path of wafers through

equipment. It is recommended that the equipment supplier provide a PDE that contains this flow information in an

open format (human readable) PDEbody.

7.12.2.3.1 Here are a few other items of note:

 The Master PDE is a designation, not a type of PDE. A Master PDE must be marked as “executable” (see

Table 5).

 There is no restriction on multiple references to the same PDE.

 The number of levels in the recipe hierarchy is not limited. However, it is to be expected that two to three

levels would be sufficient in most cases. In the case where the Master PDE contains the entire recipe, only one

level is needed.

 A PDE may appear in the hierarchy of multiple recipes. Such reuse of recipe components is expected and

encouraged.

7.12.2.4 Recipe Maintenance Considerations

7.12.2.4.1 Group IDs (gids) exist to make it easier to maintain multi-part recipes. It is possible to create recipes

where all PDE references are done with uids. However, this can lead to problems when a change is made to one of

the components.

7.12.2.4.2 Remember that when any change is made to a PDE, it must become a new PDE with a new uid. In order

to begin using this “new version” of the old PDE, some (or all) PDEs that referenced the original PDE must now

reference the new one. When the referencing PDEs are changed to refer to the new version, each of them becomes a

new PDE. And these have the same problem with any PDEs that reference them. The problem cascades to every

level above the first PDE.

SEMI E139-0705 © SEMI 2005 13

7.12.2.4.3 Any PDE reference that contains a gid can be satisfied with any member of that group. When a PDE is

changed, it can keep the same gid, even as the uid changes. Therefore, the PDEs that reference the original PDE do

not need to change. This solves the problem of cascading references.

7.12.2.4.4 Use of gids as PDE references does add a burden, however. At some point, the gid must be resolved.

7.12.2.5 Resolving PDE References

7.12.2.5.1 ¶7.12.1.5.1 discussed the fact that PDE references can be either uids or gids. When gids are used as

references, they must be resolved to uids before the referenced PDE can be executed. Resolution must occur one

level at a time beginning with the Master PDE. Only when the specific PDE(s) referenced by the current level are

known can one know the references these PDEs make to the next lower level.

7.12.2.5.2 Resolution of a gid to a uid can be performed by either the equipment or the client of the equipment. If

configured to do so, the equipment will resolve any gids that the client does not. If the equipment is required to

resolve a gid, it will choose the member of that group currently at the equipment that has the newest createDate.

7.12.2.5.3 The client can specify gid resolutions for a specific processing job through a predefined Variable

Parameter as input to the job. In this “PDEmap” parameter, the client provides a list of gids with the corresponding

uid for each. The equipment will then preferentially use the entries in this list as it resolves the recipe. If during the

resolution process the equipment encounters any gids that are not on the PDEmap, then it will attempt to resolve the

gid as mentioned above. If the client does not supply a PDEmap, the equipment will resolve all

gids it encounters.

Allowing the equipment to select the final PDEs without supervision is not advised.

7.12.2.5.4 The client can interact with the equipment to determine the best PDEmap values. Using the

resolvePDE() service, the client can supply a PDE and receive the corresponding (fully resolved) “outputMap” from

the equipment. The outputMap contains a list of the gid – uid pairs that result from the resolution process – the

equivalent of a PDEmap. If desired, the client can supply an “inputMap” listing some gid – uid pairs and the

equipment will use these preferentially as it resolves the outputMap. See the scenarios defined in Related

Information 1 for examples of this interaction.

7.12.3 Parameterization

7.12.3.1 Parameterization of process jobs is an important concept for process control. There are other SEMI

standards that define how parameters can be passed to the equipment to affect processing (for example, see SEMI

E40 and SEMI E30). RaP supports the definition of those parameters. Figure 6 illustrates the flow of parameters in

a RaP recipe.

SEMI E139-0705 © SEMI 2005 14

Variable

Parameter

Variable

Parameter

PDE

Parameter

PDE

Parameter

Process

Module

PDE

“Master”

PDE

Coordinates

Targeted For

PDE

Parameter

Module

Parameter

Input For

PDE

Parameter

Variable

Parameter

Variable

Parameter

Process

Job

Executes

Input For

Variable

Parameter

Variable

Parameter

Variable

Parameter

PDE

Parameter

PDE

Parameter

Process

Module

PDE

“Master”

PDE

Coordinates

Targeted For

PDE

Parameter

Module

Parameter

Input For

PDE

Parameter

Variable

Parameter

Variable

Parameter

Process

Job

Executes

Input For

Variable

Parameter

Figure 6

Parameter Flow Illustration

7.12.3.2 RaP assumes that recipes are executed as part of a larger job specification. When the “Process Job” is to

be executed, settings can be passed to the job to complete its specification. In RaP, these settings are called Variable

Parameters. Figure 6 shows Variable Parameters passed to the Process Job.

7.12.3.3 The Process Job references the Master PDE as the process recipe. During execution of the Process Job,

the equipment passes Variable Parameter values to the Master PDE to satisfy its PDEparameters.

7.12.3.4 The Master PDE and each successive level of PDEs coordinate the activity of the PDEs at the next lower

level. Each PDE is responsible for passing values to its referenced PDEs to satisfy their PDEparameters.

7.12.3.5 Each PDE can also directly set “Module Parameters”, the settings that affect the Process Module (or other

equipment components). Each Process Module offers a fixed set of these input parameters that can be set from

within a recipe. Note that Module Parameters are not formally defined by RaP. They are used to represent internal

equipment settings that recipes need to manipulate.

7.12.3.6 For a particular PDE, an incoming PDEparameter value may affect an outgoing setting of another PDEs

PDEparameter or of a Module Parameter. This affect may be direct, where the incoming value is used as the

outgoing value, or it may be indirect, where some sort of transformation is done to the incoming setting to determine

the outgoing values. An example of an indirect affect is a time setting that is consumed within the PDE and is used

to determine when a particular Module Parameter is to be set.

7.12.3.7 Notice that a PDE can set Module Parameters to different values during processing according to need. For

example, a process chamber might have a “ChamberTemperatureSetpoint” Module Parameter. A PDE might

require that the value for this be 450°C for the first stage of the process and 500°C for the second stage. The PDE

could set these values directly at the proper time. However, an alternative would be to define two PDEparameters

for this purpose: FirstStageTemp and SecondStageTemp. Each would map to ChamberTemperatureSetpoint and

their default values could be set to the corresponding values. Then, when the appropriate first stage temperature is

determined to be 430°C, the change can be made through a parameter setting at runtime without changing the PDE.

In this way, multiple PDEparameters might map to the same Module Parameter.