semi合集-English.pdf - 第909页

SEMI E118-1104 E © SEMI 2002, 2004 3 6 Conventions 6.1 Stat e Model M ethodology 6.1.1 This docum ent uses the Harel stat e chart convent ion for des cribing dynamic operatio n of defined objects. The outline of this con…

SEMI E118-1104

5 Terminology

5.1 Abbreviations and Acronyms

5.1.1 FOUP — Front Opening Unified Pod

5.1.2 WIDR —Wafer ID Reader

5.2 Definitions

5.2.1 attribute — information about or associated with

some entity or object.

5.2.2 carrier — any cassette, box, pod, or boat that

contains wafers.

5.2.3 cassette — an open structure that holds one or

more substrates [SEMI E44].

5.2.4 controller — a system that provides control

(performs required operations when certain conditions

occur or when interpreting and acting upon

instructions) and communicates with a higher level

manager. Controllers exist at all levels within a factory.

Examples of controllers include the Multiple Wafer ID

Reader Controller, the Equipment Controller.

5.2.5 data matrix code symbol — a two-dimensional

array of square cells arranged in contiguous rows and

columns. In certain ECC200 symbols, data regions are

separated by alignment patterns. The data region is

surrounded by a finder pattern [ISO/IEC 16022].

5.2.6 front-opening unified pod (FOUP) — a box (that

complies with SEMI E47.1) with a non-removable

cassette (so that its interior complies with SEMI E1.9)

and with a front-opening interface (that mates with a

FIMS port that complies with SEMI E62).

5.2.7 fundamental requirements — the requirements

for information and behavior that must be satisfied for

compliance to a standard. Fundamental requirements

apply to specific areas of application, objects, or

services.

NOTE 1: All portions of the Wafer ID Reader specification

are considered to be fundamental requirements unless

explicitly described as optional. See also optional

requirement.

5.2.8 load port — the interface location on a tool

where wafer carriers are delivered. It is possible that

wafers are not removed from, or inserted into, the

carrier at this location.

5.2.9 message interleaving — the practice of sending a

new message request before receiving the reply to an

earlier request.

5.2.10 Multiple Wafer ID Reader controller — a unit

controlling the Reader function of one or multiple ID

Reader Heads, communicates the command/data with

the equipment controller or the equivalent controller

such as equipment controller.

5.2.11 optional capability — a specification that is not

required for an implementation to be compliant to a

standard. See also fundamental requirement.

5.2.12 reader head — a structured portion which

functions to detect the ID code. The ID reader unifying

a head function inside its body can be placed as a head.

The ID reader not unifying a head function will be

located separately from the head.

5.2.13 substrate handler — a physical subsystem

which transfers substrates between the carriers and the

process part of the equipment.

5.2.14 upstream controller — a controller that directs

the Wafer ID Reader through the communication

interface.

5.2.15 Wafer ID — an identifier for a wafer. A value

that uniquely identifies a given wafer in a factory. The

identifier may be represented physically with LASER

technologies, etc.

5.2.16 Wafer ID mark — a physical structure for

storing Wafer ID and other information.

5.2.17 Wafer ID Reader — a unit (subsystem) that

detects and decodes data from the Wafer ID mark, and

that communicates with the upstream controller. Wafer

ID Reader may be composed of Multiple Wafer ID

Reader controller and reader heads.

5.3 Data Types

5.3.1 enumerated — may take on one of a limited set

of possible values. These values may be given logical

names, but they may be represented by any single-item

data type.

5.3.2 form — type of data: positive integer, unsigned

integer, integer, floating point (float), enumerated,

boolean, text, formatted text, structure, list, ordered list.

5.3.3 integer — may take on the value of any negative

or unsigned integer. Messaging protocol may impose a

limit on the range of possible values.

5.3.4 structure — a specific set of items, of possibly

mixed data types, in a specified arrangement.

5.3.5 text — a character string. Messaging protocol may

impose restrictions, such as length or ASCII

representation.

5.3.6

unsigned integer — may take on the value of any

positive integer or zero. Messaging protocol may

impose a limit on the range of possible values.

SEMI E118-1104

6 Conventions

6.1 State Model Methodology

6.1.1 This document uses the Harel state chart convention for describing dynamic operation of defined objects. The

outline of this convention is described in an attachment of SEMI E30. The official definition of this convention is

described in “State Charts: A Visual Formalism for Complex Systems” written by D. Harel in Science of Computer

