Industry News, Trends and Technology, and Standards Updates

Note: this will be the last blog published on cimetrix.com. For all future blogs, please visit our blog on PDF Solutions website.

Background

The SEMI North America, the Information & Control Committee meets three times per year, but this year the schedule is changed due to the SEMICON West  biennial  relocation to Phoenix beginning this year. SEMI held summer meetings in North America on June 2-4 at SEMI headquarters in Milpitas, CA. Like usual, the meetings are hybrid where attendees can join in person or remotely. The first two days are task force meetings including the GEM 300, ABFI (Advanced Backend Factory Integration), GUI, CDS (Fab & Equipment Computer & Device Security ) and DDA (Diagnostics Data Acquisition) task forces with Cimetrix task force leaders. The third day is the committee meeting where final decisions are made (usually) based on task force recommendations. This is a summary of what happened in some of the task forces and the committee meeting.

Note that all ballots that pass in the committee are still subject to a final review by the global SEMI Audit & Review committee, where a ballot technically can still fail when proper SEMI procedures and regulations are not strictly followed. This is rare in the North America Information & Control Committee but can happen and has happened.

A SNARF is a Standards New Activity Report Form. Before a task force can submit a ballot proposing a new standard or to modify an existing standard, the SNARF for this work must be approved by the technical committee.

Note that SEMI publishes a website with all global committee information where anyone can peruse the extensive details. It is at this website: https://www.semi.org/en/products-services/standards/developing-technical-standards.

Leadership Changes

Several leadership changes were approved during these meetings. For the last several years, Brian Rubow has been vice-chair of SEMI North America (NA) RSC Organization. During the NARSC meeting, Brian was nominated as co-chair. Alan Weber was nominated as co-leader of the Equipment Data Publication task force and co-leader of the Fab & Equipment Computer & Device Security Task Forces.

GEM 300 Task Force
Several weeks prior to meeting, Brian submitted a SNARF to the GEM 300 task force members for review. The SNARF proposes developing a new standard that enables secure GEM interface communication using gRPC technology and TLS. The new standard would be an alternative to the existing SECS-I and HSMS protocols used today. Neither of today’s protocols are secure and therefore present a cybersecurity risk. Feedback on the proposed SNARF indicates clear approval that we need a secure GEM protocol. However, the means to achieve security is still up for debate. Alternatives to gRPC offered by task force members include HTTP/2, WebSockets and secure TCP/IP communication. We discussed this a little at the task force meeting and plan to start meeting regularly to discuss and debate the alternatives until a technical solution is selected. We also decided to postpone approving any SNARF for this work until we decided on a technical direction. The addition of a secure protocol will be the big improvement to the GEM standard. Anyone interested in this topic should join the North America GEM 300 task force. The task force approved to work on ballots to modify the well-known implementations in four standards, E30 (GEM), E40 (Process Job Management), E87 (Carrier Management) and E90 (Substrate Tracking). In GEM, we wish to clarify the well-known naming for the Processing State Model collection events. Since every equipment can implement a unique Processing State Model tailored to its operation, the number and name of the Processing State Model collection events vary. We expect each of these ballots to be relatively small. The task force is also working on another ballot (7345) for the E90 (Substrate Tracking) standard related to batch processing. The current E90 standard is unclear how to report when batches are assembled and disassembled. The batch location state model has contradictions between the batch location states OCCUPIED and UNOCCUPIED and the transition tables. The ballot proposes a solution to the contradiction and additional collection events for batch assembly and disassembly. This ballot is ready for review by task force members and will be submitted for voting in the next voting cycle.

DDA (Diagnostics Data Acquisition) Task Force

The DDA task force remains very active while trying to finalize the EDA (Equipment Data Acquisition/Interface A) freeze 3 standards. All activities are focused on this goal. Ballot 7321A proposes changes to the core EDA standards, E120/E120.2, E125/E125.2, E132/E132.2, E134/E134.2 and E179. This ballot intends to be the final ballot for Freeze 3 for these core standards. It introduces one new feature, filtering E125 metadata to allow clients to request a subset of the equipment metadata when calling GetParameters, GetExceptions, and GetSimpleEvents. The other proposed changes reflect issues raised by task force members. These issues were raised either during the last vendor test session or since then as software development teams implement EDA Freeze 3 software. Both line items in the ballot failed and will be reworked for voting in Cycle 7 and adjudicated at SEMICON West in October. By failing the ballot, we can resolve the issues reported in ballot 7321B and resolve a few more issues reported since ballot 7321A was submitted. The final piece to EDA Freeze 3 is an update to the E164 standard (Specification for EDA Common Metadata). This ballot also failed and will be reworked for the next voting cycle. When these ballots (7321 and 7180) are approved and published by SEMI, we expect EDA Freeze 3 to be complete. Then we will modify standard E178 (Guide for EDA Freeze Version) to officially declare the EDA Freeze 3 version. In addition to this work, the DDA Task Force is also working on subordinate standards to E164. Each subordinate standard will standardize EDA metadata for one GEM-based standard, standardizing how to implement that standard in an EDA interface. The subordinate standard for E40 (process job management) is nearly ready for task force review. This work is outside the scope of EDA Freeze 3, only applicable when you implement the respective standard, but still directly related to EDA Freeze 3. This constitutes the bulk of remaining work.

ABFI (Advanced Backend Factory Integration) Task Force

The ABFI task for approved a SNARF to work on E142 to resolve some editorial changes and to add well-knowns to the subordinate standard E142.4. The task force is also working on a ballot to update the recently published E192 Guide for Equipment Adoption Criteria for GEM and GEM-Related Standards. Since this guide was published, two new standards related to GEM were published including the new Cybersecurity standard E191 and a new equipment data publication standard E190. This ballot has been submitted to the task force for review and will be submitted to SEMI in the next voting cycle.

CDS (Fab & Equipment Computer & Device Security) Task Force

