Department of Electrical and Computer Engineering. PED: A Graphical Process Editor for FABRICS-I1

Transcription

1 Department of Electrical and Computer Engineering PED: A Graphical Process Editor for FABRICS-I1 Kah-Kuen Low

2 PED: A Graphical Process Editor for FABRICS-I1 Kah-Kuen Low Department of Electrical and Computer Engineering Carnegie-Mellon University Pittsburgh, Pennsylvania May 1985 Submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Engineering. This research was supported by Semiconductor Research Corporation under contract number

3 Abstract An interactive graphical process editor which provides an efficient means for entering descriptions of IC fabrication processes to the process simulator FABRICS-11 has been developed. It has been successfully incorporated into an integrated process simulation system which can be used in computer aided design and development of Ic fabrication processes. A general purpose user-interface system and a device independent graphics package have also been implemented for use in the process editor.

4 2 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-11 Acknowledgements First of all, I would like to thank my advisor, Professor Steve Director, for his invaluable guidance and support in this project. I am also most grateful to Professors Andrzej Strojwas and Bob Wedig for serving on my thesis committee. I would like to express my gratitude to my colleagues in the CAD group for much help in the past one and a half years. I am particularly indebted to Sani Nassif for his many useful suggestions and ideas. I am also thankful to Patrick Kager, who developed PI/c, and with whom I worked very closely in this project. My thanks also go to my past and present office mates, especially Peter Odryna, P.K. Mozumder, and Mark Beardslee. In addition, I am grateful to Mike Trick, Mike Bushnell, and Dave Lapotin. Last, but not least, I would like to thank Christine for her constant encouragement, patience, and understanding.

5 TABLE OF CONTENTS Table of Contents I 1. Introduction 1.l. A Brief Description of FABRICS-I The Integrated Process Simulation System 1.3. Thesis Outline 2. Process Editor Design Considerations 2.1. Functional Capabilities Specification of Fabrication Process Steps Communication with the Process Interpreter/Compiler Display of Profiles Miscellaneous Functions 2.2. User Interaction Style 3. Implementation and Internal Structure 3.1. Implementation Guidelines 3.2. An Overview of PED's Internal Structure 3.3. User-Interface Data Structures Utility Functions Database Management Screen Organization and Interaction Style 3.4. Process Step Database Manager Data Structures Maintenance Routines 3.5. Mask Editor Mask Record Manipulation Functions 3.6. Profile Plotter Impurity Profile Graphs Cross-sectional Contours 3.7. Graphics Package Brief Background on GKS Implementation 3.8. The Filer and Help Modules Filer On-line Help

6 11 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-I1 4. Example 5. Summary 5.1. Conclusions 5.2. Future Extensions Appendix A. PED User's Guide

7 LIST OF FIGURES List of Figures Figure 1-1: Figure 1-2: Figure 1-3: Figure 1-4: Figure 2-1: Figure 3-1: Figure 3-2: Figure 3-3: Figure 3-4: Figure 3-5: Figure 3-8: Figure 3-7: Figure 41: -Figure 42: Figure 43: Figure 44: Figure 45: Figure 48: Figure 47: Figure 48: Block Diagram of the FABl Process Simulator Block Diagram of the FAs2 Device Simulator A Typical User Session with the System The Integrated Process Simulation System A Typical Functionality Tree Block Diagram of the Process Editor Screen Layout of a Typical Menu Screen Layout of a Typical Form Lithographic Masks Created Using the Mask Editor Graphs of Impurity Concentration versus Depth Path-Tracing Algorithm Cross-sectional View of Equiconcentration Contours Initial Sequence of Process Steps Masks of a Simple Enhancement Transistor A cross-sectional View of the Transistor (The values on the contours indicate log10 of ~mpurity concentration) Shorting of the Transistor's Source and Drain Effect of the Source/Drain Implantation Energy Addition of a Depletion Transistor Modified Sequence of the Process Steps (To Include Steps for the Creation of the Depletion Devwe) Cross-sectional View of the Depletion Transistor

8 INTRODUCTION Chapter 1 Introduction Process simulators have proven to be invaluable in the design of vl;si systems. By modeling and simulating Ic fabrication lines, they provide the circuit device characteristics necessary in the verification, performance evaluation, and optimization of VLSI circuits. In order to simulate a particular fabrication process accurately, the process simulator must have sufficient knowledge about the characteristics of that process. Consequently, mechanisms are needed to acquire from the designer the characteristics of the fabrication process he or she is interested in simulating. - In this thesis, we present a new CAD tool, known as a process editor (PED), that provides an environment in which the process engineer can easily enter a description of the 1 nominal characteristics of an IC fabrication process. The process editor is useful whenever a process simulator needs to be informed of a new (previously not known to the process simulator) IC fabrication process or an existing (known) process that has been modified. Coupled with a process simulator and a process interpreter, the process editor can be used by the process engineer to design and refine an IC fabrication process. An IC manufacturing line is considered by the process editor to be a sequence of process I steps, each with a corresponding set of parameters. A step is a manufacturing operation such as ion implantation which is performed on the wafers being fabricated and is defined in terms of parameters such as implantation time and dose. The process editor allows the designer to enter and edit interactively a sequence of process steps and their associated parameters within a fabrication process. It uses graphical techniques extensively to acquire from the user information about the nominal masks of typical 'gy nominal, we mean the desired values for correct operation.

