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

Semiconductor

CCF Provides Fully Implemented GEM300 and EDA Interfaces

Posted by Bill Grey: Distinguished Software Engineer

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

Implementing your Process Module Using CCF

Posted by Tim Hutchison: Senior Software Engineer

Feb 9, 2017 12:30:00 PM

You have designed the ultimate process that will revolutionize the semiconductor industry.  The parts have been collected, the process module assembled.   But now you need the software to make all the components work together.

As described in a recent CIMControlFramework (CCF) blog post around designing recipes, the recipe is the secret sauce for your process.  The recipe is used to direct the hardware to perform the process; How much time in a step, temperature, gas flow, pressure, etc.

The recipe provides directions to the process module on how to perform the processing.  How and when to enable/disable hardware components.  What setpoints to be set for components.  How much time to spend on any given step.  The process module (PM) software that you develop will take the recipe that you have defined and perform the operations using that recipe. CCF stays out of your way to allow to create your secret sauce.  

CCF makes integrating your process module easy.  CCF provides a simple process module interface that allows CCF to know when to prepare for processing, prepare for transfer, and process using the supplied recipe.

 Your process module hardware may be made up of any number and types hardware components, E.g.  Mass Flow Controller(s), valves, chuck, etc. that will be used to process the recipe. Since CCF does not use proprietary interfaces and does use C# and Visual Studio, creating interfaces to your hardware is much easier and left to you to design and develop these drivers. CCF makes it easy to connect to your hardware, whether it is via a PLC or talking directly to the hardware. 

CCF makes it incredibly simple to report data to a UI, a GEM host and even an EDA client.  Declare your status variable, update, and publish.  The data is reported to all three for you automatically!!

CCF takes the stress out of the necessary evil of moving material through the equipment to get it to your process module. It provides an interface for interacting with your process module allowing you to spend your time where it matters most - creating your secret sauce to help make you successful!

Topics: Semiconductor Industry, CIMControlFramework, Software

Designing Recipes in CCF

Posted by Derek Lindsey: Product Manager

Jan 24, 2017 11:00:00 AM

Anyone above a certain age will be able to tell you what you get when you combine two all-beef patties, special sauce, lettuce, cheese, pickles, onions – on a sesame seed bun. There are many who would argue that what sets a Big Mac apart from other burgers – and has made it one of the best-selling products of all time – is the special sauce.

In a March 2016 blog post, Cimetrix listed eleven points to be taken into consideration when starting an equipment control application using CIMControlFramework (CCF). One of the things to consider is how you want to provide process and path information through the tool using recipes. This blog post delves a little deeper into the recipe aspect of equipment control applications.

In CCF, recipes are either process recipes or sequence recipes.

Cookbook1.png

A process recipe contains the instructions to be carried out by a particular process module. These instructions can range from temperature settings to types of gas to flow. The most important aspect of any tool control application is allowing the tool manufacturer to do what they do best – perform their process better than anyone else in the world. The process recipe allows tool manufacturers to add their special sauce to the wafer. CCF provides a sample process recipe implementation as well as very simple process recipe editor. Since recipes are generally custom for each tool manufacturer, CCF application developers usually want to customize the recipe contents for a process recipe.

If the processing of material is the special sauce, the rest of the application, moving the wafer through the tool, is a necessary evil. To assist in moving material through the tool, CCF also provides a sequence recipe. A sequence recipe determines which process recipes are to be run, at which modules to run them, and the order in which this is to occur. CCF provides a sample sequence recipe editor that can be used in creating sequence recipes or customized for each tool manufacturer’s needs.

Both process and sequence recipes can be created on the tool or downloaded from a factory host. CCF provides a handler that receives recipes from the host and stores them in the Recipe Server. Regardless of where the recipes are created, CCF’s Recipe Server stores the recipes locally and passes them in to the scheduler when a job is to be run. The Recipe Server allows recipes to be stored as Engineering recipes while they are being finalized. They can then be promoted to Production recipes for use in a production environment. 

By making use of recipes in CCF, you can ensure that your special sauce is applied to material processing to help make your tool one of the best-selling in history.

 

Topics: CIMControlFramework

Create Operator Interface Screens Using CCF

Posted by Harley Pebley, Software Craftsman

Jan 5, 2017 1:31:00 PM

