SECS/GEM API Reference

Introduction

SECS/GEM is an application-level communication protocol that is commonly used in the semiconductor fabrication, or fab, industry. Its primary purpose is to handle the details of sending/receiving commands from a master host control machine to several tools on the fab floor.

The exact SECS/GEM protocol specification is described at http://www.hume.com . nSpec uses third-party software to handle the protocol's implementation details.

The SECS/GEM protocol defines a large list of control commands that it supports. However, nSpec handles a small subset of all the SECS/GEM defined control commands sent from host machines, e.g., start jobs remotely. This document outlines the supported commands the nSpec tool supports along with specific examples.

SECS/GEM Basics ​

From the SECS-II standard:

"SECS-II defines the method of conveying information between equipment and host in the form of messages. These messages are organized into categories of activities, called streams, which contain specific messages, called functions."

Each SECS message specifies a stream and a function. Specific SECS messages are often referred to in this format: S(number)F(number). For example S1F13 refers to SECS message Stream 1, Function 13.

There are two kinds of messages:

• Request: sometimes called the primary message. These originate from the Host. Requests are odd-number functions, such as S1F1.

• Response: sometimes known as a secondary message. These originate from the Equipment, which is nSpec is our case. Responses are even-number functions, such as S1F2.

Thus, the Host can send an S1F1 Request, which establishes if the Equipment is on-line. If so, then the Equipment will respond with an S1F2 Response, which signifies that the Equipment is on-line. Each request can only have a single response message, or no response message if none is needed. This Request-and-Response pattern is the basis of the module, and the standard.

Stream Functions

The nSpec Application explicitly supports a subset of all StreamFunctions, though more are supported inherently through our underlying SECS/GEM library. This guide documents only those which surface within nSpec Application logic:

States

Communication State

The communication state can be viewed in the UI but not requested via GEM.

Control State

The control state can be viewed in the UI but not requested via GEM.

Control Location

Control location can be requested via GEM with VID = 300, with local control = 0 and remote control = 1.

For example, you can request to see the remote control equipment status with the following request:

 S1F3 W
  <L [1]
   <U2 300 >
  >.

Connection State

Connection state can be requested via GEM with VID = 301, with local control = 0 and remote control = 1.

For example, you can request to see the remote control equipment status with the following request:

 S1F3 W
  <L [1]
   <U2 301 >
  >.

Process State

Connection state can be requested via GEM with VID = 810, with local control = 0 and remote control = 1.

For example, you can request to see the equipment status remotely with the following request:

 S1F3 W
  <L [1]
   <U2 810 >
  >.

GEM standard (SEMI E30) requires a Process State Model. The state values are integers >= 64.

Variables

The SECS/GEM protocol reserves Variable IDs (VIDs) 200 to 999 for protocol defined variables. VIDs 1000 to 9999 are reserved for application specific variables. nSpec breaks this section down as follows: ECVs from 1000 to 2999, SVs from 9000 to 9099, and DVVALs from 9100 to 9999.
All variable values can be retrieved from the Host via an S1F3 message. The application defined variables can be set via S2F15 message from the Host.

Note: S2F15 commands must ask for a response for nSpec to acknowledge and process the SECS message.

Protocol Defined Variables

Application Defined Variables

Alarms

The SECS/GEM protocol contains alarms that are meant to notify hosts of abnormal situations on the system.

Application Defined Alarms

Sample ID Alarms

S5F1 alarm messages are sent when a requested sample ID does not match a read OCR wafer ID. The format of this message is:

S5F1
<L [3]>
    <B 0x80>
   <U4 [SlotErrorCode]>
   <A SampleId>
>.

Where ‘SlotErrorCode’ is a number that represents the slot which had the sample ID/OCR ID mismatch. The codes range 2001-2025 for slot 1-25. These alarms can be disabled by setting the program option “GEM->Send S5F1 alarms for OCR mismatches” to 0.

Events

The SECS/GEM protocol reserves Collection Event IDs (CEIDs) 4000 to 4999 for protocol defined events. CEIDs 5000 to 5999 are reserved for application specific events.

Protocol Defined Collection Events

Application Defined Collection Events

Event Use Cases

ACEID_BUSY (5000)

This event triggers once at the start and once at the end of a job. It will also trigger when initializing the system hardware.