SEMI standard E191 Specification for Computing Device Cybersecurity Status Reporting was published less than a year ago. The current version requires a GEM interface to publish two status variables to identify operating system information about the equipment’s factory facing computers. One identifies the computers, the other identifies the operating system manufacturer, name, version and build information. This helps factories identify cybersecurity risks within the factory and request upgrades. Ballot 7311A proposed to enhance the E191 standard by publishing additional information, introducing two additional status variables. One identifies the list of installed updates. The other identifies installed operating system components. This ballot passed and now awaits review by the Audit & Review committee before publication.

Next Steps

The North America Information & Control Committee will use SEMI voting Cycle 7 for the next round of ballots. Ballots are due to SEMI by Thursday, July 24 2025. These ballots will be adjudicated at SEMICON West October 6-8 at the Phoenix Convention Center.

Background

The SEMI North America, the Information & Control Committee meets three times per year, but this year the schedule is changed due to the SEMICON West semiannual relocation to Phoenix beginning this year. SEMI held winter meetings in North America on February 24-26 at SEMI headquarters in Milpitas, CA. Like usual, meetings are hybrid where attendees can join in person or remotely. The meetings include task forces with leaders from Cimetrix on the GEM 300, ABFI (Advanced Backend Factory Integration), GUI, and DDA task forces as well as the committee meeting on Wednesday. This is a summary of what happened in the task forces including GEM 300, ABFI and DDA and other task force activities. There were few ballots this last cycle, but I will also include updates from the Fall meetings in 2024 since I did not create a blog for those meetings.

Note that all ballots that pass in the committee are still subject to a final review by the global SEMI Audit & Review committee, where a ballot technically can still fail when proper SEMI procedures and regulations are not strictly followed. This is rare in the North America Information & Control Committee but can happen.

I also wish to note that SEMI publishes a website with all global committee information where anyone can peruse the extensive details. It is at this website: https://www.semi.org/en/products-services/standards/developing-technical-standards.

GEM300 Task Force

The most recent changes to the GEM and GEM 300 standards include the addition of ‘well-known’ names for all required collection events, alarms, data variables, status variables and equipment constants within each standard. Recent ballots are related to fixing a few errors in these new tables and updates based on other ballots. This work is finally done for the core standards. Next step in this long process is to update the EDA (Interface A) E164 standard and new subordinate standard to require use of these well-knowns and also to update the SEMI E172 SEDD standard to require use of the well-known names in equipment SEDD files. This has taken a couple years to develop, but ultimately will be extremely useful to quickly map host software applications to implementations, both for EDA and GEM interfaces, and to identify GEM data in EDA implementations. Quicker mapping means quicker equipment integration at the factory.

Last fall, the GEM 300 task force passed some minor updates to the E90 substrate tracking standard in ballot 7278. This includes adding a couple new variables related to the substrate attributes not previously called out specifically yet were added more for completeness than usefulness. This winter, another E90 ballot 7316 passed that corrected a long existing spelling inconsistency for variables between E90 and E90.1. This should not affect implementations, yet some implementers may wish to rename a couple of variables in their implementations to match the standard.

Last fall, the GEM 300 task force made similar changes to the E87 carrier management standard in ballot 7279. In addition to adding a few new well-knowns mapping to additional port and carrier attributes, the well-known names for alarms now support port specific alarms. Well-known names were added for the Carrier Complete Prediction state model, recently updated in 2024 with significant changes. Finally, the carrier’s substrate count attribute format was modified from a limiting 1-byte to allowing 4-byte implementations. This is an important improvement for the semiconductor backend industry where there can be hundreds of substrates on a carrier, unlike semiconductor front end where the substrates are typically wafers and limited to 25.

This winter an E157 Module Process Tracking ballot finally passed in its third attempt. This ballot significantly enhanced to support equipment that don’t have a process chamber. The current published standard focuses on reporting recipe execution in a process module, where all the material in the chamber is processed simultaneously. Most importantly, the standard enables reporting when each step in the recipe begins and completes. Many equipment in especially outside of semiconductor front-end don’t have a process module and instead have continuous flow operation. The enhancements to E157 enable reporting the recipe execution on a specific substrate, including when each step begins and completes. This is another example how GEM related standards are adopting to the needs of backend equipment.

Ballot 7312 replaced ballots 7275 and 7276 from the 2024 fall meetings to implement well-known names in SEMI E5, the SECS-II standard. The task force decided to rename E30 well-known names that originate in SEMI E5 with an ‘E5’ prefix instead of ‘E30’. This passed ballot completes the current plans to develop these well-known names in the GEM related standards.

DDA Task Force

Last fall, the DDA task force pass just one ballot. Ballot 7288 resolved a few issues raised by task force members and an update the .proto files to align with the current Protocol Buffers Style Guide. By conforming to the Protocol Buffers Style Guide, gRPC code generators can better adapt to language specific styles.

After the DDA task force met last fall, a group of companies volunteered to test the data collection features using the proposed gRPC interface definitions and updated E134 standard. Previous test sessions had already validated E132 Session Management and E125 Equipment Modeling. A test plan was created and previously distributed to the participants. Attendees alternated connecting with each other’s software as clients and servers and then collecting data. Five companies participated. Twenty-eight issues were submitted of varying severity. Based on this feedback, the DDA task force created ballot 7321 to correct known issues. Since then a few more issues have been reported. The task force ballot failed one of the ballot line items and will resubmit with corrections and a few additional changes for voting in the upcoming cycle. If all goes well, the changes in ballot 7321A will become the core of the EDA Freeze 3 standard. We can hope!

The DDA Task Force is also actively developing a ballot to update SEMI standard E164 which establishes EDA equipment modeling guidelines. New subordinate standards will map GEM 300 standards to a specific EDA freeze 3 implementation based on the well-known items recently defined in the GEM 300 standards and based on the updated primary standard E164 guidelines. This is the final piece to establishing a complete EDA Freeze 3 standard. Client and equipment server implementers can develop software before E164 is finalized.

