Industry News, Trends and Technology, and Standards Updates

Have you ever had the situation where an application you were using suddenly quits and after a restart you discover you have lost all your work? (If not, then you will someday!) This blog discusses how Cimetrix CimControlFramework^TM handles this situation.

What is persistence and why you should use it?

The problem:

During execution of any and all applications, there is always a risk of execution termination: closing the application prematurely, power loss to the computer, or program malfunction. Normally programs have data in memory that represent the essential data and states of the application up to that point.  When execution is halted unexpectedly, all information that has been accumulated up to that point is in jeopardy of being lost and unrecoverable because what is in memory is not persistent in nature. After the program terminates, any data stored in memory is gone.

Solution:

A typical solution is to immediately write data to disk as essential data is created or changed. It is typical to save such data in one or more files to implement a complete persistent storage mechanism.  This effectively makes each data item “persistent” so that essential information is never lost, even if the program terminates. An application can then recover from unexpected termination by reading the persistent file(s) when the application is re-launched and restoring each data item to its last saved value.

Persistence in CCF:

Two examples of persistence in CCF are explained in the following section.

NVS (Non-Volatile Storage)

When the Tool Supervisor application or a GEM host changes the value of a persistent variable, the new value is stored in a corresponding file in CCF’s NVS facility. When the Tool Supervisor restarts, the values from the NVS files are read and applied to the affected variables during equipment application initialization.

Material Tracking

The CCF product includes data persistence for material (substrates) so that if the equipment application were to terminate, the persisted information about material and its last known movements is loaded and visualized on the GUI.

The Material Tracking package provides a specific service to store the current state of material within the equipment.  When enabled, each material movement will be recorded into a “material map” file on the disk.

A maintenance GUI screen is also provided so the user can identify material that is no longer present, or that is at a different location than last saved. A function to move material out of the equipment is provided to facilitate the recovery process.

Job data persistence

Now let’s discuss how to implement a feature for job data persistence. Job data are sets of values that tell the equipment how to move and process each material item. There are two types of Jobs: Control Jobs and Process Jobs.

• Process Job: Associates a list of material with a recipe.
• Control Job: Collection of process jobs. Also contains material destination information.

Implementing job data persistence in CCF:

1. What to Persist

The Cimetrix CIM300 product (installed with CCF) manages the lifecycle of SEMI E39 Objects for ProcessJobs and ControlJobs. CCF creates job-related data at runtime and stores this data in the ControlJobData and ProcessJobData classes. Additionally, the object attributes and states should also be persisted and later restored.  Both CCF and CIM300 keep a list of the instantiated ControlJobs and ProcessJobs.

CCF Objects to Serialize/Deserialize

CIM300 Objects and API to Serialize/Deserialize

2. Create a Persistence Package

CCF contains a Material Tracking package which has been developed to provide persistence for materials and locations. Let’s define a similar code package with a class (AllJobs) that will contain the serialized strings to be written to disk.

2.a When to write ALLJobs data to disk:

• On SerializedJobsChanged event (add if not handled)
• At start-up immediately after attempt to Load in order to force writing the persistence file for the first time.
• On any CIM40 Callback from CIM300
• On any CIM94 Callback from CIM300
• On SchProcessJob instantiation

The figure below illustrates how the persisted data is written.

2.b When to read ALLJobs data from disk:

• Once on Tool Supervisor start-up after StartFactoryAutomation() but before starting EquipmentControlSystem().

The figure below illustrates how the persisted data is read and applied.

Conclusion

Data persistence is a crucial aspect of any application to prevent the loss of essential information in the event of unexpected termination. By immediately writing data to disk in persistent files, applications can recover from these scenarios and restore data to the last saved values. In the case of Cimetrix CCF software, persistence is implemented through NVS and material tracking, ensuring that variables and material movements are stored and can be visualized even after equipment application termination. To learn more about how CCF handles data persistence and other features, we encourage you to reach out and speak with an expert by clicking the button below.

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.

Do you need to develop complex drivers for the components in your equipment? Let’s see how the CIMControlFramework^TM Communicator Framework helps you accomplish this.

What is the CCF Communicator Framework?

The Communicator Framework simplifies the low-level message handling to and from the hardware by encapsulating the connection between CCF and the device.

As an example, consider how the connection is made between control software and hardware devices. An ASCII serial connection needs a socket connection using TCP, a multi-threaded mechanism to handle multiple messages to/from the devices, logic to synchronize the commands and their respective responses, and several other functions. This is a lot of work when developed from scratch.

As an alternative, CCF provides a built-in ASCII serial connection class to achieve all these quickly. You can simply use this class to create an ASCII serial connection to the component.

What is the specific role of the Communicator Framework?

Each component or device in an equipment provides a set of commands and responses to perform its designated function. The Communicator Framework includes a Transaction class that handles these commands; each command to a particular device is implemented as a transaction.

