Industry News, Trends and Technology, and Standards Updates

Background

The SEMI North America Advanced Backend Factory Integration (ABFI) task force is part of the North America Information and Control Committee (I&CC or NA I&CC). Normally this task force meets every July in San Francisco as part of SEMICON West. However, this year the technical committee meetings are spread out over several weeks and do not coincide directly with the exhibition. Additionally, the I&CC did not meet at all because SEMI regulations do not currently allow TC Chapter (Committee) voting in virtual meetings. That will hopefully change later this year, but for now delays SEMI standards development.

Regardless of these challenges, the ABFI task force did meet on Monday July 13, 2020 and continues to develop SEMI standards. I am co-leader of the NA ABFI task force along with Dave Huntley of PDF Solutions. This blog is a summary of the current task force activities.

Wafer Maps

Ballot 6648 to update to the SEMI E142 (Specification for Substrate Mapping) specification has passed initial voting and is recommended to be accepted and published. This ballot significantly enhances the amount of traceability data that may be embedded within wafer maps.

Additional Wafer Map Activity

Because wafer maps will potentially be much larger with additional traceability data, they could be too large for the messages currently defined in the E142.2 standard. A new activity has been started to modify wafer map usage further and to allow Stream 21 messages to be used for wafer map transfer. The stream 21 message in the SECS-II standard can be used to transfer very large items through a GEM interface.

SEMI Standard Usage Matrix for Backend

The ABFI task force is also defining a matrix that specifies which standards beyond GEM (E30), SECS-II (E5), HSMS (E37) and Substrate Mapping (E142) should be used for backend automation, and under what conditions they should be used. This includes consideration of the full suite of GEM 300 standards and other standards that all GEM interfaces should consider, such as SEDD (E172) and SMN (E173).

Getting Involved

For those interested in participating, it is easy to join SEMI standards activities. Anyone can register at www.semi.org/standardsmembership.

All SEMI task force ballot activities are logged at http://downloads.semi.org/web/wstdsbal.nsf/TFOFandSNARFsbyCommittee?OpenView&Start=1&Count=1000&ExpandView

After joining the standards activities, anyone can get involved. The task forces post everything on the connected @ SEMI website https://connect.semi.org/home. The North America ABFI task force does not have a community.

To learn more about the standards, or to speak with a standards expert, click on the button below:

Background

The SEMI North America GEM 300 task force is part of the North America Information and Control Committee (I&CC or NA I&CC). Normally this task force meets in San Francisco as part of SEMICON West. However, this year the technical committee meetings are spread over several weeks and don’t coincide directly with SEMICON West. Additionally, the I&CC did not meet at all because SEMI regulations do not currently allow TC Chapter (Committee) voting in virtual meetings. That will hopefully change later this year, but for now inhibits the pace of SEMI standards development.

However, the GEM 300 task force did meet on Monday July 13, 2020, and continues to develop SEMI standards. I am co-leader of the NA GEM 300 task force, along with Chris Maloney from Intel. This blog is a summary of the current task force activities.

Pre-Meeting Summary

The table below contains a summary of the worldwide activities related to the GEM 300 task force as of the start of this summer’s meeting. There are corresponding task forces in the Japan and South Korea regions which are also active.

Current Ballot Activity

Two ballots were adjudicated during the most recent GEM 300 task force meeting. For those of you new to the standards development process, the term “adjudication” means that we review the results of the voting and recommend handling of all negative votes and comments received. The recommendations by the task force are then presented to and finalized at the committee level. Since the North America I&CC did not meet, the failed and super-clean ballots are being transferred to other regions (probably Taiwan) for further processing. Passed ballots with any negatives or comments are put on hold until NA I&CC meets so that the merits of the comments and overridden negatives can be evaluated.

6552A E5

This ballot modifies the E5 SECS-II standard. The ballot included three line-items, each of which is voted on separately

1. This is the most exciting activity in this ballot because it will give GEM host software much better tools for managing and testing GEM data collection. The first line item proposed adding several new messages to the E5 standard including a message to:
   1. Query the list of defined report identifiers
   2. Query report definitions
   3. Query a list of event report links
   4. Query the list of enabled events (this could already be done using Status Variable EventsEnabled)
   5. Query the list of streams and functions configured for spooling
   6. Query the list of defined trace identifiers
   7. Query trace definitions

1.  
2. Establish proper definitions for status variables, data variables and equipment constants. Additionally, deprecate the usage of the data item “DVNAME” which has generated confusion for years since it means a data variable identifier and not a data variable name.
3. Clarify the usage of message S7F17/F18. This message allows deletion of one or more recipes, but only returns a single acknowledgement code. The new clarification defines what to expect when an error is returned.

Each of the line items had at least one comment or negative; therefore, none was super-clean. The GEM 300 task force decided to pass line items 1 and 3, but fail line item 2.

6598A E37

The primary purpose of this ballot is to clarify some confusing text related to the T8 timer. Additionally, there are other improvements related to recommended settings. The GEM 300 task force decided to fail this ballot.

