The Semiconductor Simulation Hub: A Network ... - Semantic Scholar

The Semiconductor Simulation Hub: A Network-Based Microelectronics Simulation Laboratory* Nirav H. Kapadia, Jose´ A. B. Fortes, and Mark S. Lundstrom {kapadia, fortes, lundstro}@ecn.purdue.edu School of Electrical and Computer Engineering Purdue University, West Lafayette, Indiana 47907-1285

Abstract -- This paper reports on the Semiconductor Simulation Hub, a working, network-based virtual laboratory that allows geographically distributed users to share and run existing tools via standard web browsers (‘‘http://www.ecn.purdue.edu/labs/punch’’). The paper describes the capabilities of the Hub, briefly discusses the associated software infrastructure, and elaborates on the Hub’s applications in education, research, and industry. Finally, directions of further development are mentioned.

I. INTRODUCTION Technology computer aided design (TCAD) is a proven approach for developing next-generation silicon technologies, and a comprehensive set of TCAD tools is available from universities and from TCAD vendors. In advanced technology R&D, however, there are many specialized needs, both for Si and III-V technologies. Tools to address these needs have been developed, but they tend to be dispersed across universities. When a problem is encountered, locating a simulation tool, acquiring and installing it, and learning to operate it can be so time-consuming that simulation is often not attempted. A second challenge is that few research groups can afford to fund a fully-staffed modeling and simulation group to support their experimental efforts. Thus, simulation must become natural and convenient for experimentalists. Related to this objective is the need to provide users with access to simulation tools through their favored computing platforms, which tend to be personal computers, not Unix workstations. If these objectives could be accomplished, the use of simulation for semiconductor education would also be facilitated. Our approach addresses these issues by way of a networkaccessible simulation laboratory (the ‘‘Hub’’) which leverages the popularity of the world-wide web and the trend towards network-based computing. The Hub is a virtual laboratory accessible via standard world-wide web browsers which provides students and researchers using different computing environments with hhhhhhhhhhhhhhhhhh * Supported by the AT&T Foundation, the Semiconductor Research Corporation, and the National Science Foundation.

access to a broad range of simulation tools. Users can define simulations, run them, and view the printed and graphical output. The initial prototype, the Semiconductor Simulation Hub, focused on semiconductor technology CAD [1]. This Hub currently contains thirteen tools from four universities and serves over 200 users. Regular users of the Hub reside not only at Purdue, but also across the US and in Europe. During the past twelve months, these users have logged more than 230,000 hits and have performed over 13,000 simulations. New Hubs for VLSI design, computer architectures, and parallel programming have been added in recent months; they currently contain a modest complement of nine tools. In this paper, we describe the capabilities of the simulation hub, briefly discuss the software infrastructure, and elaborate on its applications and directions for further development. The Hub can be accessed at ‘‘http://www.ecn.purdue.edu/labs/punch’’. II. THE SIMULATION HUB The Hub is a WWW-accessible collection of simulation tools and related information. Functionally, the software infrastructure for the Hub (described in Section III) allows users to: a) upload and manipulate input-files, b) run programs, and c) view and download output - all via standard WWW browsers. Users can enter the Hub either as members or as guests. Members have their own (private) hub-accounts, and can access the full functionality of the Hub. Guests, on the other hand, can only view the example input files and the precomputed output available in a ‘‘public’’ hub-account. Hub-accounts can be requested on-line (accounts are generally restricted to collaborators, although courtesy accounts with access to a limited number of programs are available). Once inside the Hub, users are presented with a ‘‘directory’’. The directory page (Figure 1) provides a means to access the various tools available on the Hub. For convenience, each tool is indexed and cross-referenced by way of one or more keywords. For example, a tool may be indexed according to its functionality (e.g., heterostructure simulator), and/or according to the university at which it was developed. A master-list of all the tools available to a given

Figure 1: A view of the directory organization used in the Semiconductor Simulation Hub. This page is a standard HTML document, and can be modified as desired.

Figure 2: The user-interface for MINIMOS 6.0. Note the three steps involved in running a simulation. This page is dynamically generated by the Hub.

user (see below) on the Hub is also provided. Finally, the directory page provides access to a tutorial for first-time users and other internal and external links (e.g., a library of tool-related information). An important feature of the Hub infrastructure is its ability to customize the web-based environment for each class of users. Except for the main page and the directory page, almost all the pages in the Hub are dynamically generated. This allows the Hub to present different views to different users. For example, the Hub can be configured so that a proprietary tool ‘T’ is only visible to a specified sub-set of users ‘U’. With this configuration, the Hub will exclude ‘T’ when generating pages for users who do not belong to ‘U’. Moreover, the Hub enforces such access-restrictions; a user who does not belong to ‘U’ will not be able to access ‘T’ regardless of the URL that he/she uses (the relevant URL will be deemed ‘‘invalid’’ by the Hub for unauthorized users). Each tool on the Hub is accompanied by a brief description of its capabilities, a manual (if available), example input files and pre-computed output, and the email address of the support site for that tool. If the tool has a home-page on the web, a link to it is also provided. Running a simulation on the Hub is a three-step process (Figure 2). The first step involves the creation of the input file (Figure 3) required for the relevant simulation. To facilitate this, the Hub provides an editor interface (not shown) which allows users to create and modify text files. Also, with a view to assisting new users, the Hub provides an ‘‘examples folder’’ with sample input files for each tool.

A new user can select a sample input file that best matches his/her current needs, copy it over to his/her hub-account, and then modify it as necessary. Alternatively, users who prefer to do the editing on their own computers can upload files to the Hub via email. The Hub’s input interface (Figure 3) also supports general file-manipulation and utility functions such as copying, renaming, deleting, and compressing files; frequently-used commands are displayed as checkboxes in Figure 3, while other commands may be accessed via the text-based command-line (part ‘d’ in the figure). In the second step, users define the input parameters (e.g., command-line arguments, etc.) for the program and start the simulation. For the MINIMOS [2] program (Figure 4), users must select the input file that is to be used for the simulation, name the folder in which the output is to be stored, and name the file to which the output of the program is to be redirected. Users can also enter an email address at which they wish to be notified of the completion of the simulation. This feature is very useful for simulations that are expected to run for several hours or days. Once all this information has been entered, users can submit the request to the Hub for processing. Before initiating the run, the Hub will verify that all the necessary parameters were entered, and supply default values where appropriate. As explained in Section III, the simulation is typically initiated on a remote compute-server; a run-status page is available to allow the user to check on the status of the simulation. In general, programs may require one or more input files, associated data files, and multiple command-line arguments. In order to support programs with a wide range of

Figure 3: The input interface for MINIMOS 6.0. This interface allows the user to create and edit input files for the relevant tool. It also supports general file-manipulation and miscellaneous utility functions. This page is also dynamically generated by the Hub.

input characteristics, the Hub uses a programmable interface-generator for this part. When installing a program, the Hub administrator specifies its input characteristics via a specially designed resource-description language. This specification is then used by the Hub at run-time in conjunction with the user-input to generate an appropriate interface for that program. This mechanism allows the Hub to interactively obtain the input required by a given simulation from the user. As an example, consider a simulation tool that is capable of using an external doping file; the file is referenced in the program’s input file, if it exists. After a user selects an input file and submits a request for execution, the Hub will scan the input file for the name of the doping file. If the file-name is found, the Hub will look for the corresponding file in the search folders for that program. If it finds the file, the Hub will initiate the simulation. If not, the Hub will prompt the user to select the folder in which the doping file resides. Thus, the functionality provided by the programmable interface-generator allows the Hub to ask the user for partial input, ‘‘interpret’’ that input, and react accordingly (e.g., warn users about incomplete or erroneous input). Finally, after the simulation is complete, the user can see and download the results of the simulation via the Hub’s output interface. The output interface is very similar to the input interface (Figure 3) in that it allows the user to view files and provides general file-manipulation and utility functions. In addition to this functionality, the output interface also supports a post-processing interface. The postprocessing interface allows users to manipulate the output

Figure 4: The execution interface for MINIMOS 6.0. This interface allows the user to initiate MINIMOS simulations. Like the other Hub pages, this page is dynamically generated.

generated by the simulator. Typically, this involves generating postscript plots interactively. In some cases, the postprocessor further manipulates the results of the simulation. Like the execution interface, the post-processing interface is programmable; its organization and content are defined by the Hub administrator when he/she installs a simulation tool on the Hub. The post-processing interface for MINIMOS 6.0 is shown in Figure 5; a sample plot generated via this interface is shown in Figure 6. III. THE HUB INFRASTRUCTURE The Hub infrastructure consists of a set of specialized servers written in Perl5. The software infrastructure that supports the Hub was designed to: a) have a universallyaccessible user-interface (via WWW browsers), b) provide access-control (security and privacy) and job-control (run, abort, and program status functions), and c) support logical resource-organization and management. The infrastructure can be replicated on different types and numbers of machines and customized for specific needs. Figure 7 shows a conceptual view of the Hub. The Hub infrastructure is a distributed entity that consists of a set of specialized servers which access (and control) local and remote hardware and software resources. As implied by the figure, hardware resources include arbitrary platforms. Likewise, software resources include any program (the current implementation does not support GUI-based programs); the Hub allows these to be organized and cross-referenced according to their domain. The Hub allows resources to be added incrementally, and uses a resource-description

