Next-generation equipment, as well as new lab-to-fab equipment hitting fab production lines for the first time, pose a difficult challenge for integrators of new 300mm standards. It is not like the old days where you could simply understand SECS-I or HSMS, SECS-II, GEM, add a few state models for flow control, hammer out some general data variables and alarms, and then throw it over the wall to the fab's host integration team to make sense of your interface. In the 300mm world, it is a given that you have done the above, and that your SECS-II and GEM package works as your GEM manual dictates and responds appropriately to requests from the host. There was a time when this was a major part of equipment-to-factory integration. Now it is a prerequisite. The challenge is in the release of the 300mm SEMI standards E39, E87, E90, E40, E94 and the new standards E120,E121,E116, E109, PR8-0303,3510,3507,3569,3571, and 3509. When you read the new standards, they can seem like islands to themselves. Pulling all released standards together and applying them to a tool is difficult without having someone experienced leading you through. The standards body answer is to have more people attend the standards meetings and get engineers from each tool supplier to become experts. However, there are too many standards to keep up with, not to mention the costs implied and amount of time it takes. At least 50% of an engineer's time would be needed to keep up. This problem is made worse by the economic downturn. Tool suppliers are laying off software engineers, hoping to keep their domain engineers to maintain their core competencies. This is a fine strategy except that, generally, the software engineers understand the communication elements of their tool and how it applies to standards. This forces tool suppliers to delay investment in 300mm standards until they have an order. It also delays tool supplier shipments, which delays fab deployments. Another problem is that the standards leave too much room for interpretation. One IC maker does not interpret them as another IC maker does. The 300mm standards are certainly much better than GEM, but there is still too much interpretation required from fab integrators and tool suppliers. The problem with the new unapproved semiconductor standards is current network-based protocols rely on heavier clients, which require as much as 2000 bytes/message as opposed to 64 bytes with SECS-II. This will require larger CPUs or multiple CPUs, more memory, more upfront investment in network infrastructure, and, perhaps, special proprietary compression routines. If a required tool-side application programmers interface (API) and host-side API accompanied each standard, it would eliminate tool supplier involvement with the background behavior and changing technology required behind the API to keep up with changing capabilities (for example, creation and destruction of E39 objects, E39 to SECS conversion or any other protocol, state transitions, etc.). If the standard bodies focused on a clear abstraction between the tool-host API and the bits and bytes behind the tool-host API, then the knowledge required to match the bits and bytes could be worked on and even changed without the API abstraction changing. No one cares how the data get from point A to point B, but everyone cares about how his or her program interfaces to it. As with many complex standards, working, adoptable source code can be supplied with each standard, including SECS/GEM. This would be an implementation guide for third-party vendors or a starting base for companies to use the standard. An open source project could be created that applies standards in a fully working model supplied to members, further promoting understanding and acceptance. One only need look at the World Wide Web Consortium to see the fruits of such an effort. The standards body could require third-party software vendors to adhere to the API, and do compliance testing. Microsoft has a model of how to qualify vendors. The standards implementation could be put in hardware as an integrated chip combined with a network interface card and hardware compression technology for the required bandwidth. This would eliminate the need for blue boxes and CPU and memory increases. Aside from the pros and cons, any of these options would require less standards knowledge from tool suppliers and fab host integrators, increasing the likelihood of a tool working in the fab immediately, thereby improving deployment time.
