Industry News, Trends and Technology, and Standards Updates

Semiconductor Backend Processes: Additional SEMI Standards Related to GEM

Posted by Brian Rubow: Director of Solutions Engineering on Jul 9, 2020 11:30:00 AM

Background

In a few previous blogs I shared how the relatively new SEMI Advanced Backend Factory Integration (ABFI) task force in North America has already decided to promote the adoption of the GEM standard and selective adoption of the GEM300 equipment communication standards. In this blog I will summarize the task force’s plans to consider adoption of additional SEMI information and control standards that are complementary to GEM and GEM300.

Additional SEMI Standards for the Backend Consideration

Many of the standards listed below were developed a few years after GEM300 but are now considered to be part of the modern GEM300 set.

SEMI Designation

Standard Name

E84

Specification for Enhanced Carrier Handoff Parallel I/O Interface

E116

Specification for Equipment Performance Tracking

E116.1

Specification for SECS-II Protocol for Equipment Performance Tracking (EPT)

E142

Specification for Substrate Mapping

E142.1

Specification for XML Schema for Substrate Mapping

E142.2

Specification for SECS-II Protocol for Substrate Mapping

E148

Specification for Time Synchronization and Definition of the TS-Clock Object

E157

Specification for Module Process Tracking

E172

Specification for SECS Equipment Data Dictionary (SEDD)

E173

Specification for XML SECS-II Message Notation (SMN)

 

E84 Carrier Handoff

E84 Carrier Handoff is the only standard in this list that not a GEM standard because it deals with a separate parallel I/O interface. This interface is completely independent of GEM, although it is coordinated with E87 Carrier Management when both are supported. However, since E84 Carrier Handoff is often included in the GEM300 discussions and requirements, it is worth discussing here because it is a standard that the Backend industry should selectively adopt.

GEM-Backend-2-1

The E84 standard defines the handshake signals for use in a parallel I/O (PIO) interface to automate carrier delivery and carrier removal. The automated material handling system (AMHS) might use either an automated guided vehicle (AGV) or overhead transport (OHT) system, yet either way, the material is delivered in a carrier. E84 is widely used and accepted in every semiconductor wafer fab (front end) and an obvious choice for backend manufacturing when delivering carriers.

E116 Specification for Equipment Performance Tracking

E116 Equipment Performance Tracking was discussed in an earlier blog since there are plans to update this specification to better support backend operations. E116 is applicable to any manufacturing equipment in any industry because it is largely based on SEMI E10 principles which define generic terms for measuring any equipment’s reliability, availability and maintainability. As a bonus, each major component in the equipment can also be modelled to track its productivity.

E142 Specification for Substrate Mapping

E142 Substrate Mapping and its subordinate standards (E142.1 XML Schema for Substrate Mapping and E142.2 SECS-II Protocol for Substrate Mapping) define generic substrate maps and how to transfer them to and from an equipment through a GEM interface. Substrate maps are two dimensional arrays of data that correspond to a physical substrate—which may be a wafer, strip or tray. The map defines the dimensions of the substrate, significant locations on the substrate, and can include data about the locations (such as a numbering scheme for unambiguously identifying specific locations). For example, E142 can be used to tag “known good” devices on a substrate.

Some equipment types require a substrate map before processing can proceed. Some equipment can generate substrate maps. And some equipment both require a substrate map before processing and generate an updated substrate map after processing is completed. In E142, the substrate map is expressed in an XML file that conforms with the E142 XML schema. A lot of backend equipment need substrate maps for normal operation, so E142 is an obvious choice. Note that E142 is currently undergoing some interesting improvements via the ABFI task force to store additional data needed to address enhanced traceability requirements.

Substrate mapping is an excellent demonstration of horizontal communication implemented using GEM. Horizontal communication is when data is shared directly from one equipment to another equipment. Traditionally, horizontal communication in GEM is implemented indirectly; one equipment passes data to the host and then the host passes that data on to the equipment that needs it. In this sense, the GEM host acts as a type of broker between units of equipment.

There are significant advantages in using this indirect style of horizontal communication. For example, Equipment A might inspect a substrate, generate a substrate map and send it to the host. Equipment B might later request the substrate map from the host.