9 4 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-I1 devices that are manufactured in the process and to display impurity profiles that are generated by the process simulator. In order to allow for an efficient use of the system, a robust user-interaction scheme is employed in the process editor. The process editor has been used successfully in an integrated process simulation system. This system consists of PED, the process interpreter/compiler (PI/C) [7], and the statistical process simulator FABRICS-K~ [2] [3]. In a subsequent section, we will briefly describe the goals and motivation of the system and the roles of each of its components A Brief Description of FABRICS-11 Before we proceed to discuss how the process editor can be used in the proposed integrated process simulation system, it is necessary to have an understanding of the methodology and implementation of FABRICS-II. FABRICS-Kt differs from other process and device simulators, such as SUPREM [5] or PRIDE [13], in that it takes into account the stochastic nature of the IC fabrication process. Moreover, it incorporates a device simulator that generates device model parameters such as transistor threshold voltages which are used in circuit simulators. These important features enable FABRICS-Kt to accurately mimic the behavior of a real IC fabrication process by generating a range of device parameters for "identical" devices in a VLsI circuit. This spread in values is due to the inherent fluctuations in the manufacturing process. Since FABRICS-II uses a mixture of analytical and numerical fabrication process models, it offers substantially faster simulation time than that of a simulator which uses numerical models, while incurring very little loss of accuracy. FPRICS-II can be used in conjunction with other CAD tools to verify, optimize, and predict the yield of a VLsI circuit. In particular, FABRICS-I1 has proven to be invaluable in a number of applications including VLSI fault diagnosis systems [12], optimal design of VLSI minicells [lo], and worst case design of integrated circuits [17]. FABRICS-Kt consists of two major components, the process simulator FABl and the device simulator FAB2. The structure of FAEU is illustrated in Fig The core of FABl is a library containing a set of process supervisors, each of which models a particular IC fabrication line by specifying a particular sequence of process steps. For each of the

10 INTRODUCTION 5 Pr ess Distgrbance 8Laracterlstlcs RNG FABl Physical Process Parameters Main Routine parameters Process Supervisor Library I Oxidation I 1 Diffusion I ' Manufacturing Operation Model Library Figure 1-1: Block Diagram of the F-1 Process Simulator process steps, the process supervisor calls a set of appropriate functions in the fabrication process model library. The input to I?-1 is a set of nominal process parameters and process disturbance characteristics. Process parameters are nominal parameters such as time and temperature which characterize process steps. Process disturbances are random variations of processing conditions and material characteristics due to the inherent stochastic nature of the IC fabrication process. FABRICSIT assumes these disturbances are independent, normal random variables which are characterized by their moments. Using the process parameters and disturbances, functions called from the fabrication 4 process model library calculate and extract a set of wafer physical parameters such as impurity concentrations which are affected by their actions. The physical parameters generated are subsequently used in the device simulator, FAB2. Fig. 1-2 shows the structure of FAB2 which generates device model parameters using the physical parameters produced by FABl and device dimensions. Device dimensions are computed from nominal values which are available either as layouts in CIF format or as SPICE input parameters and their corresponding disturbances. The device model parameters extracted can be used in circuit simulators as described previously.

11 6 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-I1 Physical Parameters Layout RNG Disturbance Characterlst~cs Device Dimensions I FAB2 - Main Routine I Device Model Library Model Parameters Simulator Parasitics Extractor I Circuit Extractor I Figure 1-2: Block Diagram of the FABZ Device Simulator 1.2. The Integrated Process Simulation System Having described FABRICS-II, we will now discuss the integrated process simulation system. The main objective of this system is to simplify the task of the process engineer in creating or modifying FABRICS-I1 process supervisors by providing an environment in which the supervisors are generated automatically. As mentioned above, in order to be able to simulate a wide range of IC fabrication lines, FABRICS-a needs to maintain a library of process supervisors, each of which corresponds to a particular process. i Although the structure of FABRICS-II is modular, adding a new process supervisor, or modifying an existing process supervisor, requires not only a detailed understanding of the internal implementation of FABRICS-ll but also knowledge of computer programming techniques. This is because each FABRICS-II process supervisor is implemented as a distinct C language procedure which can be difficult for the designer to write. Thus it is desirable to develop a mechanism that can automatically create new FABRICS-TI process supervisors or modify existing ones.

12 INTRODUCTION a Start Enter Process Steps Process Simulation '-7- Check Impurity Profiles 8 In-Line Parameters Edit Process Steps No I Save Database Figure 1-3: A Typical User Session with the System