Our bodies are amazing machines. Ask a man off the street what they see when they look at someone, they will probably talk about skin, hair and eye color, height and weight and other external defining characteristics. Ask a doctor and they may see issues relating to what’s going on in the person’s organs and overall internal function. Ask a molecular biologist and they’ll talk about the chemical pathways that allow things to work at the cellular level. Much like our bodies, computer controlled systems are made up of many layers. Starting with electrons moving through conductive and semi-conductive materials, abstraction layer is added upon abstraction layer to create components, circuits, assemblies until finally a computer is created. In the same way layers of software control this computer from the BIOS up through layers in the operating systems and culminating in the application the user sees. Similar to the way doctors and biologists work at different levels of abstraction within their domains, we as engineers know about, work with and think about our system at various abstraction levels. However, the end user is like that man on the street, all they see are the external characteristics. Because of this, the operator interface is among the most important parts of the system.

SEMI established the E95 standard as general guidelines for screen layout of tool control software. CIMControlFramework (CCF) provides a standards conforming shell into which various screens may be added to create a complete operator interface. This allows the tool manufacturer to focus on the unique needs of their tool and have no worry about meeting the standard.

There are several general steps to create an operator interface using CCF:

  1. Decide on the technology. In the Windows desktop software world, there are two primary ways of developing a user interface: WinForms and Windows Presentation Foundation (WPF). CCF has historically supported the WinForms environment providing many fully functional WinForms screens. It has also supported WPF, but only provided a single example WPF screen. Cimetrix is in the process of updating WPF support and adding multiple fully functional WPF screens out of the box. Either environment may be used based on what the tool manufacturer’s developers deem appropriate.

  2. Establish the requirements. The purpose of the operator interface is for the tool to provide the operator with information about what it’s currently doing and for the operator to tell the tool what to do. Determining the correct way to do this can be one of the hardest parts of designing a user interface. This step is where the best level of abstraction is established. The user should have sufficient information to understand what’s happening without being overwhelmed by too much data. The user should also have enough control to do what needs to be done without having to worry about too many details. The analysis for this step is often done by multi-disciplinary teams using analog methods like whiteboards and pen and paper. Creating avatars for different types of users and then writing stories about what those users will want to do is a good way to help flesh out what’s needed by the operator interface.

  3. Evaluate pre-built screens against the requirements. Once the target is established, the screens provided by CCF can be examined for fitness. How well do they fit the target? Some screens may be close enough to the requirements to be used as is. Other screens may be close but require some tweaks to meet the specific needs. Finally, some screens may need to be built from components provided by CCF to satisfy the unique specifications of a particular tool.

  4. Assemble the screens into an application. Once a list of needed screens is created, the final step is to put everything together. This is generally the most time consuming part of building an operator interface. This phase is when any custom screens are built or modifications made to existing screens. Finally, all the screens, both custom and pre-built, are added to the framework provided by CCF. CCF has a number of labs to help understand how the various user interface components work together to provide a cohesive whole.

CCF provides the structure, pre-built screens and tools to assist in creating custom ones to give your tool a beautiful skin.

Topics: CIMControlFramework

Create a Scheduler Using CCF

Posted by Derek Lindsey: Product Manager

Dec 14, 2016 11:30:00 AM

Shel_Silverstein_MelindaMae.jpg

How do you eat a whale? One bite at a time. 

In a March 2016 blog post entitled CIMControlFramework Work Breakdown, Cimetrix listed eleven points to be taken into consideration when starting an equipment control application using CIMControlFramework (CCF). One of the things to consider is how you want to control the material moving through the tool – or scheduling of material. This blog post delves a little deeper into the scheduling aspect of equipment control applications.

Doctoral dissertations and entire books have been written to discuss scheduler theory. Because of sheer volume of information available regarding scheduling and scheduling theory, the topic can come across as a little (or a lot) intimidating. CCF aims to take the scare factor out of scheduling and allow equipment control application developers to fully control the movement of material through their tool.

CCF provides a framework for a reactive, rule-based scheduler. You, as the application developer and in conjunction with your customer needs, get to decide what decisions are important when creating your scheduler. One of the first things you need to do when developing a scheduler is to ask questions to help you determine the rules for scheduling. Some questions you may ask:

  • What is the most important thing I am attempting to accomplish with my scheduler?
    • Is throughput the most important?
    • Is path predictability most important?
  • How can I ensure that when I pick material up that there is a destination available to put it?
  • If two components need a robot to take action (pick up or place material), which action takes precedence?
  • Do the process chambers need to be prepared before receiving material to process?
  • What is the wafer flow scenario (is there a specific order that material must follow)?
    • Does the material need to be aligned before processing?
    • Does the material need to be acclimatized before processing?
    • Does the material need to be cooled before returning to the carrier?
  • Are there any maintenance tasks that have to be performed periodically in the tool that have to be accounted for in scheduling?