GEM-backend-2-2The benefit of using a GEM host between the equipment to realize this use case is that both Equipment A and Equipment B are only required to implement GEM—which they should be doing anyway. The equipment are not required to support additional protocols and/or custom message sequences, or to be tested against specific equipment interfaces. If each equipment follows the GEM standard, they can all be integrated into the factory system and share data through the GEM host.

E148 Specification for Time Synchronization and Definition of the TS-Clock Object

A lot of data collected in the factory is only useful when properly timestamped. Moreover, timestamps can only be compared among data from multiple sources when those timestamps are synchronized. This is where SEMI E148 enters the picture.

The E148 Time Synchronization specification requires equipment to support the industry standard Network Time Protocol (NTP) and share information about its implementation. And NTP software synchronizes computer clocks.

Because the backend industry segment is trending towards more and more data collection, it is critical to have proper timestamping for that data, and therefore time synchronization for its sources. A full E148 implementation may not be required, but certainly the equipment should support NTP as described in E148. If an equipment control systems is composed of multiple computers, E148 states that they should all be synchronized with a single computer designated as the master, which is a good idea if the other computers are generating data with timestamps.

E157 Specification for Module Process Tracking

E157 Module Process Tracking does not apply to all backend equipment. To use E157 Module Process Tracking, there must be at least one process module (aka a process chamber) which processes one substrate or a batch of material at a time. If multiple substrates are processed at a time but each having different start and stop times, then this specification cannot be applied.

E157 Module Process Tracking defines a very simple processing state model which is implemented independently for each process chamber.

GEM-backend-2-3The state model reports when the process chamber is either idle (Not Executing) or processing a recipe (Executing). And when processing a recipe, each time an individual step in the recipe starts, completes, or fails, this is reported. It is up to the implementer to decide what constitutes a recipe step. In my experience, most equipment that could adopt E157 have already implemented something very similar using a set of GEM events. However, rather than implementing something custom, it is better for end users and equipment manufacturers alike if the implementations are standardized.

E157 is a prime example of an exceptionally simple and well-written standard built on top of GEM technology that is easy to implement and provides a lot of end user value. Hopefully the ABFI task force can develop something based on E157 principles that is well suited for backend equipment that cannot accommodate the full scope of the current standard.

E172 Specification for SECS Equipment Data Dictionary (SEDD)

Go back in time (not that far, actually), and “GEM documentation” meant a stack of printed documentation on paper that was expected to be delivered with the equipment. Today “GEM documentation” means an MS Word document, PDF file, Excel spreadsheet, or some other electronic representation of the same information. Nearly any digital format is acceptable.

Nevertheless, E172 SECS Equipment Data Dictionary is the future of GEM documentation. The GEM documentation is provided in a standardized electronic XML format called an SEDD file. E172 defines a standard XML schema. The initial version of this schema included only basic information about a GEM interface. This was expanded in a later version to include several more details. Soon, I hope to report that the E30 GEM standard has been modified to officially include SEDD files as one form of documentation. Additionally, this should include enhancing the GEM standard to allow an SEDD file to be transferred directly through the GEM interface. This will significantly improve GEM’s plug-and-play capability by enabling factory host software to consume an SEDD file and automatically configure the GEM host software to support an equipment’s specific implementation of GEM and GEM messages.

As the backend industry segment is increasingly implementing GEM in its factories, I expect SEDD files to be required from all backend equipment manufacturers.

E173 Specification for XML SECS-II Message Notation (SMN)

In order to diagnose problems in a GEM interface, it is essential to have logging for the GEM messages transferred between the host and equipment. Typically, both the GEM host and equipment’s GEM interface will provide logging functionality. In the past, a notation called SML (SECS Message Language) was used for logging GEM messages. Unfortunately, SML was never standardized or even sufficiently well defined. As result, there are many different variations of SML throughout the world. While SML notation itself is relatively easy to generate with software, the breadth of implementation variations makes it difficult to automatically parse and use.

Fortunately, the SEMI North America GEM300 task force created E173 XML SECS-II Message Notation (SMN) to solve this problem. SMN defines an XML schema that anyone can use to document and log GEM SECS-II messages. The schema is feature rich allowing for both minimum and elaborate XML decoration. As an example of its usefulness and flexibility, the E172 SEDD schema references the SMN schema file. Because SMN is based on XML, it is both very easy for software to generate and consume. There are numerous software tools and libraries available in virtually every software programming language for working with XML. Using SMN with GEM allows GEM to continue to send and receive messages in an efficient binary format, yet still enjoy the benefits of using a decorated, human-readable text notation for diagnosing issues.

