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

EDA Testing – How is this accomplished today??

Posted by Alan Weber: Vice President, New Product Innovations on Feb 7, 2017 1:30:00 PM

Over the past several months, we have posted a number of blogs dealing with the testing of SEMI’s Equipment Data Acquisition (EDA / aka Interface A) standards suite. The first of these posts connected the importance of this topic to the increased adoption of the EDA standards across the industry, and broke the overall problem domain into its three major components. 

Subsequent postings provided additional detail in each of these areas:EDA_Icon.png

To bring this series to a close, this post addresses the “as-is” state of EDA testing as it is practiced today by the advanced semiconductor manufacturers who are requiring EDA interfaces on new equipment purchases and the suppliers who provide that equipment. 

For compliance testing, the three options in general use include: 

  1. ECCE Plus product- this software tool was originally developed under contract with the International Sematech Manufacturing Initiative (ISMI) to validate the fidelity, usability, and interoperability of early versions of the standard; it can used to manually execute a set of procedures documented in the “ISMI Equipment Data Acquisition (EDA) Evaluation Method for the July 2010 Standards Freeze Level: Version 1.0” document (see title page below) to exercise most of the capabilities called for in the standard; note that this is the only commercially available solution among the three.

ISMI.png

  1. Company-specific test suites – one major chip manufacturer (and early adopter of EDA) maintains its own partially-automated set of compliance tests, and provides this system to its equipment suppliers as a pre-shipment test vehicle. This set of tests is then used in the fab as part of the tool acceptance process; however, this system also includes a number of company-specific automation scenarios, which are not available for outside use. This highlights the need to support custom extensions in an industry-validated tester if it is to be commercially viable.

  2. In-house custom test clients – this is a variation of #2 that some of the major OEMs have chosen as their economies of scale dictate; the problems with this approach are that a) the test clients must be kept current with the EDA standards, which are themselves a moving target, and b) unless thoroughly validated by the eventual customers of the equipment, there is no guarantee that passing these tests will satisfy the final acceptance criteria for a given factory. 

For performance and stability testing, there are no automated solutions currently available. The ISMI EDA Evaluation Method does describe some rudimentary performance evaluation procedures, but these no longer reflect the expectations of the customers with many years of accumulated EDA production experience. Clearly a better solution is needed.

Finally, for metadata model conformance testing, the only available solution is the Metadata Conformance Analyzer (MCA) that was commissioned by Sematech and implemented by NIST (National Institute of Standards and Technology). It has not been updated in almost five years, and exhibits a number of known issues when applied to a SEMI E164-compliant equipment model (E164 = Specification for EDA Common Metadata), so it will be increasingly insufficient as more companies require full Freeze II / E164 specification compliance. 

The good news in all this is that Cimetrix has recognized and anticipated this emerging need, and is actively addressing it on our product roadmap. If you want to know more about EDA testing and/or discuss your specific needs, please contact Cimetrix for a demonstration of this exciting new capability!

Topics: Interface A, EDA, EDAConnect, ECCE, Data

President's Letter to our Cimetrix Community

Posted by Robert H. Reback: President and Chief Executive Officer on Feb 2, 2017 11:30:00 AM

To the Cimetrix community of clients, partners, shareholders and employees,

Cimetrix had another year of solid progress during 2016. Financial results were in-line with expectations, as Cimetrix continued to achieve profitability every quarter with full-year revenue in the $6M to $7M range.

Our key highlights include:

  • Cimetrix continued to enhance its reputation for product quality and the highest levels of customer support in the industry, receiving consistently excellent feedback from our client base.

  • Cimetrix continued to invest in building great products with new releases of all our product lines. Substantial improvements were made in both new features and internal testing that will benefit our clients for many years. 

  • Cimetrix gained additional “design wins” for its products in North America, Europe and Japan, where the company has an established presence. In addition, Cimetrix won important new clients in China and Korea. 

  • Cimetrix strengthened its organization as we added a number of new employees in business development, software engineering and technical support functions. The Company continued to invest in employee development, education and continuous improvement. We believe the concepts and training we’ve received in lean and agile processes will enable Cimetrix to build better products and more efficiently provide our clients with the highest levels of service. 

  • Cimetrix made a number of key investments that we believe will lead to future long-term growth. We strengthened our local sales and technical support in a number of Asian countries. We developed a number of new product prototypes in collaboration with key clients leading to the introduction of an exciting new Cimetrix product in 2016. Several other new products are in development and have the potential to significantly expand our markets.

