Java based Digital Simulation Automation System (JSAS) Youngmin Hur Quickturn Design Systems, Inc. 440 Clyde Ave. Mt. View, CA 94043-2232 Tel: (415)694-6508 Fax: (415)691-6020 Email:
[email protected] Dominik Kacprzak Silicon Graphics Inc. Mt. View, CA 94043 Tel: (415)933-8804 Email:
[email protected] Stephen A. Szygenda University of Alabama at Birmingham Birmingham, AL 35294-4461 Tel: (205)934-8400 Fax: (205)934-8437 Email:
[email protected] KEYWORDS VLSI and Simulation, Simulators, Software Engineering, Verification, Interactive Program ABSTRACTS Java based Digital Simulation Automation System (JSAS) is Java based graphical user interface that allows for a remote access to many forms of software simulation available from any remote location. The system allows uploading input simulation data, scheduling and performing simulation, and retrieving results efficiently. The web oriented and distributed architecture makes JSAS an ideal tool that allows a remote access from virtually any place to a powerful simulation engine. Also, its platform independence leads JSAS to bridge over different systems. The simulation results generated by JSAS can be represented on each user’s web browser in various formats of output files. With Java and World Wide Web (WWW), the JSAS becomes a robust, widely available simulation and design verification tool. INTRODUCTION Simulation is widely used for verification because it can verify designs under various delay conditions and either detect or isolate faults or actual design errors introduced when describing the designs. However, due to the inherent complexity and time consuming nature of equation solving, verifying the system becomes very costly and therefore, low level simulation is mostly used to verify small parts of the design, where critical analysis is necessary. Also, simulation procedures such as creating and
managing simulation models, generating model libraries, executing simulation, and analyzing simulation results, are error prone and a knowledge intensive process. As the size of digital systems increase rapidly, a system is partitioned into smaller sub-systems which can individually be simulated and multiple heterogeneous workstations are often required as a simulation engine to accomplish digital simulation for this application. This methodology allows one to solve computation problems but raises new architecture problems such as remote access. A traditional remote access method is not adequate to be used in a heterogeneous environment because frequent collaboration efforts between simulation tasks distributed in different locations requires a new user interface. The implementation of the Java based Simulation Automation System (JSAS) satisfies the requirements of the simulation environment described above. JSAS executes various simulation processes for design verification automatically and efficiently, and it provides high performance remote user interface for completion of various simulation of digital systems. The JSAS can verify designs using the functional, fault and design error simulators. It also provides a capability to derive confidence measures for each type of simulation. Hence, JSAS becomes a flexible and easy-to-use CAD system by allowing the user to simulate and verify a circuit design, interactively through a World Wide Web (WWW) based interface. Firstly, the JSAS converts input circuits described in various formats, such as Boolean equations, TEGAS Description Language (TDL), and Structural Hardware Description Language (SHDL), into the Standard Intermediate Format (SIF) that the system uses for simulation. This system also supports Automatic Model Generation (AMG) using domain specific automatic programming techniques. A user can generate models from different input formats such as Truth tables, Boolean equations, TDL, and VHDLs. The AMG generates functional models for all primitives to describe the behavior of each element and provides an efficient and effective methodology to create simulation models of digital systems. The system translates these models into C routines, generates a new model library or manages the existing one (Hur and Szygenda 1996). Secondly, the JSAS executes design simulation. The system supports various types of simulators: concurrent, parallel, and distributed (Hur et al. 1997). These simulators are table-driven, compiled, three-valued simulators which can simulate functional, fault, and design errors. Required files for simulation include the SIF file format of input circuits, input test pattern file, and the name of input and output. As circuit size increases, the number of modeled faults and design errors also increases. In order to reduce the number of faults or design errors and to increase total simulation performance, two methodologies such as: fault collapsing and error compression technique and statistical sampling methodology (Agrawal 1981; Agrawal 1981a) are applied to JSAS. These techniques can reduce simulation time as well as resources, rapidly. Finally, simulation results are generated in the output files. Output files contain necessary information for simulation analysis such as: simulation execution time, fault or error coverages, and the number of detected and undetected faults or errors. Additionally, JSAS simulators produce files, such as, the list of detected and undetected fault or design errors, as well as the list of selected and unselected simulation input patterns. This research was conducted at the Network and Software Engineering Lab. (NeaSEL) in Electrical and Computer Engineering Department of the University of Texas at Austin. This lab was primary designed
for network research and distributed simulations. Almost thirty UNIX workstations are connected by switched network topology and NeaSEL provides a unique simulation engine and a testbed for research on distributed simulation. With the heterogeneity of the lab architecture, the problem of user interface appeared. Fast and easy accessibility of user interface has to be available on different platforms. This requirement could not be met using conventional software simulation methods. A Java based graphical user interface of the JSAS allows for remote access to all forms of software simulation available at NeaSEL, from any remote location. It allows users to upload the input simulation data, schedule and perform simulation, and retrieve results easily and efficiently. Because of its web oriented and distributed architecture, JSAS is an ideal tool that allows a remote access from virtually any place to a powerful simulation engine such as NeaSEL. Because of its platform independence, JSAS bridges over different systems available in NeaSEL. The simulation results that are generated from NeaSEL by JSAS, can be represented on each user’s web browser in various formats of output files. The next sections of this paper describe three components of JSAS: processing input circuits, simulation, and result analysis. The simulation system environment and illustrations of the Java implementation are provided, followed by conclusion. PROCESSING INPUT CIRCUITS The input description formats which are the external models to simulators can be numerous. An efficient approach is to generalize all input descriptions to a valid intermediate file format which can be used uniquely by simulators. JSAS converts input circuits described in the form of Boolean equations, Tegas Description Language (TDL), or Structural Hardware Description Language (SHDL) into the Standard Intermediate Format (SIF). This translator, called SIF generator, can handle both combinational and sequential circuit descriptions. Executable files: eq2sif, tdl2sif, and str2sif, are called by the web browser and they generate SIF files. A SIF file consists of: file name, numbers of devices, nets, device types, multiple output devices, primary inputs, primary outputs, clocks, and net numbers of constant inputs to the circuit. It also includes names of all device types, primary inputs and outputs, constant inputs, clocks, delays, netlist, net names, device names, module names, and hierarchical information. When implementing a digital logic simulator, simulation models are created and added into a simulator as the most fundamental component of the simulation system. Even if many predefined models are reused to describe a large system, the process of creating a model library is one of the most time consuming tasks in the development of simulation software, since it is an error prone and knowledge intensive process (Bloom 1987). Hence, for fast and accurate simulation results in the performance of simulation models, automatic model generation for simulation and test, using automatic programming techniques, is clearly desirable so that the details of low level coding are hidden to circuit designers. Therefore, the chance of errors in the design cycle can be reduced significantly. There have been many attempts at developing general purpose automatic programming systems which could generate programs from specifications. However, these have only been successful for some simple examples. Nontheless, several successful automatic programming systems have been developed by restricting the application domain. These are called domain specific automatic programming systems. Domain specific automatic programming is concerned with: methods for selecting programming constructs for specification implementation, how to utilize fragmentary information, how to synthesize code from examples of the desired behavior, and how to utilize domain knowledge (Biermann et al.
1984). The application domain knowledge is identified, organized and incorporated as internal rules to guide several transformation processes to convert various forms of model specification into desired simulation models. The domain knowledge can be provided either by the user as a part of the interactive specification process, or it may initially exist in the system. The method of representing the domain knowledge, and the interaction between the domain knowledge, and the programming knowledge, are dictated by the specific application domain (Szygenda 1990). The application domain of this system is digital system simulation and modeling. The automatic model generating process uses two primary knowledge sources: domain-related knowledge and domain-independent programming knowledge. The former involves knowledge related to digital system modeling and simulation and the latter is concerned with the syntax of the target language and the data structures used. By automating the model generation process, many error prone and time consuming tasks are eliminated. This capability can greatly reduce the design cycle time. The system builds a simulation model library for a new simulator or upgradesan existing model library. The system, also, has the capability of developing simulators automatically, using domain specific programming techniques. This allows users, who may have limited knowledge in the application domain, to easily develop unique simulators. The simulation model represents the function of each element and consists of executable subroutines written in a simulator target language. Input descriptions are translated by a translator or parser into a formal description. There are two types of description which can be generated. One is behavioral, which focuses on abstract behavior of a circuit rather than lower level structural detail of design. These can be defined using truth tables, Boolean equations, or HDL descriptions. The other type is structural, which describes a circuit by connecting lower level elements. Truth tables and Boolean equations are also commonly used, however HDL has more flexibility for large circuits. Structural HDL descriptions are parsed and passed to the Netlist Generator. The generated net list is sent to the model generation system to describe digital circuits. The model generating process can be divided into three phases using the application domain knowledge to generate element routines. The three phases are: signal modeling, primitive modeling, and functional modeling. The details are described in (Hur and Szygenda 1996a) and the brief description of these phases are as follows. Signal Modeling Phase The software representation of the electrical signal is determined in this phase. Traditionally, two-valued modeling is used where two boolean logic values are either 0 or 1. However, this model can not represent a signal voltage range between the lower and upper cut-off voltages. For a more realistic representation, three-valued modeling is used. In this modeling, an X is used to represent an unknown signal voltage, apart from the high and low voltages represented by logical 0 and 1. For more resolution in signal representation, a five-valued model can be used. The five-value model has the ability to represent a signal in transition by using: U to represent a signal whose voltage is increasing, D to represent a signal whose voltage is decreasing, 1 to represent the upper cut-off voltage, 0 to represent the lower cut-off voltage, and E to represent all other signal states. Selecting a bit representation which accurately models the signals and makes the boolean operations as simple as possible is an important task of this phase. For a two-value model, one bit is used to represent 0 and 1. For a three-value model, two bits are used to represent the three logic values (0, 1, X). For a five-value model, three bits are used
to represent five logic values (0, 1, U, D, E). Primitive Modeling Phase Primitive elements are defined as the basic set of elements whose functionality is described by using only the logic states created in the signal modeling phase. For example, AND, OR, NAND, NOR, XOR, and XNOR can be described by using logic states created in the signal modeling process, and they can be used to build more complicated hierarchical elements. To generate code for a primitive, a truth table or a Karnaugh map depicting the primitive is transformed using different domain-related knowledge. The most important task of the transformation process is to superimpose the bit representation (from the signal modeling phase) onto the truth table (constructed from the user specification) to create multiple truth tables, each describing the logic operations in terms of each individual bit in the bit representation. The knowledge of mapping the truth tables to Karnaugh maps, the task of obtaining minimized boolean equations from a truth table or Karnaugh map, and the task of translating the boolean equations into software code, in a target language, are critical to the modeling process. Functional Modeling Phase The required input to this phase is a circuit diagram detailing the internal components and their interconnections. The transformation process involves the diagram being transformed into its netlist description, which is an internal description of the circuit components and their interconnections. Following this, an ordered netlist is generated by applying a levelizing process. The ordered netlist determines the propagation order of all circuit inputs inside the circuit net. For the levelizing process, it is important to determine the logic level of the element. The code for the functional element is generated by combining the component element routines, that are already available, in accordance with the ordering in the ordered netlist. Designers of functional elements need to know the functionality of the element to be constructed. They also need to have knowledge about netlist generation, levelization, and how to generate the functional element routine correctly using the levelized ordered netlist. Figure 1 shows the Java screen of translation utility in the processing input circuits phase. A user has to choose working directory by specifying the HTTP location. User’s directory is represented in the form of URL location. The location is accessible for read/write operations for the translation server running in the simulation environment. Transferring files between user’s directory and server is executed by HTTP data transfer. "Choose Files" button simplifies the navigation through a directory tree that stores simulation files.
Figure 1. Input Circuit Translation Window of JSAS SIMULATORS JSAS provides three different software simulators: concurrent (CSIM), parallel (PSIM), and distributed (DSIM). These simulators are general, time based, event driven, compiled model, parallel simulators, written using C++, flex (GNU version of lex), and bison (GNU version of yacc). These simulators have the ability to perform logic, fault and design error simulation using a three value signal representation (0, 1, X). Rise and fall delay models assign different delays to fan-in and fan-out signals of a primitive, depending on the transition. These models allow detailed timing simulation at the gate level and provide a mechanism to perform spike, race, and hazard analysis. The simulators consist of preprocessor, evaluator, optimizer, scheduler, and postprocessor. The preprocessor performs the necessary interface functions. It is responsible for reading the circuit description, which is in the SIF, the simulation test pattern (SIM) file, and the fault and design error lists generated by simulators. After the appropriate files are read, the preprocessor initializes and sets up the necessary data structures, and turns the control of simulation over to the evaluator. The evaluator is related to the actual circuit simulation. Each of the simulation algorithms in the evaluator are tailored to perform functional, fault or design error simulation. Optimizations during evaluation include the use of a selective trace method to propagate signal values. The simulators use a two pass strategy instead of a one pass strategy. Although the two pass strategy incurs overhead in the form of bookkeeping, it is less extensive than one pass, when using rise and fall delay models, because it guarantees to schedule only true events. The main part of the simulators is the scheduler, or the time flow mechanism. The scheduler is responsible for the execution of events in the correct temporal order. The system uses a hybrid time queue mechanism, which is comprised of a time wheel and a macro time queue. The time wheel is implemented in a fixed increment fashion and is used to schedule events that occur within a fixed time window, denoted by the boundary times of the time wheel. The macro time queue is a linked list of events sorted by event times. Events whose time stamp exceeds the current time window of the time wheel are inserted into the macro time queue. The postprocessor provides information from the simulation run. For all types of simulation, the preprocessing time, the simulation time, the number of processed events, the number of events per second, the number of patterns applied, and the simulation time per pattern are provided for performance evaluation. Errors in simulators are originated and propagated. As the error propagates through the circuit, the time stamp, net number, and signal value may change according to the behavior of the circuit to the test pattern applied. However, the other fields in the event remain the same. These fields are used to identify the original detected fault, once it propagates to a primary output. Error simulation involves two time queues - good time queue and faulty time queue. The good time queue stores events of the good circuit and the faulty time queue stores events related to the faulty circuit. Initially, for the current simulation time, all events from the good time queue are removed, evaluated and placed in the activation list, if necessary. Next, the events on the activation list are
evaluated. This causes more events to be scheduled into the good time queue. Then, every fault associated with the device is evaluated, causing events to be scheduled on the faulty time queue. If there are no more events in the good time queue, the algorithm starts removing events from the faulty time queue. The event removed from the faulty time queue is evaluated only if it has a time stamp less than or equal to the current good simulation time. Otherwise, the event is put back into the faulty time queue and the algorithm shifts attention to the good time queue. If the former case is true, the device associated with the faulty event is evaluated and put into the activation list, if necessary. If the device associated with the event is a primary output, then a fault is detected and can be removed from the fault list. The algorithm repeats itself, until no more events are present on either of the time queues. Given an initial set of test patterns, the system can automatically generate a subset of patterns to be used for simulation. The designer can generate additional simulation patterns for faults or design errors, to achieve a higher confidence level. For a large circuit, the process of manually generating an error list is quite tedious. Hence the need for the error generators: Fault and Design Error generators. These generators expect the name of a SIF file as an input. The output which is stored in a file whose name is specified by the user contains a collapsed set of faults or design errors. In the case of design error generation, the final set of design errors are extended and compressed. The user is also given the flexibility to choose the type of design errors to generate (either signal, functional, include or local errors). To speed-up the concurrent simulation, four levels of parallelism: application, subroutine, component, and event, can be considered (Hur et al. 1997). These parallelisms are exploited by using multiprocessor acceleration platforms, i.e. parallel machines, network of workstation, or hardware accelerators. In data parallel techniques, simulation input data, such as simulation input patterns, faults, and design errors, are partitioned into subsets and are assigned to available processors of an acceleration platform. These techniques are easy to implement and have less inter-processor communications. On the other hand, in circuit parallel techniques, the circuit to be simulated is split into several sub-circuits and each sub-circuit is assigned to a processor. These techniques do not have the duplicated simulation overhead of the data parallel techniques, however a heavy volume of inter-processor communications is required. The process of fault and design error simulation can be accelerated by executing simulation on general-purpose parallel machines or on a Network of Workstations (NOW). This method offers a simple and economical way for acceleration. The basic idea of the distributed simulation in JSAS is to split the simulation process into separate tasks which are executed on different workstations. There are two basic techniques to accomplish this goal: data-parallel and circuit-parallel. The input data is partitioned into subsets and these subsets are assigned to available processors of an acceleration platform. In the circuit-parallel techniques, simulation subtasks are the subsets of the simulated circuit. The simulated circuit can be partitioned statically or dynamically at the gate or module level. The experiments showed that static partition is faster than the dynamic because of the overhead introduced. This section presents the investigation and implementation of three types of data-parallel techniques: fault-partitioning, pattern-partitioning and the hybrid method -- for the acceleration of fault and design error simulation. Distributed simulation has been implemented to incorporate these three techniques. The data-parallel techniques for fault and design error simulation are similar to each other, therefore, only the fault-partitioning model is described. In this method, the modeled faults are partitioned into N groups, where N is the number of processors available. Since the detection of a fault, or the failure to detect that fault, is independent of the detection ability of another fault, no inter-processor communication is needed during the simulation. Each processor executes the concurrent simulation
algorithm for the entire circuit with a subset of the faults. After all the N processors have finished the assigned task, the individual results need to be merged to reflect the overall fault detection. The main disadvantage of this approach is that each processor simulates the good circuit for all input patterns; thus, the good circuit is simulated N times for each input pattern. In the pattern-partitioning method, the input patterns are partitioned among N processors. Each processor executes the concurrent fault simulation for the entire circuit but only with a subset of the patterns. Again, no inter-processor communication is used during simulation, but a post-processing phase is needed to merge the results. The advantage of this method over fault-partitioning is that the good circuit is evaluated only once for each input pattern, while the disadvantage is that all of the faults are simulated on all N processors. If there are few faults, this disadvantage becomes inconsequential, since the majority of the work is spent simulating the good circuit. A modified version of pattern-partitioning method which allows inter-process communication between processes in order to reduce the number of faults which are redundantly detected by different processes. Finally, the hybrid method combines the above stated methods. The distribution of the number of events through the course of simulation, showed that the simulation load is not even, and the earlier phase of simulation is dominated by faulty events, and the later phase is dominated by good events. This is due to the fact that the number of undetected faults drops exponentially with respect to simulation time. Thus, in the earlier phase, fault-partitioning is most efficient when the number of faults is large and the cost of the good-circuit simulation is small, in comparison to the cost of fault-simulation. In the later phase, the pattern-partitioning is most efficient when the number of faults is small and the good-simulation load is distributed. Unlike the previous two methods, this method requires result-merging, twice: once after the fault-partitioning phase, and once after the pattern-partitioning phase. After running the "percent" of input patterns in the fault partitioning phase, the lists of undetected faults are merged, and this entire list is used in the next section of the pattern partitioning phase. Because, usually, in the second phase the number of faults left undetected is not big, a modified version of the basic hybrid method was designed which allows communication between processes which are in the second phase of the simulation. This fact improved the overall speedup of the simulator. Figure 2 illustrates the Java input screen for the simulation phase. This window includes the simulation options such as fault collapsing, design error compression, and sampling techniques. Currently, if a user selects proper item, the text window will prompt so that user can interact with the system. Before a user executes the simulation, one needs to set proper working directory, input and output files, and a simulation type.
Figure 2. Simulation Input Window "Remote access" operation allows a user at remote location to open and access files that were already generated by simulation. This option allows sharing simulation results among geographically distributed users. ANALYZING SIMULATION RESULTS The output results from the simulators include: error coverage metric values, lists of detected and undetected errors, and simulation statistics. The principal use of output data of the simulator is to determine whether additional simulation test patterns should be added to the test suite to attain the required error coverage. However, it is not feasible for the user to draw conclusions by analyzing the huge listings of detected and undetected errors. Also, deterministic test generation requires knowledge about which errors have been detected and which have not. The Post-Processing Unit (PPU) eliminates the complexity of data analysis. The primary responsibility of the PPU is to translate the lists of detected and undetected errors into a more easily accessible and usable graphical format. The main consideration in the design and implementation of the PPU was interactivity and easy data accessibility. The window representing each module contains the module name, module number, percent coverage, number of detected errors, and number of simulated errors. The PPU requires three input files: the SIF file (containing the hierarchical module names), the detected error file, and the undetected error file. Currently, graphical representation of PPU is not implemented JSAS. Figure 3 shows the simulation output panel for JSAS. It consists of simulation output messages and all simulation output files. These files include output file of simulation result, lists of detected and undetected fault or error simulation. For a specified remote user, the server sends the simulation result files via e-mail. Those files can be used for further analysis.
Figure 3. Simulation Output Window The simulation result files listed in Simulation Output Window can be browsed individually as shown in Figure 4. This figure illustrates fault list of a decoder circuit.
Figure 4: Example of file browsing using Simulation Output Window JAVA IMPLEMENTATION The implementation of JSAS is based on Java 1.0 using standard Java libraries. Hence, JSAS can be run on any, Java-enabled browser. JSAS needs to transfer data files between client and server. These operations are not explicitly allowed by the Java security model. currently, JSAS provides a text based representation of the simulation results, however, the implementation of more complex representation method will be available soon. Java interface for the simulation system is based on the client-server paradigm. An user accesses remotely the simulation environment from applet running into a Java-enabled environment. The client-server interoperation is shown in Figure 5.
Figure 5. Configuration of Client-Server The server is a deamon process, that runs in the simulation environment, listening on a well-known-port for incoming inquiries. When the inquiry from an user comes, a server accepts it and performs requested simulation. The results of simulation are returned to the user. A very important aspect of this system is the simulation environment, and the tight integration of the server process with the execution environment. The JSAS project was developed in the NeaSEL (Dwight 1996) lab which provides a multisystem execution environment. Hence, the JSAS server process, not only handles incoming tasks, but also tries to distribute the simulation balance over the entire network of workstations. The server is implemented in Java in order to provide maximum portability, and executes simulation task in binaries suitable for an execution platform. A client Java applet provides a remote access interface to the server. It provides fields allowing specific batch files, and types of simulation and results that users expects to receive as a result of simulation. The results of simulation are viewable in text form, and in the case of successful simulation can be
distributed via email to specified receivers, what allows for the implementation of a workgroup environment. This option can be used in order to communicate with the members of the group. The results are presently represented in text form, but they can be implemented using a graphic representation of results. This is an advantage of Java computing, in that it allows one to have different representation of the same stream of data for different needs and users (Kacprzak 1996). In order to allow the exchange of batch and result files between client and server, we have to pass the obstacles introduced by the Java security model a communication between client’s Java applet and simulation server is done using TCP/IP based HTTP protocol. This allows client and server for accessing of their local resources. This solution imposes on the client to provide a directory available for everybody, both for writing and reading operations. All batch data and simulation results are stored in this directory. CONCLUSION The Java based Simulation Automation System (JSAS) is a comprehensive VLSI CAD tool for three different simulation models: functional, fault, and design error. Through Java implementation, JSAS supports a graphical user interface (GUI) with three phases: input design, simulation, and result analysis. Also, it provides the user with an easy-to-use interface to access various tools and utilities to make the process of simulating a large digital design faster and more efficient. This system translates input circuits described in various formats into SIF and supports AMG for generating a model library. Simulation results show that the system is efficient and that the automatic model generation system is far superior to the manually generated process. Concurrent, parallel, and distributed simulators are implemented for the simulation process with the addition of fault or error compression and statistical sampling techniques for high performance. Java and WWW made JSAS widely available, allowing remote access from any location to a powerful simulation engine such as NeaSEL. The Internet and Web allows sharing results of the simulation between users in different locations. Since Java provides efficient methods of client-server communication, giving old concepts of client-server based architecture a new flavor, JSAS became a robust, widely available, simulation and design verification tool. References Hur, Y. and S. A. Szygenda, 1996. "A Graphical Simulation and Automatic Model Generation System," In Proceedings of the European Simulation Multiconference , June, 278-282. Hur, Y. and S. A. Szygenda, 1996a. "Bit Representations of Signal Models in a Domain Specific Automatic Model Generation System for Digital Simulation," In Proceedings of the European Simulation Symposium , vol. II, October, 197-201. Hur, Y. S. Shaikh, S. Goldenberg, D. Kacprzak, and S. A. Szygenda, 1997. "Concurrent Fault and Design Error Simulation in Interactive Simulation Automation System," In Proceedings of the SCS 30th Simulation Symposium, April, 168-176.
Agrawal, V. 1981. "Sampling Techniques for Determining Fault Coverage in LSI Circuits," Journal of Digital Systems, 189-202. Agrawal, V. 1981a. "An Information Theoretic Approach to Digital Fault Testing," IEEE Trans. on Computers, Aug. 582-587. Bloom, M. 1987. "Behavioral Models take the pain out of System Simulation," Computer Design, 38-46. Szygenda, S. A. 1990. "The Simulation Automation System Using Automatic Programming Generation for Hierarchical Digital Simulation System," In Proceedings of the International Conference on Simulation and Modelling. Java, 1997. "http://www.javasoft.com" Dwight, D. 1996. "NeaSEL Manual," ECE Dept., University of Texas at Austin . Kacprzak, D. 1996. "Rozproszony System Kontrolno-Pomiarowy na Bazie Serwisu WWW," The Warsaw University of Technology, Master Thesis, May.