ABFI (Advanced Backend Factory Integration) Task Force

No ballots were adjudicated in the ABFI task force. Instead, the task force continued several open discussions. We discussed how a ballot from last year was published as a new standard SEMI E192 Guide for Equipment Adoption Criteria for GEM and GEM-Related Standards. The guide was just published in January 2025 and aims to provide a high-level overview and organization of the 40+ GEM related standards and the GEM related 30+ subordinate standards. The guide is meant to introduce the many GEM related standards for newcomers and experts alike. Since the guide was written and now published, several developments have occurred which require the guide to be updated.

• The Computer and Device Security task force in the Information & Control Committee developed a new GEM-related standard, E191.
• The GEM 300 task force expanded the scope for E157 including a title change.
• The Equipment Data Publication task force in the Information & Control Committee developed a new GEM-related standard, E190.

A new ballot was approved to update the SEMI E192 guide with these latest changes.

Additionally, the ABFI task force is planning to update the SEMI E142 substrate map specification to include standardized XY coordinate system mapping.

CDS (Computer & Device Security) Task Force

The CDS task force is actively updated SEMI standard E191, the Specification for Computing Device Cybersecurity Status Reporting. This new standard defines standard status variables on a GEM interface regarding the operating system for each computer in the equipment, such as the name, version and build of the operating system. This enables factories to track the operating systems on the computers and compare this with any known vulnerabilities and request equipment computer patches and upgraded. The standard will be updated to provide more information, although the additional data is not yet completely decided.

Information & Control Committee

A new order of business was introduced in the Information & Control Committee by representatives from the Physical Interfaces and Carriers committee. Our two committees share control of the SEMI standard E84 the Specification for Enhanced Carrier Handoff Parallel I/O interface. Some users are interested in developing a new TCP/IP based protocol be introduced to replace the parallel I/O interface. The discussions are preliminary just seeking interested parties at this time.

To learn more about the SEMI standards, the committees or just to speak with an expert please click the button below. 

Earlier this quarter (16-18 April 2024) Alan Weber and Jon Holt were privileged to deliver the 3-hour tutorial that always precedes the opening session of the annual European Advanced Process Control and Manufacturing (APC|M) Conference. This year’s conference was held in Hamburg, Germany and again co-located with the Smart Systems Integration (SSI) Conference and attracted more than 200 participants across the industry and around the globe.

In a slight break with tradition, rather than diving deeply into one or two APC-specific technologies, Alan and Jon took a broader perspective, covering a wide range of topics that are germane to production implementations of APC and related advanced manufacturing applications. The rationale for this approach is that APC can no longer be considered a standalone suite of applications, but an integral part of an increasingly complex factory information and control system. As a result, APC practitioners should have at least a working knowledge of these necessary complementary technologies.

Against this backdrop, the theme of the tutorial was “Smart Manufacturing System Engineering for Semiconductor Factories;” the target audience included APC and smart manufacturing application developers, system engineers, and managers; and the only prerequisites were a keen interest in improving semiconductor manufacturing capability and control and a desire to understand the broader context of APC.

The session covered a broad range of topics at limited depth to give participants an understanding of how APC and other smart manufacturing applications work together in a production environment. It identified shared requirements such as data sources, standards, implementation technologies, and other system architectural elements that offer a unified perspective on this overall domain. Finally, it listed sources of information for those wanting to explore these topics in more depth.

We were fortunate to have about 120 participants in the tutorial and received positive feedback about the choice of topics and quality of the material. Alan and Jon “tag teamed” the topics shown on the agenda slide below and could have continued for another couple of hours given the attendees’ level of interest. 

A number of participants were especially appreciative of the industry history section, which emphasized how relatively young the semiconductor manufacturing industry is, and how rapidly it has evolved through global collaboration on the development of device and manufacturing technologies, enabling industry standards, and business models.

Other areas of high interest included (with presentation excerpts):

• Manufacturing applications that often co-exist with mainstream APC applications…

• Use of artificial intelligence and machine learning (AI/ML) in a real production setting

• Other implementation technologies that support manufacturing at the gigafab scale

• Key enabling industry standards for all the above, especially data collection and traceability

Even though there is no substitute for being present at an interactive tutorial like this one, If you would like access to some or all of this material, please contact us at by clicking the button below, and we’ll be happy to share and discuss it with you. Who knows… perhaps as a result we’ll see you at next year’s Europe APCM conference.

Next year’s conference will be 10-12 April 2025 in Prague (Czech Republic), so mark your calendars and plan to spend a few informative days in one of Europe’s most iconic cities! And for you music lovers… come early and/or stay after – you won’t regret it.

Background

The SEMI North America Information & Control Committee meets three times per year; spring, summer and fall. This year the spring meetings were held on March 25, 26, and 27 at SEMI headquarters in Milpitas, CA. The meetings include task forces with leaders from Cimetrix on the GEM 300, ABFI (Advanced Backend Factory Integration), GUI, DDA, CDS task forces as well as the committee meeting, held on Wednesday. This is a summary of what happened in the task forces I am highly involved in, including GEM 300, ABFI and DDA. There were few ballots this last cycle, especially compared to the last meetings.  

Note that all ballots that pass in the committee are still subject to a final review by the global SEMI Audit & Review committee, where a ballot can still fail when proper SEMI procedures and regulations are not strictly followed. This is rare in the North America Information & Control Committee but can happen. 

GEM 300 Task Force

