Previous: Concrete Representation
Up: Model Representation
Previous Page: Concrete Representation
Next Page: Design of Experiments

Encapsulation of Simulation Flows

We have made two specific uses of the generic block interface. One is to represent automatically constructed response surface models as described later in Section 4.3. The other is to automate simulation and data extraction [17]. To support the user definition of simulation flows, the following four issues are important. First, a high-level interpreted scripting language is essential for dynamic generation and use of scripts. We use the Tcl (Tool Command Language [14]) extension language for all block body scripts, thus ensuring that full language mechanisms (e.g. procedure definitions, variable manipulations, mathematical expression evaluation, and control flow) are available as needed. Second, the script must be well connected to the surrounding block, as that is where inputs, coefficients, and outputs are specified. We accomplish this by making all input and coefficient values specified via the GUI (as shown in Fig. 4) available as Tcl variables in the block body script, and by returning requested outputs back from the script to the GUI.

Third, ``template'' versions of simulation input files are important. The parameterization of simulation decks, along with parameter substitution to produce actual simulation input files, is common practice [9]. We extend this so that full expression evaluation, and indeed Tcl procedure invocation, is also possible within the template. For example, a SUPREM3 [18] deck might be parameterized as

Initialize    silicon <100> boron=1e15 Thickness=2
 Diffusion     time=#[$ox_time*60.0]# temp=1000 dryO2
 Implant       arsenic dose=1e15 energy=${energy}