13 8 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS11 The flow chart in Fig. 1-3 illustrates a typical user session with the system. As can be seen from the flow chart, the system provides an environment for interactive and incremental simulation of Ic fabrication processes. sequence of process steps. The process engineer first enters a Next, he or she requests that a process simulation to be performed on those steps. The user may then examine the effects of those steps on the wafer to be manufactured by checking the in-line measurement parameters and impurity profiles obtained from the simulation. The above procedure is repeated with process steps being added or modified until the desired process conditions are satisfied. Hence, the system can be used as a test-bed for the process engineer to design new fabrication processes. This presents a cost-effective way to define a fabrication process because it enables the process engineer to explore various designs rather quickly on a computer without having to set up any experimental fabrication line. E Process Specifications Process Process Editor Process Interpreter/Compiler Supervisor 4 Profiles & - In-Line User Parameters A Fabrication Process Model Library Figure 1-4: The Integrated Process Simulation System With the above motivation, a brief description of the system will now be given. As stated previously, the system consists of PED, PI/C, and FABRICS-11. The process editor apts as the front-end in the proposed system as shown in Fig It provides an efficient interface between the system and the user because of its interactiveness and effective use of graphics. The process editor accepts, from the user, fabrication process specifications and the nominal layout of various devices. It maintains a database of the above information which can be sent to the process interpreter/compiler for interpretation and simulation if requested. The process interpreter/compiler interprets the sequence of process steps and simulates the fabrication process by invoking appropriate functions in the FABRICS-11 process model library. The process editor then receives the simulation

14 INTRODUCTION results from PI/C and uses them to extract and display impurity profiles and in-line measurement parameters such as sheet resistances. If invoked in compilation mode, the process interpreter/compiler generates a new FABRICS-ll process supervisor while simulating the specified fabrication process Thesis Outline The remainder of this thesis is organized in the following manner: Chapter 2 discusses the design considerations and issues we encountered while specifying the process editor. These issues include functionalities and userinteraction style which PED must provide in order to achieve its goal as an effective front-end for the integrated process simulation system. Chapter 3 covers implementation details of the process editor by providing descriptions of various PED functional modules including the user-interface, the process step database manager, the mask editor, the profile plotter, and the ~~~~-com~atible graphics package. Chapter 4 presents a simple example of the IC fabrication processes that may be defined using PED and the process simulation system. 0 Chapter 5 provides concluding remarks on PED and the integrated process simulation system implemented. It also supplies some ideas for future enhancements. '~ra~hics Kernel System - A device independent graphics standard.

15 10 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-11

16 ~UJSSS EDITOR DESIGN CONSIDERATIONS Chapter 2 Process Editor Design Considerations In this chapter, we discuss the design considerations for the process editor. In partic we consider what functional capabilities PED should provide and the user interac style to be adopted. As mentioned previously, our main design goal was to develo~ tool that would provide an environment in which a process engineer can enter description of a fabrication process for the integrated process simulation system as easil, as possible, without sacrificing any pertinent detail of the design Functional Capabilities Specification of functional capabilities represents one of most important aspect of CAD tool development. It determines directly the effectiveness of the tool in performing its assigned task. The following principles are usually used in deciding what functional capabilities to include in a CAD tool: Completeness: A tool should provide a complete set of functions that will enable it to accomplish its task and also to allow for easy extension when required. Minimality: Functions which are unnecessary in the application should not be + included. Compactness: The desired task should be achieved using as small a set of functions as possible. Richness: A rich set of functions that offers extensive range of facilities is desirable. Since the above principles inherently conflict with each other, our task is to find an acceptable trade-off between them. In specifying the functional capabilities of the process

17 12 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-I1 editor, the completeness principle is emphasized since the tool is expected to handle a wide range of fabrication processes. Basically, the functional capabilities required of PED can be divided into two categories: principal and secondary. The following principal functions are imperative for PED to obtain efficiently and precisely from the user a description of the desired IC fabrication process: Fabrication Process Steps Specification 0 Communication with the Process Interpreter/Compiler Display of Profiles The secondary functions are additional utility functions which enhance the use of the editor, they include a filer and on-line help facility. We now discuss these principal and secondary functions in more detail Specification of Fabrication Process Steps The following process steps are necessary to provide the user with a complete set of primitivesfrom which to specify a fabrication process for FABRICS-11: 1. Anneal: This is used to restore the crystal structure on the top layers of the wafer, it requires time and temperature as parameters. 2. Deposit: This step deposits a layer of insulator such as oxide, nitride, and photoresist, or interconnect material such as polysilicon, and metal, it requires material, deposition rate, time, and temperature as parameters. 3. Diffuse: This provides diffusion of impurities such as Boron, Phosphorus, and Arsenic into the silicon crystal, it requires material, time, and temperature as parameters. 4. Drive-in: This is used for redistribution of impurities in the silicon, it requires time and temperature as parameters. 5. Etch: - This etches off a specific material from the surface of the wafer, it requires material to etch, time, and temperature as parameters.