I expect the ABFI task force to recommend that the backend industry segment adopt SMN in all equipment GEM interfaces.

Conclusion

As backend factories adopt GEM, we expect that they will also want to use the latest technologies with it, including SMN, SEDD, Module Process Tracking and Equipment Performance Tracking. Watch for more details and updates from the SEMI Advanced Backend Factory Integration task force as its work progresses—and feel free to join this initiative if you want to help steer and accelerate this activity!

To download the GEM300 White Paper, click the button below.

GEM300

 

Topics: Industry Highlights, Equipment Control-Software Products, Doing Business with Cimetrix, Cimetrix Company Culture, Meet Our Team, GEM300

Semiconductor Back End Processes: Selective GEM300 Adoption

Posted by Brian Rubow: Director of Solutions Engineering on Jun 24, 2020 11:15:00 AM

GEM and GEM300 Adoption

In a previous blog I shared how the relatively new SEMI task force in North America called “Advanced Back End Factory Integration” (ABFI) has already decided to promote the adoption of the GEM standard. In this blog I will explain how the task force is also planning to selectively adopt what is often called the GEM300 set of standards. I say “planning” because this is a work in progress and subject to the standardization process in which we strive for consensus among the participants. However, one can argue that this plan should not be particularly controversial since the GEM300 standards have already been adopted by several major manufacturers of semiconductor back end equipment.

What are the GEM300 Standards?

There is no official “GEM300” definition, but at a minimum, all the experts agree that the GEM300 set of SEMI standards includes the following:

SEMI Designation

Standard Name

E5

Specification for SEMI Equipment Communications Standard 2 Message Content (SECS-II)

E30

Specification for the Generic Model for Communications and Control of Manufacturing Equipment (GEM)

E37

Specification for High-Speed SECS Message Services (HSMS) Generic Services

E37.1

Specification for High-Speed SECS Message Services Single Selected-Session Mode (HSMS-SS)

E39

Object Services Standard: Concepts, Behavior, and Services

E39.1

SECS-II Protocol for Object Services Standard (OSS)

E40

Standard for Processing Management

E40.1

Specification for SECS-II Support for Processing Management

E87

Specification for Carrier Management (CMS)

E87.1

Specification for SECS-II Protocol for Carrier Management (CMS)

E90

Specification for Substrate Tracking

E90.1

Specification for SECS-II Protocol for Substrate Tracking

E94

Specification for Control Job Management

E94.1

Specification for SECS-II Protocol for Control Job Management (CJM)

 

Seen together like this in a table, it seems like a lot to study and learn. And it is daunting. However, it is important to remember that most of the primary standards (like E87 and E90) also have a subordinate standard (like E87.1 and E90.1) that defines how to implement the standard using SECS-II. Although this nearly doubles the length of the list, these “.1” standards are really just extensions of the primary standard, and are all relatively short specifications. Each of these core GEM300 standards defines specifically how to use and augment the GEM standard to implement specific factory automation requirements and production operational scenarios. Basically, they work together like this:

GEM-for-Backend-2.1

SEMI E37 (High-Speed SECS Messaging Services), E5 (SECS-II) and E30 (GEM) are the core standards for any modern GEM implementation—regardless of the GEM300 additions—so of course they apply. Each of the additional GEM300 standards builds on top of E30 and E5 to define general features for data collection, alarm handling, collection event reporting and the messaging library. For example, E87 (Carrier Management) deals with the load port services, carrier delivery, and carrier removal. E90 (Substrate Tracking) reports all substrate movement from the carrier to the process chamber and any intermediate movement. E40 (Processing Management) and E94 (Control Job Management) determine which substrates to process, which recipes to use and the substrate destinations. Finally, E39 (Object Services) defines general object handling for all of the standards.

Even though the diagram shows silicon wafers—since semiconductor front end factories use this set of GEM300 standards nearly universally—their applicability goes well beyond 300mm silicon wafer processing. However, if an equipment does not deal with the substrates (material) or substrate delivery directly, then it is best just implementing GEM rather than GEM300.

How can these SEMI standards be applied to other equipment?

E87 Carrier Management

