Industry News, Trends and Technology, and Standards Updates

With the growing interest in the use of SEMI EDA/Interface A standards, we have been getting a great deal of requests for the difference between Interface A and SECS/GEM. 

For a quick comparison, here is a table to showing some of the differences between Interface A and SECS/GEM:

Additional Resources:

• SEC/GEM SEMI Standards
• Download the Cimetrix SECS/GEM Whitepaper
• EDA/Interface A SEMI Standards
• Dowload the Cimetrix EDA/Interface A SEMI Standards Whitepaper

by Rob Schreck
Marketing Manager

As we gear up for SEMICON West, we are encouraged by some good news in the industry after enduring the bleak news of autumn and winter. SEMI reports the North American semiconductor capital equipment industry book-to-bill was over 1.0 in February and March of this year (see Semiconductor Equipment Industry Book-to-Bill), and the PV equipment book-to-bill ratio is starting back up (see PV Manufacturing Equipment Book-to-Bill Increases from Record Low). With the good news comes more companies developing new equipment, drawing more attention to SEMI standards such as SECS/GEM and PV2 (PVECI).

Understanding the SEMI SECS/GEM and PV2 standards, and the impact to their product roadmaps, might seem a little daunting for many equipment suppliers. We have updated a white paper to provide some background, called Introduction to the SEMI Standards: Implementing GEM and PV2.

This paper highlights key elements and issues associated with GEM software projects to help guide users toward a successful implementation.

A GEM (E30) interface is implemented by the equipment manufacturer to enable the equipment and factory software (a.k.a. “host”) to communicate using SECS-II (E5) messages via Ethernet.

GEM standard compliance consists of fundamental requirements and additional capabilities, and compliance is only required for the equipment interface, not for the factory host software. Companies scale the GEM standard implementations to match the complexity of the equipment and the needs of the factory host software.

The GEM fundamental requirements include establishing communication with the factory host software, implementing a processing state machine, event notification, protocol error messages, and a GEM implementation document. Here is an example of such a document, and you can find a GEM compliance check list at Are You GEM Compliant?

GEM Compliance Statement

Much like how the GEM standard is a subset of the SECS-II standard with additional required features, the PV2 standard is a subset of the GEM standard with additional required features, which include:

• The required format to use for data items in the SECS-II messages
• A specific list of variables, equipment constants, and collection events
• A subset of SECS-II messages
• An implementation of SEMI E10 to report equipment states related to reliability, availability, and maintainability (RAM)
• An implementation of the Network Time Protocol (NTP)
• A statement of PV2 compliance

These PV2 requirements should make PV2-compliant equipment even easier than GEM to integrate with the factory host software.

By David Francis
Product Manager

I ran across an old issue of Future Fab International – Issue 6 – that I have had since it was published in 1998. I helped write an article that was published in this issue titled “Complete System Integration is Crucial to the Success of 300mm Manufacturing.” The article looked at changes that would be required in semiconductor manufacturing to support the move from 200mm wafers to 300mm wafers.

At the time, I was working for a software company that specialized in the development of Material Control Systems (MCS) for controlling Automated Material Handling Systems (AMHS). Most of the 200mm manufacturing facilities had implemented inter-bay transport systems that move material from one manufacturing bay to another, but within the bays, operators manually loaded wafers onto process or metrology equipment. Operators had to decide what work should be done next, or where the material should go after each process, after reviewing choices from a dispatch screen. There were islands of automation, but not much integration.

With the size, weight, and bulk of the 300mm carriers, transport systems would need to deliver material directly to the processing or metrology tool. This required very tight integration between the MCS, the dispatching system, and the factory Manufacturing Execution System (MES). In 1998 the GEM300 standards that would make all this possible had not been adopted very widely yet and were only starting to get semiconductor equipment suppliers’ attention.

This old article talked about the need for developing a reliable, low-footprint intra-bay transport system. It also explored the new concept of having the dispatch system make the decision about what work to do next rather than just suggesting what could be done. The MCS would need to interface with the dispatching system to be able to position material close to where it would be needed for processing.

The SEMI GEM 300 standards started gaining traction about the year 2000 and the idea of “lights out” manufacturing soon became a reality. It has been exciting to watch as the MES, dispatcher, AMHS and MCS systems have progressed and the fully automated, integrated manufacturing environment described in the article has become a reality.

While the move to 450mm wafers is probably still a few years off, I expect that transition will be much easier than the transition from 200mm to 300mm because of the work done for 300mm factories. The standards are well established, the control systems have matured, and the integration of the various components is very stable. It is exciting to see these future visions become common practice.

