semi合集-English.pdf - 第1801页

SEMI E42-0704 © SEMI 1995, 2004 70 management services, to change a recipe, or to change the namespace (for exam ple, to store a new recipe or delete an existing one), from an entity o ther than an attached DRNS segment …

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 69
The object specifier for an object owned by a DRNS
manager is formed by concatenating the object type and
identifier for either the manager or the namespace,
followed by the object type and identifier of each
owned object in the ownership hierarchy. An example
of the object specifier for a recipe XYZ;3 stored by
DRNS segment ABC_Etch_Seg within the distributed
recipe namespace WetEtch003 would be:
"RNSD:WetEtch003>RNSDSegment:ABC_Etch_
Seg>MRcp:XYZ;3"
If an agent or a DRNS segment is specified, then the
DRNS manager shall delegate the operation to the that
segment. Otherwise, the operation shall be delegated to
a master segment.
A request to set one or more read-write attributes of a
recipe is treated by the DRNS manager as a change
request.
10.3.2 Delete Distributed Recipe Namespace — A
distributed recipe namespace with attachments may not
be deleted.
The delete distributed recipe namespace operation is
invoked by the service RMNDeleteNS defined in
Section 9.2.2.
10.3.3 Attach and Detach Supervised Objects — This
section defines the support required for the authorized
user to request a DRNS manager to attach or detach one
or more segments or a recorder. The operations and
services are defined in detail in SEMI E39 (OSS).
10.3.3.1 Attach Supervised Object — The attach
supervised object operation is invoked by an
authorized user to request the DRNS manager to attach
a specified unattached segment or recorder.
When a request to attach a supervised object is
accepted, the DRNS manager sends an attach or detach
request to the specified object.
The DRNS manager shall have the capability of
managing at least one attached dedicated and one
attached master segment at a time. At most, one
recorder shall be attached to a DRNS manager at any
given time.
Once attached, the segment or recorder becomes a
formal part of the namespace and is owned by the
manager.
When adding attachments to a DRNS manager, the
recorder should be added first, so that it may be used to
record the segments as they are subsequently attached.
When the distributed recipe namespace manager
receives a request to attach a segment, it sends that
request to the specified segment. If the operation is
successful, and if a recorder is attached, the manager
requests the distributed recipe namespace recorder to
record the segment specifier (the object specifier for the
segment). If the agent providing the segment is not
already in the namespace attribute Members
, it is added
at this time.
The operation of attaching a recorder shall set the
distributed recipe namespace attribute Recorder
to the
value of the recorder's attribute ObjID
. The operation
of attaching a segment shall add the segment specifier
to the Segments
attribute of the distributed recipe
namespace.
When a recorder is attached, all subsequent operations
that attach and detach segments shall update the
recorder through its operations to add and remove a
record of the segment.
Specifiers used in the namespace attributes Recorder
and Segments
, and segment specifiers stored in the
DRNS recorder, shall use the form including the
specifier for the agent providing the capability for the
recorder or segment. This is required for identification
outside the scope of the current namespace. For
example, if it later becomes necessary to rebuild the
distributed recipe namespace, then the segment must be
located through its agent owner rather than through the
namespace.
10.3.3.2 Detach Supervised Object — An attached
segment or recorder may be detached at any time. The
manager forwards the request to the specified object.
When a segment is detached, if a recorder is attached,
then the manager requests the recorder to remove the
segment that is being detached.
The user may request a DRNS manager to detach an
attached recorder or segment at any time. When a
recorder is detached, the distributed recipe namespace
attribute Recorder
shall be set to a null value. When a
segment is detached, its specifier is removed from any
attached recorder and from the Segments
attribute of
the distributed recipe namespace.
10.3.4 Change Request Management — A change
request occurs whenever the DRNS manager receives
any request, from any source, to change a recipe or the
contents of the distributed recipe namespace as a
whole. This includes requests to change the recipe
identifier, a generic attribute, an agent-specific
attribute, or the body of an existing recipe. It also
includes all changes that affect the set of recipe
identifiers within the distributed recipe namespace.
Requests for changes may come from a source that is
either internal or external to the namespace.
10.3.4.1 External Change Requests — The DRNS
manager may receive a request, through recipe
SEMI E42-0704 © SEMI 1995, 2004 70
management services, to change a recipe, or to change
the namespace (for example, to store a new recipe or
delete an existing one), from an entity other than an
attached DRNS segment. If the change involves a
specified agent (for example, verify or upload requests),
then the DRNS manager shall delegate the operation to
the DRNS segment provided by that agent. Otherwise,
operations are preferably delegated to a DRNS master
segment.
10.3.4.2 Internal Change Requests — A change
request may be initiated by a specific attached segment.
For example, a local operator may want to change the
generic attribute EditedBy
(illustrated in Figure 10.3) or
to rename a recipe. The DRNS segment then requests its
DRNS manager for approval to make the specific type
of change desired. The DRNS manager, upon receipt of
the request, shall create a change request record
(Section 10.3.4.4) for the recipe(s), specifying the
DRNS segment that initiated the request, the type of
change requested, and noting that the change was
segment-initiated.
10.3.4.3 Allowable Change Requests — A change
request may not be allowable. For example, a change to
a write-protected recipe or a change to introduce a
recipe identifier already in use may be denied
immediately. If the change is allowed, then a change
request record shall be created in non-volatile memory
for each allowed change request.
Any operation that creates or changes a recipe body, a
recipe attribute, or a recipe identifier, requires explicit
manager approval. This includes the following
operations: create, delete, modify (body), copy (new
identifier), rename (new identifier), protect, verify, link,
unlink, certify, de-certify, change read-write generic
attribute, and change read-write agent-specific
attribute.
The following requirements shall apply:
— A request to create a new recipe, or copy an existing
recipe, with a specified identifier shall be granted
only if that identifier is not in use for a write-
protected recipe within the namespace as a whole
(that is, no attached DRNS segment has a write-
protected recipe using that identifier).
— A request from a DRNS segment to rename a recipe
shall be granted only if no other segment has that
recipe and the new identifier is not otherwise in use.
— A request from a dedicated segment to delete a
recipe shall be denied only if the recipe is write-
protected.
10.3.4.4 Change Request Record Definition — A
change request record, as shown in Figure 5.7,
consists of the following information:
— The recipe identifier (RecipeID
),
— a destination recipe identifier (DestRecipeID
) (used
for copy and rename only, and otherwise null),
— the segment specifier, (Segment
), of the DRNS
segment that has requested a change or to which the
change operation is or will be delegated,
— the specific type of change requested (ChangeType),
— a timestamp of when the request was received
(Timestamp
),
— an operation identifier (OperationID
), an integer
delegated by the DRNS manager that uniquely
identifies a given change request within the
distributed recipe namespace at large,
— a boolean (SegmentRequest
) used to differentiate
requests by attached segments from other requests
(the manager responds differently in the two cases).
All of the above information, with the exception of the
segment specifier, shall be determined at the time the
change request record is created. In the case of
externally initiated requests, delegation of a segment
specifier may be postponed until the change request is
selected.
The operation identifier is used to identify a specific
change request by both the namespace and the
delegated DRNS segment. It is passed to the DRNS
segment when granting permission to make the
requested change (Section 10.3.5) and when sending
segment change approval to a DRNS segment (Section
10.1.2.2) for a previous change request made while the
recipe was locked. It shall also be used for recipe
management services defined in Section 12 that use an
operation identifier (parameter RMOpID).
For change requests initiated by an attached segment,
the boolean SegmentRequest
is set to TRUE.
Otherwise, it is FALSE.
The change request record shall be deleted when the
requested change operation has been completed,
whether successfully or unsuccessfully.
SEMI E42-0704 © SEMI 1995, 2004 71
Figure 10.3
Change Request Record State Model
10.3.4.5 Change Request Lifecycle — This section
describes the states of a change request.
A change request is received and examined. It is
determined either to be allowed or not allowed.
If the requested change is allowed, then a change
request record is created for the specified recipe by
saving the information required. The change request is
now INACTIVE and ON HOLD (see Figure 10.1). The
operations identifier is set to a unique unsigned integer.
If the change was initiated externally, a segment may or
may not be designated until the change request is
selected for approval. The remaining information is
filled at this time. The change request record is placed
in a queue for that recipe in non-volatile memory.
The change request remains on hold until the DRNS
manager selects it as the next change and it becomes
selected. If a segment has not already been designated,
then one is determined at this time. The selected recipe
may be discarded after evaluation due to changes in
circumstances since it was originally put on hold.
Otherwise, the change request becomes active, and the
change request record is added to any attached DRNS
recorder. The manager is ready to begin its
negotiations with the designated segment or to approve
a segment-initiated change request already in progress,
at this point.
These stages may occur in rapid succession if the
request is initiated by a segment and the recipe was not
locked.
Selection occurs in one of two ways: either a change
request is received when the specified recipe is
unlocked (Section 10.3.4.5), or else a currently active
change request completes, and a new change request is
selected from the queue of change request records on
hold for that recipe. Rules for selection may vary and
are beyond the scope of RMS. For example, rules could
be sequence-oriented (first-in, first-out), or they might
consider the types of operations specified. For example,
requests for verification might be given precedence
over requests to link.
When a selected change request becomes active, the
manager adds the change request record to any
attached recorder and begins negotiations with the
delegated segment.
If the change request was segment-initiated (Section
10.3.5), the segment change request is approved. The
DRNS manager shall initiate a segment change
approval to the DRNS segment (Section 10.1.2.2).
There are three possible scenarios for the negotiations
with the segment: an externally initiated request, an
internally initiated request from a segment when the
recipe specified was unlocked, and an internally
initiated request from a segment when the recipe
specified was locked. These three types of scenarios are
illustrated in Table 10.5. NOTE: In both of the first two
cases, the segment sends a request to make a change
with RMDChangeRequest.req. However, in the first
case, the initiation of that change request was external,
and the segment's request is its required response to any
change request that it receives.