Certainly, any equipment dealing with a FOUP (front-opening universal pod) that holds silicon wafers can adopt E87 Carrier Management to manage the load ports and carrier validation. But E87 Carrier Management is written in a manner flexible enough that equipment handling many other types of material can adopt it. Here are the criteria:

    1. The material arrives in a container of some sort.

      The shape of the container, the number of slots in the container and the orientation of the slots do not matter. The container can be a rectangular tray with pockets. It can also be round with pockets. E87 Carrier Management refers to these containers as carriers.
    2. The material slots in the container can be ordered.

      In a FOUP, the material is in a horizontally stacked orientation. However, the principles of E87 Carrier Management can also apply to other material orientations. Whatever the container type, there needs to be clearly defined slot numbering. E87 Carrier Management only defines the order for a stacked container; therefore, other container styles need standardization.

With these two criteria, E87 Carrier Management can be applied to add value to the equipment by supporting an increased level of factory automation.

What features determine whether E87 Carrier Management can be adopted?

    1. Carrier (Container) ID

      If there is a carrier ID of some sort, it is of course very useful for implementing carrier ID verification. The carrier ID can be a barcode or any other type of identifier. But even if there is no carrier ID (even a barcode would suffice), then while under remote control the host can assign an ID to the carrier. Alternatively, while under local control the equipment software can generate a unique carrier ID.

    2. Carrier (Container) ID Reader

      E87 Carrier Management anticipated that a unit of equipment might not have a carrier ID reader. It also anticipated that a carrier ID reader might be out of service or defective, and therefore should be ignored. Not having a carrier ID reader means that you will not have the benefit of verifying that the correct container has arrived.

    3. Number of Slots in the Container

      A standard FOUP for silicon wafers has 25 slots. But the number of slots in a container is not limited or restricted.

When can’t E87 Carrier Management be applied?

For E87 Carrier Management to be applied, the material needs to arrive and/or depart in some sort of container. If material arrives and departs continuously without any container, such as on a conveyor, then there is no container or load port for E87 Carrier Management to manage. Of course, GEM can still be applied without E87 and the other GEM300 standards, although E90 Substrate Tracking might still be useful.

What are the benefits of using E87 Carrier Management?

E87 Carrier Management provides quite a few benefits to any equipment that can adopt it.

  • Confirmation that the correct container arrived at the equipment
  • Confirmation that the container has the expected material in its various locations
  • Reporting current load port states (e.g., occupied, ready for unloading, ready for loading)
  • Placing a load port in and out of service, such as for maintenance and repair
  • Notifying the equipment when a container will be arriving
  • Managing container storage
  • Reporting when the material from a container is nearly completed processing
  • Load port identification
  • Assigning substrate IDs

E90 Substrate Tracking

The “substrate” term is not restricted to silicon wafers, but rather applies to any type of product material. This generalization of the substrate term means that E90 Substrate Tracking can be applied to many different types of equipment.

Normally substrate tracking is considered in terms of fixed substrate locations, such as a slot in a container, a specific location in a pre-aligner, the end effector of a robot arm, or a specific process chamber. However, just a like a robot for handling silicon wafers can have multiple arms for handling multiple substrates, a conveyor can be similarly modeled to have multiple substrate locations. For example, if a conveyor can hold 50 small substrates at a time, then it could be modeled with 50 substrate locations for high-precision material tracking. Doing so allows E90 to be used to track substrates even while on a conveyor. The time each substrate is placed on a conveyor can be used to deduce the order of the material on the conveyor.

E90 Substrate Tracking also provides for substrate ID verification. This is only possible when the substrates have an identification code that can be read, such as a barcode or 2D data matrix, and when the equipment has the hardware capable of reading the identification code. When both are present, substrate ID verification can allow the factory to confirm each substrate before processing, and thereby reduce scrap.

When an equipment transports and processes multiple units of material internally using any type of container, it is called batch processing. E90 Substrate Tracking also supports this method by identifying batch locations and by providing data collection features specific to batch movement.

When can’t E90 Substrate Tracking be applied?

In order to use E90 Substrate Tracking, the equipment must have at least two substrate locations and work with some type of substrate. Without these there is no benefit in implementing E90 Substrate Tracking.

What are the benefits of using E90 Substrate Tracking?

E90 Substrate Tracking provides many benefits to any equipment that handles material.
  • Providing history of substrate movement, including timestamps for each location change
  • Substrate identification
  • Substrate location identification
  • Factory substrate verification, including the automated rejection of invalid substrates
  • Providing processing status for each substrate
  • Implementing virtual substrate tracking for lost substrates

