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

Tim Hutchison: Senior Software Engineer

Senior Software Engineer
Find me on:

Recent Posts

Implementing your Process Module Using CCF

Posted by Tim Hutchison: Senior Software Engineer on 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

Create Device Drivers Using CCF

Posted by Tim Hutchison: Senior Software Engineer on 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

Subscribe to Email Updates

Follow Me

Learn More About the
SEMI Standards

SECS/GEM

GEM 300

Interface A/EDA

PV2 (PVECI)