Recently, Cimetrix updated our Introduction to SEMI GEM 300 Standards white paper.  We have refreshed the content to answer some of the questions many people pose to us. Take a look and let us know what you think.

xby David Francis
Product Manager, Connectivity Products

Back in the 1990s, Joe Diffie released an album titled “Third Rock from the Sun.”  I have to admit I liked the title song, especially the chorus:

“Cause and effect, chain of events
All of the chaos makes perfect sense
When you're spinning round
Things come undone
Welcome to Earth 3rd rock from the Sun.”

At the time, I was working with Motorola in Austin developing host-side cell control applications for one of their new fabs.  Motorola had implemented some rudimentary equipment control and data collection in their older fabs, but the standards were loosely defined at that time and the equipment interfaces were inconsistent. We realized we could not replicate the work implemented in the old fabs into the new fabs, yet we did not have solid standards to use for the new fabs.  As the song said, we were “spinning round” in this chaos.

What eventually drove more clarification in the GEM/GEM300 standards was the industry-wide push to move to fully automated 300mm IC manufacturing.  The larger wafers offer much greater productivity and throughput, with significantly lower cost per die, and SEMI wanted to ensure the industry had a well-understood and approved interface standard for the equipment used to manufacture semiconductors on these much larger wafers.  Those new standards made it easier and more cost effective to create the host-side cell control applications.  Now the chaos started to “make perfect sense.”

Embracing the GEM/GEM300 standards allowed IC manufacturers to purchase standard software components to analyze manufacturing processes and identify opportunities to increase productivity.  In other words, they wanted to bring order to all the chaos.  The alternative – developing their own data analysis applications for each fab – would have been very expensive and time consuming.  SEMI brought order to the scene by offering the GEM/GEM300 standards that all the equipment vendors and fabs could use.  Now OEMs could develop equipment needed for automated wafer processing with the confidence fabs could install the machines and link them to their networks.  Fabs could increase throughput and drive down cost per die, and, just as important, gather data necessary to increase manufacturing efficiencies even more.

Fast forward twenty years, and we see a very similar situation, this time caused by the impressive growth in Photovoltaic cell and LED manufacturing.  The fabs in those industries need more advanced equipment to increase throughput and drive down unit costs in order to meet demand.  However, up to this date, both sectors are reluctant to adopt the GEM standards.  They are concerned those standards may be too big and complex for their processes, which are simpler than the current state-of-the-art semiconductor fab processes.  Once again, we see the chaos that occurs with explosive growth and companies seeking a solution to bring order to their processes.

Since I’ve seen this story before - and heard the music played time and time again - I know that adopting communication standards will help PV and LED manufacturers continue their drive to reduce unit costs and drive demand.  The effort is underway in the PV sector with the PV2 standard.  The LED sector should also look to adopt existing standards, or do what the PV sector has done and develop their own standards.  Either way, we know that standards help all the “chaos make perfect sense.”

By: Bill Grey
Director of R&D, Cimetrix Inc.

One of the hurdles people new to the semiconductor equipment industry need to overcome is learn how to establish a physical connection between the fab network and new equipment.  To help people, we have developed a primer to provide the foundation for how to do that.

The primer provides a background for SECS/GEM communication over HSMS by describing how to configure the connections, the terminology involved, troubleshooting, and common messages.

In a factory SECS/GEM implementation, there are two parties, the host, and equipment.  The equipment runs GEM interface software, which must implement and comply with the SEMI standards, on one of its computers.  The manufacturer (factory) runs GEM host software that establishes communication with the equipment's GEM interface.

The SECS Messaging Primer is a companion to the Introduction to the SECS/GEM standard white paper available on the Cimetrix SEMI Standards web page.  That white paper provides an overview of the SEMI SECS/GEM standard. 

by David Francis
Product Manager

Many years ago, I had the opportunity to work with some large semiconductor companies, including, Intel, Motorola, Lucent, and Siltronic.  I developed interface acceptance tests for equipment they purchased.  At that time, the SEMI SECS/GEM standards were still new and not widely adopted.  Many of the tool vendors had little or no previous experience writing SECS/GEM interfaces, and they were often uncertain about the details of the standards, along with worrying about how they could comply with them.  Chief among the vendors’ concerns was how they could meet their design schedules without loading down their engineering teams with this new requirement placed upon them. 

Over the intervening years I worked in the scheduling and dispatching area of automated semiconductor manufacturing, and in that time I lost track of the SECS/GEM standards and their adoption by the wafer fabs.