New Ballot Activity

Here is a summary of the next set of ballots to expect from the NA GEM 300 task force planned to be presented for Cycle 7 voting later this year.

Getting Involved

For those interested in participating, it is easy to join SEMI standards activities. Anyone can register at www.semi.org/standardsmembership.

All SEMI task force ballot activities are logged at http://downloads.semi.org/web/wstdsbal.nsf/TFOFandSNARFsbyCommittee?OpenView&Start=1&Count=1000&ExpandView

After joining the standards activities, anyone can get involved. The task forces post everything on the connected @ SEMI website https://connect.semi.org/home. The North America GEM 300 task force community is called “GEM 300 Task Force - North America”.

To find out more about SEMI Standards, GEM300, or to talk to standards expert, click the button below. 

A SECS GEM driver can be looked at from a factory or equipment supplier perspective. I will discuss both of them in that order.

Factory Perspective

A little background:

From a factory perspective, a SECS GEM driver is the host software that talks to an equipment’s GEM interface. It allows the factory to take advantage of the features implemented in each equipment’s GEM interface. However, what the factory can do with an equipment’s GEM interface is also limited by what the equipment supplier has included in that interface. The GEM standard is very flexible and scalable, which accounts for the widespread and growing adoption of GEM technology—it can be adapted to any manufacturing equipment and market segment.

It is possible to implement features in a GEM interface. But this also means that just having a GEM interface on the equipment does not ensure that it has been correctly designed to meet the factory’s expectations. An equipment supplier’s poor implementation of GEM can frustrate a factory’s plans for Smart Manufacturing by not providing features that the factory expects that could have been implemented. The tendency of most equipment suppliers is to implement the absolute minimum functionality in a GEM interface to save money. Therefore, it is the responsibility of the factory during equipment acceptance to evaluate the GEM interface to make sure that it is robust and has the full set of required features. The factory must have a clear vision of its needs both initially and later as its Smart Manufacturing goals are realized. It is not unusual for a factory to request an upgrade to an equipment’s GEM interface with more features, but these modifications usually come at a cost.

Although a factory’s SECS GEM driver must be adaptable to different suppliers’ GEM implementations, it only needs to support the specific features that the factory uses. For example, if the factory is only concerned about alarm and event report notification, then it does not need to support the messages for recipe management, remote control or trace data collection. As such, the investment in a SECS GEM driver is proportional to the number of GRM features that are utilized. However, the SECS GEM driver should also support variations in alarm and collection event implementations, because each equipment type will support a unique set of alarms and a unique set of collection events with unique data variable for event reports. Moreover, from equipment type to equipment type, the same collection ID might have different meanings. The SECS GEM driver therefore needs an ability to adapt by having a method to characterize the GEM implementation (such as a list of available collection events) and the ability to map a general capability to the actual implementation (such as “material arrived” = collection event ID 5).

So why would a factory want to use SECS GEM technology?

In order to reach the goals of Industry 4.0 and Smart Manufacturing, factories must be able to monitor and control manufacturing equipment remotely. Therefore the equipment must have a software interface to provide this functionality and the factory must be able to access and use this interface.

Factories could let the equipment suppliers choose their own implementation technologies for this kind of capability, but as a result, different suppliers might take a different approach for every equipment type. This would be tremendously expensive and resource intensive. It is far better to standardize on one or two technologies, and ideally, one that is proven to work and known to have all of the necessary features. This allows the factory to achieve its goals with minimum investment, focusing instead on using the equipment interface in creative ways to improve manufacturing.

SECS GEM is the most proven technology already widely used across the globe and supported by the most sophisticated and automated industry in the world; semiconductor manufacturing. It is also widely adopted several other industries, making it a safe choice. The range of production applications supported by SECS GEM data collection include productivity monitoring, statistical and feedback/feedforward process control, recipe selection and execution tracking, fault detection and classification, predictive maintenance, reliability tracking, and many more. By contrast, alternatives to SECS GEM have so far been demonstrated to be incomplete or immature solutions. 

What specifically can you do with the SECS GEM technology?

1. Collection Events: Be notified when things happen at the equipment, such as when processing or inspection begins and completes, or when a particular step in a recipe is reached.
2. Collection Event Reports: Collect data with collection events. The host chooses what data it wants to receive. For example, track the ID of material arriving and departing from the equipment, or components placed on a board.
3. Alarms: Be notified when bad or dangerous things are detected, receive a text description of the alarm condition, and when the issue is cleared.
4. Trace Data Collection: Tell the equipment to report status information (software and/or hardware data) at a specific interval. For example, track digital and/or analog sensors during processing at 10 Hz frequency.
5. Recipes: Upload, download, delete and select recipes as desired, whether in ASCII or binary formats. Make sure that the right recipe is run at the right time to eliminate misprocessing and minimize scrap. Track when someone changes a recipe.
6. Remote Commands: Control the equipment, such as when to start, stop, pause, resume and abort. Custom commands, such as calibrate, skip or anything else can be supported.
7. Equipment Constants: Configure and track the equipment configuration settings remotely.
8. Terminal Services: Interact with the equipment operator remotely or provide instructions for the operator.
9. Extensions: There are numerous extensions to GEM that can be supported but are not yet form requirements. For example, implement wafer or strip maps from E142 to provide and report details about material in XML format.