Ballot 6836A was modified to address issues raised by several voting members at the fall meetings. In this round of voting, the ballot passed with no rejecting votes and some minor comments from me. Ballot 6836A modifies both specifications E87 Carrier Management and E90 Substrate Tracking. In Substrate Tracking, the substrate object now defines a new optional attribute, “AdditionalInfo”. This attribute is used to designate a list of name/value pair information to be used as needed. The existence of the attribute is standardized, but the usage and values for the names in the name/value pair are custom to be used as needed. For example, an equipment handling multiple substrate types can use a name/value pair to distinguish between the different substrate types. In Carrier Management, carrier objects now define a related new optional attribute “AdditionalSubstrateInfoMap” to store the list of name/value pair information for all substrates in a carrier. These new features enable GEM 300 like E90 and E87 standards to be more easily adapted to all types of equipment and applications.

The Japan GEM 300 task force has proposed ballot 7173 to make minor improvements to the text in the GEM E30 standard. The proposed changes have been submitted to other regions including North America for review. None of the changes are technically significant and should not affect existing GEM implementations.

A few new ideas for ballots were also discussed at the task force. Following are some details on two items that were discussed.

The most prominent new discussion proposes changes to the E157 Specification for Module Process Tracking. Currently, adoption for this standard is limited to equipment that have one or more well-defined or virtual process modules. There are many types of equipment outside of Semiconductor Front-End that do not have a clear concept of a process module like equipment with conveyors moving substrates through the equipment. The new ballot would propose modifications to E157 to define a new, similar state model that can be adapted to report processing details for a substrate rather than a process module. This continues a trend at SEMI to make changes to allow for easier GEM adoption in other industries and more types of equipment.

Another ballot proposes some changes to the new ‘well-known’ subordinate standards to the GEM and GEM 300 standards that establishes standardized names for the alarms, data variables, collection events, status variables and equipment constants required by these standards. While these new subordinate standards have not yet been published, a couple changes are under consideration soon once they are published.

DDA (Diagnostics Data Acquisition) Task Force

• Ballot 7174 was approved to update E128 Specification for SML Message Structures with language to include Transport Layer Security (TLS) because Secure Sockets Layer (SSL) has been deprecated by the Internet Engineering Task Force (IETF). E128 is a key standard in Equipment Data Acquisition communication freeze 1 and 2.
• Ballot 7175 was proposed to update E132 Specification for Equipment Client Authentication and Authorization and the E132 gRPC implementation with several issues found while preparing for EDA Vender Test #2.
  • Line item #1 introduced the most significant change; a modification to the password hash algorithm to be a binary array instead of a string. A binary array is more appropriate due to the software hash functions available to programmers. This line item failed due to a technical error in the ballot. The line item will be reworked to resolve this technical mistake and other errors that were revealed later in the week during EDA Vender Test #2.
  • Line item #2 moves some requirements from E134 to E132 in cooperation with ballot 7176. This ballot adds the requirements to E132 and passed.  
• Ballot 7176 was approved to move requirements from E134 Specification for Data Collection Management to E132 in cooperation with ballot 7175 line item #2. This ballot removes the requirements from E134. 
• Ballot 7191 approved changes to E179 Specification for Protocol Buffers Common Components. The ballot primarily introduces some optimizations to the protocol buffer usage to avoid sending parameter type information twice. This affects both ParameterValueType and ArrayParameterValue in the protocol buffer implementation. The changes also clarify the handling of 1, 2 and 4-byte integers by separating into unique types in E179. 
• A software vender test #2 was held on the day following the North America Information & Control Spring meetings. Anyone implementing client and/or server software was invited to attend. Instead of testing for standard compliance, the purpose of the vender test was to test interoperability and flush out any remaining issues in the EDA freeze 3 standards. This software vender test session #2 focused on previously untested E132 features from software vender test session #1 and will also include E125 tests. Several companies including Cimetrix attended the vender test session, providing both client and server functionality for testing against each other. Although official results of the test have not yet been made public, the primary issue discovered is that the password hash algorithm needs to be clarified. 
• A software vender test session #3 will be held either immediately following the North America Information & Control Summer meetings held in conjunction with SEMICON West in July, or after the Fall meetings in November. This test session will focus on E134 testing. Mid-April the task force will decide when to proceed.
• Future ballots were proposed for E125, E134, and E179 without specific known issues. In addition to the open ballot for E132, the task force can handle making any last minute changes to the EDA standards before EDA freeze 3 is declared.

ABFI (Advanced Backend Factory Integration) Task Force

No ballots were adjudicated in the ABFI task force. Instead, the task force conducted several open discussions. 

• A ballot has been approved to proposed modifications to E90 Specification for Substrate Tracking to accommodate equipment that have multiple substrate ID readers. Currently E90 assumes that an equipment only has one type of substrate and therefore one substrate ID reader. As the GEM 300 standards are implemented on more backend equipment, issues like this are revealed and need a standardized resolution.
• A previous proposal, 6840, to create a Specification for Equipment Adoption Criteria for GEM and GEM-Based Standards was cancelled. In its place a new proposal was approved to create a Guide for Equipment Adoption Criteria for GEM and GEM-Based Standards. A guide differs from a specification because it does not include any requirements. The new guide will help anyone implementing GEM technology understand how the vast number of GEM related standards fit together and when they should be used.
• A new activity was introduced to consider handling substrates with topside and bottom-side identification. More to come as the task force investigates this further. 
  
  

SEMICON West 2024

The next North America Information and Control meetings will be held in conjunction with SEMICON West in San Francisco. The dates will be July 9-11, 2024. Due to the association with SEMICON West, these meeting typically have the most in person attendees.

The amount of data generated in a modern wafer fab is astounding – a terabyte of data can be produced in mere moments. And while the technologies harnessed to build modern chips are at the absolute bleeding edge and have been compared to the sacred by some reviewers, the technology used to gather data and monitor factory equipment is often, surprisingly, not.

