Semiconductor Industry News, Trends, and Technology, and SEMI Standards Updates

Storing Data in a CCF application

Posted by Derek Lindsey: Product Manager on Mar 8, 2017 1:00:00 PM

In Sir Arthur Conon Doyle’s A Scandal in Bohemia, Sherlock Holmes tells Watson, “It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

In a March 2016 blog post on CCF work breakdown Cimetrix listed eleven points to be taken into consideration when starting an equipment control application using CIMControlFramework (CCF). One of the tasks in the work breakdown is to determine what kind of data collection and storage is to be used in your CCF application and determine how that data is to be stored.

User_Interface_Sm_CCF_1-5-17.jpg

CCF provides several mechanisms for collecting and storing data. These include:

  • History Objects

  • Full GEM Interface

  • Full EDA/Interface A Interface

  • Centralized DataServer

The remainder of this blog post will look at each of these items in more detail.

History Objects

In early iterations of CCF, users noticed when using logging, there were certain messages that they wanted to be able to query without the overhead of having to search all log messages. To help accommodate this need, History objects were introduced. Some examples of these objects in CCF are EPT History, Wafer History and Alarm History. When an important event happens in the life of a history object, a log message is written to a database table (configured during CCF installation) that corresponds to that type of object. That database table can be queried for the specific historical information for only that type of data. 

Full GEM/GEM 300 Interface

As described in a CCF blog post from February 15, 2017, CCF comes standard with a fully implemented GEM and GEM 300 interface. The GEM standards allow users to set up trace and event reports for the collection of GEM data. No additional programming is required by the application developer to have access to the GEM data collection.

Full EDA/Interface A Interface

The same blog post of February 15th also states that CCF comes standard with a fully implemented Freeze II and E164 compliant EDA interface. EDA can be used to set up data collection plans based on Events, Exceptions and Traces. With the E157 standard and conditional trace triggers, EDA makes it easy to zero in on the data you want without having to collect all data and then sift through it later.

Centralized DataServer

In order to create, initialize, populate and pass data, CCF uses a centralized DataServer object. The DataServer is responsible for creating the dynamic EDA equipment modelas well as populating CIMConnect with Status Variables, Data Variables, Collection Events and Alarms. All this is done at tool startup so that the data available exactly matches the tool that is in use.

Data is routed to the DataServer which then updates the appropriate client – such as EDA, GEM or the Operator Interface. An equipment control application can register to receive an event from the data server when data changes. Users can key off of this event to capture that data and route it to a database as desired. Since all tool manufacturers have different requirements for which database to use and how data is written to that database, CCF leaves the actual SQL (or equivalent) commands for writing the data to the equipment application developer.

With CCF Data collection and storage is … Elementary.

Topics: Interface A, CIMControlFramework, Equipment Control-Software Products, GEM Interface

CCF Provides Fully Implemented GEM300 and EDA Interfaces

Posted by Bill Grey: Distinguished Software Engineer on Feb 15, 2017 1:00:00 PM

What does this mean and why should I care?

The SEMI standards for 300mm Semiconductor Manufacturing Equipment can be an overwhelming burden of information to understand, let alone implement.

The GEM standards comprise over 450 pages of documentation: E4, E5, E30, E37, E37.1, E172, E173.

The 300mm standards add another 280 pages: E39, E40, E87, E90, E94, E116, E157, E148.

And the EDA standards pile on an additional 480 pages: E120, E125, E128, E132, E134, E138, E164.

That’s over 1200 pages of standards documents filled with requirements and implementation information. 

On top of that GEM and EDA collect data differently from the equipment.  See a post we did on data collection for more information on those differences.

Implementing the requirements defined in those standards without an SDK would be a very brave undertaking.  Even with SDKs for the standards, it would be a fair amount of work, when all you really want to do is get your equipment automated.

In addition, it is very important that those standards be implemented correctly in order for your equipment to be smoothly integrated and accepted into each fab.  Different fabs use the standards slightly differently or have additional requirements.   This requires experience.

GEM300 and EDA standards implementation is a very large burden.

semi standards difficult burden

So what does this mean?

One of the large tasks for the EDA standards is defining a hierarchical model of the equipment and what data it can produce in XML per the schemas defined in the standards.   Creating the initial model and keeping it up to date as the equipment evolves is a tedious task.  In addition, that model must be conformant to the E164 standard (which has over 10 pages of requirements on its own).   See our blog post on conformance testing. CCF does this for you, producing an E164 compliant EDA model in the background based on your CCF programming. See our blog post on CCF dynamic model creation further details.  CCF also builds the GEM interface model for you at the same time.

Further, CCF is completely GEM compliant and 300mm compliant, using the Cimetrix CIMConnect and CIM300 products which have been successfully deployed in every 300mm fab around the world on many different equipment types.

Twelve hundred pages of standards, compliantly implemented, at no additional effort.  That is what this means.

Turn that donkey into a goat and use CCF.

 

 

Topics: SECS/GEM, EDA, CIMControlFramework, GEM Interface

GEM 300 - All of This Chaos Makes Perfect Sense

Posted by Cimetrix on Jan 20, 2011 1:23:00 PM

by 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.”

 Joe Diffie resized 600

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.”

Topics: PV Standards, PV2 Standard, Semiconductor Industry, SEMI, GEM Interface

Revisiting SECS/GEM: The Other Side of the Wire

Posted by Cimetrix on Dec 6, 2010 2:49:00 PM

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.

IBM Fishkill Photo resized 600

 

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.

Topics: Equipment Data Acquisition, SECS/GEM, Semiconductor Industry, Interface A, GEM Interface

8 things to consider when implementing a GEM Interface

Posted by Cimetrix on Feb 9, 2010 7:57:00 AM

by Matt Mayer,
Principal Software Engineer, Global Services

GEM interface checklist

  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
  9. 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.

    You might also be interested in:

Topics: SEMI Standards, SECS/GEM, CIMConnect, GEM Interface

Subscribe to Email Updates

Follow Me

Learn More About the
SEMI Standards

SECS/GEM

GEM 300

Interface A/EDA

PV2 (PVECI)