Consider the case of the Clamp activity for a loadport—the associated command could be “LOCK.” Now let’s see what are our tasks are to implement this command in a loadport driver as a CCF developer.

The first step is to create a Transaction class for the loadport which must be inherited from the base CCF Transaction class. See below for an example that creates the “Clamp” transaction.

In this example, the ClampTransaction class accepts the command Clamp as an attribute. The command which is passed as the attribute to its base class will be sent to the device through the ACSII serial connection.

The next step is to implement a Communicator class to send the command and receive responses from the device. See the sample code below.

The CCF product includes a LoadPort class. Here we initialize the Communicator class with the ASCII serial connection to perform the transaction.

When a clamp activity is needed, CCF calls the Clamp function of the LoadPort to do the clamping. We use the Communicator object just initialized to send the command to the hardware. Note that we did NOT write any code for sending the command or receiving its response because this is the job of the Communicator.  You send the command to the hardware by calling the PerformTransaction function of the Communicator base class as shown below.

Believe it or not… that’s it! We sent a command to the device with very few lines of code in the driver. Now, how do you handle responses from the device? Let’s have a look.

Each device implements different responses to the command set, depending on the manufacturer of that device. This may include acknowledgments, data items, events of various types, and so on. So, whenever the Communicator receives a response from the device, it calls an abstract method on a child class to parse the response. As a CCF developer you must decide what type of response it is, whether or not it successfully completes the transaction, and how to respond to the Communicator as a result.

The example below shows how to parse a response from the device.

Finally, how can we deal with the events from the hardware? From the code above you can see how to indicate that the type of response is an Event, and in this case, it will invoke another abstract method on its child class to handle the event. The CCF developer can then handle it in their code as shown below.

That’s all there is to it. The code segments above provide an example of a basic loadport driver that includes a Clamp transaction.  To implement additional commands for your device, simply add more transactions and call them from the equipment controller. The Communicator Framework will handle the rest of the communication with your device.

To learn more about CCF or other Cimetrix products, click the link below:

Background

The China summer SEMI Standards meeting was convened on August 8, 2023 in Shanghai. Two task forces met; the ABFI (Advanced Backend Factory Integration) and GEM300 Task force in the TC China Chapter. I actively participated in both task forces to closely monitor and comprehend all activities discussed during the meeting.

ABFI (Advanced Backend Factory Integration) Task Force

Ballot 7018, one Line Item revision to the SEMI E87-0921, Specification For Carrier Management(CMS) and E87.1-0921, Specification for SECS-II Protocol for Carrier Management(CMS).

It provides a means for the host or equipment to provide the slot map, which contains information regarding the correct and incorrect placement of substrates within a carrier. Additionally, it supports configuration settings that indicate the slot map is not read and will not be verified against host-provided information.  Furthermore, new related roundtrip scenarios are added to Related Information 1 – Carrier Object ID when the equipment lack the hardware for scanning a carrier’s slot map. This ballot was submitted for cycle-2 voting in February 2023 but received three rejections with a total of five negatives. During the ABFI Task Force meeting, we thoroughly reviewed and addressed these negative items.  Consequently, we will revise this ballot accordingly and submit it to the A&R committee for review. 

1. Line Item #1, Reject from Miyamoto Motoki (Yokogawa)
   • Negative 1 to Line Item #1 :  Accepted and do modification according to negative comments.
   • Negative 2 to Line Item #1-g : Accept and do modification according to negative comments.
2. Line Item #1 Reject from Matsuda Mitsuhiro (KKR)
   • Negative 1 to Document 7018 Line Item #1:  Negatives is not related with this ballot. This negative was not accepted by Task Force.
   • Negative 2 to Document 7018 Line Item #1:  Negatives is related but not persuasive. This negative was not accepted by Task Force.
3. Line Item #5 Reject No.1 from Mochizuki Tadashi (TEL)
   • After communication, voter withdrew the reject.

GEM 300 Task Force

In this task force we proposed two SNARFs, one for a line item revision to E40-1218, Specification For Processing Management, and another for E40.1-1218, Specification For SECS-II Protocol For Processing Management, and another for a line item revision to E94-0819R, Specification For Control Job Management and the E94.1-0819R, Specification For SECS-II Protocol For Control Job Management (CJM).
 
Some background information is useful here. In the semiconductor industry, the E90 Specification for Substrate Tracking, E40 and E94 are used together to monitor the substrate and job status in most 300mm frontend and advanced backend factories. Typically, after completing a job, it is the responsibility of the factory host to check the state of all materials to determine if the job has been successfully finished. However, some factories do not track E90 substrate events, and/or certain equipment types lack the capability to report such events. Additionally, some factories believe that the calculation of processed materials, failed materials and  unprocessed materials in a job should be performed on the equipment side, which then provides the final processed results. These factors make it challenging for the factory host to check the process status (processed, failed or unprocessed) of all materials in a job. As more straightforward data reporting requirements have accumulated from various factories, many equipment suppliers have developed their own means for delivering the processed substrate lists and counts. However, due to a lack of reference standards for these requirements and implementations, many variations exist in the data formats used to serve this single purpose.
 