Ripping out and replacing shop floor applications is rarely done. And so, when a fab is built, its data acquisition and control architecture is generally as permanent as the bulk gas transports often seen hulking on the exterior. Modern software architecture has changed dramatically over the last 10 years. Yet the fab and its support systems are relatively static as compared to the process equipment needed to build the latest chips. The result of this imbalance and inertia is that fabs are full of equipment generating oceans of bits and bytes while the managers are struggling to stay afloat and man the oars. This problem only gets worse as management climbs the corporate ladder, or the mast, to extend the metaphor. The people in the corporate suites trying to understand and manage the realities going on in multiple fabs are absolutely inundated and clinging to debris in the deluge. No enterprise-level software system was ever designed to deal with this Noachian torrent of data. Out of this necessity fab managers have been employing data center technology and software architectures more commonly used to run social media sites and Amazon than to run factories.

On the 8th of August 2022, Google Search went down for approximately 34 minutes due to a poorly planned software update.  What is surprising about this is that it had been years since Search had suffered an outage like this, and more years hence. Google’s search page is the most heavily visited site on the internet and yet has one of the best availability metrics and performance history.  There are undoubtedly many reasons for this success, but one of the most acclaimed is Google’s application server: Kubernetes.  Named for the Greek word for helmsman or navigator, Kubernetes has become the standard application server for modern software architectures.  Software purists will undoubtedly object, and say that Kubernetes, or K8s, merely orchestrates the deployment of software, but this is no longer true.  K8s has become an ecosystem that hosts scores of other software products that do everything imaginable from compiling, testing, packaging, deploying and monitoring all the code required to keep a product like Google Search running.  

Incidentally, many of the most successful K8s ecosystem products continue the nautical theme with names like Docker, Armada, and Helm.  

In 2015, Google, in partnership with Docker and others, gifted the K8s technology to the open-source community at the Linux Foundation.  The Cloud Native Compute Foundation (CNCF) project was announced at that time with the goal to unify the rather fragmented containerized approach to software deployments. 

At PDF Solutions and the Cimetrix Connectivity Group, we saw this transformation happening and decided to get out in front of it.  We’d been training shop floor engineers to drink from data firehoses for decades, showing them how to tap into the torrents and pull out just the manageable streams they required and were equipped to handle.  Now, thanks to the CNCF, we can build software that handles far more data and still survives in the 24x7 environments that wafer fab production demands. Cimetrix’s Sapience Manufacturing Hub is our answer to this. 

The Hub solves the problem of getting actionable shop floor data to the top floor for the semiconductor industry, akin to navigating between Scylla and Charybdis. Because the most complex wafers take 3-4 months to process through a fab with the number of process steps in the thousands, even dealing with a single wafer lot of data has proved to be an enormous challenge.  Consequently, cost data associated with materials, labor and rework are allocated equally across all the products in the fab over many months. The result is that detailed data about how much a particular wafer costs or the profit margins of a product are buried in the averages.

The Hub is used to gather clean data from the factory floor and aggregate it where it makes sense. Milestone processes are used to report aggregated data by product, order, lot and other relevant factors so that costs can be accurately accounted for at the enterprise level. When the costs for energy, materials and testing go up while yields fall, knowing the details is important.  The Sapience Manufacturing Hub is the first cloud-native platform that can scale using common and well-known data center tools and provide this data in a way that is useful to the corporate suite of applications.

If you want to know more, please reach out to us by clicking the button below. We are a group of engineers committed to working on the biggest and most insoluble problems facing the electronics industry and really enjoy collaborating about all things semiconductor and data science.  

Background

The SEMI North America, the Information & Control Committee meets three times per year; spring summer and fall. This year the fall meetings were held on November 6, 7 and 8, 2023 at SEMI headquarters in Milpitas, CA. The meetings include task forces with leaders from Cimetrix on the GEM 300, ABFI (Advanced Backend Factory Integration), GUI, DDA, CDS task forces as well as the committee meeting on the final day which was held on Thursday instead of the typical Wednesday. This is a summary of what happened in the task forces I am highly involved in including GEM 300, ABFI and DDA. The recent voting cycle included 22 ballots—the most ballots in one voting cycle that we have seen for a very long time.  

Note that all ballots that pass in the committee are still subject to a final review by the global SEMI Audit & Review committee, where a ballot can still fail when proper SEMI procedures and regulations are not strictly followed. 

GEM 300 Task Force

A lot is going on the GEM 300 task force. The following SEMI standards were reapproved: E39 and E39.1. Reapprovals occur every 5 years else a standard becomes inactive.  

Ballot 7066A proposed changes to the SEMI E87 Carrier Management Services (CMS) standard. This ballot failed previous voting, but now time passed as a ‘superclean’ ballot (no negatives or comments during voting). This ballot included a significant change to the Carrier Ready to Unload Prediction feature which is now called a Carrier Complete Prediction. Anyone who implemented Carrier Ready to Unload Prediction will have to make a lot of changes to comply with the new implementation. A primary driver for this change is to accommodate internal buffer equipment where the READY TO UNLOAD state depends on when the host sends a CarrierOut message and the queue of previously requested activities; therefore, not a useful prediction to make. 

The benefit of this new state model is to notify the factory host before a carrier is completed so that the automatic delivery can be scheduled to arrive for pickup when the carrier is ready. This can shorten the time it takes for the factory to move material from one equipment to the next. 

Seven similar ballots 7114, 7115, 7116, 7117, 7118, 7119 and 7120 were submitted respectively for standards E5/E30, E40, E87, E90, E94, E116 and E157 to define a ‘well-known name’ for each require collection events, variables and alarms. The ‘well-known’ names are aliases for mapping purposes; necessary because each implementation can use different names. The ultimate goal of this feature is to make the GEM and standards based on GEM more plug-and-play. This new feature serves at least two purposes. Standard E172 already defines a well-known name attribute in the SECS Equipment Data Dictionary (SEDD) file. In the Equipment Data Acquisition (EDA) standard freeze 3 version, E164 will use this well-known name as well. The regular GEM documentation can also reference the well-known name. To explain the value of this feature, E90 requires a collection event for Substrate Location State Model transition 1. Implementers might define this collection event using any name such as E90_Loc_Unoccupied2Occupied, SLTrans1, SubstrateLocationUnoccupiedToOccupied or CollectionEvent901. Any name is allowed. The new well-known name establishes a standardized alias name called the well-known. 

