An Interview with David Bricker, Semitool Corporation:
SECS/GEM as the Foundation of “Modern Era” Software Standards
Interviewed by Paul Trio, SEMI
David is a co-chair for the Information & Control committee as well as the leader for the GEM300 task force. In task force meetings, his leadership harmonizes the different expertise and personalities of his group members. Between meetings, David communicates with his team regularly to foster consensus-building. Furthermore, his thoroughness and attention to detail produces well-written ballots. As a co-chair, his grace under fire and clear focus of the objectives enables the committee to work efficiently and in unity. Also, his timely response to staff requests, from committee meeting minutes to A&R ballots, guarantees no loss in momentum. (Information & Control Committee). He was the recipient of the Standards Leadership Award in 2006. The Leadership Award is given to an individual for providing outstanding leadership in guiding the SEMI Standards Program.
Paul Trio (PT) of SEMI: The continued importance of SECS/GEM as the foundation of "modern era" software standards. How do you think these standards are viewed by the industry today?
David Bricker (DB): SECS/GEM will not go away any time soon. Because the transport layers for GEM (E4 and E37 HSMS-SS) are point to point, and a single point of control is deemed necessary for tool control, GEM will be the control communication mechanism for fabs for quite some time. Regarding SECS, we don't have many complaints except some limitations on message size. GEM is aging a bit. The remote commands are not needed on most tools that implement process and control jobs. Complaints about the E30 GEM standard are usually about requirements for spooling and limits monitoring, which in actuality are not used or not implemented according to the E30 standard. E30 recently got an infusion of new life with the addition of E139 "Recipes and Parameters" as a recipe management method. When 300 Prime is mentioned, some people are eager to revamp E30.
(PT): The Global I&CC and its task forces have created suites of standards (SECS/GEM, Interface A, sensor bus) of which some are interdependent. What are the benefits and risks of this type of interrelationship?
(DB): The benefits are similar to that of breaking a problem into manageable pieces. Also, this allows for reuse. As an example, E139 RaP (Recipe Management) is making use of E132 (part of the EDA suite).
One risk involves updates to any of the standards that make up a suite. Sometimes changes in one standard result in an incompatibility with another standard in a different suite. This is usually due to an oversight of the interdependence of the separate standards. No one person has enough domain knowledge to prevent this from happening altogether. However, the International Equipment Engineering Task Force works with multiple task forces of the I&C to try to prevent these incompatibilities. Compatibility problems can also arise out of different revisions of the standards.
Another problem can occur when a suite becomes very large. E54 now has 20 subdocuments. It is a challenge to make sure that corresponding updates are made to parent documents and other related documents when the subdocuments are changed.
If a suite of standards is only made available as a package, it is difficult to determine which technologies represented by the subdocument are being used and which ones are falling out of favor.
(PT): What do you see coming on the horizon for software standards? What standardization efforts (technology, focus, area) do you foresee I&CC would engage in the next few years? What challenges do you see happening with the continued use of current protocols?
(DB): The semiconductor industry is moving toward web services and XML. The ability to support multiple clients with web services is powerful as it allows for distribution of data to multiple systems in the fab as well as the vender for customer support.
It would be beneficial to leverage existing web services standards in making standards for use by SEMI members. Why reinvent the wheel when you can use open-source standards? This also helps in human resource acquisition for all parties, because knowledgeable people may be hired from other industries.
SECS-I messages are limited to about 8 mb, HSMS messages are limited to about 4 gb, and SECS-II item lengths are limited to about 16 mb. These are size limitations that could be prohibitive for transport of very large recipes or metrology/summary data.
EDA can actually extend the life of current communication interfaces such as HSMS. Without EDA, the primary SECS/GEM connection would have to be used for control, data, and recipe management. This situation would cause data collection to be voluntarily limited by the factory automation department at the fabs because they couldn't allow rapid data collection or large recipe file transfer to delay important collection event messages which may need to be acted upon quickly by the host control system. With EDA in place (and soon the possibility to transfer large recipe files via web services), the HSMS-SS connection has plenty of bandwidth for control messages and transmittal of event messages necessary for control.
(PT): How important is it to control Standards revisions to keep implementation costs under control as well as to avoid confusion among users?
(DB): The answer varies depending on who you ask and seems to vary region to region. Changes to standards that require implementation changes on behalf of many suppliers/end-users/third parties should be avoided if possible. Return on investment must be analyzed, but this data is very hard to obtain. The newly formed Manufacturing Technology Forum (MTF) can help us in that regard.
Standards changes that are clarifications that affect a few suppliers that made odd interpretations of the standard are not very costly and actually reduce confusion. Most of the functional changes are driven by IC Makers; requests for standards changes for clarification usually come from equipment suppliers.
The question of backward compatibility and the cost of becoming compliant to the latest standards comes up frequently during ballot adjudication by the GEM300 Task. Many users of the standards realize that when a standard changes it is not always necessary to implement the changes immediately. Implementation of changes must be addressed on a case by case basis; considering when the change is needed and how much benefit the supplier and/or IC maker gains from the change. I review a lot of purchase specifications and some IC makers are still requiring (using) versions of the 300mm standards that are 4 or 5 years older than the latest revisions. This shows that it’s okay to be compliant with an older revision in some cases.
Programming styles and modern programming languages that are highly flexible can greatly reduce the cost and time needed to change to meet evolving standards.
It is best if a standard is prototyped before it is ever accepted. The Standards Improvement Task Force of the I&C has promoted this as well as documentation of requirements as an effort to reduce changes after the standard has been initially printed. Including clearly defined requirements in the standard facilitates the creation of test methods, test plans and, if applicable, test software (e.g. the Brooks Envoy test suite for testing 300mm SEMI standards). Using the test plans and test software allows the suppliers to create a product with some assurance that it will be acceptable to the end user and analogously the device makers have some assurance that the interface is compliant and will be interoperable with their host systems.
The bottom line, I think, is that we need to do a better job when creating standards. It is better to treat the cause of the problem than the symptoms (frequent revisions).
—David Bricker was interviewed by Paul Trio of SEMI on February 12, 2008.