18 PROCESS EDITOR DESIGN CONSIDERATIONS 6. Implant: This step deposits high energy impurity ions into the silicon crystal, it requires impurity material, dose, and energy as parameters. 7. Oxidize: This grows a layer of silicon oxide on the wafer surface, it requires type of oxidation, time, temperature, and the partial pressures of Oxygen and Hydrochloric acid as parameters. 8. Mask: This is used to create a mask for the photoresist according to the pattern defined. A graphical mask editor is needed to help the user specify the mask pattern. It should provide editing functions such as adding, deleting, moving, copying, and stretching of each mask window within a mask layer. Each mask layer has a property of either positive or negative, corresponding to the type of photolithography to be performed on it. In addition to specifying the individual process steps, the process editor should provide a mechanism for manipulating the sequence of such steps within a fabrication process. The following process sequence editing functions accomplish this goal: 1. Add step: - Appends a new process step to the end of the process sequence. 2. Delete step: Deletes a specified process step from the process sequence. 3. Edit step: Modifies the parameters of a specified process step. 4. Insert step: Inserts a new process step before a specified step in the process sequence., Communication with the Process Interpreter/Compiler During the course of defining a fabrication process, it is often useful for the designer to be able to examine the various physical parameters which would have been generated by the fabrication process specified up to some point. This feature is useful since it enables the designer to iteratively refine the fabrication process being developed until he or she is satisfied with the parameters produced by the process. This is achieved in the integrated process simulation system by invoking the process interpreter/compiler and FABRICS-11 to interpret and simulate the sequence of process steps at any point during the process

19 14 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-11 design stage. Consequently, a mechanism must be provided for PED to communicate efficiently and effectively with PI/C. In particular, PED is required to send the description of the fabrication process entered by the user to PI/C and to receive from it simulation results such as in-line measurements and impurity profiles which can then be shown to the user. To provide an effective communication channel between PED and PI/C, an information packet transfer scheme should be adopted to send process descriptions and invocation commands to PI/C. In this scheme, PED will initiate the transfer (when the user indicates that process simulation be performed) by sending PI/C the start interpret packet. Upon the receipt of this packet, PI/C will respond by making a request for the next packet. PED will then retrieve the information for the first process step from its process database and forward the next packet to PI/C. This procedure will be repeated for the subsequent process steps until the entire process sequence has been exhausted. If the automatic generation of a FABRICS-II process supervisor has been requested, PED will send the generate supervisor packet to PI/C. Otherwise, the null packet will be sent indicating-the end of transfer. To extract simulation results, PED will simply invoke various accessing functions provided by the process interperter/compiler which will retrieve or compute the desired information Display of Profiles It is a well-known fact that graphics is an efficient and indispensable tool for communication of information. By employing graphical techniques, the effects of various processing parameters on the Ic being manufactured can be observed. 4 Since the physical characteristics of an IC are mostly dependent on its impurity distributions and layer thicknesses, functions must be provided to display the profiles graphically. PED provides two different ways for viewing the impurity profiles that are generated by PI/C using FABRICS-TI. The user has the option of viewing the profiles as plots of impurity concentrations versus distance, or as contours of equiconcentration in the cross-sectional view of the wafer. The cross-sectional option also conveys some additional information such as deposition thicknesses and various junction depths.

20 PROCESS EDITOR DESIGN CONSIDERATIONS 15 The above features provide the user with a physical insight into how various processing parameters may affect the final IC. This is particularly helpful when a new fabrication process is being defined Miscellaneous Functions In addition to its main functions, it is essential for a CAD tool to have a set of utility functions in order to make its use more pleasant to the user, thereby improving his or her productivity. One of the most desirable features of an interactive design capture tool is the ability to allow the user to suspend a design session at any instant and continue with it at a later time. This feature requires that a filer be included in PED. A filer enables the user to exit from PED at any stage without losing the state of the design. This is achieved by saving the pertinent information onto a disk file and retrieving that file during a later session. - Another important function that a successful tool should provide is the help facility. PED should provide on-line documentation of all its features which may be invoked by the user at any point during a design session User Interaction Style The user interface represents another major component in an interactive CAD tool. More often than not, a tool is judged primarily by its user friendliness rather than its real performance. This is particularly true when the user is not familiar with the tool. 8 Consequently, it is essential that considerable effort be directed towards the design of a user interface that will make the tool attractive to novice as well as advanced users. The following basic principles are observed in the design of the PED user interface [I] [6]: 1. Simplicity: The user interface should make the program easy to use. This means that a novice user should be able to run the program without much time spent on learning the system. On the other hand, the interface must be robust enough so that the advanced user does not feel handicapped by it.