When ballot 7117 is published, the well-known name table establishes well-known name “E90:SubstrateLocation:001:Unoccupied-Occupied” as the standardized alias for this collection event. This SEDD file can be downloaded through the GEM interface, tell the GEM host exactly which collection event implements the Substrate Location State Model transition 1. During the Information & Control Committee, ballot 7117 resulted in a Ratification ballot handling a long existing E90 naming issue for one status variable. All of the other ballots passed with a simple editorial change. 

A few of the above well-known name ballots included additional line items to resolve issues in the respective standard, mostly editorial or minor. Ballot 7114 included an E5 clarification that Stream 21 Function 17/18 sequence can be aborted by the receiving entity with an S21F0 message. Ballot 7116 included several additional changes/corrections to E87. 

1.    Clarification on the CARRIER SLOT MAP STATUS state SLOT MAP VERIFICATION FAILED, which sometimes was spelled in E87 without the ‘ED’ in FAILED. 
2.    Corrections to Table R1-21 in the table heading.

3.    Carrier object attribute Capacity can now be format code 51, 52 or 54, increasing the allowed carrier size from 255 to 4.29 GB to accommodate carriers not holding wafers but smaller substrates. 
4.    Carrer state model transition 7 includes a new trigger as already described scenario R1-21. 
5.    Scenario R1-20 was reverted to its original design, undoing an error introduced in 2012

6.    And finally, equipment constant BypassReadID was added to E87.1. This equipment constant has been defined in E87 but missing in E87.1

Ballot 9836 proposed some synchronized changes in E87 and E90 to define new name/value pair attributes. The ballot failed due to some limiting details in the value format definition. The ballot intends to allow equipment and factory to agree to using additional substrate content and characteristic information.

The Japan GEM 300 task force is working on improving the GEM E30 standard. The task force proposed a number of minor improvements mostly editorial to clean up several areas with the specification. Although the work was originally proposed to occur in the North America group, the task force decided to handle this ballot in Japan who will meet in December of 2023. Of course, the regional GEM 300 task forces worldwide all share and vote together on all E30 ballots.

DDA (Diagnostics Data Acquisition) Task Force

The DDA task force reapproved three standards: E128, E138 and 145. Additionally, the DDA task force made more plans to complete the Equipment Data Acquisition (EDA) freeze 3 version. Here are the key activities and findings as of today:

• E164 will be modified to incorporate the well-known names from the GEM 300 force. Instead of including all GEM 300 standards directly in the E164 primary standard, each GEM 300 standard will have a smaller, simpler E164 subordinate standards (E164.1, E164.2, …) to define the EDA implementation for that standard. This strategy makes adopting EDA and E164 more flexible to use in industries beyond semiconductor front end equipment.
• Some errors were found in the published .proto files for E132 and E134. New ballots will be submitted as soon as possible to make corrections.
• A software vendor test #2 will be held immediately following the North America Information & Control Spring meetings. Anyone implementing client and/or server software is invited to attend. Instead of testing for standard compliance, the purpose of the vender test is to test interoperability and flush out any remaining issues in the EDA freeze 3 standards. This software vender test session #2 will focus on previously untested E132 features from software vender test session #1 and will also include E125 tests. Anyone interested in joining should contact me (Brian Rubow) or Albert Fuchigami (Brian’s co-leader). Prior to the software vender test session, the task force co-leaders will provide a test plan document and .proto files with corrections in E132 for known issues.
• A software vender test session #3 will be held immediately following the North America Information & Control Summer meetings held in conjunction with SEMICON West. This test session will focus on E134 testing. 

ABFI (Advanced Backend Factory Integration) Task Force

Ratification ballots R2924A and R6925A both passed. This means that the new Consumables and Durables standard is in the SEMI publication queue. 

Additionally, ballot 6948 passed with several great improvements to the E142 substrate mapping standard. The improvements should help users better understand how to use the E142 schema files for more consistent adoption by implementers. 

Spring 2024

The next North America Information and Control spring meetings will be held again at SEMI headquarters in Milpitas, California. The dates will be March 25-27, 2024. Although many attendees were remote during these meetings, I expect many more attendees to be in person at these spring meetings due to the EDA software vender test session.  

To learn more about the SEMI Standards and the work we do as members of SEMI, please click the button below.

The Cimetrix EquipmentTest software product provides a feature for creating a user interface which can be thoroughly customized according to user preferences. The user interface is created as a user control in Microsoft Windows Presentation Framework (WPF) using the standard .NET Integrated Development Environment, and appears as a separate tab following the default “Tests” tab in EquipmentTest. The tab header can also be customized to fit different testing scenarios. Note that the EquipmentTest Pro version is required to develop a customized GUI tab in any plug-in.

This feature is useful for a variety of user types. For instance, factories can run tests back to back on their equipment and use the custom GUI feature to save the output logs as separate files on the system to efficiently identify failed cases. Equipment manufacturers can use this feature to customize their test scenarios and analyze results in a way that enables the comparison of previous test output data to the latest results. Other user types may imagineer all sorts of additional possibilities, making EquipmentTest a truly versatile tool. 

How To Add a Custom GUI Tab To a Plug-in

One can either override or append to the OtherTabs property of the PluginBaseModel class to add as many GUI tabs as needed. The examples below include code snippets for both cases.

The following image shows a general plug-in with two GUI tabs in which the custom GUI has been modified to contain a single button.

Uses for Customized GUIs in a Plug-In

The following paragraphs discuss two elegant uses for customized GUIs in EquipmentTest.

Duplicate a Different Control Panel

