With respect to potential uses of the software, the current implementation has academic merit and may be useful in an introductory course on digital logic. From a research perspective, the GUI can be used to give a common interface for other simulator engines, thereby providing a uniform environment in which the performance of several different digital simulator engines may be compared. However, despite the potential benefits and applications of the GUI and simulator, there are still several improvements which can be made to enhance the functionality and practicality of both modules. Some of these enhancements could lead to industrial applications of the software.
In the context of the GUI, perhaps the biggest drawback is the lack of hierarchical support in the circuit layout editor. While the simulator engine itself does support arbitrary nesting of components, the GUI, unfortunately, still forces the user to adopt a flat view of the circuit being designed. Once hierarchical support is implemented for the GUI, the existing protocol between the GUI and the simulator would have to be enhanced to support the multi-level nature of the circuit design. Another limitation is the lack of component configurability from the GUI. For example, the GUI does not yet have the ability to let the user specify the number of inputs for a logic gate. For the most part, the user is restricted to using two input gates. Also, the end user should be able to specify the component delay using the GUI. One final minor enhancement is to have the GUI report all of its diagnostics and error messages to a separate modal dialog box. Currently, most diagnostics are sent to standard output, which is usually hidden by the circuit editor window. By presenting the diagnostics in a separate window, or maybe even in a subframe of the main window, the warning and error messages generated by the GUI will become more obvious to the user.
There are still some internal issues left to resolve with respect to the existing GUI code base. For example, as the implementation progressed, the prefixing convention for procedure and variable names became more difficult to maintain. Also, the required proliferation of global variables and arrays in the source code compromised the level of encapsulation between Tcl modules. In the future, a possible rewrite of the GUI using an Tcl/Tk extension language with better namespace control and more effective code sharing support may be possible. However, the disadvantage with using extension packages is that they may not always keep pace or be compatible with the latest release of the Tcl/Tk core from Sun Microsystems.
With upcoming releases of the Tcl core supporting nonblocking I/O, it may be possible to make the simulation interactive. This would permit the user to pause and maybe even reverse the simulation while it is in progress, for example. It may also be possible to animate the simulation itself, thereby demonstrating to the user the propagation of signals along netlists, hence making the circuit behaviour more lucid.
With the rise in the popularity of the Internet and the World Wide Web, one future project might be to rewrite the simulator engine using the Java programming language and to then integrate it with the Tcl/Tk GUI. This would enable anyone with a Java compliant web browser that has the appropriate Tcl/Tk bindings to download and execute the GUI and simulator directly over the Internet. How this would actually be accomplished depends largely upon how the two languages can be integrated with one another.
From the point of view of the simulator engine, there are many enhancements which would increase the potential usefulness of the engine. For example, zero delay components are not yet feasible with the current state of the implementation. In theory, however, it does seem possible to implement zero delay elements in a distributed queue simulator. If a component sends a signal to one of its output wires that conflicts with an existing signal on the wire at the same time, the component would not update its local time. If the output signal does not stabilize, then after a given number of oscillations, the simulation will be terminated with a diagnostic, indicating a possible flaw in the circuit design.
Like the GUI, the circuit representation employed by the simulator engine restricts the number of inputs of the basic logic gates to two. A more generic mechanism for specifying the number of inputs to these gates would contribute significantly to the extensibility of the engine. This can be achieved by supplying the appropriate component constructors with an array of connector references instead of passing the connector references individually. The addition of a clock class would also improve the simulator engine, since it would facilitate the creation of synchronous circuits. When queried by a component which has a clock input, the clock object would return the signal value that would occur at the time requested by the component in accordance with the frequency of the clock.
These enhancements would serve to increase both the academic and industrial viability of this software package and may even serve as the foundation upon which more generic queuing simulators may be based.