E40 Processing Management

E40 Processing Management creates a list of materials to process and the name of the recipe to use. When using silicon wafer substrates, this list is either in the form of a carrier ID and a set of slot numbers, or a list of substrate IDs.

When can’t E40 Processing Management be applied?

If an equipment processes material continuously without having a discrete set of material that is known and identified ahead of time, you cannot apply E40 Processing Management. E40 Processing Management assumes that you have a specific set of material to process. If each substrate is simply processed as it arrives, then you are better off just using GEM’s PP-SELECT remote command to choose the correct recipe.

What are the benefits of using E40 Processing Management?

E40 Processing Management provides multiple benefits when it can be applied to an equipment:

  • Easily configure the equipment to process a specific set of material with a specific recipe. For example, 20 substrates can all be processed with the same recipe, or each with a different recipe.
  • Allows the equipment to support process tuning in which specific default settings in a selected recipe can be overwritten with new values. This is far easier than creating a proliferation of nearly identical recipes.

E94 Control Job Management

E40 Processing Management can be used in a standalone fashion but is usually implemented in conjunction with E94 Control Job Management. I recommend implementing both. Even if you don’t need all the extra features of Control Job Management, it adds very little overhead and is easy to use.

When can’t E94 Control Job Management be applied?

E94 Control Job Management cannot be used without E40 Processing Management, because its primary function is to manage the E40 process jobs. Therefore, its applicability is subject to the same criteria as E40 Processing Management.

What are the benefits of using E94 Control Job Management?

E94 Control Job Management has some features that benefit some equipment:

  • Allows material to arrive in one container and depart in another. This is beneficial when the source container needs to be kept uncontaminated by the effects of a process.
  • Allows material to be sorted based on some criteria. This is beneficial when sorting takes place based on inspection and/or other conditions, and the material is subsequently routed to different destination containers based on the sorting.
  • Manages a set of process jobs. For example, one can abort, pause or resume all process jobs.

How does all of this apply to the back end industry segment?

Factories must decide if they want the benefits of GEM300. Although E90 Substrate Tracking can be applied to most equipment, E87 Carrier Management, E40 Processing Management and E94 Control Job Management are only applicable to the equipment that deliver and/or remove material in containers. The features of each standard may not seem remarkable in and of themselves, but it is important to remember that these features have been implemented in a standardized way that many equipment manufacturers and their factory customers around the world have all agreed to follow—and that is truly remarkable.

One of the primary benefits of the GEM300 standards is the factory’s ability to move material to the equipment and process it in any order. The term “process” is used very loosely with the understanding that in addition to material transformation, inspection, metrology, sorting, testing, packaging, and other manufacturing activities are all types of processing. The material can be moved from any equipment to any equipment. This flexibility is a key to the success of modern integrated circuit manufacturing. It allows for the fabrication of many products without moving equipment or setting up conveyors. It allows process steps to be added or removed at any time. It enables the optimum use of inspection and metrology equipment since the same equipment can be used before and after any process step. The GEM300 standards directly support this flexibility.

The SEMI Advanced Back End Factory Integration task force plans to standardize the criteria for determining which standards apply based on an equipment’s functionality. What I’ve explained in this posting is just the starting point for this work—there is much more to be done. We welcome more participants on the task force to ensure the standardization is done accurately and efficiently.

Contact Us

Topics: Industry Highlights, Equipment Control-Software Products, Doing Business with Cimetrix, Cimetrix Company Culture, Meet Our Team, GEM300

How we helped a customer deliver a GEM-compliant equipment using CCF

Posted by Rich Kingsford; Project Manager, CCF Services on Jun 4, 2020 2:30:00 PM

Welcome to the first posting in the Cimetrix CIMControlFramework (CCF) Services blog series! While Cimetrix has been providing professional services for many years, in order to better serve the growing demand from many new equipment maker customers worldwide that have purchased our CCF product, Cimetrix earlier this year formed a new CCF Services group, reporting directly to the CEO. Being a senior developer at Cimetrix for the past 15 years in a variety of positions, I was delighted when asked to lead this group. We have an outstanding team of software engineers highly experienced in factory automation, equipment control software and SEMI standards. We are dedicated to ensuring our customers’ success by providing training, consulting, and developing custom solutions for our CCF customers. We love learning about the myriad ways that companies can integrate CCF with their equipment to meet the material handling and factory automation requirements of their factory customers. Our goal for these articles is to share some of the lessons learned and other implementation insights to help you efficiently build manufacturing equipment that is sophisticated, robust, and productive. To this end, our first posting will deal with one of the most common requests we get – enjoy!