language specifically designed to facilitate the specification of tool and machine characteristics. For example, a new machine can be incorporated into the Hub simply by specifying its architecture (make, model, operating system, etc.) and starting a server on the machine. Similarly, a new tool can be added by ‘‘telling’’ the Hub the tool’s location, its input behavior (e.g., command-line arguments), what kinds of machines it can run on (e.g., Sparc5), and how it fits into the logical organization of the Hub (e.g., circuit simulation tool). These tasks can be typically accomplished in less than thirty minutes. Purdue Users Mac/PC/Unix

External Users Mac/PC/Unix

User-Interface Distributed Hub ‘‘Engine’’

Tools: - Device - VLSI - Other

Resources: - Servers - Workstations - MasPar

Purdue Purdue Illinois

............

Member Supercomputing Center

Maryland

Figure 5: The post-processing interface for MINIMOS 6.0. This interface allows the user to plot internal quantities for the device at specified bias points and cross-sections.

Contributing Members

Purdue University Network-Computing Hub ‘‘A Network-Based Virtual Laboratory’’

Figure 7: A conceptual view of the Purdue University Network-Computing Hub.

Figure 6: A sample plot of the doping profile used by MINIMOS for an example run.

Functionally, the Hub infrastructure is divided into three parts - the HTTP (HyperText Transfer Protocol) frontend, the lab-engine, and the remote servers. The front-end deals with access-control and file-manipulation, and translates the output of the lab-engine into HTML. To facilitate this functionality, the Hub server interprets the URLs differently from the standard document-oriented web servers. The structure of the URL is decoupled that of the underlying file-system and interpreted in a context-sensitive manner (based on user-specific state stored by the server), thus allowing virtual accounting and arbitrary accesscontrol. The lab-engine provides the Hub with its ondemand high-performance computing capabilities. When a user requests the execution of a program (Figure 8), the labengine uses information in the user-specified input file to predict the resources required for this run, selects an appropriate platform (e.g., workstation for 2-D, supercomputer for 3-D), transfers relevant input files to the selected machine, and initiates the program (via the remote server). When the run is completed, the remote server notifies the lab-engine, which retrieves the output files and informs the user. Note that the above discussion presents a highly simplified functional view; a detailed discussion is beyond the scope of this paper.

