The Challenges of Implementing the 300mm SEMI Standards

摘要

A core set of SEMI standards comprise the "300mm standards": E30 (Generic Equipment Model),rnE40 (Processing Management), E94 (Control Job Management), E87 (Carrier Management), and E90rn(Substrate Tracking). These standards give a factory host the ability to tell equipment which materials tornexpect, how to process them when they arrive, and how to inform the host about their progress. All this isrnnecessary to minimize the possibilities of misprocessed materials.rnBut how difficult has it been for equipment vendors to implement these standards? The shortrnanswer: Very! A number of challenges had to be conquered before arriving at a good, stablernimplementation. This presentation lists the major challenges, and how one company solved them.rnThe first thing was the sheer size of these standards. If one includes the supporting standardsrn(E37, E39, and E84), there are about 300 pages of details to read and thoroughly understand.rnThe standards were a moving target. During implementation the standards underwent severalrnrevisions. Constants were defined, new services added, and mappings to SECS-II messages were changed.rnKeeping abreast of all these changes required constant attention and, in some cases, undoingrncustomizations that covered the gaps that being filled by the later revisions.rnMost of the standards are complex, requiring much effort. For example, consider the E87 carrierrnverifications scenarios. The equipment must report proper carrier attributes to the host at certain times.rnThe host may send updated carrier attributes to the equipment, but not necessarily within a single messagerntransaction. The equipment software must track these updates correctly.rnWithin a given standard one will find varying degrees of ambiguities, contradictions, and holes.rnSelf-contradictions and holes are few, but ambiguities are many. Alarms were defined but their triggeringrnconditions were not described. Error scenarios were missing. A few object attributes were not clearlyrndefined. Error codes and services were defined but not mapped onto SECS-II message transactions andrndata items. An object's attributes may be declared modifiable, but in practice cannot be modified after thernobject is created.rnThe interaction between standards is also subject to ambiguities and holes. For example, if somernProcessJobs terminate abnormally and others complete normally, what is the correct state transition of thernControlJob running it? For another example, what is the interaction between a ControlJob'srnProcessOrdrMgmt attribute (which governs when to initiate all of its ProcessJobs), and the ProcessJobs'rnPRProcessStart values, some of which are AUTO and the remainder are MANUAL?rnPortions of the standards are also interpreted differently by different equipment vendors or buyers.rnThe differences become a problem when using commercial test packages to test all equipmentrnimplementations. If the equipment passes a particular test, does the test provide adequate coverage or is itrntoo shallow? If equipment fails a particular test, is it because the implementation is incorrect or because therntest software is incorrect? If the test software is incorrect, will the equipment buyer still require thernequipment to pass the test?rnFinally, different device makers may force an equipment vendor to tailor the equipment softwarernto accommodate the device makers' procedures. The software challenge then becomes further compounded.rnSo how can we maintain our sanity? We will present some solutions that have worked well tornminimize the implementation effort. For example, stay in touch with SEMI through ballots and throughrnmailing lists such as the 300mm mailing list, actively suggest changes and interpretations wherernappropriate, and write the software in a well-designed object-oriented manner that will most easily map tornthe formal objects defined in the SEMI standards themselves.rnThese issues and others will be discussed.