This event is triggered when the system switches busy states. The busy state is set when a scan is currently executing or when the stage is initializing. To determine which state the system has just transitioned into, request data variable 9100 (DVVAL_BusyFlag) which will return a 0 for “not busy” or a 1 for “busy”. Note: the same data is available in status variable 9009 (SV_BusyFlag).

ACEID_SCANPROGRESS (5001)

This event triggers once per tile of a sample scan.

During a scan, progress updates will be posted during every newly scanned tile. Every time this event is triggered, data variables 9102 (DVVAL_CurTileNo) and 9103 (DVVAL_MaxTileNo) can be read to show the progress of how many tiles there will be in total and how many of them have been scanned so far.

ACEID_ANALYSISCOMPLETE (5002)

This event triggers once per analysis.

When an analysis completes, this event will be triggered to notify the host. At this point, the host can request the following pieces of data: the analysis output path in data variable 9105 (DVVAL_AnalysisOutputPath), the analysis scan ID in data variable 9106 (DVVAL_AnalysisScanID), the analysis ID in data variable 9107 (DVVAL_AnalysisAnalysisID), the analysis type in data variable 9109 (DVVAL_AnalysisAnalysisType), and the sample ID of the sample analyzed in data variable 9116 (DVVAL_AnalysisSampleID).

ACEID_WAFERSCANSTART (5003)

This event triggers once per sample scanned.

This event triggers whenever a wafer scan is started by the nSpec. The host can poll the data variable 9151 (DVVAL_CurrentWaferSampleID) to see the current wafer sample ID.

ACEID_WAFERSCANEND (5004)

This event triggers once per sample scanned.

This event triggers whenever a scan is completed by the nSpec. The output scan path will be included with this event if the host requests data variable 9110 (DVVAL_ScannedImagePath). As with the ACEID_WAFERSCANSTART event, the host can also poll data variable 9151 (DVVAL_CurrentWaferSampleID) to see the just scanned wafer sample ID. These data variables will be the same as they were when the ACEID_WAFERSCANSTART event was triggered.

ACEID_SCANNINGERROR (5005)

This event triggers once per sample scanned (if necessary, will not show unless there is an error).

This event can be triggered by a plethora of scanning errors. Any failure during a scan should trigger this event, including a failed analysis (instead of event 5002, ACEID_AnalysisComplete). To get a better understand of what the specific error was, a host should request data variable 9108 (DVVAL_ScanErrorMessage) when it sees this event triggered.

ACEID_WAFERSCANSKIPPED  (5006)

This event triggers once per sample skipped (if necessary, will not show unless there is a skipped wafer).

During a scan, a user has the option to skip a single wafer or to cancel a job entirely (more relevant for cassette jobs). If a user chooses to skip a specific wafer, this event will be triggered. To determine which wafer was the one skipped, request data variable 9111 (DVVAL_SkippedWaferSlotNum) which will identify the slot number that the wafer originated from.

ACEID_JOBPROPERTIESSET (5007)

This event triggers once per command sent by the GEM host to obtain job properties (GET_JOB_PROPERTIES).

Notifies the Host when equipment constant variable 1103 (ECV_JobProperties) was updated with the current job properties list for a selected job. This event happens shortly after a “GET_JOB_PROPERTIES” received from the Host.

ACEID_ALIGNMENTERROR (5009)

This event triggers once per sample (if necessary, will not show if there is no alignment error).

This event triggers any time that an alignment error occurs (during a scan or during layout creation). This can be caused by a number of reasons, but to determine which request the data variable 9118 (DVVAL_AlignmentErrorMessage).

ACEID_SCANABORT (5010)

This event triggers once per job (if necessary, will not show if there is no request to cancel the job).

This event triggers whenever a scan was attempted to be aborted. If a host requests to abort a scan but the scan was not aborted, false will be assigned to data variable 9119 (DVVAL_ScanAbortMessage). If the abort was successful, then true will be assigned to 9119. This verification event was implemented to prevent hosts from hanging up expecting nSpec to abort when nSpec never successfully processed the request.

ACEID_INVALIDCOMMANDERROR  (5011)

This event triggers once per invalid command sent (if necessary, will not show if all messages sent by GEM host are valid).