Cimetrix also held its first shareholder meeting since going private in late 2014, which provided a forum to explain to shareholders why the Company took that important step, the progress we’ve made since going private, and our future plans. As a result of generating positive cash flow from operations, Cimetrix was able to continue providing liquidity for shareholders that contacted the Company. Prior to going private, the Company had over 4.5M shares outstanding, adjusted for stock splits. As of December 31, 2016, the Company had fewer than 3.9M shares outstanding. This means that every current shareholder’s ownership percentage has increased by over 15%.

Going Forward

Going forward, industry analysts predict an increase in semiconductor capital equipment spending for 2017. In addition, we are seeing increased traction for the relatively new SEMI Standards for Equipment Data Acquisition (EDA), also known as Interface A. We believe these trends will enable us to achieve short-term incremental increases in revenue that support continued operations on a profitable basis and investments in new products and markets that will lead to longer-term step function increases in revenue.

We will continue to focus on satisfying our worldwide base of clients, improving our efficiencies and effectiveness, and executing our plan to expand the markets for Cimetrix products for long-term growth.

From all of us at Cimetrix, we thank our clients for the trust they have placed in our products and our team. We also thank our shareholders for their patience and support. 

Sincerely,

Robert H. Reback
President and Chief Executive Officer

Topics: Partners, Doing Business with Cimetrix, Working at Cimetrix, Cimetrix Culture, Announcements, Investor News

14th Innovations Forum for Automation

The 14th innovations forum for automation was held on January 19 and 20, 2017 at the DGUV Akademie in Dresden, Germany.

14-Innovations-forum-snow.jpgCimetrix was one of the sponsors of the conference.  Dresden is hot bed for semiconductor manufacturing in Europe.  In fact, 50% of the chip output from Europe comes from Dresden. The conference is organized by the Automation Network Dresden which consists of 5 Dresden based companies; AIS, HAP, Ortner, SYSTEMA and Xenon.  SYSTEMA is a Cimetrix partner and helps us with integration projects. 

The focus of the conference is to bring the latest information on best practices, new technologies and the future of automation.  Themes this year were Smart Manufacturing, Industry 4.0 and IIOT (Industrial Internet of Things).  Presentations by Bosch about their automation roadmap, Infineon about running experiments in a highly automated fab, Kostal about standardizing MES, and IAV about the challenges of automated driving where a few of the interesting case studies and technologies.  This is a great conference to meet semiconductor professionals from Europe and learn what the European community is doing in the area of fab automation. For Cimetrix, it is good to see that equipment to host connectivity plays a key role in all the projects outlined during the conference. Sponsoring and attending gave us the opportunity to meet with current customers and start discussions with new potential customers. 

Innovations-forum-pic2.jpg

Before the conference, SYSTEMA held an Expert Day session at the SYSTEMA facility in Dresden on the morning of January 19.  The session was a series of presentations targeting predictive maintenance.  SYSTEMA and its partners have a wealth of experience in this area.  

innovations-forum-pic3.jpg

 

Topics: SEMI, Events, Germany

Cimetrix HostConnect

Posted by Joe Cravotta, Client Support Engineer on Jan 26, 2017 11:45:00 AM

Cimetrix is proud to release its first new product to assist in GEM host application development, and I’m excited about how this is going to change the development of new host applications. Prior to the release, I was given access to HostConnect, a native .NET software development kit, and used it to create a couple of applications that connect to GEM equipment.

In developing those applications, I quickly became familiar with the layered architecture of HostConnect. HostConnect has four layers; each layer name and relevant classes is shown in the image below.

HostConnect_Layers.jpg

As with most layered objects, each additional layer adds to the previous layer. Now that I’m familiar with these layers, starting with the first layer, these are the aspects that stand out to me:

  • SECS Messaging: This is equivalent to our SECSConnect product. A solid understanding of the SEMI E5 (SECS-II) and E30 (GEM) standards is necessary to interact with this layer. The user application must be able to construct, parse, and handle asynchronous SECS-II messages.

  • SECS Transactions: This layer adds classes (generically called SxFy classes) to abstract the construction and parsing of many SECS-II messages. It also has the ability to synchronously send and receive SECS-II messages. Automatic message replies may be configured, but none are setup by default.

  • GEM Capabilities: This layer specializes the SECS Transaction layer for use in GEM host applications by setting up common automatic message replies and providing the EquipmentCapability classes (more detail about these classes below).

  • Connection and Discovery: This is the layer I’m most excited about because it is configuration based. The discover feature quickly characterizes an equipment’s GEM interface for HostConnect to use.

