Journal Title: Wiley Encyclopedia of
`Electrical and Electronics
`
`Call #: TK9 . E53 1999
`
`Volume: Published Online: 27 DEC 1999
`Issue: 001: 10.10021047134608X.W7034
`MonthlYear: 1999
`Pages: unknown
`
`Article Author: D. E. Troxel, D. S. Boning,
`M. B. Mcilrath
`
`Article Title: Semiconductor Process
`Representation
`
`Imprint:
`
`Location: Folsom Book Stacks AVAILABLE
`
`Item #:
`
`CUSTOMER HAS REQUESTED:
`Hold for Pickup
`
`Fred Schubert (schubert)
`110 Eighth Street
`Troy, NY 12180
`
`Page 1 of 10
`
`

`
`44. R. E. Bank, PLTMG: A Software Package for Solving Elliptic Par(cid:173)
`tial Differential Equations. User's Guide 7.0, Philadelphia:
`SIAM, 1994.
`45. A. Brandt, Algebraic multigrid theory: The symmetric case, in
`Proc. Int. Multigrid Cont, Copper Mountain, CO, 1983.
`46. J. W. Ruge and K. Stuben, Algebraic multigrid (AMG). In S. F.
`McCormick (ed.), Multigrid Methods, Vol. 5 of Frontiers in Ap(cid:173)
`plied Mathematics, Philadelphia: SIAM, 1986.
`47. C. P. Ho et al., VLSI process modeling-SUPREM III, IEEE
`Trans. Electron Devices, 30: 1438-1453, 1983.
`48. M. E. Law and R. W. Dutton, Verification of analytic point defect
`models using SUPREM-IV, IEEE Trans. Comput.-Aided Des. In(cid:173)
`tegr. Circuits Syst., 7: 181-190, 1988.
`49. G. Hobler, P. Pichler, and K. Wimmer, PROMIS 1.6: User's Guide,
`Tech. Rep., Vienna, Austria: Technical University, 1991.
`50. M. G. Hackenberg et al., Coupled simulation of oxidation and
`diffusion in VLSI wafer fabrication. In A. Sydow (ed.), Proceed(cid:173)
`ings of the 15th World Congress on Scientific Computing, Modelling
`and Applied Mathematics-IMACS, Berlin: Wissenschaft und
`Technik Verlag, 1997, Vol. 3, pp. 587-592.
`51. S. W. Director, W. Maly, and A. J. Strojwas, VLSI Design for
`Manufacturing: Yield Enhancement, Boston: Kluwer Academic
`." ,/,- "
`Publishers, 1990.
`52. S. R. Nassif, A. J. Strojwas, and S. W. Director, FABRICS II: A
`statistically based Ie fabrication process simulator, IEEE Trans.
`Comput.-Aided Des. Integr. Circuits Syst., CAD-3: 40-46, 1984.
`53. F. Fasching, S. Halama, and S. Selberherr (eds.), Technology CAD
`Systems, Wien: Springer-Verlag, 1993.
`54. O. A. McBryan et al., Multigrid methods on parallel comput(cid:173)
`ers-a survey of recent developments. Impact Comput. Sci. Eng.,
`3: pp. 1-75, 1991.
`55. D. W. Yergeau, R. W. Dutton, and R. J. G. Goossens, A general
`OO-PDE solver for TCAD applications. Paper presented at 2nd
`Annu. Object-Oriented Numer. Conf., Sunriver OR, 1994.
`
`WOLFGANG JOPPICH
`German National Research Center
`for Information Technology
`SLOBODAN MIJALKOVIC
`University of Nis
`
`SEMICONDUCTOR PROCESS REPRESENTATION
`
`Semiconductor chip manufacturers, foundries, research labo(cid:173)
`ratories, and other enterprises all use some sort of represen(cid:173)
`tation of the semiconductor fabrication process in order to
`make or design semiconductor devices and integrated circuits
`(Ie). In their most elementary form, such representations
`may be textual or graphical and intended solely for human
`interpretation. Of much greater use, however, are highly
`structured or formalized representations that can be under(cid:173)
`stood and manipulated by a collection of computer programs.
`The purpose of such a process flow representation is to cap(cid:173)
`ture key information for one or more purposes in the life of a
`fabrication process or semiconductor product, from early con(cid:173)
`ceptualization through design and manufacture. Such infor(cid:173)
`mation ranges from manufacturing details, including instruc-
`
`SEMICONDUCTOR PROCESS REPRESENTATION
`
`139
`
`tions for fabrication equipment or operators, to design
`knowledge about a process under development or optimiza(cid:173)
`tion. Process representation is of particular importance in the
`semiconductor field because of the process-intensive nature of
`semiconductors. That is, the key characteristics of semicon(cid:173)
`ductor products are highly dependent on the specific details
`of the process used to manufacture them.
`There are many ways to describe or document a semicon(cid:173)
`ductor process, and the process flow representation can be
`variously thought of as a language (if it has a textual form),
`a data structure, or, if sufficiently powerful and comprehen(cid:173)
`sive, a knowledge base. Initially, when little is known about
`a process, an overview with many details hidden or unstated
`is desirable. This allows a big picture of the process so that
`at least the intent of the process can be understood. A circuit
`or device designer will generally be concerned with the vari(cid:173)
`ous material layers, how they are patterned (what masks to
`specify), what regions are implanted with dopants, and so on.
`Physical realization of the process requires synthesis of a pro(cid:173)
`cess flow to achieve the designers' intent and typically in(cid:173)
`volves computer simulation of key process steps. A presenta(cid:173)
`tion of the process similar to a programming flowchart shows
`the main flow of control. All of the detailed exceptions, such
`as what happens when something out of the ordinary occurs,
`are hidden. Figure 1 shows the initial sequence of steps of a
`hypothetical but typical process. The process starts with a sil(cid:173)
`icon wafer of known characteristics, and a pad oxide is grown
`followed by a nitride growth or deposition_ A photomask step
`is used to pattern a protective resist layer on the wafer so
`that the subsequent etch step will selectively remove the ni(cid:173)
`tride on specific areas of the wafer. Actual fabrication will
`generally require expansion of this simplified process flow
`and provide details in both sequence structure (sub steps) and
`equipment-specific processing parameters. In the typical ni(cid:173)
`tridation step, for example, the wafer is first cleaned and then
`the nitride material is deposited, using a particular schedule
`of gas flows and temperatures, often called a recipe, in a par(cid:173)
`ticular furnace. Mterward, the thickness of the deposited ni(cid:173)
`tride may be measured as a standard part of the complete
`nitridation step.
`In a real factory, there are, of course, other details that are
`important, some of which are often not written down. Such
`implicit details may be part of the knowledge, experience, and
`training of the fabrication operators, the equipment specialist
`
`Figure 1. Semiconductor process representation involves multiple
`levels of detail. Shown here is a simplified sequential process flow for
`the selective creation of active areas where transistors will be formed.
`
`Page 2 of 10
`
`

`
`140
`
`SEMICONDUCTOR PROCESS REPRESENTATION
`
`CIM system
`
`Scheduler ~
`Wafer/
`lot
`data
`
`Material
`
`Data
`
`Flow
`representation
`
`handling ~ V
`Process V collection
`~ ~ CAD system
`
`r-...
`--'
`Process
`Process
`library
`library
`- - ' " ..... r-- .....
`
`/
`
`'\
`
`Graphic user
`interface
`
`t I
`
`PFR
`text
`files
`
`'-
`
`Figure 2. A unified process representa(cid:173)
`tion provides a common interface to vari(cid:173)
`ous applications. A process representation
`may be created by a user through a com(cid:173)
`bination of graphical user interfaces or
`editors operating on textual process de(cid:173)
`scriptions and may draw process steps
`from one or more process libraries that
`could reside either locally or be accessed
`via a computer network. The process rep(cid:173)
`resentation may be utilized or integrated
`with applications supporting fabrication
`or simulation.
`
`I
`Process
`simulation ~ Sim.
`datal
`~ input
`Recipe
`files
`synthesis
`
`f-
`
`or engineer, or ofthe equipment developer and manufacturer.
`The details may be embodied in multiple places, so that which
`details are used depends on when and where the ICs are
`made.
`With computer representations for the process flow at vari(cid:173)
`ous levels of detail, software programs that use process infor(cid:173)
`mation may perform, for example,
`
`• simulation
`• safety checks
`• instruction formatting
`• data collection
`• data reduction
`• control
`• process analysis and diagnosis
`• scheduling
`• rule-based or intent-based process synthesis
`
`A complete software process flow representation system
`consists of four basic elements: the information model, user
`and programmatic interfaces, a base collection or library of
`processes, and a set of application programs that use or man(cid:173)
`age the process representation, as shown in Fig. 2. These ele(cid:173)
`ments enable the process representation to act as a general(cid:173)
`purpose, unified means for expressing what is already known
`about the process, or what is learned about a process in the
`course of design, simulation, or manufacturing itself. A uni(cid:173)
`fied process representation is one in which the knowledge
`about the process is represented coherently and in a uniform
`fashion in order to bridge and integrate related activities
`(e.g., process design and manufacture). A unified process rep(cid:173)
`resentation organizes the various levels of detail that are es(cid:173)
`sential to the making of an IC and provides a comprehensive
`framework for knowledge about process steps.
`The first element is an information model that specifies the
`type and format of process information that can be expressed.
`In particular, the information model defines the methods for
`
`describing both process structure (e.g., linear sequences of
`process steps or hierarchical decompositions of complex pro(cid:173)
`cesses) and the organization of process details (e.g., details
`about what happens to a wafer during a process as it is sub(cid:173)
`jected to specific gas flows, thermal treatments, etc.). Exam(cid:173)
`ples of the information expressed by a process representation
`include the process structure, control structure, simulation
`results, desired effect on the wafer, processing models, equip(cid:173)
`ment operation or microprograms, scheduling data, and test(cid:173)
`ing and yield results. Once a process representation is struc(cid:173)
`tured around such a model, application programs can be
`written to accomplish particular tasks. For example, a process
`representation may be used to generate fabrication instruc(cid:173)
`tions for people or machines-that is, the representation can
`be viewed as a program that operates on wafers as inputs,
`transforms them, and produces wafers as outputs. Alterna(cid:173)
`tively, the representation can be viewed as data that include
`knowledge as to specifications, documentation, and the ma(cid:173)
`chines or other resources required to manufacture the product
`IC; software programs then use these data to accomplish fab(cid:173)
`rication or other tasks.
`The second key element of a process representation system
`is the mechanism or interface for capturing, storing, and ac(cid:173)
`cessing process information. One simple approach is to write
`a process flow in a prespecified textual format or language,
`which is then read and interpreted by computer. Graphical
`user interfaces (GUI) are generally preferred by users who
`are not programmers; the GUI helps guide an engineer or de(cid:173)
`signer in the creation and modification of process steps and
`the assembly of these steps into correct process flows. In addi(cid:173)
`tion to human interfaces, well-defined and standardized ap(cid:173)
`plication program interfaces are critical to enabling a multi(cid:173)
`tude of manufacturing or computer-aided design (CAD)
`systems to use and manipulate pyocess information.
`The third element of a working process representation sys(cid:173)
`tem is a collection of process libraries, which provide the
`available processes for one or more particular fabrication
`facilities (fabs). Such libraries may also include unit process
`
`Page 3 of 10
`
`

`
`steps and reusable subprocess modules that can be integrated
`by a process designer to create new complete manufacturing
`processes.
`Finally, a process flow representation is of limited value
`without a supporting set of computer integrated manufactur(cid:173)
`ing (CIM) or CAD applications to enable the accomplishment
`of actual fabrication or design goals.
`In the following sections, process flow information models,
`as well as user and application program interfaces and pro(cid:173)
`cess libraries, are discussed in detail. These form the generic
`core of a process representation system. More advanced issues
`and the current state of the art regarding the integration of
`process representations with CAD and CIM applications, as
`well as industry standardization efforts, are then described.
`
`INFORMATION MODEL
`
`The information model is fundamental to creating a shared
`understanding of terms and definitions in a formal process
`representation. At its most basic, a semiconductor fabrication
`process can be thought of as the movement of a silicon wafer
`through a series of process operations or steps, each step oc(cid:173)
`curring in a piece of equipment where the wafer is subjected
`to some treatment that causes some desired change in the
`wafer (e.g., addition or removal of thin film layers, changes to
`material conductivity). The information model details both
`what is meant by process sequence and what can be said about
`what happens during each process step.
`
`Process Sequence
`
`Complete IC manufacturing processes are frequently thought
`of as being divided into smaller sequences of steps or modules
`(e.g., well formation, active area definition, metalization).
`Therefore, a fundamental "chunking" abstraction capability of
`process representations is the ability to describe a manufac(cid:173)
`turing process as composed of sequences of process building
`blocks or components.
`Because each component may itself have subcomponents
`(e.g., subprocess steps), process flows are typically repre(cid:173)
`sented in a hierarchical or tree structure, as illustrated in
`Fig. 3. This hierarchical decomposition also enables modular
`process development, as the same process step (e.g., clean
`steps, thin oxidations, resist development) is often used at
`several points in the same process flow or across multiple pro(cid:173)
`cess flows. In some process representations, the number of
`levels (and terminology at each level) is predefined (e.g., a
`process flow consists of process modules made up of unit pro(cid:173)
`cess steps, which each occur on a specific piece of equipment).
`Such fixed hierarchies have been found to help communities
`of users structure and share complex processes. On the other
`
`.
`
`Masked
`implant
`
`Grow oxide
`
`Deposit resist
`Pattern oxide ~ Develop
`Expose
`~Etch
`Strip resist
`
`~
`
`Implant
`
`Figure 3. A hierarchical or tree decomposition for a masked implant
`process step. Each substep can be decomposed into an ordered se(cid:173)
`quence of smaller substeps.
`
`SEMICONDUCTOR PROCESS REPRESENTATION
`
`141
`
`hand, many process representations do not impose a strict
`hierarchy and provide for arbitrary levels of process sequenc(cid:173)
`ing (e.g., each process step can be decomposed into smaller
`process steps as needed to describe the process to whatever
`detail is desired). For example, while a unit process step
`might be a thermal operation in a furnace, it is often desir(cid:173)
`able to break this into smaller sequences of time blocks or
`events where temperatures or gas flows are changed during
`the process.
`Several process representations have also been proposed
`that deal explicitly with more sophisticated process sequenc(cid:173)
`ing requirements. One example is timing constraints on the
`execution of process steps. It is often critical that one process
`step be immediately followed with zero or finite delay by the
`next step (e.g., polysilicon deposition after a gate oxidation),
`and attributes on a process step have been used to express
`such requirements (e.g., tagging a process to indicate that all
`of its substeps must be done within specified allowable de(cid:173)
`lays). Process sequences may also be conditional on certain
`states or other events. The most common case is rework loops.
`Programming languagelike constructs can be used to specify
`under what conditions a change in the normal process se(cid:173)
`quence is required (e.g., to remove resist after a failed inspec(cid:173)
`tion followed by reinsertion in a photolithography step). In
`process representations that seek to support experimental
`splits or sophisticated feedforward capability, additional
`branching, looping, and other process sequencing capability
`for individual wafers in a lot (or for splitting or merging/
`batching wafers and lots) is also provided.
`
`Generic Process Model
`
`In addition to process sequence information, details about in(cid:173)
`dividual process steps are needed. The second key idea in a
`process representation is that specific information can be as(cid:173)
`sociated with process steps at various points in the process
`hierarchy; this information is usually captured in the form of
`attributes of the process step that express detailed or aggre(cid:173)
`gate information at the appropriate point in the process. An
`example of a scheduling-related attribute is the time required
`to perform an operation, where this time might be the sum of
`the time-required attributes associated with the process
`step's subcomponents. To help organize and structure de(cid:173)
`tailed unit process information, a generic model for semicon(cid:173)
`ductor processing, as conceptually pictured in Fig. 4, has been
`defined. The process representation then supports the speci(cid:173)
`fication of desired states of the wafer, environment, or equip(cid:173)
`ment at various points during fabrication as dictated by this
`generic process model.
`During a process step, a wafer (or several wafers) is con(cid:173)
`tained within some physical environment that has been gen(cid:173)
`erated as a result of settings on a fabrication machine within
`a facility. These settings are, in turn, controlled or dictated
`by a program or recipe. The layering in Fig. 4 indicates a
`number of boundaries: between the wafer and the wafer envi(cid:173)
`ronment, between the wafer environment and machine/facil(cid:173)
`ity, between the machinelfacility and settings (as well as
`readings), and finally between settings/readings and control
`programs. This conceptual layering is loosely guided by the
`physical containment that exists during the processing (i.e.,
`wafers within wafer environments within machines). One of
`these can affect another only through one of the boundaries
`
`Page 4 of 10
`
`

`
`142
`
`SEMICONDUCTOR PROCESS REPRESENTATION
`
`Figure 4. A conceptual model for semiconductor fabrication, identi(cid:173)
`fying groups or categories of state information and interfaces between
`those states as they occur during Ie manufacture.
`
`shown in Fig. 4 or through a chain of such interfaces. Each
`may evolve over time due to internal interactions or as it is
`affected through interaction with the surrounding or en(cid:173)
`closed entities.
`This partial decoupling of entities (or the states of those
`entities) motivates a generic model of the semiconductor pro(cid:173)
`cess to enable identification and differentiation among catego(cid:173)
`ries of state information corresponding to the partitioning
`shown in Fig. 4. In general, a state description may be speci(cid:173)
`fied directly (e.g., to indicate the desired or resulting state) or
`indirectly (e.g., as a delta or change in state that the step is
`intended to accomplish).
`
`Wafer State. Of key interest is the state ofthe wafer at the
`completion of the process as well as at intermediate points in
`the process flow. While potentially infinite in complexity and
`detail, the process representation typically captures only
`those aspects of the wafer state that are necessary for either
`further processing (e.g., states that indicate what materials
`are on the surface of the wafer that enable safety or design
`rule checks) or further modeling (e.g., representations ofindi(cid:173)
`vidual devices to sufficient detail that desired process and de(cid:173)
`vice simulation can be performed). Common descriptions of
`the starting material include crystal orientation, resistivity,
`and carrier type of a wafer. Other state descriptions may in(cid:173)
`clude surface topography, bulk dopant concentrations, thin
`film stresses, and other geometric and parametric properties
`of the wafer. A typical desired change in wafer state is the
`addition or removal of a thin film of specified thickness or
`properties (e.g., deposit a 0.5 /Lm silicon dioxide layer). This
`is also sometimes termed the effect that a process has (or is
`.
`desired to have) on a wafer.
`
`Wafer Environment or Treatment. The wafer environment
`captures the relevant physical environment that the wafer is
`subjected to during processing. This treatment can be de(cid:173)
`scribed as functions in position and time of temperature, par(cid:173)
`tial pressures of ambient gases, and so on. These parameters
`are typically thermodynamically intensive, a property that
`helps to distinguish them from machine state parameters.
`
`Machine/Facility. The machine state might include the cur(cid:173)
`rent machine setup and configurations during operation, such
`as valve positions or the voltages across plates in plasma
`equipment. The machine resides within a facility that has at(cid:173)
`tributes such as gases, airborne contaminants, and staff.
`
`Settings and Readings. Settings correspond to the desired
`positions of knobs or other controls and may vary discretely
`or continuously as a function of time in response to operator
`or automated instructions. Examples of readings are the cur(cid:173)
`rent shown on a meter of an ion implanter and a temperature
`derived from a furnace thermocouple.
`
`Implementing the Information Model
`
`A great deal of progress has been made in identifying a ge(cid:173)
`neric process model for unit process steps, as well as generic
`process sequencing mechanisms. Because of the complexity
`and varying scope of the problem domain, however, modem
`process representation implementations use process modeling
`and representation techniques that are extensible (that is, ca(cid:173)
`pable of easily being extended to accommodate new kinds of
`knowledge about processes for new and different purposes).
`Process representation implementations may be divided
`into three basic types: programming language based, knowl(cid:173)
`edge based, or hybrid systems. In the programming-language(cid:173)
`based approaches, such as FABLE (developed at Stanford)
`and BPFL (developed at UC Berkeley), the process is explic(cid:173)
`itly represented as a program in a specialized programming
`language to be executed. In knowledge-based approaches, the
`process representation is treated as a general knowledge rep(cid:173)
`resentation problem; the Stanford MKS and PDS systems are
`examples of this approach. The hybrid approaches attempt to
`combine the benefits of the other two. The MIT PFR is an
`example of the hybrid type; a textual form can be used to
`specify processes (or the same textual form can be used as an
`interchange format to exchange process information between
`different systems). A sample of this flow representation is
`shown in Fig. 5. Other systems have also adopted a hybrid
`approach; the Texas Instruments MMST system, for example,
`adopts a language-based front end with an object-based back
`end or application programming interface. These distinctions
`are not sharp; for example, a knowledge-based approach may
`also include mechanisms for representing control flow by
`means of explicit computation in an embedded programming
`language. These implementation approaches are closely re(cid:173)
`lated to the human and programmatic interfaces they utilize.
`
`USER AND PROGRAM INTERFACES
`
`A number of possible interfaces, both for human interaction
`and computer program access, can be utilized for the capture
`and expression of specific process flow and unit process step
`information. First discussed are methods for human inter(cid:173)
`faces to the process flow, followed by issues in computer-ac(cid:173)
`cessible representation.
`
`Human Interfaces
`
`Two different approaches (or a hybrid of these approaches)
`have been widely used to enable engineers and operators to
`specify process steps and flows. On one end of the spectrum
`
`Page 5 of 10
`
`

`
`(define cmos-baseline
`(flow
`(:documentation "CMOS Baseline Process")
`( : body
`, , u"
`initial-epi
`well-formation
`active-area-definition
`field-formation
`channel-formation
`source-drain-definition
`bpsg-passivation
`contact-definition
`metal-definition))))
`
`(define well-formation
`(flow
`(:body n-well-formation
`p-well-formation)) )
`
`(define n-well-formation
`(flow
`(:body stress-relief-oxide
`lpcvd-silicon-nitride
`n-well-pattern
`nitride-plasma-etch
`n-well-ion-implant
`resist-ash) ) )
`
`(define p-well-formation
`(flow
`(:body
`n-well-cover-oxide
`nitride-wet-etch
`p-well-ion-implant
`well-drive
`well-oxide-wet-etch)))
`
`"
`
`r,.'
`
`(define active-area-definition
`(flow
`(:body stress-relief-oxide
`lpcvd-silicon-nitride
`active-area-pattern
`nitride-plasma-etch
`p-field-pattern
`p-field-ion-implant
`resist-ash) ) )
`
`(define field-formation
`(flow
`(:body n-field-pattern
`n-field-ion-implant
`resist-ash
`field-oxide
`nitride-wet-etch)))
`
`(define channel-formation
`(flow
`(:body stress-relief-oxide-wet-etch
`dummy-gate-oxide
`n-channel-definition
`p-channel-definition
`dummy-gate-wet-etch
`gate)) )
`
`SEMICONDUCTOR PROCESS REPRESENTATION
`
`143
`
`,} ;,.
`
`!",oA
`
`"
`
`'.
`;,! ,
`
`~!
`..
`, : ;
`
`j
`
`)
`
`(define n-well-cover-oxide
`(flow
`( : documentation
`"Grows a thick cover oxide using a thermal treatment")
`(:permissible-delay :minimal)
`rca-clean
`(operation
`(:body
`(:change-wafer-state
`(:oxidation :thickness (:angstroms (:mean 5100 :range 250))))
`( : treatment
`(thermal-rampup-treatment : final-temperature' 950)
`(thermal-dryox-treatment :temperature 950 :time (:minutes
`(thermal-wetox-treatment :temperature 950 :time (:minutes
`(thermal-dryox-treatment :temperature 950 :time (:minutes
`(thermal-rampdown-treatment :start-temperature 950))
`(:machine Thick-Oxidation-Tube)
`(:settings :recipe 240)))))
`
`30) )
`175) )
`30) )
`
`(define (thermal-rampup-treatment final-temperature)
`(sequence
`(:thermal :temperature 800
`:time (:minutes 20)
`(:thermal :temperature 800
`:ambient :N2)
`:time (:minutes 10)
`(:thermal :temperature 800 :ambient :N2
`:time (:minutes (I (- final-temperature 800) 10.0))
`:temp-rate 10)
`(:thermal :temperature final-temperature
`:time (:minutes 10)
`:ambient :N2)))
`
`:ambient :N2)
`
`Figure 5. Sample process flow representation. Here a textual programming language format is
`used to capture key information about a process flow.
`
`Page 6 of 10
`
`

`
`144
`
`SEMICONDUCTOR PROCESS REPRESENTATION
`
`lies the programming language analogy and approach, with
`engineers editing text files that express process steps as
`somewhat like subroutines or procedures, with the ability to
`identify variables and parameters in those steps to enable
`generalization or reuse of those steps in different process
`flows. From the very earliest work on programming languages
`for semiconductor process representation (e.g., the Stanford
`FABLE system), the need to represent multiple abstraction
`levels or views for process information was recognized, lead(cid:173)
`ing to language descriptions that are somewhat different from
`those in conventional programming languages (e.g., through
`the definition of different code branches or blocks that are
`only applicable to fabrication interpretation or simulation in(cid:173)
`terpretation). At the other extreme of the spectrum lies the
`knowledge or object-based analogy and approach, where the
`engineer locates and adapts (e.g., by specializing or overriding
`default attributes) existing process objects and wires these to(cid:173)
`gether to construct larger objects or flows.
`The process flow language approach can be implemented
`in as simple a fashion as text files that are interpreted by
`different kinds of application programs to accomplish specific
`subsequent tasks (e.g., to run fabrication or simulation tools).
`On the other hand, the object-based approach immediately
`suggests a graphical user interface whereby the user manipu(cid:173)
`lates some visual representation of process step and flow ob(cid:173)
`jects and specifies or edits their characteristics. In practice,
`the distinction between these approaches is not so sharp. In(cid:173)
`tegrated programming or design environments also support
`the building of libraries of process steps and flows, as well as
`guide the graphical editing of either procedure parameters or
`object attributes. Additional search and design aids are typi(cid:173)
`cally desired in both approaches. Maintenance of consistency
`(e.g., between versions of steps and process flows that use
`those steps) is important; process design rule checkers that
`verify that safety or other requirements are satisfied are also
`often provided.
`Another element-document management-has often
`been integrated with process representation systems. In
`many environments, the careful management of versions of
`process steps and flows is important, together with authoriza(cid:173)
`tion or sign-off procedures.
`
`agement Group (OMG) Common Object Request Broker
`Architecture (CORBA) also enable remote network access to
`such information from multiple applications implemented in
`widely different programming languages. At present, exam(cid:173)
`ples of such interfaces have been demonstrated, and the semi(cid:173)
`conductor industry is working to define standard interface
`definition language (lDL) specifications so that independently
`developed utilities and systems can interoperate.
`
`PROCESS LIBRARIES
`
`It can be argued that process knowledge capture alone is suf(cid:173)
`ficient to motivate development of a process representation.
`Indeed, a huge concern is that substantial experience and
`knowledge about the process generated during design stages
`is lost and never transmitted to the manufacturing effort. A
`detailed process representation, particularly one that can in(cid:173)
`corporate both formal and human digestible information (e.g.,
`scanning electron microscope [SEM] images of typical or prob(cid:173)
`lematic cross sections, simulation results), can serve as a
`shared repository for knowledge about the process.
`The development and support of process libraries is an im(cid:173)
`portant part of virtually every process representation system
`developed to date. Part of this stems from the desire to unify
`both design and manufacturing views of the same informa(cid:173)
`tion. Another motivation is the inherent complexity of semi(cid:173)
`conductor fabrication, which dictates that as much as possible
`of previous process steps and flows be reused when creating
`a new process. Finally, it is often the case that process design
`occurs with physical or logical separation between the unit or
`module process designer and device or integration engineers,
`who must assemble or adapt individual process steps to cre(cid:173)
`ate an integrated flow that produces the desired devices. A
`more recent trend is the increase in use of foundries, which
`provide fabrication services; to support both conventional
`complementary metal oxide semiconductor (CMOS) and un(cid:173)
`conventional (e.g., microelectromechanical system, or MEMS)
`foundry capability, the need for network-accessible process re(cid:173)
`positories (including statistical, design rule, and simulation
`information) will likely increase in the future.
`
`Program Interfaces
`
`APPLICATION PROGRAMS
`
`The definition of standard program interfaces is of critical
`concern for the development and integration of the many ap(cid:173)
`plication programs that need access to process information.
`At this stage, most contemporary process representations
`adopt an object-based approach. Each process component typ(cid:173)
`ically has multiple views that contain attributes (or name(cid:173)
`value pairs) that can be accessed and manipulated. Clearly,
`one set of these attributes must capture the process sequence
`or hierarchy. Other views typically align with the generic pro(cid:173)
`cess model or with other sets of attributes needed to accom(cid:173)
`plish specific tasks. Conventional object and object attribute
`creation, access, and mutation methods are typically pro(cid:173)
`vided.
`Historically, many such programming interfaces have been
`language and implementation specific. Generic object models
`and standard interface description languages, however, en(cid:173)
`able the specification of language-neutral interfaces to com(cid:173)
`mon data sto