This event is triggered whenever an invalid command message is sent over from the Host. For example, when a “START_SCAN” command is sent without first setting the equipment constant variables 1101 and 1102 (ECV_ScanSingleWaferID and ECV_ScanSingleJobName respectively). When this event is triggered, the Host can request data variable 9120 (DVVAL_InvalidCommandErrorMessage) for a description of what specifically was invalid.

ACEID_ALLANALYSESABORTED (5022)

This event triggers when all analyses are aborted via the STOP_JOB command.

Following this event, nSpec behavior depends on the state of the program option How to Handle Queued Analyses When Job is Aborted in the Scanning category, and also on whether or not a scan or analysis is running.

The behavior of the How to Handle Queued Analyses When Job is Aborted program option is:

• Continue → Queued analyses continue running

• If Running → Queued analyses cancelled if a scan is running

• Always → Queued analyses always cancelled

In the table below, “X” represents either yes or no. “Second” means that the scan will cancel and the analysis will finish, and which ever process ends last will send the 5022 event.

ACEID_SCANJOBEND (5023)

This event triggers once per cassette or wafer job started by the nSpec tool (whether local or via SECS/GEM). This event notifies the Host that the scanning portions of the job have been complete (all scanning, state restoration of hardware, wafers returned, etc.). This event can be used to trigger a second job request from the Host to the nSpec tool. Note that if a second job is requested of the nSpec from the Host before this event is received from the previous job, the system will likely error out.

ACEID_ALLANALYSESCOMPLETEFORSAMPLEID (5024)

This event triggers when all analyses have completed for a given sample.

Once this event triggers, the Host can poll DVVAL_AllAnalysesCompleteForSampleIDMessage (9125) to get the sample ID for the analyses that are complete. Depending on recipe setup, this sample ID can be the sample ID sent from the Host or it can be the OCR-read ID.

