Книги2 / 1993 P._Lloyd,__C._C._McAndrew,__M._J._McLennan,__S._N

style similar to that originally proposed by Duvall [10]. The format has since been used in other semiconductor support tools [11]. A short extract from a device file is shown below:

region

( type semiconductor )

( name "bulk silicon" ) ( attributes

( doping

( profile ld

( dopant "phosphorus" )

( filename "emitter.sup3" ) ...

Even though large files are created e.g. the data file containing doping and region information from a SUPREM-IV profile translated into the IDDE format, the time required to load the files has not been a problem and so binary files are presently not used.

3.Evaluation

3.1Evaluation for Release

During the development of the IDDE system which began in August 1987 until beta release in August 1988 local evaluation was performed by members of the discrete device research group. Although the code was quite immature at this stage such was the disdain for text based input that there was no shortage of volunteers to try the evolving system. This effectively enabled us to perform rapid prototyping of the interface which, as a consequence of this feedback, changed considerably during the development period.

In August 1988 the beta release of the IDDE software was installed in a development site for evaluation. This evaluation took a number of forms:

•Observation of users completing a given task.

•Bi-weekly meetings for users to present feedback.

•The completion of a questionnaire by users at the end of a three month trial period.

It is important to realise that the goal of this evaluation was to assess the "usability" of the software which is distinct from software testing. In the latter the software is compared against the requirements specification. A piece of software may well meet it's requirements but this does not mean that it will be easy to use by an engineer, hence the need for a measure of usability [21]. As far as we are aware this was the first attempt to look at usability in the TCAD field.

In the initial study 4 novice users from the development site were observed, by an IDDE designer, drawing a two dimensional bipolar transistor, meshing this and translating this into input for a device simulator. The observers recorded at what points users had problems or required assistance. These points were raised together with other comments from the users, who in addition to running test problems were also running practical devices. Alterations and extensions to the interface were made as

a result of these discussions. On average a new user required 40 minutes to complete the task of generating error free input for a device simulator. This compares with a time of 2 hours for an expert user to construct text based input. At the end of the trial period users, now much more familiar with the system, repeated the exercise and completed the process in 15 minutes. At the time we were concerned that such a small sample of users would not be adequate to assess the system, however, recent work in the field of usability engineering [22] [23] has indicated that such a sample size is reasonable.

The main findings of the 3 month study were:

•A significant increase in the efficiency of data preparation for device simulation. A novice user with IDDE could out perform an expert using a text based system.

•Fewer errors were made in defining a device when using the device editor in IDDE. This is attributed to the graphical feedback.

•The rate at which new users learned how to use the device simulators increased noticeably compared to those using text based formats.

•The ease of translation between packages encouraged users to simulate with packages they were previously not familiar with.

•The tighter integration of process and device simulators lead to a noticeable increase in the use of simulated process data in device simulation.

•A perceptible change in the attitude of development engineers towards device CAD. It is now perceived as something positive and a tool which they themselves can use.

3.2What Have We Learnt in the Meantime?

In January 1989 the IDDE system was generally released within Philips. Since this inception its use has grown and it is now actively used in 3 research sites, 6 development sites and 1 university covering the full range semiconductor devices from power to IC's.

During the 4 years of use feedback has been gathered on the system. Encouragingly this information strongly supports the initial findings described in the previous section. Some other features that have emerged from extended use, these are:

•The use of multiple device simulators. Having access to a number of device simulators some users became aware that certain simulators were better at certain types of simulation. For example avalanche simulations with CURRY and electrothermal calculations with TESSA. Therefore users would switch simulators depending on the type of phenomenon they were investigating.

•The generation of device libraries. Most sites quickly realised that many simulations required a simple modification of an existing structure and therefore once drawn up these devices should be placed in a library that other users

could access. This lead to a further decrease in preparation time for a device simulator.

•The device file became a means of remotely exchanging information on a structure even to engineers that were not performing simulations. That is, a device file could be sent to a remote party who could then examine profiles and dimensions in the device editor.

•As far as we are aware no user having used IDDE has returned to a conventional text method of input.

The complexity of simulations has, along with computing power, generally increased, certainly when compared to the type of simulation that were performed with IDDE when it was first introduced. We were therefore interested in how well moderate users of IDDE (those that use it in short bursts with extended breaks which is typical of development work usage) coped with these more complex types of structure, as the initial study did not address these. To examine this a set of users were were asked to generate a number of devices. The most complex structure was an IGBT which contained:

•Boron and Arsenic profiles from SUPREM-IV

•Polysilicon and oxide regions also simulated by SUPREM-IV

•I-D Boron and Phosphorus profiles from SUPREM-III that model the out diffusion from the epitaxial layers.

The user had to translate and manipulate thesE" items to generate the final IGBT cell structure. Devices of such complexity would not be tackled by development engineers without the use of a graphical device editor as the chance of introducing an error via a text based input is extremely high and potentially very costly if a number of simulations are performed before it is discovered. For the IGBT task the moderate users required between 50 minutes to 75 minutes to complete the task. The time for an expert user was 25 minutes. This result is encouraging as it indicates that even casual users (one of the groups particularly targeted by IDDE) can generate quite involved devices without a significant penalty in efficiency.

Along with positive feedback on the system there has of course been negative comments. In many respects these are the more interesting as they give direction to future work. The main criticisms of the IDDE system are:

•The system is incomplete. Users requiring extended features of a device simulator (e.g. a transient simulation) have to edit the the t.ranslated device file. This "stepping-out" of the environment is not liked by the user. What is required is a tool such as an analysis editor which would allow the user to graphically specify the type of analysis, voltage or current steps, external circuits etc. Output from this could then be translated, with the device information, into the input for a device simulator. Although the engineers also use the process simulators directly there was less strong feeling on providing a graphical front-end to these. This appears to stem from the fact that the input to a process simulator is similar to a standard process sheet.

•The system does not provide for multiple simulation runs.

•A more sophisticated database management system is required to help an engineer manage the many results that are generated from using multiple simulators.

•Recent users are more familiar with graphical software having been exposed to it on PC's and workstations. While this makes some aspects of IDDE easier, problems occur as it was not develop in accordance, as there was none, with a style guide. Therefore certain users would like to see aspects of the interactions more closely follow the current conventions e.g. a drop down menu bar along the top of an application.

•Engineers want support, preferable on-line, while they are defining a device as to the appropriate choice of physical models. For example users are often confused about when to apply various mobility models.

4.Future Directions

From our experience with IDDE a number of options have been identified that attempt to address the perceived short-comings in the existing TCAD systems.

4.1Open Framework

From an industrial perspective an open framework is highly desirable. The freedom to mix software from multiple vendors and to integrate internally generated software provides a means of defending investment in this area. Although it is currently possible to use vendor software in IDDE the responsibility for integration currently rest with ourselves. With the advent of an open system vendors will, provided there is sufficient market pull, be disposed to ensuring conformance of their software. The efforts of CFI are therefore to be supported even though an effective standard may only be available in the medium term.

4.2 Incorporating Domain Knowledge

To effectively use simulators in the TCAD field a user must have a good understanding of the physical models used and, importantly, their limitations. For example if you wish to simulate the gain of a bipolar transistor you have to include SRH and Auger recombination and bandgap narrowing. The parameters that are used for the bandgap narrowing depend on the type of mobility model that are used. Similarly in process simulation a transient enhanced diffusion model may need to be included in a simulation for a short low temperature diffusion. It is our experience that many new users have great difficulties with this and as a result execute many unphysical simulations. While they generally learn from this process it is costly in terms of computing and engineer time.

A possible solution to this problem is the incorporation in a TCAD system of some form of domain knowledge. A possible form for this could be an expert system that could comment on a the consistency of a device representation. Many of the rules are relatively simple e.g. when simulating a bipolar device included SRH and auger recombination, and so a practical knowledge base could be constructed.

4.3Visual Programming

If a user wishes to depart from the standard path through a TCAD system e.g. to perform multiple coupled process and device simulations with a specific post-processing filter then the user generally has to describe the problem in a script language [25].

While such languages are suitable for experts they will generally not be used by engineers who are casual users of TCAD. A simpler programming paradigm is therefore required. Visual programming [26] offers such benefits. Research [30] has shown that visual languages can be highly effective in supporting nonor novice programmers in narrow, specialised domains. This matches closely the situation of engineers in the TCAD domain.

Practical examples of such systems in other fields are AVS [27] for visualisation and [28] for GIS. As visual programming follows a dataflow paradigm its application would be greatly facilitated by a standard representation for the components (e.g device, mesh, data) that will be manipulated.

4.4Usability

Great strides have made in the field of software usability in the past decade (see [24] for a snap shot of this active field). However, much of this work has currently gone unexploited by the TCAD community. The two topics mentioned previously, domain knowledge and visual programming, are examples of aiding usability but I mention it separately as there are many other aspects that can be applied to this field. For example recent research [29] has indicated that it is possible to ascertain a users level of expertise by automatically monitoring how a user interacts with a system.. Consequently, appropriate help, arrangement of menus can be adapted to better support the interaction.

It is important to realise that software usability stands in the critical path for efficient use of a TCAD system and therefore should be considered an important component of a TCAD framework. With few exceptions the developers of todays tools have largely based their user models on themselves assuming a great deal of domain knowledge. This poorly represents the practising device designer with the consequence that TCAD tools are still not fully utilised.

5.Conclusions

Reviewing the 4 years of IDDE use it is clear that the project achieved its original goal of providing more efficient assess, and use, of process and device simulators. Further, it has played a key role in making TCAD accessible to engineers and for facilitating the assimilation of such tools into their device design methodology. In a wider context, despite it's shortcomings, it has shown that a TCAD systems is much more than an abstract representation of components and a database. Support tools and in particular usability stand in the critical path to an effective TCAD environment. The time has come to seriously consider the engineer not just the physics and the algorithms.

6.Acknowledgements

The author would like to thank the members of the Hazel Grove development team and colleagues at PRL for evaluating and providing valuable feedback on IDDE. In addition I would like to acknowledge and thank M.Driessen and A.Heringa who ported IDDE to X-Windows.

References

[1]P. A. Gough, M. K. Johnson, P. Walker, H. Hermans, An Integrated Device Design Environment for Semiconductors, IEEE Trans. Computer-Aided Design, VoLlO, pp.808-821, June, 1991.

[2]S. E. Hansen, SUPREM III User's Manual, Stanford Univ., 1985.

[3]M. E. Law, C. S. Rafferty, R. W. Dutton, New N- Well fabrication techniques based on 2-D process simulation, IEEE Trans. Electron Devices, Vol.27, pp.518521, Dec. 1986.

[4]J. Lorenz, el al., COMPOSITE - A complete modelling program of silicon technology, IEEE Trans. Computer-Aided Design, Vol 4, Oct. 1985.

[5]S. Polak, et al., The CURRY algorithm, Simulation of Semiconductor Devices and Processes, Pineridge Press, Vol.2, p.131, 1986.

[6]K. R. Whight, et al. Computer aided design of multiple guard ring systems for the passivation of high voltage planar semiconductor junctions, Proc. NASECODE III, Boole Press, 1983.

[7]N. T. Gladd, Object-oriented interface system for particle-in-cell simulations,

IEEE Trans.Electron Devices, Vol.35, Nov. 1988.

[8]B. A. Myers, User-Interface tools: Introduction and survey, IEEE Software, Jan., 1989.

[9]P. A. Gough, Device, Mesh, and Results file formats within IDDE - A proposed standard, PRL Tech.Note. No.2801, April 1989.

[10]S. G. Duvall, An interchange format for process and device simulators, IEEE Trans. Computer-Aided Design, Vol.7, July, 1988.

[11]M. R. Simpson, PRIDE: An Integrated design environment for semiconductor device simulation, IEEE Tran. Computer-Aided Design, pp.1163-1174, Sept. 1991.

[12]B. Shneiderman, Direct manipulation: a step beyond programming languages,

IEEE Computers, pp.57-69, August, 1983.

[13]I. Benbasat, P. Todd, An experimental investigation of interface design alternatives: icon vs. text and direct manipulation vs. menus Int. J. Man-Machine Studies, Vol.38, pp.369-402, 1993.

[14]P. A. Gough et al., Fast switching lateral insulated gate transistor, IEDM Tech. Dig., pp..218-221, 1986.

[15]M. R. Pinto, C. S. Rafferty, R. W. Dutton, "PISCES II: Poisson and continuity equation solver", Stanford Electron.Lab., Tech.Rep., Sept. 1984.

[16]E. Roks, et.al. A bipolar floating base detector (FBD) for CCD image sensors,

Proc. IEDM, pp.109-112, 1992.

[17]P. A. Gough, P. Walker, K. R. Whight, Electrothermal Simulation of Power Semiconductor Devices, Proceedings of ISPSD'91, pp.89-94, 1991.

[18]P. A. Markowich, The Stationary Semiconductor Device Equations, SpringerVerlag, 1986.

[19]P. Pichler et.al., Simulation of Critical IC Fabrication Steps, Vo1.32, Oct. 1985.

[20]M. Smooke et.al., Two-Dimensional fully adaptive solutions of Solid-State Alloying Reactions, J. Compo Physics, Vo1.62, pp.I-25, 1986.

[21]J. Nielsen, The usability engineering lifecycle, IEEE Computer, Vo1.25, pp.12-22, Mar. 1992.

[22]J. Nielsen, Usability engineering at a discount, In Designing and Using HumanComputer Interfaces and Knowledge Based Systems, G. Salvendy, M. J. Smith (Eds.), Elsevier Science Publishers, Amsterdam, pp.394-401,1989.

[23]J. Nielsen, Big paybacks from discount usability engineering, IEEE Software, Vo1.7, pp.l07-108, May 1990.

[24]Human Factors in Computing Systems, Proceedings of INTERCHI'93, Addison Wesley, 1993.

[25]F.Fasching, et.al. A New Open Technology CAD System, ESSDERC'91, Elsevier, pp.217-220, 1991.

[26]S. K. Chang Visual Languages: a Tutorial and Survey, IEEE Software, pp.29-39, Jan. 1987.

[27]C. T.Upson, et.al. The Application Visualization System: A Computational Environment for Scientific Visualisation, IEEE Computer Graphics and Applications, pp.30-42, July 1989.

[28]F. Paterno, et.al. The Design and Specification of a Visual Language: an Example for Geographic Information Systems Applications, Proceedings of Eurographics UK 1993, March 1993.

[29]K. P. Vaubel, C. F. Gettys, Infering User Expertise for Adaptive Interfaces,

Human Computer Interaction, Vo1.5, pp.95-117, 1990.

[30]D. D. Hils, Visual Languages and Computing Survey: Data Flow Visual Programming Languages, Jour. Visual Lang. and Computing, Vo1.3, pp.69-101, 1992.