This is by no means an exhaustive list of questions, but these are the types of questions that need to be answered when creating your scheduler. 

The scheduling framework provided by CCF allows you to translate these rules into C# conditional statements. No proprietary scripting languages need to be learned. No specific configuration training is required. C# developers can use industry standard IDEs to put these rules into scheduling practice.

Once the scheduling rules are determined, it can still be intimidating to know how to start creating your scheduler. Cimetrix provides a few basic, as well as more advanced,of  scheduling labs that fully explain how to translate your rules into a functional scheduler. These labs can be completed in as little as a few hours. The labs explain the scheduling theory used by Cimetrix and allow users to create functional schedulers in a short amount of time. Many CCF users can create a working scheduler in one week.

Cimetrix also provides complete working examples of atmospheric and vacuum schedulers as part of CCF. Another lab provided by Cimetrix clearly describes how to start with one of these working schedulers and modify it to suit your scheduling needs.

The CCF scheduling framework allows the software to be hardware agnostic. In other words, it is not tightly coupled to device drivers. This allows tool manufacturers to change out hardware without having to make scheduler changes to support the new hardware.

Although scheduling may seem like an intimidating whale to eat, CCF helps break the tasks down into bite-sized chunks.

 

Topics: CIMControlFramework

Create Device Drivers Using CCF

Posted by Tim Hutchison: Senior Software Engineer

Dec 6, 2016 11:30:00 AM

In 1976, Blue Oyster Cult released their hit song, “Don’t Fear the Reaper”.  In 2000, Saturday Night Live produced a fictitious, but humorous skit around the production of the “Don’t Fear the Reaper” called, “More Cowbell”.  The “More Cowbell” skit put a very light hearted spin on the production of the hit song.   After seeing that skit, I can never hear that song the same way. The cowbell, for as small a piece it plays, is a huge part of the song.

Keep_Calm_Cowbell.jpg

The same can be said for the hardware that is used in Semiconductor manufacturing tools.  Tool control boils down to controlling the hardware. Without controlling the hardware, the UI and factory automation will not amount to much if the robot doesn’t move. Everything from the robot, down to a simple presence sensor on a load port is needed. What may seem to be the simplest device can be the most prominent.  Each device plays an important part in the process. 

A Cimetrix blog post on March 15, 2016 entitled CIMControlFramework Work Breakdown, identifies driver integration as one of the first steps that needs to be done in the work breakdown for a CIMControlFramework (CCF) application. It may seem intimidating to create a driver to control hardware. There is the need to connect to the device. There is some number of commands and possible responses to deal with.  It can be overwhelming, but can be conquered by understanding what needs to be done to control a device through a driver.

Let’s look at how to go about developing a driver.

  1. Understand the interface to the device using any and all documentation available.  The documentation will provide information on how to send commands and interpret the responses.
    1. Does the device control only one device or many?
    2. What is the communication protocol to the device?
      1. TCP/IP
      2. Serial ports
    3. What are the commands?  How are the commands composed?
    4. What are the responses?
    5. Will the device need to be polled?
    6. Will the device send unsolicited messages? 
  2. Understand what needs to be controlled on the device for the tool. 
    1. Will you only need to use a subset of the interface or the entirety of the interface?  If just a subset, then there is only a need to write those initially.
  3. Writing code to “talk” to the device
    1. Do you have a simulator for the device?
      This one is important, especially if the hardware has limited availability.  If needed, a simple simulator can be developed to at least validate communications, then expanded over time to simulate faults or other conditions.

      As the tool begins to come together, each simulator will become invaluable when developing the other parts of the tool and coordinating the devices together. 
    2. Unit tests can be useful to verify that the driver behaves as expected before using on actual hardware.  Unit tests can also provide regression testing should changes be made to a driver.
      Some areas to consider unit testing;
      1. Handling of failure to connect
      2. Handling of failure to send to the device or receive from the device
      3. Handling of return values
    3. Start out simple, just get a connection to the device to begin with.  Next send a simple command and inspect the response.  Create a success and build upon the successes!

In the end, a driver will be sending commands and getting and interpreting a response. For every device you create a driver for you’ll also become the expert on that device.

Even though it can be intimidating to start, developing drivers is one of the fun parts of tool development. There is nothing more exciting than seeing the hardware begin to dance in the fashion that has been choreographed in your software

