semi合集-English.pdf - 第3026页

SEMI E122-0703 © SEMI 2003 7 # Current State Trigger Ne w State Actions Comments 29 INIT WITH ALARMS The tester ex ecutive has been stopped by an S TOP EXEC command form a valid source. GEM READY An operator ha s verifi …

100%1 / 7923
SEMI E122-0703 © SEMI 2003 6
# Current State Trigger New State Actions Comments
15 CHECKING Parameter checking
completes successfully.
State based on
conditional
table.
The tester resumes PROCESS
execution.
This is a conditional re-entry
to the PROCESS state. (See
Table 2.) If there are no
parameters, the CHECKING
state is a pass through.
16 PROCESS
PAUSE
An alarm is set. ALARM
PAUSED
The tester waits for all alarms to
be cleared.
None.
17 ALARM
PAUSED
All alarms are cleared. PAUSED An operator has verified that all
alarms and abort conditions have
been cleared.
The tester is waiting for a valid
command.
None.
18 PAUSE The tester has received a
STOP command from a
valid source.
STOPPING The tester executes the actions
required to perform a STOP.
The definition of a valid
source is application
dependent.
19 PAUSE The tester has received an
ABORT command from a
valid source.
ABORTING The tester executes the actions
required to perform an ABORT.
The definition of a valid
source is application
dependent.
20 STOPPING The tester completes the
actions required to
perform a STOP.
IDLE The hardware resources for this
virtual tester are released.
21 STOPPING The tester has received an
ABORT command from a
valid source.
ABORTING The tester executes the actions
required to perform an ABORT.
The definition of a valid
source is application
dependent.
22 ABORTING The tester has completed
the action required to
perform an ABORT.
IDLE The hardware resources for this
virtual tester are released.
Unsafe conditions have been
resolved where possible.
An operator has verified that all
alarms and abort conditions have
been cleared.
23 IDLE The tester receives an
STOP EXEC command
from a valid source.
GEM READY The tester executive is unloaded
from all testers.
The definition of a valid
source is application
dependent.
24 IDLE An alarm is set. IDLE with
ALARMS
The tester waits for all alarms to
be cleared.
If the ALARM already exists
upon entering the IDLE state,
the tester transitions
immediately from IDLE to
IDLE with ALARMS.
25 IDLE WITH
ALARMS
All alarms on the tester
have been cleared.
IDLE An operator has verified that all
alarms and abort conditions have
been cleared.
The IDLE state is free of
alarms.
26 IDLE WITH
ALARMS
The tester executive has
been stopped by an STOP
EXEC command form a
valid source.
GEM READY An operator has verified that all
alarms and abort conditions have
been cleared.
The tester executive is unloaded
from all testers.
The definition of a valid
source is application
dependent.
27 INIT An error occurred during
the loading of the tester
exec.
INIT WITH
ALARMS
None.
28 INIT WITH
ALARMS
Alarms are cleared. INIT An operator has verified that all
alarms and abort conditions have
been cleared.
None.
SEMI E122-0703 © SEMI 2003 7
# Current State Trigger New State Actions Comments
29 INIT WITH
ALARMS
The tester executive has
been stopped by an STOP
EXEC command form a
valid source.
GEM READY An operator has verified that all
alarms and abort conditions have
been cleared.
The tester executive is unloaded
from all virtual testers.
The definition of a valid
source is application
dependent.
6.5 Process Model Conditions Table
Table 2 Process Resume Conditions
Condition Next State
Checking determines that process program conditions were
changed.
SETTING UP
Previous state EXECUTING, and no process program
conditions were changed.
READY
Previous state READY, and no process program conditions
were changed.
READY
Previous state was SETTING UP. SETTING UP
7 Virtual Testers
7.1 General Definitions
7.1.1 The virtual tester is defined as a single load
instance of a test program (regardless of how many test-
sites, test system resources, or test-heads are associated
with that instance) that is capable of operating as an
independent tester in accordance with the state model
shown in this document.
7.1.2 Loading another instance of the same test
program, which uses separate or shared test system
hardware resources, establishes another virtual tester.
The multiple copies of that test program are
independent of each other. In this context, program
independence describes the condition that one virtual
tester program does not expect or rely on the existence
of another virtual tester program in order to run.
7.1.3 For a single test system with one test-head that
must be dedicated to a single test program, the physical
tester and virtual tester are the same and a single GEM
communication interface is needed. In a test system
with two test-heads, where each test-head can execute a
unique process program autonomously, two virtual
testers may be operating at the same time with two
GEM communication sessions. If a test-head may be
divided into several segments, each capable of
autonomous execution of a unique program, there will
be one virtual tester and one matching GEM
communication session for each of those segments.
7.1.4 The number of virtual testers operating at any
time depends on how the test system is configured
(hardware and software) and may range from one to the
maximum capability of the particular test system. The
number of GEM communication sessions is equal to the
number of virtual testers supported by the tester.
7.2 GEM Communication Sessions
7.2.1 From the GEM communication host connection,
only one program and virtual tester exists and the host
GEM communication connection has no knowledge or
view of other virtual testers. Independence does not
preclude the tester executive or test hardware from
sharing resources between virtual testers, such as in the
case of power supplies or shared software libraries.
7.2.2 For each virtual tester, the test system must
provide a separate GEM client connection. The test
system controller has responsibility to manage the
multiple client connections.
7.2.3 For each virtual tester the station controller
establishes a unique host connection to a single tester
GEM client. The station controller has responsibility to
manage the multiple host connections.
7.2.4 The test system will have a set maximum number
of allowable unique GEM host/client connections. The
maximum number of connections (n) and the port IDs
for these GEM communication connections are
constants known to the station controller and available
from the test system controller after that controller is
booted.
7.2.5 The maximum number of GEM communication
sessions allowed by the test system is also the
maximum number of virtual testers allowed by the test
system, regardless of the number and allocation of
tester resources.
SEMI E122-0703 © SEMI 2003 8
7.2.6 Each unique virtual tester host/client connection
is an independent GEM communication session. The
following hierarchy relationship can be established.
7.2.7 GEM Communication session (1 ... n) accepts
program load instances (1 ... n) which uses tester
hardware resources (x ... y) which establishes Virtual
Tester (1 ... n). This relationship does not imply any
order of assignment. The station controller can select
any available GEM communication port in order to load
a program and establish a virtual tester.
7.2.8 Multiple station controllers can address a single
physical test system, with each station controller
establishing its own virtual testers, until the physical
limit for the test system is met.
7.3 GEM Communication Synchronicity to Virtual and
Physical Tester
7.3.1 The GEM communication client interface must
represent the actual real time state of the related virtual
tester at all times.
7.3.2 Events from outside the GEM communication
interface, such as local operator actions, can cause state
transitions to occur.
7.3.3 Synchronization of the virtual tester to physical
tester events (from any source) is required.
7.3.4 The methodologies and effectiveness of this
virtual tester to physical tester synchronization is
outside the scope of the TSEM and is the responsibility
of the test vendor.
7.4 GEM communication Sessions and Alarms
7.4.1 Any alarm condition that impacts more than one
virtual tester must be communicated to all impacted
virtual testers.
7.5 State Model Implications
7.5.1 When the test system workstation is powered up,
and the workstation operating system (O/S)
successfully loads, (n) GEM communication port IDs
will be established and made available for the station
controller. Each GEM communication port represents a
potential virtual tester. Each GEM communication port
will have a fully independent process state model,
which initializes into the GEM READY state.
7.5.2 The station controller can connect to and
establish a GEM communication session with any of
the available GEM communication ports. Once the
station controller establishes a GEM communication
session, the remote command START EXEC will load
the tester executive and, if successful, cause the process
state model for that GEM communication session or
virtual tester to transition to the IDLE state. This
transition is wholly independent of any other GEM
communication sessions. The other GEM sessions
remain in their original states.
Example: The host issues the first START EXEC to
GEM communication port #1. The virtual tester
transitions to INIT and starts the Tester Executive
which in turn initializes all hardware. If successful, the
virtual tester then transitions to IDLE. GEM
communication ports 2 through (n) remain in a
“logical” GEM READY state even though the physical
test system has started the Tester Executive.
7.5.3 If a previous START EXEC remote command to
a different GEM communication session on the same
tester workstation has already started the tester
executive, and the tester executive can support multiple
virtual testers, then the new GEM communication
session can transition to the IDLE state without starting
a new tester executive.
7.5.4 The station controller can issue a STOP EXEC
remote command to an active virtual tester. If another
virtual tester is running in that test system, the virtual
tester that received the remote command will transition
to the GEM READY state, but leave the tester
executive running. If no other virtual testers are
currently running on that test system, the test system
can shut down the tester executive.
7.6 Physical Resources and Virtual Testers
7.6.1 For the case of a multi-site virtual tester, each
test-site should be uniquely identified without having to
identify the test-head associated with that test-site.
7.6.2 Once a GEM communication session or virtual
tester is in the IDLE state, the station controller can
issue the PP-SELECT remote command. Until a PP-
SELECT has been issued to a virtual tester, and the
SETTING UP state is entered, the GEM
communication session exists only as a
communications path to a potential virtual tester.
7.6.3 In the SETTING UP state, the test system will
determine whether the physical hardware resources
required for that test program are available. If the
resources are available, they are reserved for this virtual
tester, the test program loads, SETTING UP process
state is successful, and the virtual tester transitions to
READY. If the physical hardware resources required
for that test program are not available, the SETTING
UP process state fails, the virtual tester has an ALARM,
and it returns to the IDLE state. Before entering the
IDLE state, all resources that have been reserved during
SETTING UP must be freed.
7.6.4 Depending on the architecture of the test system,
the hardware resources may or may not be tied to a
specific virtual tester.