21 16 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS Response Time: As PED is meant to be an interactive tool, it is imperative that its user interface response be as fast as possible. The process editor should use a menu-and-form based user interactive style because it seems to satisfy the above principles. The menu scheme is appropriate for novice users since it can clearly display all the options available at any point during the design session. The scheme is also acceptable to advanced users because it will require minimal effort on their part to make a selection. This feature makes the tool very convenient to use because it will require virtually no learning or memorization on the part of the user. The form format of the user-interface allows the process editor to request several user inputs at once. Each form consists of several blanks to be filled in by the user. Each such input may be a different data type such as integer, floating point number, character string, and enumerated type. This feature is nicely suited to the need of PED to obtain a number of parameters for each process step from the user. Rather than overwhelming the user with a large number of selections in a single menu, the -process editor functions should be organized in a hierarchical fashion by grouping them into various categories according to their functionalities. A functionality tree similar to that illustrated in Fig. 2-1 is constructed. The user moves to different parts of this tree during various design stages. This enables the user to focus his or her attention on one aspect of the design at a time.

22 PROCESS EDITOR DESIGN CONSIDERATIONS PED I Define A Process Simulate Add Insert Edit Delete ~~~~h cross Print Define proceed Read Write Section Device Etch Mask Diffusion Add Edit Delete Device Device Device Add Delete Copy Move Stretch Window Window Window Window Window Figure 2-1: A Typical Functionality Tree

23 18 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-I1

24 IMPLEMENTATION AND INTERNAL STRUCTURE Chapter 3 Implementation and Internal Structure This chapter describes the implementation details of the process editor. We first discuss the guidelines used in the implementation of PED and then proceed to describe, in detail, its internal structure. 3.l. Implementation Guidelines As with other sizable software development projects, in order to overcome the complexity of the programming task, it is essential that a set of guidelines be adopted in writing the process editor. Specifically, emphasis must be placed on making the software easy to debug, modify, and extend. Also, the program must be written in such a fashion so that it can be easily transported to other computer systems. I A modular, topdown, hierarchical programming approach was taken in designing the process editor. The program is divided into several roughly independent major modules according to their functions. Each of these major modules is again subdivided into various submodules and so on. The idea is to relegate the implementation details of each function progressively down to the next lower level of abstraction as far as possible. This approach makes the program much more comprehensible and manageable, hence substantially simplifies the task of the programmer in debugging and modifying the software. One of the increasingly important concerns in CAD tool design is portability. With the diversity of hardware and software facilities in use today, it is very desirable to be able to transport a software tool to other machines with minimal recoding effort. Portable software not only saves time and money, it also guarantees that the behavior of a

25 20 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-I1 program as seen by the user will be the same on different computer systems. Consequently, the tool will be more widely used compared to a non-transportable tool. In order to increase the portability of a program, system dependent code must be kept to 3 a minimum and preferably concentrated into a few easily modifiable modules An Overview of PED's Internal Structure With the implementation guidelines discussed above in mind, we now describe the internal structure of the process editor. As illustrated in Fig. 3-1, FED consists of the following six major functional modules: 1. User-Interface: This module is the communication channel between the user and PED. menu-and-form interaction scheme is employed to obtain user-inputs. A 2. Process Step Database Manager: This module contains routines for manipulating the fabrication process database. 3. Mask Editor: - This-module handles the entering of lithographic mask. It contains various mask editing (i.e. mask database manipulation) functions. 4. Profile Plotter: This module contains the impurity profile display procedures. 5. Graphics Package: This module contains GKS-compatible device independent graphical input/output procedures Miscellaneous Function Handlers: This module contains miscellaneous utility function handling routines such as filer and on-line help. These modules are coordinated by a small main procedure which interprets the userinputs obtained from the user-interface and invokes the appropriate modules to perform the requested tasks. The main procedure also acts as an interface between the process editor and the process interpreter/compiler. Both the graphics package and the userinterface module communicate with the user through the Unix terminal driver. In the 3~ote that the modular approach as discussed above suits this requirement well.

26 IMPLEMENTATION AND INTERNAL STRUCTURE 2 1 Interpreter/ Compiler * Process Editor 3 Main Procedure< I Mask Editor Process Step Database Manager Miscellaneous Function Handlers Graphics Package C u Figure 3-1: Block Diagram of the Process Editor remainder of this chapter we describe, in more detail, the internal structures of each of the above major modules User-Interface I Having decided in the previous discussion (see Chapter 2) to use a menu-and-form interaction scheme, our main implementation concerns for the user-interface are simplicity, flexibility, and portability. We require the user-interface to be simple and yet flexible so as to minimize future efforts in modifying the menus and forms in anticipation of feedbacks from the users and any future changes or extensions that may be made to PI/C or FABRICS-II. These design goals are achieved by representing each menu and form with a simple data structure and providing a small set of utility functions. To make the user-interface portable or device independent, we use the termcap approach similar to that found in Unix. Basically, this means storing the characteristics such as the escape sequences for clearing screens of all the supported terminals in a disk file and