Equipment Supplier Perspective

From an equipment supplier’s perspective, a SECS GEM driver is the software used to implement GEM technology on the equipment. In other words, the software to create a GEM interface. The equipment-side software requirements are inherently more complex that the host SECS GEM driver. This is because the equipment-side features are precisely defined by the GEM standard and should be implemented to the fullest extent possible. By contrast, the host can really do whatever it wants, so a limited implementation may be sufficient. In an ideal situation, the equipment supplier will implement just enough features in its GEM interface to satisfy all of its customers and therefore ship an identical GEM interface to all its customers. It is up to the equipment supplier to decide what GEM features to implement and how to adapt them for a particular type of equipment, but the factory should provide clear expectations about its planned use of the interface. It is also the factory’s responsibility to qualify the GEM interface during equipment acceptance. Note that it is not uncommon for factories to withhold partial equipment payment until the GEM interface has also passed its own acceptance.

Some equipment suppliers include the GEM driver as a standard feature on all equipment. This is ideal because it makes the GEM interface much easier to support and distribute. Some equipment suppliers only install GEM when it is specifically purchased. This often results in installation problems because the field technicians may or may not be knowledgeable enough or specifically trained to do this correctly. Other equipment suppliers include the GEM driver on all equipment, but only enable it when the feature has been purchased. This is better than attempting GEM interface installation after equipment delivery because the GEM interface can often be enabled with a simple equipment configuration setting.

Here are some key reasons for implementing a SECS GEM driver:

1. “One ring to rule them all”

By implementing a GEM interface, an equipment supplier can avoid having to implement multiple interfaces. Because GEM is the most feature complete option, the it should be implemented first and Thoroughly integrated with the equipment control and user interface software. If other protocols must be supported, they can usually be mapped onto the GEM capabilities or a separate external system because they only include a subset of GEM functionality.

2. Equipment Supplier Application Software

If the GEM implementation includes support for multiple host connections, then the GEM interface can be used by the equipment supplier itself for many applications. For example, an equipment supplier can develop a software package that monitors and controls their specific equipment at a factory. This can run simultaneously and independently while the factory GEM host software is connected. Many factories are willing to buy applications from the equipment supplier that enhance the productivity of the equipment they have purchased. As an example, equipment suppliers are better equipped to develop predictive maintenance applications that determine when parts are approaching failure and need replacement. These applications can save the factory time and money by avoiding unscheduled downtime. Other applications can also be developed by equipment suppliers to analyze and optimize equipment execution.

3. Competitive Advantage

A well implemented GEM interface can differentiate a supplier’s equipment from that of its competitors. Factories are beginning to recognize the value in controlling and monitoring equipment remotely, and know that a poor GEM interface contributes nothing to a factory’s Smart Manufacturing initiatives. A GEM interface that goes the extra mile to be truly useful empowers the factory to excel at Smart Manufacturing and to be far more productive. Selling equipment in today’s market without a GEM interface is like selling a television without a remote. On the other hand, providing a fully featured GEM interface is like selling a smart television.

Final Words

Experts on GEM technology are available all over world. Because GEM is a mature industry standard and well defined, it can be implemented by anyone in a range of different programming languages and operating systems. however, to save time I recommend using a commercially available product rather than developing the complete GEM interface from scratch. This can save massive amounts of time and effort, and ensures the quality of the resulting implementation.

To speak with a Cimetrix GEM expert, or to find out more about our GEM software products, you can schedule a meeting by clicking the link below.

The SEMI North American standards meetings for the Information and Control Committee were held recently and the following is a summary of some of the highlights and action items. 

In the GEM 300 task force, a revision to GEM officially removed E139 as a recipe management option. A planned revision to GEM should be much more exciting and progressive, but this work cannot begin until E30 is published with the current changes. In the meantime, future near-term plans include defining new SECS-II messages to improve host access to data collection setup and some terminology clarification. Brian Rubow from Cimetrix continues to co-lead this task force with Chris Maloney of Intel.

In the DDA (Diagnostics Data Acquisition) task force, which Brian Rubow from Cimetrix continues to co-lead, the standard that establishes gRPC and Protocol Buffers for EDA freeze 3 was approved. However proposed changes to the other core standards E125, E132 and E134 all failed, as well as the gRPC adoption for E132. The failures were expected. Additionally the North America DDA task force leaders continue to actively collaborate with the co-leaders of the DDA task force in South Korea. It is a great example of competitors working together at SEMI to create common solutions that satisfy everyone’s requirements.

Tami Tracy, a Cimetrix Solutions Engineering Manager, was officially voted in as a GUI task force co-leader for 2020, co-leading with Frank Summers. Congratulations and thanks to Tami for volunteering for this position. This will accelerate the task force's plans to modernize the SEMI E95 standard.