User 1

6

Network Link

1. User Makes Request 2. Lab Processes Request

HTTP User-Interface

3. Lab Sends Request to Remote Server(s)

2

Distributed Lab ‘‘Engine’’ 3 5

Network Link(s)

4. Remote Server(s) Inform Lab when Job is Complete 5. Lab Retrieves Output 6. Lab Notifies User

4

Remote Lab Server(s) Figure 8: A simplified view of the steps involved in running a program on the Hub.

IV. APPLICATIONS IN EDUCATION It is very rare to see state-of-the-art research packages being used as an integral part of a curriculum. This is largely due to the lack of portability and the idiosyncratic userinterfaces of these tools. The Hub addresses the portability problem by allowing tools to be used where they reside. Also, because the Hub infrastructure dynamically generates user-interfaces, it implicitly provides flexibility with respect to how users see the tool’s original user-interface. For example, if a tool accepts a command-line argument ‘‘-O’’ to indicate optimization, the web-based interface can present this as a check-box or a menu with a list of choices with the desired caption. Thus, although the Hub cannot by itself transform a non-friendly idiosyncratic program interface into a user-friendly one, it provides a mechanism by which tool developers and installers can improve the userinterfaces to their codes. At Purdue University, the Hub is currently being used in several undergraduate and graduate courses. We have found that the Hub facilitates the use of simulation in courses by providing an easy, platform-independent means to access simulation programs, run simulations, and view printed and graphical output. Many students use the Hub through a modem from their residences rather than making use of on-campus computer labs where seats are frequently hard to find. Based on our experiences in using the Hub in an educational setting during the 1996-97 academic year, we plan to significantly expand the applications in the coming school year. In addition to making use of the Hub in a larger number and variety of courses, we also plan to explore applications in distance education. Currently, simulationintensive courses are difficult to offer to off-campus students because of the difficulties in providing access to a common tool-set (e.g. a particular version from a specific vendor).