27 22 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-II having a set of standard screen controlling and utility functions which make use of this information Data Structures There are two basic data structure types in the process editor user-interface module: the menu and the form records. These data structures contain information about the current states of all the menus and forms that have been created. 1. The menu record consists of the following fields: Title: This is a character string identifying the menu. Icon: This includes the number of icons in the menu, the icon length, the default icon, and an array of character strings containing icon texts. a State: This contains the current state of the menu, which is the index of the most recently selected icon. Miscellaneous: This includes pointers to user-help procedures and screen repaint handlers. 2. The form record consists of the following fields: Title: This is a character string identifying the form. Blank: This contains the form blank information including the number of blanks in the form and for each blank, the location and content of its prompt string, the location and pointer to its content, and its data type. There are four blank data types: fixed point, floating point, character string, and enumerated type. Each blank data type has a distinct subfield: a. Fixed Point: This contains the default value, the acceptable range (minimum and maximum values), and the current value of the fixed point number. b. Floating Point: This contains the default value, the acceptable range (minimum and maximum values), and the current value of the floating point number. c. Character String: This contains the default character string. d. Enumerated Type: This contains the number of enumerated items, an array of item texts, the index of the default item, and the index of the most recently selected item.

28 IMPLEMENTATION AND INTERNAL STRUCTURE State: This holds the current state of the form, which is defined by the index of the most recently visited blank, the current location of the cursor, and the contents of all the blanks found in the form. Miscellaneous: This contains other informations such as pointers to user-help handling procedures Utility Functions Having defined the data structures for the user-interface module, we need a systematic and consistent way to manipulate them. This is accomplished by providing a set of standard data structure utility functions. There are two categories of utility functions, each of which corresponds to the menu and the form records respectively. menu utility functions include the following: The major Create/Dispose Menu: The Create Menu function allocates storage for a new menu record and initializes all its parameters according to the following arguments which are passed in by the calling routine: title, icon texts, number of icons, and default selection. It returns the pointer to the new menu record. The Dispose Menu function discard a menu by deallocating its storage space. Add/Delete Icon: These functions add and delete an icon and update various relevant parameters in a menu record. The input arguments to the Add Icon function are menu pointer and the icon to be added. The icon number (positive integer) is returned upon successful addition, otherwise a negative number is returned indicating error. The Delete Icon function may be used to remove an icon from a given menu. It requires menu pointer and an icon number as arguments. This feature makes the menu system very flexible since menus can be dynamically changed if necessary. Set Current Icon: This function sets the current icon (selection) of a menu (identified by its pointer) to the specified value (an index to the icon array). Default Menu: This function sets the current icon of a menu (identified by its pointer) to its default value (as specified in the Create Menu function). Display Menu: This function paints a menu (specified by its pointer) on the screen (the menu is not activated).

29 24 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICSII Get Menu Selection: This function activates a menu (identified by its pointer) and handles the keystrokes entered by the user while he or she is selecting an icon in that menu. The input arguments are menu pointer and a flag indicating if the menu is to be repainted on the screen upon activation. The major form utility functions include the following: Create/Dispose Form: The Create Form function allocates storage for a new form record and returns a pointer to it. The title of the new form is needed as input parameter. The Dispose Form function discards the form record specified by its pointer. Add/Delete Form Blank: These functions add or delete a form blank in a given form. Four different types of form blanks may be added to a form. They are: string, fixed point number, floating point number, and enumerated type. A prompt string and a default value are required as input parameters when adding a blank regardless of its type. In addition, the allowable range (minimum and maximum values) must be supplied if the blank is a fixed point or floating point number. If the blank is of type string, the length of the expected string is needed. In the case of an enumerated type blank, the calling routine must state the number of enumerated items and their corresponding text strings (in an array). The - blank number (positive integer) of the added form blank is returned upon successful addition, otherwise a negative integer is returned indicating error. A form blank may be removed from a given form using the Delete Form function with the following arguments: form pointer and blank number. These functions enable the forms structure to be changed dynamically during program execution. Change Form Blank: This function allows the value of a form blank to be changed from that last entered by the user. The required parameters are form pointer, blank number and its new value. 4 Default Form: This function sets the values for all the blanks in the specified form to their default values (as specified in the Add Blank functions). Display Form: This function displays the specified form on the screen (the form is not activated). Get Form: This function activates the specified form and handles the keystrokes entered by the user. For each blank type, it performs consistency checks on all user keystrokes in the partially filled form blanks. For example, in a floating point blank, only one decimal point is allowed and it has to be to the left of