The Computer and Device Security (CDS) task force announced a vastly improved collaboration with its sister organization in Taiwan which has officially agreed to "divide and conquer" rather than attempting to address the entire scope of this domain with a single standard. A few months ago, the two groups seemed to be at odds with each other...The Taiwan task force proposed to include all factory and equipment security issues in one effort, while the North American task force wanted to focus initially on the equipment issues. The Taiwan, Japan and North America Task Force Leadership have now agreed to convert the Specification for Malware Free Equipment Integration (SNARF) 6506 into an overarching standard. The CDS task force is moving forward on SNARF 6566, and received authorization for a ballot on this proposed new standard for Cycle 2-2020.

The Advanced Factory Factory Integration (ABFI) task force, headed by Brian Rubow (Director of Solutions Engineering, Cimetrix) and Dave Huntley (PDF Solutions), held its first task force meeting. One order of business is to update E142 substrate mapping. The task force intends to map equipment features to SEMI standards including GEM and GEM 300. This effort could facilitate adoption of the GEM standard on equipment that previously had little interface standardization. It should also encourage further advance the goals of Smart Manufacturing and Industry 4.0 in related industries, encouraging more factories and equipment to adopt the standards that have been so successfully applied in semiconductor manufacturing for decades.

To find out more, you can speak with an industry standards expert today by clicking the link below.

During the SEMICON West exhibition in San Francisco this past week (July 9-10), the North American Information & Control Committee and its Task Forces met to continue SEMI standards development. Here is a brief summary of the proceedings.

The GEM 300 task force, in addition to reapproving E90, also approved minor title changes to the E39, E39.1, E40 and E40.1 standards. Each SEMI standard must be revised or reapproved to avoid becoming inactive. A few years ago, SEMI changed regulations that mandate that each standard declare its classification, such as a “guide” or “specification”. Since then the task force has been slowly correcting the titles. The E37.1 standard is in the middle of such classification, but has been riddled with reapproval complications due to minor concerns and some needed corrections in the standard. The ballot to make these corrections, 6349, failed for the second time at SEMICON West. The ballot will be slightly reworked and resubmitted for another round of voting. Another ballot, 6348 proposed to clean up the GEM E30 standard, to improve its readability and to bring the standard in conformance with current SEMI regulations and its current style guide. The forefront of the discussions was surrounding the confusing use of acronyms DVNAME, DVVAL, SVV and other such acronyms where the meaning and use of the acronyms was confusing to new readers. The 6348 ballot also failed, but hopefully the task force is progressing towards reaching an agreement. One major challenge is that ballot 6348 is a major revision ballot, where the entire specification is opened up for review and scrutiny, as opposed to line item ballots where only specific sections of a standard are modified.

Finally, and most exciting is ballot 6114B; a revision to the SECS-II E5 standard. The ballot proposed a set of new messages for transferring any large items between a host and equipment. Typically, one item in a message is limited to about 16.7 MB. The new messages are specifically targeting the transfer of equipment recipes, but the messages are written generic enough so that anything else can be transferred, too. The new messages support two styles of item transfer. Either the item can be transmitted in a single message, or broken into parts for transfer with the expectation to be concatenated by the recipient. Or the item can be transmitted in multiple messages, broken into parts with each part sent in a separate message and the same expectation to be concatenated by the recipient. An item is identified by its “type”, “id” and “version”. The messages are intended to resolve current issues with recipes where some equipment suppliers are using recipes that surpass 16.7 MB. And the messages open the door to be used by other SEMI standards and to be customized for specific applications. After passing this ballot, the task force intends to make the messages part of the GEM standard. Even though the ballot 6348 failed, the task force seems to have finally reached consensus on the message formats and continues to work out minor details.

The DDA Task Force continues to work on the next version of the Equipment Data Acquisition (EDA) standards. In the latest cycle of voting, changes were proposed to E138 (ballot 6336), E134 (ballot 6335) and E132 (ballot 6337). Although one part of E134 passed, most of E134 failed and the other ballots failed. All of the failed ballots will be reworked and resubmitted for voting. Additionally, during the task force meeting additional proposed changes were reviewed and discussed. The task force continues to make plans to move from HTTP 1.1 and SOAP/XML to HTTP 2.0 and Protocol Buffers. Specifically, the plan is to recommend using gRPC. Testing done to date indicated an 18 times performance improvement and significant bandwidth reduction. The task force also discussed changes to simplify the equipment model metadata handling. Finally, Cimetrix proposed the implementation of a new method of data sampling designed for higher data collection frequencies. The current trace data collection messages, while very effective for speeds up to maybe 80 Hz, become inefficient when trying to collect data at even faster rates. The concept is called a “cached data sample” where the equipment collects the data at a specified frequency and then reports the data in an array syntax. When using HTTP 2.0 and Protocol Buffers, this will be an especially efficient format expected to allow much higher frequencies.

