Collaborative Alliance for Semiconductor Test (CAST)

Tester Event Messaging for Semiconductors (TEMS) Overview2017

Special Interest Group

Overview

• How and why we got here – a little history

• What is TEMS & What does it do

• How TEMS fits in

• Where is the working group at - Status

– The good, the bad and the ugly

• Next steps & schedule

2

TEMS - History

• Started in mid 2014

• Original “charter”

• Kick off participants

– Advantest

– Teradyne

– Xcerra

3

How we got here – problem

• Every ATE vendor and Every Data analysis vendor, or semiconductor manufacturer, had their own [custom] way to get events from the ATE to the server for analysis.

• Wasted time & effort for all involved!!

4

CAST ATE WG (TEMS) Charter

• To develop a standardized ATE data messaging system based on standard internet communication protocols between a Test Cell host and a server. The standard will be limited to ATE data messaging, using RITdbentity types, where applicable, as the standard data format, and control requirements. It will exclude other test communication interfaces such as those involving handlers, probers, test instrumentation, and other systems covered by existing standards (e.g. SEMI E30, E4, E5, STDF, etc.)

• The developed Standard shall be known as:

– Test Event Messaging for Semiconductors (TEMS)

• The primary spec shall define the Model, and a subordinate spec shall define the Transport layer to maintain consistency with prior standards.

5

What is TEMS ?

• A set of Standards to define a vendor neutral way to collect test cell EVENTS

– SEMI EXXX – Model for Test Event Messaging for Semiconductors (TEMS)

– SEMI EXXX.1 – Specification for HTTP-JSON Protocol for Test Event Messaging for Semiconductors (TEMS)

• Utilizes easy to use internet standard protocols and methods

– RESTful HTTP/HTTPS POST

– JSON

6

TEMS Message Types

Message Name Message Name Comment

TCS Initialization TCS Shutdown System startup / shutdown

Status Periodic heartbeat

Test cell configuration Test cell config activity

User Account User account activity

Tester OS Tester OS activity

TestProgram load Test program activity

Run Start Run End

Lot Start

Test Start Test End

Test Data

Halt

External Source User API on TCS

Peripheral Messages from attached peripherals

Maintenance Maintenance Data

Generic User specific extensions

7

TEMS State Diagram

8

• TEMS is [mostly] a data out [event] messaging system

• A Single (Primary) DAS can interact with the TCS for halt/error condition test

Where does TEMS fit in ?

9

The Interface

10

Test Cell

Handler/ Prober

Test Cell Host Test Cell

Control

Existing MES etc.

Server

Server

On H

ost Data service

GPIB,RS-232, Ethernet, SECSGEM

SEMI E4, E5, E30

STDF, OTDF etc.

TEMS

No Change in existing

Infrastructure

ATE WG Focus

New method for status/info transfer

between cell and server

TEMS CommunicationJSON Message explained

11

POST <server>/TEST_CELL/<TEST_CELL_ID>/ LOT/<LOT_ID>/RUN/<RUN_ID>/TEST_DATA HTTP/1.1From: <test cell TCS>User-Agent: HTTPTool/1.1Content-Type: application/jsonContent-Length: xx

{“EVENT_DTTM”: “2015-07-08T19:53:24.589Z”,“TEST_DATA”:[{“TEST_NAME”: “IDD”,“RESULT_ID”: 6547,"RESULT_COND_INFO": { “PIN_NAME” : “string”,“DYNAMIC_LIMITS_LL”: 1.2,“DYNAMIC_LIMITS_UL”: 1.1,“RESULT_SCALE”: 1,“RESULT_UNITS”: “mA”,“TEST_EVENT_GROUP”: “IDD_test”

},“SITE_ARRAY” : [{“SECTOR”:1,“SITE_NUM”:1,“PF_FLAG”: “P” ,{ “PIN_NAME” : “VDD”,

},"RESULT_INFO":{“R_TYPE”: “PARAM” ,“R”: 1.15,

Only POST HTTP commandURL has info on LOT, TEST CELL

Each message has timestampJSON message heirarcy“TEST_DATA” is a key (an array in this example)

Key can contain multiple nested keyse.g. RESULT_CON_INFO contains limits, scaling etc.

Also has nested arraysExample here is individual site P/F and value

TEMS Features & Benefits

• ATE Platform independent

– Same tool used for multiple ATE vendors

– Easier tool portability

• Eliminates needs to store data on ATE, then move and import to DB

• Near real time data availability

• Extensible for custom data

– Both within the defined spec (Generic) and with additional events that vendors & customers can define.

• Standard protocols (HTTP/JSON) enable easy tool creation

• Co-exists with current standards

• Easily expanded to other test steps (bench, SLT, burn-in)

• Can leverage existing DB infrastructure

– Vendors can use their favorite method to store the data based on the application’s need

12

TEMS – Where are we ?

• The good:– Specification of probably about 80-90% complete

• Good alignment in recent meetings with RITdb naming conventions and entity types

– Needs validation with other participants to ensure that all information is present

• Validated that HTTP/JSON can be use in real life

– Test cases tomorrow

– The “big 3” ATE are all participating

• The bad– It’s been a slow arduous process

• Participants are only part time

• Alignment to RITdb entities took longer than anticipated

– And are still evolving

• The ugly– Data is easy, events are hard, testers are impossibly unique !!!– Participants all new to developing SEMI standards !!– Dropped adaptive test pieces of specification

• WG felt that tester implementation architecture uniqueness would mean no agreement could be achieved

13

TEMS - Desire

• Have a spec that can go to initial ballot by Semicon West !!!

• Risk:

– WG participants availability to write and review the actual spec document !!

14

Thank You