Programming 8, 1987

6.1.2 Transition tables are provided in conjunction with the state diagrams to explicitly describe the nature of each

state transition. A transition table contains columns for Transition number, Previous State, Trigger, New State,

Actions, and Comments. The “trigger” (column 3) for the transition occurs while in the “previous” state. The

“actions” (column 5) includes a combination of:

 Actions taken upon exit of the previous state.

 Actions taken upon entry of the new state.

 Actions taken which are most closely associated with the transition.

6.1.2.1 No differentiation is made between these cases.

6.2 Object Notation

6.2.1 The object models in Related Information 2 use the Object Modeling Technique (OMT) developed by

Rumbaugh, James, et al, in Object-Oriented Modeling and Design

. An overview of this notation is provided in

SEMI E39, Object Services Standard: Concepts, Behavior, and Services.

Num Previous State Trigger New State Actions Comments

6.3 Service Message Representation

6.3.1 Services are functions or methods that may be provided by either the equipment or the host. A service

message may be either a request message, which always requires a response, or a notification message, that does not

require a response.

6.3.2 Service Definition

6.3.2.1 A service definition table defines the specific set of messages for a given service resource, as shown in the

following table:

Message Service Name Type Description

Type can be either “N” = Notification or “R” = Request & Response.

6.3.2.2 Notification type messages are initiated by the service provider (e.g., the equipment) and the provider does

not expect to get a response from the service user. Request messages are initiated by a service user (e.g., the host).

Request messages ask for data or an activity from the provider. Request messages expect a specific response

message (no presumption on the message content).

6.3.3 Service Parameter Dictionary

6.3.3.1 A service parameter dictionary table defines the description, format and its possible value for parameters

used by services, as shown in the following table:

2 Elsevier Science, P.O. Box 945, New York, NY 10159-0945, http://www.elsevier.nl/homepage/browse.htt

3 James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, Object-Oriented Modeling and Design

, Englewood

Cliffs, New Jersey: Prentice-Hall, 1991.

SEMI E118-1104

Parameter Name Description Format: Possible Value

6.3.3.2 A row is provided in the table for each parameter of a service.

6.3.4 Service Message Definition

6.3.5 A service message definition table defines the parameters used in a service, as shown in the following table:

Parameter Req/Ind Rsp/Cnf Comment

6.3.5.1 The columns labeled REQ/IND and RSP/CNF link the parameters to the direction of the message. The

message sent by the initiator is called the “Request”. The receiver terms this message the “Indication” or the request.

The receiver may then send a “Response” which the original sender terms the “Confirmation”.

6.3.5.2 The following codes appear in the REQ/IND and RSP/CNF columns and are used in the definition of the

parameters (e.g., how each parameter is used in each direction):

Code Description

M Mandatory Parameter — Must be given a valid value.

C Conditional Parameter — May be defined in some circumstances and undefined in others. Whether a value

is given may be completely optional or may depend on the value of the other parameter.

U User-Defined Parameter.

- The parameter is not used.

= (For response only.) Indicates that the value of this parameter in the response must match that in the primary

(if defined).

7 Overview

7.1 The Wafer ID Reader Model defines the behavior and services (functions). The Wafer ID Reader is a small

intelligent system, typically used as a subsystem within equipment.

7.1.1 The primary functionality of the Wafer ID Reader is to read the identifier of the wafer (Wafer ID).

7.1.2 The acronym WIDR is used to refer to the Wafer ID Reader.

7.1.3 An object model for the WIDR is provided in Related Information 2 – Object Model.

7.2 Number of Heads

7.2.1 A WIDR provides one or more ID reader heads and is connected to an upstream controller by a single

interface. This allows the upstream controller to control either one head or multiple heads using the same interface

specification.

7.2.2 Single Head Configuration

7.2.2.1 In the case of a single head, the head may be presented as an integrated part of the WIDR.

7.2.3 Multiple Head Configuration

7.2.3.1 In the case of multiple heads, some services are logically performed by the WIDR, and the individual heads

logically perform others. The individual heads are numbered sequentially and may be referenced individually by the

upstream controller. Note that the upstream controller does not communicate directly with the heads. All

communications are between the upstream controller and the WIDR unit.

7.2.3.2 In the multi-head case, the WIDR shall allow independent control of the heads. Multiple transactions

invoking services performed by the individual heads may be open at the same time. For example, when a read