30 IMPLEMENTATION AND INTERNAL STRUCTURE the exponent character <e>. Moreover, before a form is accepted, range checking is done to ensure all entries in the form lie in the allowable range as defined by the programmer. Form Entry: This function retrieves from the given form record the current value in the blank specified by its number. It is usually invoked after calls to the Get Form function to obtain user-inputs from a form Database Management The are several ways of storing and managing the menu and form database. One way is to store them in a centralized database with a hierarchical structure. The advantage of this scheme is that it is very systematic. Unfortunately, there are high storage and speed overheads associated with this scheme since significantly more elaborate data structures and additional access functions are required to reference a menu or form entry. Thus, there is a degradation of performance as the number of menus and forms increases. An alternative and simpler approach is to distribute the data structure storage amongst the menu or form handling procedures using the static variable4 feature of the C programming language. Each handling procedure stores the pointers of the menu or form data structures that it services. Assuming that the number of'menus or forms for each handling procedure is small and there is no sharing of menus and forms between different procedures (which is the case in PED since modularity is emphasized), the above overheads are effectively eliminated. This scheme is also attractive because no access or search function is required. For these reasons, the latter approach is adopted in PED'S user-interface. I Screen Organization and Interaction Style Having discussed the internal structure of the user-interface, we now describe how the screen appears to the user. Specifically, we will discuss the screen layouts and interaction styles for both the menu and the form modes. 1. Menu: The screen layout for the menu mode is shown in Fig The menu screen 4~his feature provides a mechanism to store the value of a local variable in a procedure even when that procedure is not active.

31 26 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS-I1 min Figure 3-2: Screen Layout of a Typical Menu is divided into three different viewports. The title viewport appears on the top line of the screen, it contains the title of the menu which explains to the user the function of that menu. The icon viewport is located at the far right of the screen. Icons (menu selections) are listed vertically down the screen within this viewport. The last viewport encompasses the remainder of the screen. It contains other information external to the user-interface that may be shown to the user, such as lithographic masks created using the mask editor. To select an icon, the user first presses the <control>-<n> or <control>- <p> keys on the keyboard to move the current selection (which is highlighted) to the next or the previous icons respectively. Alternatively, the user may type any printable key to invoke the incremental matching mechanism. This mechanism attempts to match an icon with the string entered by the user. If one or more such icons exist, the current selection will be moved to the first icon found in the search list. The user may also press <return> to test if the string that he or she entered so far is ambiguous. If it is ambiguous, a warning bell will be sounded. Otherwise, the match pattern wifl be completed and the incremental match mechanism will be terminated. When the icon that the user desires is highlighted, he or she may then press the <control>-<d> key to confirm the selection. 2. Form: Fig. 3-3 illustrates the screen organization for the form mode. The layout consists of two separate viewports: namely the title and the form viewports.

32 IMPLEMENTATION AND INTERNAL STRUCTURE 27 The title viewport occupies the top line of the screen and contains the title of the form. The remainder of the screen is used by the form viewport which contains several form items. Each form item occupies one or more lines and consists of a prompt string which explains the item, a type string which indicates the input type of the item, and a blank which contains the default or user input value of the item. The current form item is signified by having the cursor in its blank. The user may move to the next or previous form items by typing <control>-<n> or <control>-<p>, respectively. While in a blank, the user may change its content by typing a set of acceptable characters and editing characters such as <delete> (delete the previous character) and <control>-<u> (clear the blank). The set of acceptable characters is different for each form type. For a string blank, the set includes all alphanumeric characters. A fixed point number blank expects only numeric characters and the <+> or <-> characters while a floating point number blank allows the <.> and <e> characters in addition to those of a fixed point number blank. An enumerated type blank accepts only two characters: namely <n> and < p> which are used to move to the next or previous selections respectively. When the user is satisfied with all the values in the form blanks, he or she may transmit the entire form by typing <control>-<d>. Oxidize Specifications Name CSTRINGI: Type CENUM3: Time (5) CFLOAT Temperature (K) Oxygen partial pressure EFLOATI <Osi>r HCI partial pressure CFLOATJ <0:1>: Figure 3-3: Screen Layout of a Typical Form The following functions are available in both the menu and the form mode: <escape>-< h>: invokes generic menu or form on-line help facility. <escape>-<g>: invokes menu or form specific on-line help facility. <escape>- <r>: repaints the screen.

33 28 PED: A GRAPHICAL FABRICATION PROCESS EDITOR FOR FABRICS Process Step Database Manager We now describe the implementation of the fabrication process database and the corresponding database maintenance functions. Since a fabrication process is modeled as a sequence of process steps, it can be mapped directly into a linked list. Each node in the list corresponds to a process step and contains the process parameters of that step. In addition, a list of nominal devices for the process is also maintained. The task of the process step database manager is simply to maintain and update the lists of process steps and nominal devices Data Structures The basic process step data record consists of the following fields: Name: This field contains a character string identifying the process step. Type: This field indicates the type of the process step such as implantation, oxidation, diffusion, etc. i Parameters: This field is a variable field containing various process parameters. For example, if the process step type is oxidation, the parameters included are: oxidation type, time, temperature, and partial pressures of oxygen and hydrochloric acid. Previous and Next Pointers: These fields contain the pointers to the previous and next process step record, respectively. The nominal device data record has the following fields: Name: This field contains a character string identifying the device., Type: This field indicates the type of the device such as pchannel enhancement MOS transistor, resistor, capacitor, etc. I Extent: This field contains the coordinates of the rectangle enclosing the device defined by lithographic masks5. Regions: This field contains the coordinates (with respect to the lithographic masks) of various regions in the device such as source/drain and gate for a MOS transistor. 5~hese masks are created by the mask' editor to be described below.