- Forward by Brent Forsgren, Director of CCF Services

How we helped a customer deliver a GEM-compliant equipment using CCF

The Goal

One of our recent customers wanted to build a new type of LED manufacturing equipment that could be controlled by a Factory Host using the standard GEM Remote Commands: PP_SELECT (Process Program Select), START, STOP, ABORT, PAUSE and RESUME. The equipment could be delivered in a variety of physical configurations, including 1-to-multiple source cassettes for product material, and 1-to-multiple process modules. It also had multiple destination cassettes to be filled according to the post-process analysis results. The initial instance of the equipment had 4 loadports (LPs) and four process modules (PMs).

The functional requirements were clear – that was the good news. Now for the rest of the story… the project schedule and budget constraints were closing in, so we needed to work quickly and efficiently with the customer to get it done. Sound familiar?

The Approach

The Cimetrix CCF Services team always works closely with the software team of the equipment manufacturer. In this case, we started with one week of mutual discovery and in-depth hands-on training. Team members were fully engaged and picked up the CCF capabilities very quickly. This included even some of the more advanced features, such as developing a scheduler that would control the components of the customer’s application. We regularly fine tune training modules to 1) introduce CCF concepts, 2) expose common challenges and potential approaches, and 3) provide realistic implementation practice exercises. As anticipated, the customer was able to use the results of the training exercises in the actual equipment control solution. We also kicked off the project with our work-breakdown exercise to more deeply explore the unique requirements for their specific equipment type.

After an intense first week, everyone on the project team concluded that CCF would in fact be a strong match for their needs. CCF features direct integration with our CIMConnect, CIM300, and CIMPortal connectivity products to provide full GEM, GEM300 and EDA compliance. Because the Cimetrix connectivity products are deployed in every semiconductor 300mm factory in the world, our customers can be assured that they will meet their customer’s factory automation requirements. In this application, the end customer’s LED factory only required GEM.

To address requirements that may go beyond the basic GEM standards, CCF also provides support for custom remote commands, data publication, and alarm management. Finally, CCF supports integrating custom hardware devices using CCF’s base Equipment Classes.

To prove all was working, we chose the Cimetrix EquipmentTest product to develop and execute a set of unit tests that emulate communications with the factory software using GEM messages. This was not intended to be a comprehensive set, but rather just enough to show the equipment passed round-trip system testing. In this context, round trip means showing that the equipment can move material from the incoming cassette to the aligner to the process module and back into the cassette. EquipmentTest also supports editing message settings and parameters on the fly to experiment with different configurations of a round-trip test.

The Challenge: “The Host is unavailable, but we need to validate that the equipment is both GEM compliant and accomplishes the communication flows the end user requires.”

We get this challenge a lot… Our customers almost always develop the host interface and the embedded control software in parallel and integrate them later in the project. This makes sense at one level, but it does introduce a “chicken and egg” problem for testing this kind of GEM interface. In particular, how can our customer provide evidence that the solution will work with the factory host without testing with the actual host system? Our answer: apply our EquipmentTest custom plugin capability to simulate the end user’s host so we can validate all necessary communication between host and equipment.

Our protocol validation product, EquipmentTest, makes it possible to simulate communications between an equipment control implementation and the host. And although it is impractical to implement scenarios for every possible interaction, we can create enough representative scenarios to be confident the “happy path” (i.e., no errors) will work and that the interface will handle a large handful of “sad path” cases as well.

CCF-Services-Image1

Outcome

We passed all the tests! “Let’s go get some tacos.”

Specifically, we validated that the communications interface supported…

  • Standard GEM Remote Commands
  • Custom Remote Commands
  • Material tracking
  • Data publication

In closing, we must emphasize that our customer should take most of the credit here. Nevertheless, we enjoyed observing, consulting, and testing the equipment. It is always gratifying to see the CCF solution fit so seamlessly into the hardware, execute its commands with optimal timing, and not break anything in the process! Truly a successful, joint team effort.