If a Host is configured to store the last sample ID of a given carrier (can be collected from other GEM messages like DVVAL_MoveWaferToStageSampleId (9406), it can use this analyses complete event to signal a completed carrier.

Host Commands

The SECS/GEM protocol allows for the Host and Client to establish custom commands via S2F41 and S2F15 messages.

Note: S2F41 commands must ask for a response for nSpec to acknowledge and process the SECS message.

Accepted Host Command List

nSpec Host Command Acknowledgement

Host Command Examples

START_SCAN

This command is documented in the Workflows section.

START_CASSETTE

This command is documented in the Workflows section.

STOP_JOB

During a wafer or cassette scan, a Host can command the job to be completely aborted via a “STOP_JOB” command. This command uses a special acknowledge ID, HCACK_STOP_JOB_COMMAND (7). To verify that the Host and nSpec stay in sync, an ACEID_ScanAbort (5010) event will trigger once nSpec has successfully processed the “STOP_JOB” command. When this event is detected by the Host, the Host should request SECS/GEM variable

DVVAL_ScanAbortMessage (9119) which will notify the Host if nSpec successfully aborted (true = successful, false= not aborted). The event was added so any Host will not assume nSpec aborted if the command was received at an invalid time (like when a job is not running for example).

Note: if a “STOP_JOB” command is successfully received, all queued analyses will also be aborted.

SET_JOB_PROPERTIES

After the ECV_JobProperties (1103) is updated with job properties, the Host can run a job via a “START_SCAN”

command or to save the job properties via a “SET_JOB_PROPERTIES” command. If the scan is started immediately, then the current job properties in ECV_JobProperties will be used for that run but then discarded. To permanently save the job properties in the ECV_JobProperties variable, run the command “SET_JOB_PROPERTIES”.

TURN_LIGHTS_OFF

When nSpec is in an IDLE state, sending the command “TURN_LIGHTS_OFF” will result in all lighting sources (including lasers) on nSpec to be turned off.

MOVE_STAGE_AND_OBJECTIVE

When nSpec is in an IDLE state, the stage and the objective position can be controlled remotely in two steps. First, set the X, Y, Z and Objective values respectively with the StageAndObjectivePositions_Modify command, which will set the ECV_ManualMovePositions (2100) SECS/GEM variable. The X and Y parameters are required, but the Z and Objective parameters are optional. The X, Y and Z parameters can accept any value along their respective axes range. The Objective parameter can accept any of the objective position values that can be found in the Select Objectives dialog (which can be found by clicking Objective->Define Objectives in the Camera View window).

Once valid parameters are set with the StageAndObjectivePositions_Modify command, send a StageAndObjectivePositions_Move (MOVE_STAGE_AND_OBJECTIVE) command to move to all the positions stored in the ECV_ManualMovePositions (2100) SECS/GEM variable.

CLEAN_OBJECTIVES

When nSpec is in and IDLE state, this will start an air knife cleaning of the objectives. When the air knife hardware is present, the stage will move away from the objectives and the objective turret will rotate to its farthest position. The oxygen and nitrogen gases will then turn on as the objective turret rotates to the opposite end, cleaning each objective as it passes over the gas “knife” that is formed. When the cleaning is complete, the objective turret and stage will return to their original positions from before the cleaning process was started.

Workflows

Running a Cassette Scan via SECS/GEM

A cassette job is run in two steps. Step one is to set up the cassette job via an S2F15 message. The message should include a wafer scan ID (ECV_ScanCassetteWafer01_ID – ECV_ScanCassetteWafer25_ID)*, a job name (ECV_ScanCassetteWafer01_Job – ECV_ScanCassetteWafer25_Job) and optional job properties (ECV_ScanCassetteWafer01_Props – ECV_ScanCassetteWafer25_props set for every slot in the cassette that you want to run the job for. The pairings are mapped out so the 1201 – 1225/1301 – 1325/1401 – 1425 maps to slot 1 – 25 respectively.

For example, if you want to scan the wafers in slots 5 and 12, you would set up the following message:

S2F15 W
  <L [5]
    <L [2]
      <U4 1205 >
      <A "Slot05_ID_1" >
  >
  <L [2]
    <U4 1305 >
    <A "Slot05_Job" >
  >
  <L [2]
    <U4 1405>
    <A “JobProp1,Value1;JobProp2,Value2”>
  >
  <L [2]
    <U4 1212 >
    <A "Slot12_ID_1" >
  >
  <L [2]
    <U4 1312 >
    <A "Slot12_Job" >
  >
  <L [2]
    <U4 1412>
    <A >
  >
>.

Note: optional job properties were provided for slot 5 but none for slot 12. A blank value was sent for slot 12’s job properties to clear out any previously sent value for this ID.

After the S2F15 message is sent, the cassette job is initiated over SECS/GEM via a START_CASSETTE S2F41 command.

S2F41 W
  <L [2]
    <A "START_CASSETTE" >
    <L [0]
    >
  >.

Once this command is received and acknowledged by nSpec, the Host will receive a S2F69 message containing a comma-separated list of all slots that will be scanned. Depending on the state of program option Verify Cassette Mapping Before Job in the SECS/GEM category, nSpec will either automatically start the scan after the S2F69 message is acknowledged, or will wait for the Host to send a S2F70 message to scan. The S2F70 message contains a boolean indicating whether or not the scan should start.

Note that to be in this list, a wafer must be available in the slot and requested by the S2F15 message. The example below would be sent to the Host if slots 1, 5 and 15 were available and requested to be scanned.

S2F69 W
  <L [2]
    <A "1,5,15" >
    <L [0]
  >
>.

Depending on the state of the program option “Verify Cassette Mapping Before Job” in the SECS/GEM category, nSpec will either send the list and automatically continue or wait for a response from the Host. If set for verification, then the Host will need to reply with an S2F70 message indicating whether the cassette scan should continue or be cancelled. The reply to continue with the cassette scan is:

S2F70
  <L [2]
    <B 0x01 >
    <L [0]
  >
>.

The reply to cancel the cassette scan:

S2F70
  <L [2]
    <B 0x00 >
    <L [0]
  >
>. 

If confirmed to continue the cassette scan, the autoloader will grab the wafer from the first slot listed in the previously sent S2F15 message and begin the alignment process with the OCR. Once alignment completes and the OCR ID has been read, nSpec will send a S2F67 message to the host that contains the OCR ID.

S2F67
  <L [2]
    <A "OCRID_READ_FROM_WAFER" >
    <U4 1 >
    <L [0]
  >
>.

The host should send a reply to the S2F67 message indicating whether the wafer should be scanned or skipped. The reply message to scan the wafer is:

S2F68
  <L [2]
    <B 0x01 >
    <L [0]
  >
>.

To skip the wafer, reply with:

S2F68
  <L [2]
    <B 0x00 >
    <L [0]
  >
>.

The reply to the S2F67 message must be received within the T3 timeout period which is currently set to 45 seconds. If the T3 timeout is reached before the reply is received the wafer will be automatically skipped.

Once the wafer is moved to the stage to be scanned, an ACEID_WaferScanStart (5003) will notify the Host of a new scan. The data variable DVVAL_CurrentWaferSampleID (9151) will be updated to identify the sample ID of the current wafer (will be updated with reading from OCR where applicable). This update is signaled to the Host by the ACEID_ScanProgress (5001) event.

As the scan progresses, ACEID_ScanProgress events will continue to trigger for every tile scanned. Scan progress can be viewed by requesting the DVVAL_CurTileNo (9102) and DVVAL_MaxTileNo (9103) to see how many tiles of the total have been scanned so far. While this wafer is being scanned, the next slot listed in the previously sent S2F15 message will be retrieved and aligned with the OCR.

When the wafer on the stage is done being scanned, the Host will be notified via an ACEID_WaferScanEnd (5004) event at which point the Host should poll the DVVAL_ScannedImagePath (9110) variable. The autoloader will start to return it to the slot where it was originally from and then move the wafer waiting at the OCR to the stage to repeat the process.

While this autoloader motion is taking place, the analysis for the recently finished scan will start and notify the host via an ACEID_AnalysisComplete (5002) event.

When the analysis complete event is triggered, the DVVAL_AnalysisAnalysisType (9109), DVVAL_AnalysisAnalysisID (9107), and DVVAL_AnalysisOutputPath (9105), DVVAL_AnalysisScanID (9106) can all be polled.

When the entire cassette has finished being scanned, the Host will be notified with a ACEID_ScanJobEnd (5023) event.

After completion of the scan, there is some additional follow up on the system to officially complete the job and return the system to a state where it can accept new jobs from a Host again. When the system is ready to signal the entire scanning portion of the job is complete (not including analyses), it will trigger event ACEID_ScanJobEnd (5023). This event can be used as a trigger on a Host system to request another job to start on the nSpec.

*Note: Instead of running the job with an ECV_ScanCassetteWafer##_ID, a Host can leave this blank so that it will be automatically filled in by the Wafer ID read back from the OCR.

In order to do this over SECS/GEM, there is an additional parameter that must be enabled. Open the Options->Program Options dialog in nSpec, then change the “Allow Empty Sample Id” value in the “SECS/GEM” category from a 0 to a 1.

The ability to skip/scan a wafer based on the reading from the OCR is also only available if turned on from the program options. In the “SECS/GEM” category, change “Verify wafer OCR IDs” from a 0 to a 1.

Running A Single Wafer Scan via SECS/GEM

A single wafer job is run in two steps. Step one is to set up the wafer job via an S2F15 message. The message should include a wafer scan ID (ECV_ScanSingleWaferID, 1101) and a job name (ECV_ScanSingleJobName, 1102) pair. If so desired, a Host could also send temporary job properties (ECV_JobProperties, 1103). A message containing all three would look like the following:

S2F15 W
  <L [3]
    <L [2]
      <U4 1101 >
      <A “ExampleScanID_01" >
  >
  <L [2]
    <U4 1102 >
    <A "ExampleJobName" >
  >
  <L [2]
    <U4 1103 >
    <A "ShutdownLights,1;ManualLoadWafer,100,200,300,2" >
  >
>.

Once the above variables are updated, a Host can choose to save the job properties to the job (using the “SET_JOB_PROPERTIES” command) before starting a job, or the Host can start the job immediately. In the latter case, the job properties sent over SECS/GEM will be used for that job and then discarded afterwards. The two commands can be used as formatted here:

S2F41 W
  <L [2]
    <A "SET_JOB_PROPERTIES" >
    <L [0]
    >
  >.

S2F41 W
  <L [2]
    <A "START_SCAN" >
    <L [0]
  >
>.

After completion of the scan, there is some additional follow up on the system to officially complete the job and return the system to a state where it can accept new jobs from a Host again. When the system is ready to signal the entire scanning portion of the job is complete (not including analyses), it will trigger event ACEID_ScanJobEnd (5023). This event can be used as a trigger on a Host system to request another job to start on the nSpec.