If you are a new user of EquipmentTest, you can use the custom GUI feature to recreate familiar interfaces from other test systems. Since the GUI is developed in WPF, you have a great deal of flexibility and control over the layout and operation of the GUI. This means that the tests can be modified to be run according to  specific user selections, and/or additional information specific to the chosen tests can be included on the GUI. For instance, logs can be modified to include more detail than is currently shown on the default screen.

The following Images show the TESTConnect user interface and its recreated GUI on EquipmentTest. Of course, it is not an exact replica, but most of the original functionality can be supported, and with some effort, the GUI could be modified to become an exact match.

Compile On the Fly

The EquipmentTest custom GUI feature enables use of the compile-on-the-fly capability of .NET. If you can dynamically write and run test code, tests scenarios can be changed without editing, rebuilding, and loading the plug-in each time a change is required. this results in a faster and more efficient testing process.

The “Compile” method defined below takes in the test code to be run as a parameter. It is then compiled to create a DLL library with the required references. Any compilation errors are written to a designated TextBox on the GUI through the event handler “WriteLog”.

The following image is a GEM plug-in with an additional custom control panel for dynamically running code. The TextBox is dedicated for writing code, and the various buttons are used to control the testing procedures. This example is part of a project that supported direct execution of TESTConnect scripts in EquipmentTest.

The first task was creating a console application to generate an XML file containing the converted C# test code of the TESTConnect script to be passed as the argument. The next task was developing an EquipmentTest plug-in that loads the XML file and displays each script as a separate test on the example GUI shown below. This example is designed to support any number of tests, and new tests can be added using the “New” button. In this way, you can directly write code to send messages and check to see if the reply message is the expected one. The example also defines wrapper methods to reuse this messaging code and thereby speeding the development process for similar use cases. Console output can be redirected to text boxes designated for logging, and wrapper methods can be defined to log message details. Although this feature effectively enables scripting in EquipmentTest, there are a few drawbacks that must be addressed. Whenever you need to use a new API method, you must add the reference to the required library in the plug-in, rebuild and load it again to continue testing. A good solution is a 'Save' button which allows you to create an XML file similar to the one you initially loaded with the current changes so you can directly load it after adding the library references. Another issue is that the aesthetic feel code written in Visual Studio will differ from that of the text boxes in EquipmentTest.

However, the overall picture is bigger than what I have explained here. You can customize EquipmentTest to run your tests in any way you prefer. If you need more space to write your test code, you can edit the test code in a C# file stored on your computer and directly run it from EquipmentTest. You may or may not display the code on a text box on the EquipmentTest GUI. Moreover, you can also save the generated output logs in a local file as well. It is up to you to further explore this feature.

Conclusion

In the previous paragraphs, we explained what a custom GUI plug-in is and how to access it with a dedicated GUI tab. This is a powerful capability that opens up a wide range of possibilities for all the users of EquipmentTest. We highly recommend that you explore this feature and puttit to good use to increase your testing productivity while reducing the overall effort to achieve results. The EquipmentTest documentation is a great source of additional information, and we sincerely hope we’ve convinced you to give it a try!

Process Recipe Management Custom Message Handling

Process Recipe Management provides a means to transfer process specifications and to share the management of these specifications between the host and the equipment. CCF provides GEM-compliant Process Recipe Management through class RecipeHandler which handles Steam 7 functions used for formatted and unformatted process programs. In some cases, CCF users may want to implement equipment-specific recipe handling, which can be done by extending the methods of RecipeHandler. For example, to customize host-initiated S7F5 for a recipe to be uploaded from the equipment, create a subclass MyRecipeHandler from RecipeHandler, and override the RecipeRequest method.

Follow this same approach to use the customized message handling class properly: before creating the FactoryAutomationServer, create a CimConnectServices and assign it to the CimConnectServices instance. Then create the custom message handling class MyRecipeHandler and assign it to the corresponding property on the CimConnectServices.Instance.

Custom SECS-II Message Handling

CCF provides a mechanism that enables the equipment’s GEM interface to support any SECS-II messages. These can be additional SECS-II messages defined in the SEMI E5 standard but not supported by CCF, and/or they can be custom SECS-II messages defined by and required by the end user or by the equipment supplier. For example, if a user wants to handle a custom message S100F1, they can create a subclass CustomMessageHandler and let it implement the IGemHandler interface, and then initialize it by overriding the Initialize method of CIMConnectServices.

To learn more about GEM interface custom message handling, please schedule a time to talk with a Cimetrix representative by clicking the button below.

This blog explains an approach that Cimetrix CIMControlFramework^TM (CCF) developers can use to dynamically generate ECVs (EquipmentConstant Variables) in source code as a convenient, effective alternative to including them in the default configuration file.

When implementing the GEM interface for equipment, it is often necessary to define EquipmentConstant Variables (ECVs). If the GEM interface is part of a CCF-based equipment control system, you would normally define the ECVs in the Equipment.epj file. However, registering the ECVs with this approach can take a lot of effort in a number of situations. Among them:

• When you need to register hundreds or even thousands of ECVs;
• When you need to dynamically register ECVs based on the specific configuration of an instance of the equipment;
• When you want to register ECVs without changing the EPJ file.

In these cases, dynamically generating the ECVs from the source code easily addresses these challenges.

The rest of this posting briefly shows you how to accomplish this, and how to change and monitor the values of ECVs.

How to generate ECVs programmatically 

After calling ecs.Start() inside Supervisor's Run(), the code sample below generates an ECV.

What you need to be most careful about here is that the ecid and ECV’s name should not be duplicated with other VIDs.

Then you can see the newly generated ECV  in the Equipment Constants screen of the OperatorInterface.

How to change the value of an ECV

The ECV’s value can be updated  through FactoryAutomationServer using the code below.

You can then see a message that the ECV’s value has been changed.

How to detect the ECV’s value change

If you want to detect changes to the ECV’s value, you can receive a callback  by registering ValueChangedHandler as shown in the code sample below.

To Summarize:

