3.1 Model Objects: Syntax and Semantics



next up previous contents index
Next: 3.2 Architecture Up: 3 Software Issues Previous: 3 Software Issues

3.1 Model Objects: Syntax and Semantics

  A fundamental element of the integration architecture is a common representation of models. As introduced in the preceeding chapter, a model is an expression of the relationship that maps the inputs of a system under analysis to the responses they produce. A model formulation which is general and independent of the underlying implementation is needed. It should be capable of representing equally well simulation flows [80], their analytic response surface models, or their real manufacturing counterpart. The concept of a Model Object (MO), an encapsulation of model data and associated methods and procedures, is introduced to facilitate the uniform representation of models and tasks.

A MO is a specialized construct that extends the usual syntax and semantics of programming languages procedures or functions. MO data consist of a model name, input and output variable names, and the computational body that implements the relationship between input and output variables. The model input variables are further divided into model parameters and independent variables to distinguish them in parameter extraction applications. For each model variable, the name, default, minimum and maximum values can be defined. This representation is general and conveniently matches the mathematical expression of models introduced in Chapter 2.

Input variables are read-only variables whose values are initialized to the values of the calling arguments at the beginning of model execution. Output variables are write-only variables whose values are set by the model commands and bound to corresponding call arguments after model execution. In general, the executable code is a list of TCAD interpreter commands that encodes simulation flow execution and output extraction and manipulation commands. Analytical calculations can be implemented as interpreter commands or as pointers to external code in another programming language (e.g. C, Fortran).

In [76], two approaches for command interface definition are suggested:

An object-oriented command interface fits nicely with the MO concept. Accordingly, task programs are implemented as MO methods and TCAD tasks are invoked as MO commands. The following commands have been implemented:

Other commands can also be added as new task analysis tools are implemented. It is noted that the type of a MO dictates the subset of supported methods. For example, whereas the EXECUTE command is supported by all models, the FIT command can only be invoked for models that have both parameters and independent input variables.

 
Figure 3.1: XLISP code to define a linear regression () model  

The syntax of the VISTA XLISP interpreter was extended to recognize the new language constructs for model definition and model commands invocation. Figure 3.1 shows a typical model declaration and the corresponding FIT command to perform a nonlinear least-squares optimization using the data stored in file linear.dat. The model data is also passed to the task program as part of the initialization process. Consequently, VISTA and the task module share the same model representation as part of a common task specification.

The MO abstraction can be derived from the more general VISTA Tool Abstraction Concept (TAC) [34]. In fact, a TAC implementation of MO's and their associated methods would provide major benefits in terms of consistency, ease of inclusion of externally defined models, and standardization of the graphical user interface. The MO attributes and methods provide the link between the TCAD interpreter and the task programs. It is the basis of the integration architecture that is described in the next section.



next up previous contents index
Next: 3.2 Architecture Up: 3 Software Issues Previous: 3 Software Issues



Martin Stiftinger
Tue Aug 1 19:07:20 MET DST 1995