Letters to the Editor: SEMI Standards Redux

In a recent editorial, I criticized SEMI for being behind the times when it comes to its standards program (see "It's Time for Online, On-Time Standards ," Semiconductor International, October 2003). We've had many interesting responses to that editorial, and we offer here a few of them. First, a letter from Bruce Gehman, SEMI's vice president of standards and CTO, sets the record straight on a few items. This is followed by a note from Intel's Dave Bloss, explaining why he believes the standards-setting process needs to be faster; and various responses to Bloss's comments and to the original editorial. — Peter Singer

There's an old joke at SEMI: "Standards are wonderful — but nobody in the media is interested in writing about them." We at SEMI thank you for putting this old joke to rest with your editorial published in Semiconductor International (October 2003). By shining a spotlight on the issue of semiconductor industry standards, and SEMI's important role in developing them, you have done the industry a great service.

However, in order to set the record straight, I would like to address some of the points made in the editorial:

• NIST does not publish semiconductor industry standards. Only SEMI standards focus exclusively on standards supporting semiconductor manufacturing.
• The SEMI standards program started 30 years ago in an effort to control the proliferation of silicon wafer sizes. Factory automation standards started later (in the 1980s).
• The SEMI standards program has continued to evolve, but the basic scheme (voluntary consensus) is still a core value. Balloting for approval of the technical content of SEMI standards is via web-based electronic voting. Resolution of negative votes and other important matters are handled in face-to-face meetings.
• The most time-consuming aspect of generating standards is the development of technical content by the participants. The rest of the process is completed relatively quickly, in 45-60 days. SEMI standards are truly global, which means additional time is required to gather and gain consensus.
• The $22,440 (member) cost you cite for purchasing SEMI standards is for an Unlimited Download Package, appropriate only for the very largest organizations wanting to use the standards throughout their worldwide workforce. A single standard can be downloaded from the web for $50.
• Finally, SEMI began Internet-based voting for standards in 2000 and implemented this system worldwide at the start of 2002.

We recognize that our standards development work, like all business processes, can be improved and streamlined. We are committed to making continuous improvements for the benefit of SEMI member companies and the industry at large. We appreciate your interest in SEMI standards and look forward to continued dialog with you on the improvements we will be making in the future.

Bruce Gehman
Vice President for Standards and CTO
SEMI

Singer replies: One of the things that compelled me to write the editorial on SEMI standards was a mention in an article by Dave Bloss and Devadas Pillai of Intel Corp. (see "E-Manufacturing Opportunities in Semiconductor Processing ," Semiconductor International, July 2001). The article stated the following with regard to e-manufacturing (and e-diagnostic) standards: "Another concern is whether standards-setting bodies can keep up with cycle-time reduction expectations that users of this capability will demand. At the current time, the process is rigid and not built for speed. Using Internet capabilities for streamlining standards ballot submission, voting and approval loops will be necessary to attain a 10× reduction in cycle time for this process."

Following is an expansion from Bloss on this statement, as well as responses to Bloss's viewpoints.

The requirement of 10× reduction time came from historical data on standards development cycle time coupled with our need to meet the requirements in the ITRS. We have been seeing standards take on the order of 2-3 years to be developed and approved, which is about the same timeline that the ITRS lays out for overall technology node development and rollout. We would like to see the turnaround time be in the ~2-4 month timeframe (perhaps incomplete but usable revisions occurring every 2-4 months instead of the big bang approach of today) in order to address the following issues:

• As in industry, we must anticipate detailed, integrated specifications at least one entire technology node ahead. This is fine for basic stuff like Ethernet adoption, etc., but difficult to impossible for detailed specs that have not been implemented before, like 300 mm standards (E40/E87/E90/E94). Even in the most recent SEMI voting cycle, the core set of 300 mm standards are changing due to learnings from implementations. We are not sure these will be implemented (or even accepted in some cases), since the cycle time is too long to intercept current implementations in factories being built today — custom solutions will already be in place by the time the revisions pass.
• Currently, we see no effective procedure in place to prototype/iterate standards during the development process. Interface A attempted to pass an interim standard with the thought that this spec would be available for IC makers and OEMs to try out the concepts and technologies, understanding that the spec is not complete and any learnings would be incorporated into the final standard. The TF was formed in March 2001, scope was finalized in October 2001, and the interim spec was passed a year later in October 2002 (including an extra three months to fix issues with the first ballots). The long-term specs (everything needed to implement Interface A) are expected to pass in October 2004 (two years after the interim spec was available; 39 months after the task force was formed). Compare this to XML itself (Table ) — preliminary specs in place at the time the task force started (called a Note in W3C terminology), with implementable specs appearing 15 months later in the form of XML 1.0. SEMI needs a way to kick-start the efforts like a W3C Note.
• Long cycle time inhibits investment during early standards development and increases the overall cost of standards. Since we go from nothing to full standard over a period of about 2+ years without any effective checkpoints (has anyone ever implemented a blue ballot?), we typically see folks waiting for the standard to pass before getting involved to avoid wasting time on standards that will never make it out of task force. The effect is that good inputs to standards come after the fact (causing further cost/delays), and implementations do not start until the standard is totally finalized (causing further delays).