• You can dynamically generate an ECV by calling CreateVariable of CIMConnect;
• You can change the value of an ECV by calling SetEquipmentConstants of FactoryAutomationServer;
• You can detect changes in the value of the ECV by calling RegisterValueChangeHandler of CIMConnect.

All are helpful solutions for CCF developers who need to generate ECVs dynamically.

To learn more about this solution and other CCF programming best practices, please schedule a time to talk with a Cimetrix representative.

Background

At SEMI in North America, the Information & Control Committee meets three times per year; spring summer and fall. This year the summer meetings were held on July 10, 11 and 13 in conjunction with SEMICON West is San Francisco, CA. The meetings include task forces with leaders from Cimetrix on the GEM 300, ABFI (Advanced Backend Factory Integration), GUI, DDA, CDS task forces as well as the committee meeting on the final day which was held on Thursday instead of the typical Wednesday. This is a summary of what happened in the task forces I am highly involved in including GEM 300, ABFI and DDA as well as some updates from SEMI.

Note that all ballots that pass are still subject to a final review by the global SEMI Audit & Review committee, where a ballot can still fail when proper SEMI procedures and regulations were not strictly followed.

SEMI

A few changes are happening at SEMI. SEMI is planning to start publishing ‘red-line’ versions of the SEMI standards. Today, when a new version of a SEMI standard is published, it includes change bars on the side to indicate where changes have occurred. The changed section can then be compared with the previous publication to see what changed. While this is helpful to readers, the planned ‘red-line’ versions will identify precise changes using redline strikethrough and underlining to identify the changes. This is a big benefit to the standards community. I look forward to seeing this new feature.

SEMI is planning to add additional digital enforcement to the SEMI standard documents to help enforce SEMI’s copyright to the standards. This should help curb some of the copyright abuse. Every company implementing or using the SEMI standards should have at least one subscription to SEMIViews, https://www.semiviews.org/.

SEMI has hired another technical writer to help keep SEMI standard publication up to date. Recently, the growing queue of standards awaiting publication has affected SEMI standards development. For example, this has caused delays in the DDA task force developing EDA Freeze 3. In the last 9 months, SEMI has already reduced the publication queue substantially and is committed to catching up early in 2024.

GEM 300 Task Force

A lot is going on the GEM 300 task force.

Ballot 7065, an update to the SEMI E172 passed nearly super-clean. SEMI E172, SPECIFICATION FOR SECS EQUIPMENT DATA DICTIONARY (SEDD) defines the XML schema for documenting a GEM interface. Recently the GEM standard was updated to allow transfer of a SEDD file through the GEM interface using Stream 21 messages. Ballot 7065 adds a few new features and changes to the schema files. The most important changes are names for alarms and a ‘well-known’ element to all collection events, variables, and alarms. This ‘well-known’ element is meant to contain a standardized alias so that end users can automatically map an implementation to required items in the SEMI standards. To capitalize on the new E172 ‘well-known’ feature, new ballots were approved to modify E5/E30, E40, E87, E90, E94, E116 and E157 to include standardized ‘well known’ names. These ballots are expected to be completed in time for cycle 7 voting this year.

Ballot 7066 proposed changes to the SEMI E87 Carrier Management Services (CMS) standard. This included a significant change to the new Carrier Ready to Unload Prediction feature. The primary driver for this change is to accommodate internal buffer equipment where the READY TO UNLOAD state depends on when the host sends a CarrierOut message and can be drastically impacted by the carrier-out queue. The ballot proposes to use CARRIER COMPLETE prediction instead, which can be universally applied both fixed buffer and internal buffer equipment. The change has little impact on fixed buffer equipment, where the time between CARRIER COMPLETE and READY TO UNLOAD is typically short and a fixed time. Unfortunately, this line item in the ballot needs some rework before it is ready for acceptance.

The other line items in ballot 7066 passed including a clarification to the ContentMap behavior and an update to the CMS compliance statement. Two requirements related to the ContentMap were in contradiction to each other affecting the ContentMap value when a carrier object is instantiated. The clarification allows the ContentMap to either be an empty list or a structured list of empty lot and substrate ID information. The change only affects the initial value. The compliance statement change adds the missing “Access Mode State Model” to the compliance statement so implementers can declare whether this feature is implemented and compliant.

Ballot 6991 also passed as super-clean (no negative votes) to update SEMI E4 SEMI Equipment Communications Standard 1 Message Transfer (SECS-I). The update removes biased terminology to be compliant with recently updated SEMI regulations. No technical changes were made.

ABFI (Advanced Backend Factory Integration) Task Force

New proposed standards for Consumables and Durables (ballots 6924A and 6925A) both will require Ratification ballots. This means that a few technical changes need to be made for the new standards to be accepted. Ratification ballots R6924A and R6925A will be submitted in the next voting cycle with those technical changes. If this passes, then the new standards will be published. If it fails, then the ballots will be reworked for another voting cycle.

DDA (Diagnostics Data Acquisition) Task Force

The DDA task force meeting was relatively quiet and uneventful for the first time in years while the task force waits for accepted ballots to be published including updates to E125/E125.2, E134/E134.2, and E120.2. No ballots were adjudicated. Ratification ballot R7002 for SEMI standards E132 and E132.2 passed in the voting cycle 4. Meanwhile new versions of E121 and E179 were published by SEMI in April and June, respectively.

Next steps for the DDA task force include updating E164 and planning a ‘vendor test session’. The E164 update is tied to the GEM 300 ‘well-known’ feature mentioned above, where the E164 names and IDs will be synchronized with the aliases added to the GEM 300 standards. The vendor test session is planned to occur during Spring 2024. Any company wishing to participate to validate EDA client or server software against other implementations is welcome. Participants will run through a small set of E132 scenarios, E125 scenarios and E134 scenarios to validate the current standards. Any issues found during this testing will be quickly resolved so that an EDA freeze 3 version can finally be declared. The task force leaders plan to share a test plan before Fall meetings to help everyone prepare.