CCF provides utilities and examples to help create drivers for your hardware and easily integrate them into the application, to assist you to orchestrate and provide more cowbell in your tool control. 

Topics: CIMControlFramework

Learning from Others

Posted by David Francis: Director of Product Management

May 10, 2016 2:37:12 PM

blueprint.jpg

Almost everyone I know that has built a house has given me a list of things they would “do differently next time,” but a lot of those same people would also say that they would never build again. So does that mean everything they learned through the process is lost? Is it possible to get it right the first time? Maybe not, but there are a lot of things you can do to learn from the experience of others. For example, you can buy house plans that have been used before and are designed to leverage standard components. Rather than designing and building everything from scratch, you can use pre-built sub systems like fabricated floor joists and manufactured roof trusses. Using proven components saves a lot of time and worry about whether or not they will work properly and as expected. This allows you to focus on the customizations that will make the home meet your unique needs.

Implementing an equipment control application is a lot like building a house. You can design and build a complete control system from the bottom up—building all the components necessary to handle communication with the hardware, display information to the operators, manage user access, log relevant event and data information—but it doesn’t add value to the core competency of your equipment. The best option is to leverage proven design that has been built through multiple prior applications and leverages those lessons learned along the way.

Cimetrix's CIMControlFramework provides all the standard components necessary to build an equipment control application. With working samples for both atmospheric and vacuum equipment, it can easily be customized and extended as needed to meet specific control needs.

There is an old saying that goes, “If you don’t have time to do it right, when will you have time to do it over?”

If you would like to learn more about CIMControlFramework and how it can help you on your next project, give us a call or feel free to contact us here.

Topics: CIMControlFramework, Equipment Automation Framework

CIMControlFramework Dynamic Model Creation

Posted by Derek Lindsey: Product Manager

Apr 14, 2016 1:00:00 PM

turkey-218742_960_720.jpg

Have you ever watched one of those cooking shows where the chef spends a lot of time whipping up the ingredients to some elaborate dish, and, when it comes time to put the dish in the oven to bake, there is already a finished one in there? If only the real world worked that way. Sometimes it would be nice to be able to go to the oven and have a delicious meal already waiting for you.

The Cimetrix CIMControlFramework™ (CCF) product is unique among Cimetrix products in that it not only provides source code, but also combines several other Cimetrix products (CIMConnect, CIM300, and CIMPortal™ Plus) and takes full advantage of all the features provided by each product.

One of the features of CIMPortal Plus that is used in CCF is the concept of an equipment model. The equipment model describes the data that your equipment provides through Interface A. The tool hierarchy is modeled along with all of the parameters, events, and exceptions published by the tool. It used to be that CCF users had to manually create the tool hierarchy in their base equipment model. CCF would then populate the model with the parameters, events, and exceptions. If the tool hierarchy changed, the base model would have to be modified. It made changing the tool configuration much more difficult.

Starting with the CCF 4.0 release, a base equipment model that is common to all equipment was installed. Generally, CCF users will not need to modify the base model. CCF takes advantage of the modeling API provided by CIMPortal Plus to dynamically add hierarchy nodes to the base model depending on the components that are created in CCF. This new feature makes it easy to change the configuration of the CCF tool because the user does not have to make modifications to the base model and redeploy the package to be able to run CCF.

The dynamically created model is also compliant with the SEMI E164 Common Metadata standard. This compliance is possible because of the dynamic nature of model creation. The required elements of E164 are added to the equipment model dynamically during the startup of Tool Supervisor.

Having a dynamically created Interface A model that exactly matches your equipment structure and is guaranteed to be E164-compliant without having to do any extra work is similar to going to the oven and finding a delicious dish already cooked and waiting for you.

Topics: EDA, CIMControlFramework, Product Information, Software

CIMControlFramework Work Breakdown

Posted by Derek Lindsey: Product Manager

Mar 15, 2016 1:00:00 PM

FirstStepofaThousandMileJourney1.jpg

“A journey of a thousand miles begins with a single step.” – Lao Tzu

“Watch out for that first step Mac, it’s a lulu!” – Bugs Bunny

These quotes by the great philosophers Lau Tzu and Bugs Bunny have more in common than would appear at first glance. At the beginning of a journey you have the element of the unknown. There is excitement that it could be a great journey, but there is also an element of the unknown that may make that first step the hardest to take. If you haven’t put in the preparation for a successful journey, that first step might be a lulu.