If SEMI can produce standards with a cycle time of about two months, along with a robust process to iterate these specifications, then the effects of these issues can be greatly reduced, enhancing the main benefits of standards: reduced cost and increased implementation speed in non-competitive areas. Harnessing the power of the Internet is key for establishing standards (content, communications, progress report) to people worldwide. Accessibility to (standards) work-in-progress and invoking online editing will greatly speed up development and collaboration efforts needed to get good working standards quickly adopted. From historical data, this may reduce overall standard cycle time by ~1-4 months — pre/post-voting document formatting takes 3-4 weeks and post-committee approval work takes ~1-3 months today.

SEMI has taken some steps to improve along these lines, but they are not all the way there yet. Allowing voting to occur on a more frequent basis and exploiting the Internet to ballot, etc., has helped, but we really need drastic changes to get the results we are after. It seems that a process to encourage early implementations and also to iterate specifications over the development cycle of the standard itself would go a long way in closing the gap.

Dave Bloss
Automation Integration Manager
Technology and Manufacturing Group
Intel Corp.

In studying Dave's information, it seems clear that he and his Intel colleagues know the W3C activity better than they know SEMI's.

A SEMI task force often produces several revisions of a developing standard's text in a year's time. They are "drafts," familiar to all those working on the project, but not made public (W3C seems to call these "notes"; it is not clear if these are widely available). If the parent SEMI technical committee wishes, an interim "proposed standard" can be published. Dave wants frequent "incomplete but usable revisions," but does not seem aware how he can get the advance information he wants by being active in SEMI.

Intel's business risk in early use of a W3C development before its final version is no different from the risk in using a preliminary draft of a SEMI standard. The timing is much the same. SEMI discourages use of its drafts, for obvious reasons, but that does happen. In the end, the implementation problems and risks commonly fall on the supplier anyway.

It is really unfortunate that this discussion has to be done this way. I have heard Intel and others complain before in the same misinformed way. In nearly every case, they only "know" the urban legends about how the SEMI standards program doesn't work, not troubling to learn more. That's a bum rap.

No, the process is not perfect. Yes, many of us are working to make it more responsive. Those who complain would help themselves a great deal more by joining us in that effort.

Robert I. Scace
President
Klaros Corp.

The information from Dave was very enlightening. I was personally unfamiliar with W3C, and took the opportunity to look them up to see if there was something that we could learn from them. What I found was a loosely organized sort of organization that develops "recommended practices" for software implementation. They are not incorporated, and do business under the auspices of three universities. It appears that they do not control the commercial interchange of products, and only agree upon the format and schema used to move information around. While this is a very important part of the worldwide business picture, it is very different from the SEMI charter.

Insofar as the process is outlined in the W3C website, it appears that the process is designed to get something out quickly, even if it is incomplete. Member companies are the only ones who may participate formally in the development of a practice. My supposition is that, since participants are assigned by their companies to develop these practices, they devote substantial time "on the clock" to perform these tasks. The meeting schedules seem to be flexible and can be called frequently as web conferences where relatively binding decisions may take place. Upon the recommendation of the task force or working group, the committee chair may decide that the practice is ready to publish. There is a comment period during which a member may object, but participation from the general population does not seem to be widely sought. Once the comment period is completed, the committee chair decides if the practice is to be published, even if there are objections to it. There is a voting process that may be used, but it does not seem to be for the purpose of adjudicating negatives; only to decide if the document goes forward. In particular, section 3.3.2 Recording and Reporting Formal Objections states that dissenters cannot stop a group's work simply by saying that they cannot live with the decision.

SEMI Standards are designed to facilitate the commercial interchange of goods and services, so must service a much different clientele with much different goals and objectives. In fact, some SEMI safety guidelines have been codified by municipalities, and they carry the weight of law. The SEMI process is governed by a set of regulations that intentionally limit the power of one entity over others. The anti-trust laws of the United States and existing case law place limits on the power of a standards organization to restrain a company's ability to compete. SEMI requires an open process for balloting potential standards, and any objections to the acceptance of the standard must be heard and formally acted upon in an open meeting. The technical committee, not the chair, makes the final decision on the technical merit of the dissenting opinion, and the regional standards committee reviews the technical committee actions for procedural compliance. To date, there have been no successful legal challenges to the SEMI process, unlike some other U.S.-based standards organizations.

The SEMI process, while more formal, is probably more able to withstand legal challenges than the W3C process. In particular, section 3.3.2 of the W3C process seems to be an open invitation for a Restraint of Trade lawsuit by anyone who feels his ability to do business was hindered. But since the W3C practices do not seem to play in the commercial interchange of goods and services, their model may be acceptable in their regime.

One final note is the role of the contributing members. The W3C model appears to be that individual contributors are assigned specifically by their company to accomplish this task. One would surmise that these individuals are given time "on the clock" to do this work. In SEMI, the participants are largely volunteers who initially were assigned to "make sure that their company does not get hurt." They often decide that participation is a better course of action, but few of them have SEMI standards development activities as a line item in their job description. More often than not, the company attitude is, "You can go to SEMI, but don't let it get in the way of your real job."

SEMI is not a perfect place; we often do not get standards out as quickly as we would like. However, the standards that are in place have been and continue to be used to govern the commercial interchange of products to the benefit of the global semiconductor community. If specific companies desire to have standards developed, then they should step up and make the commitment of their people's time and talent to make it happen. Comparing SEMI's legal and commercially impacting standards to software protocols from an informal consortium is like comparing apples to bowling balls. Most importantly, standing off to the side complaining that the volunteers from other companies do not do their bidding is non-productive.

From an experienced but anonymous leader in SEMI standards whose employer is a supplier to Intel.