Recently I joined Cimetrix as Product Manager for the connectivity and tool automation products, and now I am back in the world of SECS/GEM standards.  A lot has changed since those early years, as fabs moved from 200mm to 300mm, and now considering 450mm wafer fabrication.  In addition, the geometries have shrunk from 1 micron down to 40nm and below.  However, I still see many of the same industry concerns as I did many years ago, even though there has been little change to the SECS/GEM standards.

The real change I see is the wide spread adoption of the SECS/GEM standard.  Previously, only a few leading edge companies requested SECS/GEM interfaces on their tools and were working feverishly to set up host-side equipment controls.  Today, SECS/GEM is well rooted in 300mm semiconductor manufacturing and tool vendors have very mature automation interfaces.

The move to 300mm processing created an ideal opportunity for the development and adoption of the GEM300 standards. Building new 300mm tools created an ideal environment for designing in the GEM300 standards right from the start.

More recently, new standards, like Interface A, have emerged from their R&D phase and are now going through the same refining process that SECS/GEM went through a decade ago.  These new standards will continue to support the industry’s efforts to create more efficient devices, at ever-decreasing geometries, with increased reliability and yield quality.

It is exciting to be working with these standards again and looking at them from the other end of the wire – the tool-side as opposed to my previous fab-side experience.  I look forward to writing more about how the tool vendors are adopting, and demonstrating compliance, to the new standards.

The semiconductor industry's largest event of the year, SEMICON West, is right around the corner.  And with the market in recovery, we expect it to be a good turn out and a great show.

This year, Cimetrix has several exciting new developments to discuss at the show:

• GEM Implementation - Faster & Better
  We've been at work developing a new solution that enables an even faster GEM implementation... while still improving the already high level of quality you've come to expect from Cimetrix. Designed to cover 90% of typical GEM interfaces, the new solution helps reduce time to market (and headaches) for our customers.
• The Year for Interface A - Are you Ready?
  ISMI announced the new Freeze Version of the Interface A Standards on June 17. Also, with increased SEMI investment and fabs requiring implementation, this has quickly become a hot topic. Is your software able to support multiple versions of the Interface A standard at the same time? Are you set up to adopt the new version effectively and efficiently?

We would love the opportunity to discuss your unique needs and projects with you further at the show.

Not registered for the show?  Email us for a free pass.

We will be in the South Hall - Booth #2331.

See you at the show!

by Matt Mayer,
Principal Software Engineer, Global Services

1. Establishing Communication- A standardized communications mechanism ensures both equipment and host have agreed, and all requirements necessary for properly collaborating data (between tool and host) based on the SEMI® SECS messaging standards (E5) are compatible during the connected status and after connection could have been disrupted.

2. Spooling- Spooling is an essential part of keeping synchronization with the tool. Communications (connect status) can be disrupted. In the event of communication disruption, the tool can be configured to spool collection event (S6F11) messages after communications has been restored and the host requests the last know transactions for the lost time span.

   Spooling can be configured to retain a SECS message pooled history of almost any stream and function (SEMI E5 standard). With this enriched functional capability, any condition of the tool can be relayed at anytime after communication has been re-established (e.g.: alarms, events, processing state changes, etc…).

   With that said about spooling, the host is required to take special care of the data received and re-act to the latest available data (spooled messages) in the most appropriate manner. In many cases, this behavior of the host takes special care at documentation and tool manufacturer collaboration.

3. Alarm Handling- The alarm handling capability provides for host with notifications and management of alarm conditions occurring on the equipment. Typically an alarm is associated with abnormal conditions of the equipment.

   With each alarm a correlating set/clear event notification will be issued to the host. As with each event definition, a report can be defined and linked in order to associate variable data specific to the alarm (see Event Handling).

4. Event Handling- Event handling provides a dynamic and flexible method for the tool manufacturer to customize the equipment to meet needs specified by the fabrication facilities with respect to data representation and presentation to the host. The event based approach to data collection provides automatic notification to the host and its activities which are useful in monitoring the equipment and in maintaining synchronization with the equipment.

   Reports can be configured by the host application and attached to event report messages (S6F11). These reports are linked to the desired event and are typically associated with variable data relating to the event generated by the equipment.

5. Variable Handling- The variable handling capability provide both the tool and equipment the ability to share details. Variables are categorized in three groups.

   Groups:

   • Equipment Constants, provides the capability for the host to read and change the value of selected variables of type EC which allow the host to reconfigure the variety of equipment functionality.
   • Status data, the values of a status variable will be current.
   • Discrete data, the values of DVs are only guaranteed to be valid at the occurrence of a collection event.

