This section describes the tasks involved in the simulator development cycle. It can be treated as an overview of the SansGUI Developer's Guide with details explained in the following chapters.
The beginning step in creating a simulator is to define the scope in the modeling domain and to identify the system elements within the scope. From the system elements, you can create the underlying logic and mathematics of the model based upon certain theories and experiences. Using SansGUI as a tool, you need to find a built-in program flow control (cycle simulation, for example) that is suitable to your modeling problem. If you have a unique requirement that cannot use any of the built-in flow control mechanism, you may use the external-process simulation control and implement your simulator as an external program to control the program execution by yourself. It is a good idea to send us the particular flow control scheme as a feature request, so that SansGUI developers can generalize and implement it in the future releases.
Once the scope has been defined, the simulation developer will use the SansGUI Development Environment to create a Schema Definition. The simulator's identification is determined and entered in the Schema Definition.
As a simulation developer, you will spend the majority of your time working on the definitions of classes in the simulation control, component, and reference categories.
Simulation Control Class: You need to decide whether your simulator should be a tightly-coupled in-process simulator, a loosely-coupled external process simulator, or both. The in-process simulation control requires you to select a built-in control flow paradigm, such as cycle simulation, and a supported programming environment that can create "plug-in" DLLs. The external process simulation control can be used with any execution paradigm and any programming environment that can generate an executable program for command script invocation. Create a subclass from the intrinsic simulation control classes is the way to let SansGUI know which control mechanism you would like to use. If you provide your users with both in-process and external process simulators, they will be able to run simulations in highly interactive sessions or in batch processes during off-hours.
Component Class: Physical components in the system are classified into a hierarchy of component classes. Most of the component classes are subclasses of the Base class, used to create component objects and parts. You can also create a subclass from the Link class and add attributes to it. SansGUI allows only one link class in the system for performance reasons. If you need some other link classes with a connection nature but vary in attributes, you should derive them from the Base class and treat the instances as parts, not links.
Reference Class: All data objects that are referred to in the system are organized into reference classes. These include collections of attributes in different types, matrices, and tables.
See the SansGUI Intrinsic Classes chapter in the SansGUI Reference Manual for descriptions of the supported classes. Chapter 2 Creating Schema Definitions describes the procedures for defining simulator classes in a Schema Definition.
Once the Schema Definition is complete, you can generate an Object Library and a set of source files that contain skeleton code for implementing class functions in an in-process simulator. The skeleton code in the source files are to be filled in with the underlying logic and mathematics of the classes in the system. The Object Library can be further customized before distribution. Chapter 3 Generating and Maintaining Object Libraries and the Using Source Code Framework section in Chapter 4 contains related topics in greater details.
For external process simulators, there is no restriction imposed upon the program control flow. The only requirement is that the simulator should read textual Model Files in a format supported by SansGUI. If not, a filter needs to be written to convert the model file from a supported format to the format the simulator understands.
For in-process simulators, the communication between SansGUI and the class functions relies on the following:
Uniform Data Object Format: All the data objects in the SansGUI environment, be it a part, a link, a reference object, or the simulation control object, are stored in the SansGUI Data Object format, which contains two structures SG_OBJ and SG_VALU. See the Implementing Class Behavior section in Chapter 4 for how to use them and Chapter 2 SansGUI Data Object Format in the SansGUI Reference Manual for more details.
Single API Prototype: All the class functions in the simulator DLL share the same prototype. See the Implementing Class Behavior section in Chapter 4 for how to use it and Chapter 3 SansGUI Application Programming Interface in the SansGUI Reference Manual for more details.
Simulation Program Flow Control: The sequence of executing the class functions for system objects and parts is controlled by SansGUI. The implementation of class functions are more of a "local" nature than the global flow control in SansGUI. The currently supported flow control can be found in Chapter 4 SansGUI Simulation Control in the SansGUI Reference Manual.
The combination of the uniform data object format and the single API prototype makes SansGUI an easy to learn and program environment for simulation developers. Because SansGUI monitors global program control flow, the developer can concentrate on the behavior of the classes, all without having to write any code to handle user interaction.
Basically, a simulator contains the following items:
An Object Library: generated from a Schema Definition and may contain convenient objects prepared by you, the simulation developer.
A Simulator Executable: either in the DLL form for in-process simulation or as a external process program to be executed by an invocation script.
A Set of Documentation: related to all the system classes defined by you, for on-line reference.
A Set of Examples: for demonstrating the use of your simulator.
SansGUI specifies default subdirectories under the SansGUI installation directory for these items. Users may customize the locations of them to suit their needs. The deploying process involves with installing the items to proper locations and managing the co-existence of multiple versions. See Chapter 7 Deploying Simulators for more details.
|
|
SansGUI Modeling and Simulation Environment Version 1.2
Copyright © 2000-2003 ProtoDesign, Inc. All rights reserved.