After working with HostConnect, I’m reminded of the task that got me acquainted with the SEMI E5 and E30 standards. I was asked to create a GEM host sample application from scratch. A large majority of my time was spent learning specific SECS-II messages and understanding the capabilities defined by GEM. After a few months, the sample application included trace report, collection report, and unformatted recipe management. If HostConnect was available, I’m willing to say I would have been able to complete this task in only a couple of weeks.

Remember the EquipmentCapability classes I mentioned? These classes encapsulate common GEM capabilities, and is one reason I believe I would have been able to complete the sample application in a much shorter time. For example, the EventReports class greatly simplifies report management. Simply register for the EventReportReceived event to receive incoming report data. The report data is parsed and provided in an easy to use parameters object. You don’t need to parse the SECS-II messages, and you don’t even need to know which SECS-II messages are used.

Another reason HostConnect would simplify my sample application, and the most exciting feature to me, is the configuration ability at the fourth layer. HostConnect stores default behavior options and an equipment’s GEM interface within a single configuration file. The discover feature can characterize an equipment’s GEM interface and create the configuration file for you. With a single file per equipment, it would be simple for my sample application to communicate with several different equipment without any code modifications. This flexibility makes HostConnect ideal for developing an application that needs to communicate with multiple different equipment, such as a testing application.

Seeing how much HostConnect does out of the box, but also allowing customization by accessing lower layers, I can say that I wish I had HostConnect when I built my sample host application.

Topics: Announcements, HostConnect

Designing Recipes in CCF

Posted by Derek Lindsey: Product Manager on 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

Fall 2016 SEMI Standards Meeting

Posted by Brian Rubow: Director of Client Training and Support on Jan 18, 2017 11:30:00 AM

SEMI_logo_share.jpg SEMI North America Information & Control Task Force and Committee fall meetings were last held at SEMI headquarters November 7 through 9, 2016. During these meetings, SEMI announced that they are relocating their headquarters to Milpitas, CA. That move is currently underway. In the GEM 300 task force, all of the ballots failed to pass. This include ballot 5872A, 5549, 6026, 6066, and 6068. In the DDA task force, ballot 6064 also failed.

Ballot 5872A is work driven by Cimetrix to complete to work initially proposed for the E172 standard SEDD files, a feature to enable an electronic format for GEM documentation. Ballot 5872A failed due to some minor issues. SEDD files already provide partial GEM interface documentation in an XML file by listing the data variables, status variables, equipment constants, collection events and alarms. The ballot proposes to enhance SEDD files by adding a list of supported SECS-II messages, remote commands, SEMI standards (with compliance tables), and default event reports. The ballot will be reworked and resubmitted as ballot 5872B.

 Ballot 5549A is a title change and organizational change to the GEM E30 standard. Several years ago, SEMI required all standards to have an official designation, such as Guide or Specification. E30 currently has a title that fails to establish an official standard designation. Additionally, the standard currently fails to have the mandatory sections “Purpose”, “Scope”, “Limitations” like other standards. The ballot was delayed several years due to the SML copyright claim by Peer Group and the ensuing legal confrontation with SEMI. The ballot was finally submitted in 2016 and failed because it renamed the Application Notes as an Appendix instead of “Related Information”. Additionally, there was some confusion because the ballot was based on the 0611 version of E30 rather than the 0416 version which had just been published. This ballot will be reworked and resubmitted as ballot 5549B.

 Ballots 6026, 6066, 6068 and 6024 are reapproval ballots for standards E109, E130/E130.1, E116/E116.1 and E121. SEMI automatically submits all standards for re-approval every five years if a standard has not been revised. These standards all failed due to outdated references. They will all be resubmitted in 2017 with minor changes to correct the outdated references.

 The new GUI task force was approved to create a new major revision of the E95 standard. In particular, the new revision will accommodate new software and hardware technology when laying out equipment user interfaces.

 Cimetrix proposed a new activity to define new SECS-II messages for transferring recipes. The activity will result in a new ballot 6614. Currently, the GEM standard defines two ways to transfer unformatted recipes. Using simple Stream 7 messages S7F3 and S7F6, the entire recipe is part of a single message. This makes is really easy to implement in the host and equipment GEM software, but recipes are limited to about 16.7 MB (the maximum size of a single data item in any SECS-II message). The second way is using the large recipe scenarios which involve using a sequence of messages S7F43/F44, S13F1/S13F2, S13F3/F4, S13F5/F6 (repeated iteratively until there is an error), S6F11/F12 and finally S13F7/F8. Even for an expert, this is very complicated. Ballot 6614 will propose simple new messages for transferring a large recipe using a single message where the recipe can be broken up into multiple parts where each part is up to 16.7 MB in size. If approved, another ballot will attempt to add this to GEM standard. This will open the door for the GEM standard to be used more effectively and in more application where the 16.7 MB limitation posed an issue.

 Japan Information & Control committee (I&CC) announced the official withdrawal of OBEM standards E98 and E98.1. Japan also announced a GEM300A initiative which includes standards E170 and E171 and E174. E170 is the Production Recipe Standard which allows equipment to designate production and non-production recipes; where production recipes are given change protection. E171 defines predictive carrier logistics. Ballot 5601 defines Wafer Job Management. It is not clear whether or not there any IC makers will demand any of these newer standards. Of the three, E170 seems to be most useful and interesting. Predictive carrier logistics seems to be useful only for equipment that have carrier internal buffers. It attempts to help the equipment report when carriers will be ready for removal. It is not clear how E171 will compete with the upcoming E87 ballot 4946 to be submitted by the Korean Information & Control Committee in 2017. Ballot 4946 modified the E87 standard to predict when carriers will be ready to unload. Wafer Job Management is a controversial standard. Japan I&CC announced the passing of ballot 5601 (now E174) despite the strong opposition by multiple knowledgeable voters in other regions, and despite very underwhelming support from regional leaders in North America, Korea, Europe and Taiwan.

 Korean Information & Control committee announced plans to submit ballot 5832, a proposal for a new Generic Counter standard which is built upon the GEM standard. The standard would allow an equipment to define various types of generic “counters” that can be reset by the host. The counters could be used a wide variety of applications; particularly predictive maintenance. The standard as defined in the current ballot defines digital counters, analog counters and collection event counters. Voting period for this ballot just ended recently.

 Next North American I&CC meetings will be held first week in April, 2017.