Industry, however, continues to express interest in such courses to assist engineers in becoming effective users of sophisticated simulation programs and in the use of simulation for computational prototyping. For an integrated circuit processing course to be offered in the Spring of 1998, the Hub will provide on- and off-campus students with a common simulation lab accessible at Purdue, the engineer’s workplace, or at the students’ residences. The Hub is also the enabling technology for a newlyfunded NSF-supported project directed at the use of simulation in semiconductor technology development. The objectives of this three-university project (Purdue, Univ. of Illinois - Chicago, and Univ. of Texas - El Paso) are to: a) educate technology-developers on the use of computer tools (as opposed to producing computational specialists), b) bring the use of advanced, university-developed simulation tools into the silicon technology development process, and c) bring the use of simulation into the field of emerging semiconductor technologies, where it currently finds little use. The Hub provides a comprehensive simulation laboratory to the three universities, making it possible for them to share specialized tools. V. APPLICATIONS IN RESEARCH The Hub also has a number of useful applications in research where it provides a community of researchers with centralized access to an extensive set of tools that are maintained and operated at different locations throughout the world. This service is especially useful in specialized fields where vendor-supported packages are not available due to the small user base. In this regard, the Semiconductor Simulation Hub provides a computer lab for Purdue’s NSFfunded Materials Research Science and Engineering Center (MRSEC) for Technology-Enabling Heterostructures. Experimentalists in the Center, and their collaborators worldwide, have access to an extensive set of simulation tools. The Hub is providing experimentalists with an easy means to test device designs before fabrication and to analyze the results of device measurements. In addition to providing experimentalists with ready access to a set of simulation tools, the Hub also promotes collaborative research by facilitating interactions with experimentalists and computationalists. In a recent example, one of the MRSEC’s collaborators was conducting measurements on semiconductor films grown at Purdue’s Center. Because the results of the measurements proved difficult to interpret, a software tool to simulate the experiment was installed on the Hub where it could be run by the experimentalists using their own data as inputs. Computationalists at Purdue worked with experimentalists at Brooklyn College in New York City to iteratively modify the simulation program and the experimental analysis procedures until a satisfactory understanding was developed. A publication quickly resulted [3]. We find that by facilitating interactions between experimentalists and computational experts, both parties benefit, and research is accelerated.