The client specifies the data collection frequency as well as the reporting frequency. For example, a client might specify a frequency of 10 kHz and a reporting frequency of 1 s, where 10,000 data samples would be reported each second. Such proposal if accepted, combined with the faster Protocol Buffer, will open the door for a number of new data collection applications.

A lot of people are wondering when EDA freeze III will be done. Probably not until late next year. How soon this happens mostly depends on how efficiently task force members provide feedback on the ballot drafts.

Subscribe to our blog in the upper right corner of this page to be sure not to miss that or any of my future updates on the North American Information & Control Committee.

The SEMI North American Information & Control Committee meetings were held in Milpitas, CA at SEMI headquarters. The following activities might be important for Cimetrix customers and employees.

By far, the longest discussion was surrounding the biggest decision of all. Currently, the EDA standards are using HTTP/1.1 for message transfer and SOAP/XML for message body. This means that the EDA standards are text based. At the time of EDA development, this seemed to be the best internet technology for data collection. Today, HTTP/1.1 is out of date. More recently, advances have been made in internet technology for sharing data in a binary format. The biggest advantage of transferring data in a binary message format is message efficiency. A binary message generally will be about 15 to 20 times smaller than text based messaging. This means less load on the equipment that publishes EDA data, much less load on the network and less load on the subscribing EDA clients. Many alternatives were discussed including WebSockets, HTTP/2, and even HSMS. It was discussed whether to stick with a text based protocol and use compression or move to a binary protocol. Data was presented from a DDA Task Force member regarding a performance comparison between HTTP/1.1 with text messages (like EDA today), HTTP with binary messages, HTTP/2 with SSL, WebSockets with binary messages and WebSockets with SSL. The test results showed binary messaging to be allow 25 times more data collection than the current HTTP/1.1 technology. Ultimately, it was decided that moving to a binary protocol was the right strategic direction.

Another point of discussion was how to implement binary messaging. Google has developed the Protocol Buffer technology. Specifically, we looked at version 3 called “proto3” which defines a notation for establishing binary messages. They have also published open source code gRPC in various software programming languages that implement the binary encoding and decoding for the Protocol Buffer technology and HTTP/2. This seems to be today’s best technology for binary web services. The DDA Task Force is in the process of developing a ballot to propose the adoption of this technology for the EDA messages. If approved, this would be the foundation of freeze 3 communication and a vast improvement.

In Japan, the Information & Control Committee recently created a DDA task force. The leader, Mitch Sakamoto from company ZAMA is coordinating with the North American DDA task force. Similarly, the DDA task force leaders in Korea are also working closely with North America. The Freeze 3 EDA development really is emerging as a worldwide coordinated development. The world-wide cooperation and coordination is much stronger and cohesive than the development was for Freeze 1 and Freeze 2.

The GEM 300 task force passed a ballot approving the use of SECS Message Notation (SMN) for GEM implementations. SMN could already be used anyway, but adding this to the GEM standard makes its use more official. This means that messages can be logged and documented using SMN.

The GUI task force continues to move along with planned improvements for the E95 standard. This including modernizing the graphics in the standard, updating the text and most importantly having the standard include the adoption of small screen devices as an equipment HMI. The new E95 standard will be a major revision standard.

In Korea, several ballots continue to be developed and reworked. This includes an update to the E87 carrier management services standard to allow more precise reporting when carrier approach the completion state. This includes an update to the E142 wafer map handling standard with new features in the schema file. Additionally, they are working on an equipment generic counter standard, which establish standardized methods for equipment to “count” things that happen on the equipment. This proposed specification is a favorite of mine personally. It is a clever way to recognize that it is important to count things on every equipment such as the number of times a vacuum has a been cycled, the number of times a nozzle has been used, the number of times a user has logged in, the number of times a robot has moved a substrate, the number of times an equipment has been restarted. It could be anything and it could be very different on two types of equipment. Collecting such data in a generic, natural way facilitates predictive maintenance; a key to minimizing factory equipment downtime.

SEMI held the spring 2017 North American standards meetings during the week of April 3 at the new SEMI facility in Milpitas, CA. The new facility had only been occupied for a few weeks prior, yet SEMI was able to hold the meetings with few technical difficulties. The new facility is quite attractive with improved accommodations for standards meetings.

There is a lot of activity currently, in the two task forces that I lead; namely the GEM 300 task force and DDA task force.

Every five years SEMI re-approves every active standard. Without renewal, the standards become “inactive”. During the Information & Control Committee (I&CC) meeting a few standards were re-approved this cycle with a few editorial changes including:

• Ballot 6066A: E130 (Specification for Prober Specific Equipment Model for 300 mm Environment) and E130.1 (Specification for SECS-II Protocol for Prober Specific Equipment Model for 300 mm Environment) 
• Ballot 6068A: E116 (Specification for Equipment Performance Tracking) and E116.1 (Specification for SECS-II Protocol for Equipment Performance Tracking)
• Ballot 6064A: E121 (Guide for Style and Usage of XML for Semiconductor Manufacturing Applications)