These two SNARFs include revisions as follows to cover the above requirements and gaps:
1. Add new definitions for the Processed, Failed and Unprocessed state of materials.
2. Add a state matrix to better explain the E90 substrate processing states
3. Add new material processing result-related variables for job (process job and control job) events.
4. Add new object attributes for material processing result of job a (process job and control job) objects.
 

Note that these two SNARFs have undergone formal review, and ballots 7139 and 7140 were created as a result.

This blog provides a summary of the deliberations that took place during both task force meetings. For more information about these standards meetings, or questions about Cimetrix, please contact us by clicking 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.

Richard Howard, Director of Technical Operations, Cimetrix Connectivity Group (a part of PDF Solutions), along with other leaders of the SEMI Fab & Equipment Computing Device Security (CDS) Task Force, were awarded the SEMI International Standards Excellence Award, along with his co-leaders on the SEMI Fab & Equipment Computing Device Security (CDS) Task Force  (Leon Chang of TSMC, Ares Cho from ITRI and Ryan Bond of Intel). The award was announced at SEMICON West.

This award recognizes years of involvement and leadership by Richard Howard and the team in the development of new Semiconductor industry standards, in particular in the area of cybersecurity. Recognizing the urgent need for robust cybersecurity measures, SEMI's International Standards Information & Control Committees in Taiwan, Japan, and North America formed task forces in the fall of 2018 to investigate the feasibility and implementation of standards to address these threats. Over the years, the task forces worked diligently through regular meetings to coordinate efforts and eliminate redundancies.  As a direct result of this work, SEMI recently published its first two Cybersecurity Standards.

"I am very honored to be recognized with the other co-leaders of their respective task forces." said Richard Howard.  "I believe this award also truly recognizes the collaborative, international effort of the many task force members who have worked diligently to develop these initial standards. Our work is just beginning."

"We are extremely proud of the work of Richard Howard," said John Kibarian, PDF Solutions’ President and Chief Executive Officer. "These standards are a critical step toward safeguarding the semiconductor manufacturing infrastructure from the growing threat landscape. Through the dedicated efforts of the leadership of these task forces, and SEMI Standards members, there is a robust framework designed to enhance cybersecurity practices across the industry."

PDF Solutions and Cimetrix by PDF Solutions are exhibiting at SEMICON West 2023 in less than a week and we hope to see you there!

SEMI is the principal industry association that represents the global electronics manufacturing supply chain, and regularly brings industry leaders together to drive the future of electronics and advanced semiconductor manufacturing. SEMICON West is one of its premier annual industry events, and this year’s gathering will take place July 11-13, 2023 at the Moscone Center in San Francisco, California with the theme “Building a Path Forward.”

At SEMICON West 2023, The Cimetrix Connectivity Group (CCG) of PDF Solutions will exhibit our latest software solutions that are designed to improve manufacturing quality and productivity. You can find us at booth #344 as well as a variety of other places during the exhibition. Be sure to stop by any of the following activities:

• John Kibarian (CEO, PDF Solutions) will participate In DAC Research Panel "Why Is Curvy Design an Opportunity Now?" (July 11 at 1:30 pm)
• Greg Prewitt (Director, PDF Solutions) will speak at the Test Vision Symposium on "Enhanced Parametric Test Insights Through Dynamic Data-Driven Test Flow Execution" (July 12, 11:15 am)
• Ranjan Chatterjee (VP, Cimetrix Connectivity Group) will chair the AI/ML Enabled Manufacturing Operations Panel (July 12 at 2:00 pm @ Smart Manufacturing Theater)
• Alan Weber (VP, Cimetrix Connectivity Group) will present "Connecting the Dots: From KPIs to Smart Manufacturing Applications to Industry Standards" (July 13 at 10:35 am @ Meet the Experts Theater)
• Ming Zhang (VP, PDF Solutions ) will participate In a panel discussion "From Assembly Line to Field: The Future Semiconductor Testing" (July 13 at 3:40 pm @ Test Vision Symposium)
• PDF Solutions presentation at AWS booth #1841
• Exensio and proteanTecs daily demos - DAC booth #2449 at 2:30 pm and SEMICON booth #1834 at 11:30 am

At our booth (#344) we will showcase the latest versions of all our industry-leading solutions, as well as our Smart Factory platform, Cimetrix Sapience. Stop by to speak with an industry expert, or contact us by clicking the button below and let us answer all your questions!