VI. APPLICATIONS IN INDUSTRY-UNIVERSITY INTERACTIONS Universities and industry interact through educational and research programs, and simulation hubs can play a role in enhancing these types of interactions. Technologytransfer of software-related university research is a particular example where the Hub can play a positive role. For example, the Hub allows engineers in industry to access and try out university-developed software tools with a minimal investment of time and effort. If, in the process, the engineer becomes convinced of the need for the tool, he/she can then justify the effort needed to install the software and learn how to operate it. As one example, the Hub was recently used in a successful, four-university technology-transfer short course for the Semiconductor Research Corporation. Before the course began engineers at SRC member-companies were able to access the Hub and examine the device simulation tools being released to industry. At the course, they became acquainted with the operation of the tools in more detail, and now, they are able to continue to access and use the simulation tools via their WWW browsers. In addition to its role in enhancing university-industry interactions, there are also potential applications for simulation hubs in industry. For example, a hub could be used by a company internally to provide organization-wide networkcomputing (or intranet computing). This would be especially useful for companies that have multiple, geographically distributed sites. The hub would allow each tool to be supported ‘‘on-site’’ by the group that originally developed it, and, at the same time, allow any modifications and/or upgrades to the tool to be propagated to the users instantaneously. A hub could also increase the visibility of new and existing products to potential users. For example, an organization’s sales representative could use the hub to access and demonstrate relevant tools at a customer’s site without being constrained by the computational resources available at that site. Likewise, the organization could use a hub to allow potential customers to evaluate sophisticated tools that need highly specialized computational resources. The hub’s functionality can also facilitate the software industry’s move towards a ‘‘subscription’’ model. VII. SUMMARY AND FUTURE DIRECTIONS The network-based simulation laboratory described in this paper has been successfully implemented and applied to education, research, and technology-transfer. The Hub’s user base currently consists, for the most part, of students, faculty, and researchers at Purdue University. Regular users of the Hub also reside across the US and in Europe. In addition to the initial hub, the Semiconductor Simulation Hub, new hubs for VLSI Design, Computer Architecture, and Parallel Compilers are currently being established. A special hub to facilitate technology-transfer activities for the Semiconductor Research Corporation has also been established. Having successfully demonstrated several disciplinespecific simulation hubs, applications will expand. As they do, however, several issues regarding the hubs functionality will have to be addressed. Currently, tools in the Hub run in

a ‘‘batch mode’’: users define an input file, perform a simulation, and then analyze the results. Interactive programs are a challenge because of the current bandwidth limitations of the network. Also, the increasing use of graphical userinterfaces for programs presents a challenge for the infrastructure. The use of Java programs may help provide interactivity as well as GUIs for simulation programs. Postprocessing simulation results interactively is an issue that is easier to handle. The hub provides some basic postprocessing now; for extensive post-processing, simulation data can be downloaded and analyzed on the user’s own computer. Simulation hubs provide convenient access to simulation programs, thus facilitating wider use in education and research. They do, therefore, address one of the major barriers preventing the more widespread use of simulation tools. The next problem, however, is even more challenging. Simulation tools tend to be very sophisticated and difficult to use. It is not uncommon for a new user to take several months or more to become proficient at using these tools. (This is an important problem for industry in meeting the need for TCAD engineers, and it limits the use of simulation in education because an inordinate amount of classroom time is consumed by learning to operate the tool.) In this regard, we have begun experimenting with the application of artificial intelligence (AI) systems to assist new users in solving problems. Such a system might ‘‘learn’’ how to perform simulations by ‘‘observing’’ experts solve problems on the Hub. It would then be able to offer advice to new users attempting to solve similar problems. A simple system has already been implemented. By examining specified features in the input files for programs and co-relating them with the amount of time that the simulation takes to complete, the AI system learns how to predict the simulation time on the basis of the input parameters supplied to the simulator. This prediction is then provided to the user, and it may also be used to select an appropriate machine on which to perform the simulation. In summary, we have successfully implemented a network-based simulation hub and applied it to education, research, and technology-transfer. Those interested in network-based simulation are encouraged to try it out at http://www.ecn.purdue.edu/labs/punch. REFERENCES [1] N. H. Kapadia, M. S. Lundstrom, and J. A. B. Fortes, "A Network-Based Simulation Laboratory for Collaborative Research and Technology Transfer", Semiconductor Research Corporation’s TECHCON ’96, Arizona.

[2] S. Selberherr, A. Schutz, and H. W. Potzl, "MINIMOS - A two-dimensional MOS transistor analyzer", IEEE Transactions on Electron Devices, Vol. 27, No. 8, pp. 1540-1550, August 1980.

[3] T. Holden, F. H. Pollak, J. L. Freebuf, D. McInturff, J. L. Gray, M. Lundstrom, and J. M. Woodall, "Reflection anisotropy spectroscopy study of the near surface electric field in lowtemperature grown GaAs (001)", Applied Physics Letters, Vol. 70, pp. 1107-1109, 1997.