Additionally, during the Information & Control Committee (I&CC) meeting, the following ballots were passed which make changes to standard:

• Ballot 5549A: E30 (Generic Model for Communications and Control of Manufacturing Equipment) with the following changes to the GEM standard
  • The title was changed to “Specification for the Generic Model for Communications and Control of Manufacturing Equipment”
  • The initial sections were reorganized to have sections Purpose, Scope, and Limitations which results in renumbering all following sections
  • The Application Notes were renamed Related Information
  • Equipment Constant “EnableSpooling” was added to the Variable Item List.
• Ballot 5738: E87.1 (Specification for SECS-II Protocol for Carrier Management)
  • Title was changed to remove the provisional status. All other references to provisional status were removed.
  • Numerous editorial changes were made for clarity, misspellings, incorrect references
  • Format codes were clarified for consistency
  • The only “technical” change was to allow for up to 255 slots in a carrier for attribute “Capacity”. This makes E87.1 more consistent with E87 which does not restrict carrier capacity and with known existing implementations that have more than 25 slots in a carrier. 

Ballot 5872B, an update to the E172 Specification for SECS Equipment Data Dictionary (SEDD), failed to pass. This update adds numerous optional features to the SEDD file for documenting GEM interfaces in an XML file. With this update, GEM interfaces can be documented almost entirely in an XML file; virtually eliminating the need for the traditional GEM documentation. The most valuable addition is the list of supported SECS-II messages and the expected format for each message. By documenting GEM interfaces in an XML file, factories can write software to parse the SEDD file and automatically configure host software to adapt to an equipment’s GEM implementation. The GEM 300 task force expects this ballot to pass later this year after making a few small changes.

In the next SEMI voting cycle for North America, called “Cycle 5”, the GEM 300 task force plans to resubmit ballot 5872C to update the E172 SEDD.

Additionally, a new ballot 6114 will be submitted for vote. Ballot 6114 introduces a new set of SECS-II messages for transfer of large strings or binary data. The new messages are initially intended for transfer of large Recipe files to/from the host system. Currently, the typical stream 7 SECS-II messages are limited to 16.7 MB. With these new messages, recipes could theoretically be allowed up to about 4 GB. Additionally, the new messages could be used to transfer other types of large strings or binary streams. The new messages include a “type” field to indicate the type of object being transferred. For recipes, field will most likely be “SEMI:RECIPE”, but other types could be defined in other standards like “ProductionRecipe” for E170 or “SEDD” for E172.

In the DDA Task Force, more plans were discussed for the EDA Freeze 3. The Korea DDA Task Force leaders have committed to working with North America DDA Task Force in this effort and presented several ideas for changes. The most dramatic change they presented was to consider using WebSocket technology instead of HTTP in order to make the SOAP/XML messages perform much better by maintaining a socket connection.

The GUI task force has begun its work to revise the E95 standard. It is still a great time for new task force members to join and contribute.

The Japan GEM 300 task force have previously made some announcements concerning a GEM300A initiative to expand the traditional GEM 300 standards (E30, E37, E39, E40, E87, E90, E94) to also include newer standards developed in the Japan GEM 300 task force. Namely E170, E171 and E174. E174 has been very controversial. During the North American GEM 300 task force meeting, it was requested that if there be any initiatives to declare a GEM300A set, that this be a collaborative effort between the various GEM 300 task forces and also consider including E116, E148, E157, E172 and E173.

During the GEM 300 task force, a representative from the Japan GEM 300 task force presented some possible future ideas to have a separate GEM connection for recipe management, to ensure that data collection reporting is not hindered by the transfer of large recipes files.

 SEMI North America Information & Control Task Force and Committee fall meetings were last held at SEMI headquarters November 7 through 9, 2016. During these meetings, SEMI announced that they are relocating their headquarters to Milpitas, CA. That move is currently underway. In the GEM 300 task force, all of the ballots failed to pass. This include ballot 5872A, 5549, 6026, 6066, and 6068. In the DDA task force, ballot 6064 also failed.