6. Process State Model Handling- The processing state model is dependent on the equipment process and technology. However, there are expected common aspects to these models. Many of these equipments use the GEM proposed state model with some variations. An ERROR and MANUAL state can be utilized during initialization and when the state is idle.

   Based on the SEMI E30 standard, the equipment must generate collection events for each processing state transition, as well as provide status variables (ProcessState, PreviousProcessState) which values represent the current processing state and the previous processing state. Other collection event reports can be defined and linked to event triggers.

7. Remote Command Handling- The capability which provides the host with control over the equipment and its operations. A remote command consists of parameter name/value pair with a particular host command (S2F41). The equipment manufacturer will provide unique names for any supported command parameters. The command parameters are defined by fabrication facilities and equipment manufacturers.

   A typical set of remote commands are listed below. However, the list is not a constraint and any set of remote commands can be specified and used.

   • PPSELECT
   • START
   • STOP
   • PAUSE
   • ABORT

8. Recipe Upload/Download Handling- Recipe handling provides the means for transferring process (recipe) information between the host and the equipment. The specifications for equipment processing (e.g. recipes) are managed through SECS messages (E5). Recipe uploading and downloading will be accomplished using several formats and combination thereof.

   Formats:

   • Unformatted recipe content
   • Formatted recipe content
   • Value based content transfer
   • File based content transfer

In addition to the above mentioned considerations, Cimetrix's CIMConnect, an object-oriented software development kit for equipment suppliers to quickly develop a GEM interface, also allows for multi-host connections.

by Brian Rubow,
Principal Engineer

He Said…No I Didn’t
I have a lot of children—seven. Many of them are still young. Sure it is a lot of fun. However, more often than I like (yet not terribly often since I have really good kids), I get caught in the middle of a “he said/no I didn’t” dispute. That is where one of my children shows up in a huff to wherever I am and reports what “he said”, he meaning another one of my children. Then in the background I’ll hear the other one say either the “no I didn’t’ or the “but that’s because he said” response. And both kids look at me and expect the impartial judge (a.k.a. me) to do something. Each of them will give the impression of complete honesty and full recollection, yet they cannot agree about what happened or about what the other said.

My preference is to make them work it out. Still, I can’t help but wish that I could have recorded what actually happened so that if one of them is being a poop I can apply fair discipline. It would be really nice to attach a recording device to each of my children 24/7 to see what really happens. Would that be considered cruel or responsible parenting? Probably depends on whether you are the parent or child.

At Cimetrix, we deal with similar situations working with SECS/GEM communication. Sometimes either the host or equipment reports a problem. The host software says “the equipment said” and the equipment software says “but the host said”. And both look to an expert like me and want a resolution.

Often the best way to resolve the problem is to look at communication log files. Often enough when such problems occur the first time, neither the host nor the equipment was logging the SECS/GEM communication. Sometimes turning on communication logging in the host or equipment is more difficult than it should be. In a few cases, the host or equipment logging might not be trustworthy. The best solution is an impartial judge that records what both the host and equipment are saying so as to not rely on the host or equipment software.

But can that be done? The answer is yes. There is a free product called WireShark available on the internet at http://www.wireshark.org/. It is a network protocol analyzer, also called a “network sniffer”. It is really cool because it can capture all messages sent by the host and by the equipment without any modification to the host or equipment. Just configure it and run the problem scenario again.

Only it is not quite that easy. One problem is that WireShark does not have a plug-in to interpret the binary SECS/GEM message format (HSMS). If you are a SECS/GEM/HSMS guru that can readily and quickly interpret SECS/GEM messages in hexadecimal format, then this is a minor inconvenience. But for most of us that are too busy for such a tedious task, this is a major problem that makes WireShark impractical.

Fortunately, Cimetrix has a new product to resolve this, CIMSniffer. Under the hood, it uses the same network capturing libraries as WireShark, yet it has the capability to convert the messages into human readable SML formatted messages. You don’t have to wonder exactly what “the equipment said” or what “the host said”. You can record what they said yourself using a third-party software application. I wish I had this years ago. Too bad it won’t work with my kids.

For more information regarding the CIMSniffer product, please email sales@cimetrix.com.

You might also be interested in:

• Download the white paper on the SECS/GEM standards

by Vladimir Chumakov,
Software Engineer

HSMS or High-Speed SECS Message Services is a messaging protocol used in semiconductor and other industries as means for connecting to, controlling and gathering data from equipment inside the factory. HSMS provides means for independent manufacturers to produce implementations which can be connected and interoperate without requiring specific knowledge of one another.