In order to integrate the GUI and the simulator engine, we must devise a means whereby they may communicate with one another. In essence, we want the GUI to be able to send the input signals and circuit description to the simulator engine and we want the simulator engine to be able to transmit the resultant output signals back to the GUI for presentation in the signal waveform display window. As a result, the chosen communication mechanism must support bidirectionalism between the two software units. Adding to the difficulty of integration is the fact that the GUI was written entirely in Tcl/Tk while the simulator engine was implemented in C++. Hence, linking the two modules together in the conventional sense is not an option, since a relocatable object module cannot be generated for Tcl scripts.
One integration strategy would be to embed the Tcl script into a C program, devise a functional interface between the C program and the C++ simulator and then to link the resulting object modules together. However, this method was rejected because it is somewhat complicated and because it may contribute to obscuring the distinction between the layout editor and the simulator engine. As will be justified later, preserving the relative autonomy of the GUI and the simulator engine contributes significantly to the potential reusability of each unit.
After weighing some of the options, it was decided that a command pipeline should be used as the fundamental conduit of information transfer between the GUI and the simulator engine. Using a pipe, a simple protocol could be developed by which the GUI and simulator engine would communicate with one another. In addition, the only means by which the GUI and the simulator would interact with each other is via the pipe, thereby encouraging loose coupling between the two modules. A simple, high-level overview of the system model showing how the pipe enables interaction between the GUI and the simulator engine is presented in Figure 5.1. The numbers located in the small nodules of the figure represent the four stages of the interaction between the two modules. These stages are discussed in detail in Section 5.4.
Figure 5.1: Communication between the GUI and Simulator Engine
Of particular importance is the bidirectional nature of the command pipeline. Many software applications already employ pipes to achieve communication between two or more separate software modules. However, that communication is usually unidirectional -- one software module produces output which is then manipulated and supplied as the input to another application over the pipe. At this point, the latter application cannot send information back through the pipe to the original module. This may severely limit the functionality and flexibility of the software application as a whole. A bidirectional pipe, however, makes it possible for two or more applications to operate as peers. In such a situation, all of the modules have the ability to send data to and receive data from one another. This makes it possible to achieve more flexible behaviour, especially on the context of several modules operating in parallel.