Ballot 5872A is work driven by Cimetrix to complete to work initially proposed for the E172 standard SEDD files, a feature to enable an electronic format for GEM documentation. Ballot 5872A failed due to some minor issues. SEDD files already provide partial GEM interface documentation in an XML file by listing the data variables, status variables, equipment constants, collection events and alarms. The ballot proposes to enhance SEDD files by adding a list of supported SECS-II messages, remote commands, SEMI standards (with compliance tables), and default event reports. The ballot will be reworked and resubmitted as ballot 5872B.

 Ballot 5549A is a title change and organizational change to the GEM E30 standard. Several years ago, SEMI required all standards to have an official designation, such as Guide or Specification. E30 currently has a title that fails to establish an official standard designation. Additionally, the standard currently fails to have the mandatory sections “Purpose”, “Scope”, “Limitations” like other standards. The ballot was delayed several years due to the SML copyright claim by Peer Group and the ensuing legal confrontation with SEMI. The ballot was finally submitted in 2016 and failed because it renamed the Application Notes as an Appendix instead of “Related Information”. Additionally, there was some confusion because the ballot was based on the 0611 version of E30 rather than the 0416 version which had just been published. This ballot will be reworked and resubmitted as ballot 5549B.

 Ballots 6026, 6066, 6068 and 6024 are reapproval ballots for standards E109, E130/E130.1, E116/E116.1 and E121. SEMI automatically submits all standards for re-approval every five years if a standard has not been revised. These standards all failed due to outdated references. They will all be resubmitted in 2017 with minor changes to correct the outdated references.

 The new GUI task force was approved to create a new major revision of the E95 standard. In particular, the new revision will accommodate new software and hardware technology when laying out equipment user interfaces.

 Cimetrix proposed a new activity to define new SECS-II messages for transferring recipes. The activity will result in a new ballot 6614. Currently, the GEM standard defines two ways to transfer unformatted recipes. Using simple Stream 7 messages S7F3 and S7F6, the entire recipe is part of a single message. This makes is really easy to implement in the host and equipment GEM software, but recipes are limited to about 16.7 MB (the maximum size of a single data item in any SECS-II message). The second way is using the large recipe scenarios which involve using a sequence of messages S7F43/F44, S13F1/S13F2, S13F3/F4, S13F5/F6 (repeated iteratively until there is an error), S6F11/F12 and finally S13F7/F8. Even for an expert, this is very complicated. Ballot 6614 will propose simple new messages for transferring a large recipe using a single message where the recipe can be broken up into multiple parts where each part is up to 16.7 MB in size. If approved, another ballot will attempt to add this to GEM standard. This will open the door for the GEM standard to be used more effectively and in more application where the 16.7 MB limitation posed an issue.

 Japan Information & Control committee (I&CC) announced the official withdrawal of OBEM standards E98 and E98.1. Japan also announced a GEM300A initiative which includes standards E170 and E171 and E174. E170 is the Production Recipe Standard which allows equipment to designate production and non-production recipes; where production recipes are given change protection. E171 defines predictive carrier logistics. Ballot 5601 defines Wafer Job Management. It is not clear whether or not there any IC makers will demand any of these newer standards. Of the three, E170 seems to be most useful and interesting. Predictive carrier logistics seems to be useful only for equipment that have carrier internal buffers. It attempts to help the equipment report when carriers will be ready for removal. It is not clear how E171 will compete with the upcoming E87 ballot 4946 to be submitted by the Korean Information & Control Committee in 2017. Ballot 4946 modified the E87 standard to predict when carriers will be ready to unload. Wafer Job Management is a controversial standard. Japan I&CC announced the passing of ballot 5601 (now E174) despite the strong opposition by multiple knowledgeable voters in other regions, and despite very underwhelming support from regional leaders in North America, Korea, Europe and Taiwan.

 Korean Information & Control committee announced plans to submit ballot 5832, a proposal for a new Generic Counter standard which is built upon the GEM standard. The standard would allow an equipment to define various types of generic “counters” that can be reset by the host. The counters could be used a wide variety of applications; particularly predictive maintenance. The standard as defined in the current ballot defines digital counters, analog counters and collection event counters. Voting period for this ballot just ended recently.

 Next North American I&CC meetings will be held first week in April, 2017.

Interest in SEMI standard E30, known as the GEM standard has grown in recent years. That interest has increased in various manufacturing industries has matured in which factories are seeking to increase automation and carefully monitor equipment activity in order to increase production and product quality. Initially, the GEM standard targeted just the semiconductor industry, but then expanded to include any industry that used manufacturing equipment. In fact, a number of years ago the name of the GEM Standard changed from the “Generic Model for Communication and Control of Semiconductor Equipment” to “Generic Model for Communication and Control of Manufacturing Equipment.” Adoption by other industries is possible because the GEM standard defines generic features to control and monitor any manufacturing equipment. The GEM standard technology is not limited to semiconductor manufacturing. Over time, other industries have taken notice, especially as they try to develop increased control over their equipment.

CIMConnect™ is the best software product on the market for implementing the GEM standard. Of course CIMConnect supports all of the required GEM features as well as additional capabilities. This even includes excellent support of the Spooling feature, which saves messages that are otherwise dropped during a loss of communication. Early implementations of the GEM standard by others gave the GEM standard’s Spooling feature a bad reputation. This reputation is undeserved when Spooling is implemented by a robust product like CIMConnect. In CIMConnect, not only does Spooling work; it works well. It has been proven by customers that CIMConnect’s Spooling implementation does not lose any messages—even while under high-stress conditions. This means that when using CIMConnect, the Spooling feature can be used to effectively preserve critical data from the equipment.