34 IMPLEMENTATION AND INTERNAL STRUCTURE 29 Next: This field is a pointer to the next device. In addition to the above data structures, a special record is used to store global process information such as process type (e.g. nmos), substrate dopant and concentration, the number of process steps, and the number of nominal devices Maintenance Routines A set of database maintenance routines are needed in the process step manager in order to perform various database editing operations. These routines include the following: Add Process Step: This function allocates storage for a process step and appends the created node to the end of the process sequence. It uses the menu facility to query the user the process type and then invokes the appropriate form to obtain process parameters pertinent to that process type from the user. Insert Process Step: This function performs the same operation as the Add Process Step function except that the new process step is inserted preceding a specified step. Edit Process Step: This function modifies the parameters of a given process step by requesting the user to change the appropriate entries in the associated form. Delete Process Step: This function removes a given process step from the process list and deallocates its storage. Show Process Sequence: This function traverses down the process step list and prints out the name and type of every process step on the screen. 4 The simple linear search algorithm is employed in all the above functions to locate a given step in the process list since the number of process steps is usually small. A similar set of maintenance functions is used to edit and update the list of nominal devices for the process.

35 PED: A GRAPHICAL FABRlCATION PROCESS EDITOR FOR FABRICS-I Mask Editor The task of the mask editor is to provide an efficient means for the process designer to enter nominal device masks in a fabrication process. Therefore, the editor is not intended to subsume the functions of a typical layout editor. In particular, no effort is placed in providing a hierarchy cell design facility typically found in a layout editor. Instead, each device is defined by an extent rectangle enclosing its mask windows. Each lithographic mask in the fabrication process consists of a set of rectangular mask windows and has a distinct line type or color. Fig. 3-4 shows an incomplete process containing three masks, defining the active area, the gate, and the depletion threshold implantation regions respectively. Each mask is either of type negative (meaning the area enclosed by its windows are free of photoresist) or positive (meaning the area enclosed by its windows contain photoresist). A negative mask is distinguished from a positive one by having diagonal lines drawn in its windows. For example, the d-thresh and the contact masks in Fig. 3-4 are of type negative !---...! I I : -... /... : ".=., i - -,-i "-,...a. -...c.... #! JC I -, l *.l- I I.+--. I I /--- I :! : I :.-a : I -. '!.@..:---'-. *----., r.c... I. = * d. /:, ;!. ',,. *-L !" i '.*\,/ : 1.:..:.- I : I -2:. \, I :,.f !. i, i : I, I..... :.. I : ;.*..! % u......:... : I :.-.."' : : I I 1 I... 4 I -...,..?'.-...-!...?.,, ; I 1,,,.,..z--,, J.-.C.C-. I I metal id:: ; : !... :< I I contact I I gab I I huwsh J active... 1 *.-. '-.. i Figure 3-4: Lithographic Masks Created Using the Mask Editor Since a lithographic mask is regarded in PED as a process step, the data associated with each mask is stored in a process step record as described in Section 3.4. above. However.

36 IMPLEMENTATION AND INTERNAL STRUCTURE 31 in order to provide the mask editor with a more efficient way to access the mask data, an additional list of mask pointers is used. Each mask pointer node in the list contains a pointer to the corresponding mask process step in the process step list. In this scheme, the mask editor maintains the mask list while depending on the process step manager to handle the data in the mask process step record Mask Record As mentioned previously, a mask record is a process step record with a mask parameter field (see Section ). The mask parameter field contains the following subfields: 0 Mask Type: This field indicates if the mask is of type positive or negative. 0 Number of Windows: This field indicates the total number of windows in the mask. Window List: This field contains a list of all windows in the mask. Each window node in the list contains the coordinates of a rectangle which defines the window. 0 Visibility: This field is a non-processing parameter indicating if the mask is to be displayed on the screen. This feature is useful when the user would like to concentrate on editing a few masks while ignoring the others. Line TypelColor: This field contains the line type or color unique to the mask Manipulation Functions 4 The mask editor consists of a collection of mask manipulation functions which are used to edit the windows in a given mask. It displays a menu containing all options provided to obtain editing commands from the user. The mask manipulation functions relies on the graphics package (described below) to perform the necessary graphical operations on the screen and to obtain graphical inputs from the user. These functions include the following: Add Window: This function allocates storage for a window and appends it to the mask window list. It then prompts the user to enter two points using the input device (such as graphical tablet or cursor keys) supported by the graphics package. These two points represent two vertices of a rectangle ~hich~defines the desired mask window.