If the situation above resonates with your current challenges and past experiences, give us a call. We look forward to working with your software engineering team to speed your time-to-market and deliver a high-quality solution quickly, allowing your team members to focus on developing value-added functionality for your customers.

Topics: Industry Highlights, Equipment Control-Software Products, Doing Business with Cimetrix, Cimetrix Company Culture, Meet Our Team, GEM300

Implementing CIM300

Posted by Brent Forsgren on Oct 26, 2017 11:34:00 AM

I have fond memories as a kid spending Saturdays working on the family cars with my dad. We would dive in to taking things apart and putting them back together again. Whatever the problem was we could figure it out and fix it. With cars from the 1960s and 1970s, there wasn’t too much risk with this approach to car repair. Today, I still like to do my own car repairs when I can. But cars nowadays are far more complicated and compact. I have learned that I can’t just jump in and wing it with any hope of getting it done right or in a timely manner. My experience has taught me to rely on the experience of others, learn from their lessons and save myself from late nights asking, “what have I gotten myself into?”

Cimetrix CIM300TM tool kit out of the box has already implemented a lot of the GEM 300 work for you. Notice I said “a lot” and not “all” of the work for you. To complete your GEM 300 application, your software will have to integrate with CIM300. The GEM 300 standards can be quite complex and some of the scenarios have intricate details. CIM300 provides a rich set of APIs and callbacks to help you implement a compliant GEM 300 solution. The key to success is knowing how to use the APIs and callbacks for the different GEM 300 scenarios.

The SEMI E87 Carrier Id Status state model, pictured below, is just one of many state models defined in the GEM 300 standards.

Carrier ID Status State Model for CIM300Figure 1 CARRIER ID STATUS STATE MODEL

There are several transitions in this state model and intricate conditions that determine which transition should be triggered. CIM300 supports this state model, but it requires interaction with your application to know which transition to make in the state model. In my experience, most people handle the happy path scenarios correctly, whether they're “winging it” or had formal training. However, I have rarely seen people handle the error scenarios correctly, without training on GEM 300 and CIM300. While understandable, error scenarios are often hard to follow and the implementation differences are subtle. The risk of doing it wrong in the software will execute the wrong transition in the state model, which in turn sends the incorrect event to the GEM host. The wrong event could really mess things up for the host. In both the happy path and error scenarios, the CIM300 API to call is the same:

CMSLib::CCxE87CMS::CarrierAtPort

However, how you specify the parameters to the call, it is different for each scenario. The differences in how you call the API will trigger different transitions in the state model. Our documentation for this one API call alone is longer than this entire blog post. That is how important it is to get it right. In addition to our product documentation, Cimetrix also provides CIM300 training and sample applications illustrating how to use our products.

I strongly recommend taking advantage of our CIM300 training. Training is the best first step to integrating CIM300 with your tool application. Training is typically a week long and provides an overview of the GEM 300 standards as well as hands-on experience using CIM300. The goal for Cimetrix in training is that by the end of the week-long training, clients have completed an implementation of a GEM 300 happy path scenario. That is, you receive hands-on experience using CIM300 to implement carrier verification (SEMI E87), creating and running a process job (SEMI E40) and control job (SEMI E94), tracking substrates (SEMI E90), and tracking equipment performance (SEMI E116).

Make sure you also leverage the sample applications that accompany CIM300. The sample applications provided with CIM300 give a jumpstart on integrating CIM300 with your own application. You can use the sample application as a reference for how to use our APIs and callbacks, copy/paste portions of the code into your own code, or use our application as a starting point for your own software. If you’re like me, you like having working source code you can refer to for concrete examples of how to do things and to see how things should work together.

If you dive right in and start implementing CIM300 without training or mentoring from an expert, you may find yourself spending a lot of late nights asking yourself, “what have I gotten myself into?” A little training goes a long way in simplifying the implementation!

Find out more about CIM300 or request a Technical Product Overview and/or Product Demo today!

Request CIM300 Resources

Topics: Doing Business with Cimetrix, Cimetrix Products, GEM300

A Look Back at 300mm Semiconductor Fabs

Posted by David Francis: Director of Product Management on Mar 26, 2012 10:34:00 AM

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.

300mm Wafer resized 600

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.

Semiconductor Fab resized 600

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.

Topics: Industry Highlights, SECS/GEM, Cimetrix Products, GEM300