Topics: SEMI Standards, Semiconductor Industry, SEMI

Create Operator Interface Screens Using CCF

Posted by Harley Pebley, Software Craftsman on 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 on 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 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

Leveraging GEM

Posted by David Francis: Director of Product Management on Nov 28, 2016 11:30:00 AM

One of my favorite gifts when I was a kid was an erector set. I could build all kinds of machines and robots. The set I had even included a simple motor, so I could make things move. I spent a lot of hours building machines and robots and dreaming of doing that on a bigger scale.

When I graduated from college I worked for a small company that did warehouse automation and automated transport control systems. It took me back to when I was a boy building robots with my erector set. Except these robots could actually move things and had a full set of commands to control them, not just on or off. The company I worked for had a small group that did firmware programming for the robotic controllers. I worked in the software group that wrote the software systems for controlling the whole automated warehouse. I soon learned that each type of automated equipment had its unique set of commands and that just because two pieces of equipment might perform the same function, didn’t mean they used the same commands.

Along the way I had the opportunity to work with Motorola to develop cell controllers for one of their new, state-of-the-art fabrication facilities in Austin, Texas. This opened up a new world of automation for me. The SEMI Equipment Communication Standards (SECS) were fairly new and still trying to gain wide acceptance. There were a lot of similarities to the automated material handling equipment I had been working with. Each piece of equipment had a defined set of SECS messages it supported, but each tool had to be carefully characterized in order to know how to create the cell control application that would interface with it. It was exciting to bring new tools on line and see the benefits in reduced scrap and improved throughput. But it took a lot of time to develop the cell controllers and there wasn’t much code that could be reused from one to the next.

During this time, I had the opportunity to attend some SEMI standards meetings and participate in discussions about the development of a Generic Equipment Model (GEM) to achieve more consistency across different companies’ SECS interface implementations. It made so much sense! I had built a good business doing equipment characterizations for semiconductor manufacturing companies, but it seemed like there should be a better way of interfacing with the equipment – a more standard way. As the adoption of GEM grew in the semiconductor manufacturing industry, the cost of developing equipment cell control applications decreased. Much of the code could be used across different pieces of equipment, because there was a standard for interfacing with all equipment.

While GEM was developed by and for the semiconductor industry, it could also benefit many other industries. GEM provides a standard way to control a factory and gather equipment and process data that can be used to measure and monitor Overall Equipment Effectiveness (OEE), implement Statistical Process Control (SPC), manage material queues and WIP levels, and a wide range of additional factory applications. Several parallel markets (PV, LED) have adopted the GEM standard to take advantage of commonality required by the standard. Other markets would also benefit by adopting the GEM standard to help increase software reuse and productivity

 

Topics: SECS/GEM

Subscribe to Email Updates

Follow Me

Learn More About the
SEMI Standards

SECS/GEM

GEM 300

Interface A/EDA

PV2 (PVECI)