Another feature that makes CIMConnect the best GEM software product is the CIMConnect Control Panel. In the new CIMConnect release, this application was completely rewritten, redesigned in .NET,  giving it a modern look and feel while adding lots of new convenient functionality. With other GEM products, the GEM interface is essentially a black box. With CIMConnect, however, the Control Panel application gives full visibility into the GEM interface. And you can run it at any time during GEM interface development and also during production. This means that you can see what reports and traces are defined, the link between reports and events, the status of all state machines, the state of each alarm, the enable status of every event, the history of occurring collection events, the history of alarm state changes and the current values of all data variables, and status variables and equipment constants. You can also view and capture the SECS-II message logging at any time for scenario diagnostics. Additionally, the CIMConnect Control Panel provides features to simulate the occurrence of collection events, collection event data, alarms, and variable data; thereby making it a built-in simulator included requiring no additional effort. And when you are ready to update your GEM documentation appendix with the list of defined collection events, alarms, status variables, data variables, and equipment constants, use the documentation builder feature.

CIMConnect has also already adopted use of new SEMI standard E173 Specification for XML SECS-II Message Notation (SMN). CIMConnect allows software applications to use SMN notation both when providing variable values to CIMConnect, as well as when getting variable values from CIMConnect. This means that you can pass data around in XML, retaining the data type and data structure information; bringing the convenience of XML into the SECS/GEM technology. You can log the GEM communication messages using SMN format making log messages much more useful, and they are able to be easily deserialized by any software applications that has XML libraries.

For additional detailed information about CIMConnect or to request a product demonstration, please contact us.♦

During the week of SEMICON West in San Francisco this past July, the North American Information & Control Committee met to discuss and consider new and pending standards within the industry. SEMATECH was noticeably absent from the sessions. For many years, SEMATECH has been a leader in developing and promoting the GEM 300 and EDA standards.

Here are the highlights from those meetings and how they will effect you.

The DDA Task Force is in the early stages of planning a Freeze 3 version of the EDA (Interface A) standards. This may cause some concern—especially with OEMs—as some are just now getting their Freeze 1 interfaces accepted in Fabs. Freeze 2 was a big step forward in making the standards clearer and easier to adopt, but it required a lot of work to move from Freeze 1 to Freeze 2. The hope is that the transition from Freeze 2 to Freeze 3 will be easier, but there will be doubt and concern among many OEMs.

One of the changes proposed for Freeze 3 is replacing the usage of SSL (HTTP) with WS-Security, an extension to SOAP and a member of the web services specifications published by OASIS. This extension allows for secure data within a SOAP message, while still using HTTP for data transfer. This is really an underlying issue and should not affect the applications that would interface with our CIMPortal Plus product. It would allow for a secure connection between CIMPortal and the Fab client so that the data transmitted is protected from theft. There would be configuration changes required to allow the secure connection to be defined, but—once it is—the actual interaction between the OEM’s application and CIMPortal Plus should not change.

Another change being considered is the implementation of WS-ReliableMessaging, another extension to SOAP and also a member of the web services specifications published by OASIS. WS-ReliableMessaging describes a protocol that allows SOAP messages to be reliably delivered between distributed applications in the presence of software component, system, or network failures. Just as the WS-Security item above, this would be at the protocol level, an “under-the-hood” change. It should not affect the way applications interact with our product, but should provide for a more reliable connection to the host EDA client. Use of this extension could also allow EDA to be used in more factory applications, where guaranteed data acquisition is required.

The final issue that was discussed relating to Freeze 3 was a new high-frequency trace for collecting data at very high speeds triggered for short periods of time where the collected data is sent at the end of the collection period. For example, a 1 ms trace for 5 seconds where the 5,000 collected samples for each parameter would be sent at the end of the 5 second period. This change might require alterations in our products. This will help the data reporting be more efficient. Rather than reporting small individual pieces of data to the EDA client, this will allow many data samples to be sent together making for more efficient use of the network.

The GEM 300 Task Force had three ballots on hold due to the ongoing SML copyright legal trial between SEMI and The PEER Group. However, work on other pending ballots continued. The first, Ballot 5872, proposes to add new features to the E172 SEDD standard. E172 is a new standard that provides an XML schema for documenting a GEM/GEM 300 interface. Eventually, E172 can completely replace the current GEM documentation requirements.

Recipe Integrity ballot 5618 has an uncertain future since ISMI failed to pursue its development; unfortunately, the ballot had seemed very close to completion. This standard says that it will not require changes to SECS II messages, but simply clarifies what parameters are defined and how the existing pieces work together. So, essentially, it would be a standard that tells you how to use other existing standards.

Finally, the Task Force discussed enhancing the GEM 300 standards to handle equipment that bond substrates and divide substrates. This will affect E90 and could affect E40, E87, and E94 as well. These changes would likely require updates to CIM300. Right now the standards just address how to treat equipment where the same material (substrates or wafers) go in and out. Traditional material tracking assumes one wafer in, get processed, then return to an output carrier. In the proposed case, either two wafers go in and one unit comes out, or one substrate goes in and two come out

The committee is scheduled to next meet in November, so you can plan on seeing another post from me on the outcome of those meetings afterwards. Subscribe to our blog in the upper right corner of this page to be sure not to miss that or any of my future updates on the North American Information & Control Committee.