Similarly, when starting a new equipment control application, there is excitement for the great end product, but also some element of not knowing the best place to start. CIMControlFrameowrk (CCF) offers a great training program to get you started and many building blocks for helping create a first-class equipment control application. Even with these great starting tools, many users still have the question, “Where do I go from here?”

The first step is to create a work breakdown of what it takes to create a successful equipment control application. There will obviously be tasks that are unique to each equipment control application, but most applications have some common tasks or epic user stories that have to be completed during the project. The order in which these stories are completed may depend on milestones and expectations for when they are accomplished, but they generally all need to be completed during the project.

  • Integrate Devices – CCF provides an Equipment layer with abstractions of most commonly used devices. Integrating these devices into CCF only requires the implementation of the abstract interface.

  • Material Movement Through the Tool – CCF provides a flexible scheduler with complete working examples of different types of scheduling that could be done.

  • Implement the Process Module – CCF provides a process module interface that allows the rest of CCF to communicate with your process module – your secret sauce.

  • Create an Operator Interface (OI) – CCF provides an OI framework that allows commands to be sent and updates to be made. It also provides some default screens that use this interface. It also allows for insertion and use of custom OI screens.

  • Simulation – CCF provides a simulator that can be used in place of real hardware. The simulator can be used to deliver/remove material, perform robot moves, and do simulated IO. This is invaluable in continuing development before the hardware is ready or if there is limited tool time for the developers.

  • Recipes (Process Recipes and Execution) – CCF provides a recipe manager for passing recipes through the tool. The default recipe can be used or custom recipes can be added.

  • I/O – CCF provides ASCII serial drivers and other common IO providers. Custom IO providers can also be included in CCF.

  • Data Collection and Storage – Knowing what data to store and what medium to use for storage is recommended up front.

  • Factory Automation – CCF provides a fully integrated GEM, GEM300, and EDA implementation.

  • Diagnostics and Testing – The CCF logging package is a fantastic tool for debugging your application both on the tool and remotely.

  • Errors and Recovery – CCF provides an Alarms package for signaling of and recovery from error conditions.

By going through CCF training and creating a work breakdown of the tasks that need to be done for your equipment control application, you can ensure that your first step will be the foundation of a successful journey.

Topics: CIMControlFramework, Product Information, Software

Build vs. Buy?

Posted by David Warren: Director of Software Engineering

Feb 18, 2016 1:06:00 PM

Every company that needs software must make a build versus buy decision at some point. Some choices are easy—it makes little sense to build your own office software for word processing, spreadsheets, or presentations. But what if you need software to control specialized physical equipment?

Classic advantages of building your own software are:

  • Canned software is generally targeted to meet many needs for most problems. Custom software is better suited to meet specific and uncommon needs.

  • Canned software has a fixed set of features and it may be difficult to add or remove specific features, which may lead to software that contains unneeded features or is missing features that you do need. Custom software can be built to meet the specifications of a projects and include all the features that are needed and never any that aren’t.

  • The process of developing software builds in-house technical expertise. This expertise can be used to create competitive advantage through higher performance and faster reaction time in meeting the changing needs of the marketplace.

Classic advantages of using standardized software are:

  • Standardized software is generally less expensive than custom software because its cost can be spread across many customers and/or tools.

  • Standardized software can require less time depending on the degree of customization required.

  • Standardized software can be more reliable since it has been tested and used in many different applications.

  • Standardized software may provide more features than would otherwise be available.

Why Not Combine the Best of Both Options?

Brackets_Code.png

Buying a tool control framework can help you build your own tool control software and still get the benefits of using standardized software. The framework can take care of common problems while you focus on items unique to your specific tool. As a framework, features can be removed, replaced, or even modified as needed. You reduce your costs as well as your time-to-market by using a selection of reliable, field-proven features and including only those that are relevant and add value to your control system. You still retain and build your in-house technical expertise to create competitive advantages in controlling your equipment instead of treating tool control expertise as a commodity.

Using a tool control framework can be a smart way to improve your processes by using standardized software that is easy to customize. So why not consider it as an option for your next project?

If you are interested in downloading the data sheet on Cimetrix’ tool control framework software, CIMControlFramework, click here.

Topics: CIMControlFramework, Equipment Control-Software Products, Equipment Automation Framework, Software

Receive Email Updates

Follow Us

Learn More About the
SEMI Standards

SECS/GEM

GEM 300

Interface A/EDA

PV2 (PVECI)