Distributed VHDL Simulation within a Workstation Cluster

Transcription

1 Distributed VHDL Simulation within a Workstation Cluster Michael Koch, Djamshid Tavangarian FernUniversitiit Hagen, Technische Informatik II E?O.Box 940, D Hagen, Germany Phone: , Fax: mic hael.koch@ femuni-hagen.de Abstract Simulation and verification are very important steps within the development cycle of an integrated circuit. In particular, the simulation of complex architectures in a hardware description language like VHDL is a major time factor within the design process. To accelerate such a simulation, the distribution of the VHDL model data base and of the stimuli data base within a workstation cluster of general purpose machines has been developed. Compared with other acceleration methods, this distributed simulation method neea3 no expensive hardware extensions. It uses the temporary idle workstations within a cluster to speed up the simulation. In this contribution, the basics of VHDL and distributed discrete event simulation (DDES) will be discussed together with the developed distributed VHDL simulator. 1 Introduction The steadily increasing level of integration in modem data systems leads to more and more complex circuit designs. One of the tools for handling such designs is the hardware description language VHDL'. The description of a circuit, the VHDL model, can describe different aspects of a high integrated circuit concerning hierarchy, architecture, functionality, etc. To test the behavior of the modelled circuit, a VHDL simulator is used. The time necessary for such a simulation and for verification is a major factor within the design cycle. In spite of the increasing power of a single workstation, the response time for the simulation of complex architectures in VHDL is unsatisfactory. Thus, the aim is to carry out a faster simulation in order to shorten the design cycle. To accelerate the VHDL simulation, different software and hardware solutions are possible: 1. VHDL ((Very High Speed Integrated Circuits) Hardware Description Language) First, we can optimize the software algorithms. In most VHDL systems, the VHDL source code is translated into pseudocode (p-code). Then, this p-code is interpreted during simulation by a VHDL simulation program which is normally written in C. The conversion and the interpretation take time and slow down the simulation. To accelerate the simulation on a sequential machine, one solution is to use native compiler code, rather than a combination of pseudocode and interpreter 141. Cadence states that a native code simulator can run 10 times faster than a normal simulator (interpreter). The major drawback is the portability. A native code simulator needs to be specially adapted for each platform and operating system. Hardware accelerators like the IKOS Systems VHDL accelerator [121 are fast, but they are very expensive. In such systems, parts of the VHDL simulation run on the accelerator; the workstation is used for user interaction and file handling only. Depending on the workstation connectivity, the special hardware may be used by the related workstation only. Furthermore, special software is necessary to integrate the hardware into the workstations operating system (OS). Another way to accelerate simulation is to use parallel computer architectures. In this area, different approaches exist which use processor arrays (transputer) [2] or massive parallel systems like the connection machine CM-5 [23]. Vellandi distributes all VHDL processes to the processing elements of the CM-5. For large architectures, a very large number of processing elements are necessary to have a good balanced system. The simulation capacity of processor arrays is limited by the local memory of each processor. For example, normally each transputer has 8 to 16 Mbyte RAM for program and model data. If this limit is reached, additional RAM or processors are necessary to simulate the model. Like special hardware, processor arrays are specialized and expensive machines which need special software for the operating system and simulation. As an alternative method to a processor array, we propose a workstation cluster of general purpose machines for the acceleration of circuit simulation tasks. A /94 $ IEEE 313 Proceedings of the Twenty-Seventh Annual Hawaii International Conference on System Sciences, 1994

2 workstation cluster is a local group of workstations COMeCted by a local area network (LAN). The processing in the cluster itself is done using the client-server-model. The clients send requests to the servers, and the servers react. In this case, one workstation requests servers to run a simulation (Fig.1). In a workstation cluster usually not all machines are busy all the time, especially outside the business hours. If it is possible to collect this unused power for simulation, the simulation can be accelerated without expensive extensions. Each workstation in the cluster is used as a processing element. When simulating very large models, the workstation has the possibility to use its mass storage system for swapping. In this way, the model size is not limited by the RAM capacity. clien Figure 1: Q P r v e r Workstation cluster (client-server-model) The following sections of the paper are organized as follows: First, basic simulation methods for digital systems and distributed simulation concepts are described. Then, the necessary VHDL statements and the VHDL simulation cycle are introduced. Afterwards, the pre-simulation steps for a distributed circuit simulation using VHDL, in the following called distributed VHDL simulation, and the extensions of the simulators are explained. Finally, the acceleration achievable is discussed together with the software requirements. 2 Distributed simulation concepts To simulate digital systems (circuits) in a hardware description language, we need a representation of the system: the architecture. The architecture of the circuit (structure and/or behavior) is represented by the model of the circuit. The input signals for simulation are represented by the stimuli. Evaluating the model, using the stimuli as inputs, the behavior and the function of the architecture can be simulated. We differ between event driven simulation and time driven simulation. In event driven simulations, the model is evaluated when a change (an event) occurs on an input of the model. In time driven simulations, the evaluation takes place at fixed time steps regardless of external transitions. Because of the discrete increment of time within the simulation, the event driven simulation is called discrete event simulation (DES). In this paper, the event driven approach is used for the distribution of a circuit simulation using VHDL. Before we can distribute a simulation of a digital system, we have to look at the different simulation data types: program data and model data. - The program data are in this case the simulator itself, including the event list administration and other support functions (e.g., communication). - The model data represent all information about the architecture and the environment necessary for simulation. They consist of different parts (architecture, stimuli, fault models). Each part of the model data is stored in a single data base. The structure and behavior of the circuit architecture are represented by the model. Generally only this part of the model data is called the model. The model data base of a VHDL system is built by analyzing the VHDL source code (see VHDL basics). The input signals (pattem) of an architecture during simulation, the stimuli, are the second part of the model data. They are stored in the stimuli data base. A special case of model data are fault models which describe architectures with supposed errors to test the suitability of the stimuli for fault detection. Depending on these model data, we can distinguish between two general ways of distributed simulation: - the dynamic model data base distribution (stimuli) and - the architecture model data base distribution (VHDL models). Some distribution methods are explained in the following example. 2.1 Dynamic model data distribution The simplest way for a distributed simulation is to break down the stimuli data base into smaller parts (e.g., to test the same model under different circumstances). Thereby, the simulator is started with the same architecture model (static model data) and a part of the stimuli (dynamic model data) on different machines. Using this way of distribution, no manipulation of the application program is necessary (Fig. 2). 314

3 The initialization of the simulator on the workstations and the collection of the results is done by remote procedure calls (RPC), remote shells (RSH) or an operating system extension like parallel virtual machine (PVM). PVM provides an interface to start programs within a network, to exchange different data types between the programs and to synchronize actions [201. Figure 2: Distributed simulation with different stimuli A special case are fault models. Using fault simulation, a fault-free architecture is compared with the same architecture containing faults. The result is the information whether the input pattern data base (stimuli data base) is suitable for fault detection or not. For any fault, a simulation of the whole architecture with the same input pattern is necessary. As the simulation of any fault can be done independently, the distribution of the simulation is simple. 2.2 Static model data distribution Another way is to subdivide both the model and the stimuli data base of the architecture. Each part of the model is executed with the corresponding stimuli on an instance of the simulator on a different machine. Figure 3: Distributed model data The results are collected at the designers workplace. An operating system extension like PVM is necessary too. Unlike the distribution of the stimuli, communication between the simulator instances is necessary in dependence of the architecture, just as algorithms for the partitioning of the model and for synchronization (Fig. 3). 2.3 Integrated model data distribution In dependence of the architecture, the overhead using external communication (the communication is not embedded in the simulator) to exchange information during the simulation can be in the area of a simulation on a single workstation. So, the next step is not only to distribute the model data, but also to include special functions for communication and synchronization in the simulator. In this way, the data exchange between the simulators is done directly without additional external subprograms. The disadvantage is the necessity to carry out a source code manipulation or to develop a special simulator. The model data are distributed similar to 2.2. Thereby, both the architecture and the stimuli data base are subdivided for simulation. In this work, we especially consider the last case of distributed simulation, because the simulation of different architectures with different abstraction levels in a complex hardware description language like VHDL can require a lot of communication between the machines. Such a communication can only be handled effectively by using embedded communication algorithms. Before we explain the necessary steps for a distributed VHDL simulation, we will introduce some of the basic concept of VHDL. 3 VHDL basics A way to help the designer to develop a complex architecture is the use of a hardware description language (HDL) which allows the description of an architecture on different levels of abstraction in every phase of development. VHDL, the IEEE Standard VHSIC Hardware Description Language, is such an HDL [7][8][14][15][17]. It is derived from ADA and contains concurrent statements which are useful to describe concurrence within digital systems. A detailed description of VHDL is given in the language reference manual [15][16]. In order to help understand a circuit simulation using VHDL and the necessary transformations of the VHDL source code for a distributed simulation, we will explain the basic structure of a VHDL description. The textual description of an architecture in VHDL is called a VHDL program or a VHDL model. In the following, we use the term VHDL model for a description 315

4 of a circuit in VHDL. Before simulation, a VHDL model has to be analyzed by a VHDL analyzer. The analyzer checks the syntax and semantics of the VHDL model. The analyzed VHDL model is stored in a VHDL library, in this case, in a model data base. The analyzed parts within the library can be instantiated by other VHDL descriptions. A design specified in VHDL is separated in the interface specification and in the implementation itself. The design interface is declared within an entity, the implementation of the entity is declared within an architectural body. For a given entity there can be several architectural bodies which contain different implementations of the same design. To describe the design hierarchy, other entities can be instantiated within an architectural body (component instantiation). Connections between the different components within a VHDL program are established using signals. This is the only way to exchange information between components. The signals are like wires within a netlist which connect the elements of an architecture. These elements can be descriptions on different abstraction levels, e.g. only simple gates on gate level (structural description) or black boxes on system level (behavioral description). So the signals can be the exact equivalent of a physical signal or the abstract representation of data flow. All the statements which describe an architecture within an architectural body are evaluated concurrently. These statements are: - Process statements - Block statements - Concurrent statements - Component instantiation statements - Generate statements A basic statement of VHDL is the process statement. A process statement is simulated concurrently, but the process body itself only contains sequential statements. The following source code shows a simple description of a D-flip-flop: entity d-ff is port(clk, clr, din: in bit; q: out bit); end d-ff; architecure test of d-ff is process (clr, ck) if (clr = 0 ) then q <= 0 after 10 ns; el se if (not clk STABLE and clk= l ) then q <= din after 10 ns; end if; end if end process; end test; Normally, the execution of a process is controlled by a list of signals called the sensitivity list. The process will not be evaluated unless at least one signal in the sensitivity list changes. In the example, the sensitive signals are clr and clk. The statements in the process body will not be executed unless clk or clr change their values. Instead of a sensitivity list, the sensitive signals may be placed within the process body using the wait statement: process if (clr = 0 ) then q <= 0 after 10 ns; else if (not clk STABLE and clk= l ) then q <= din after 10 ns; end if; end if wait on clr, clk; end process; In the initialization phase of simulation, the process is invoked executing the sequential statements until the wait statement is reached. Then the process is suspended until one of the signals clr or cl k changes its value. The body of a block statement is executed concurrently. The statements within the block body are also executed concurrently. To control the execution within the block, the block guard expression is used: block (CS = 0 ) douto <= guarded din0 after 5 ns; doutl <= guarded not din1 after 7 ns; end block; The statements within the block, in this case the signal assignments. will only be evaluated, if the guard expression is true. The statements within the block body are independent from each other and may be executed on different processors. Concurrent statements are special versions of some sequential statements. For example, the concurrent assignment statement replaces a whole process with a sequential signal assignment statement in it: q <= il nand i2 after 5 ns; (2) 3 16

5 The signal assignment is executed whenever il or i2 changes its value. Using the concurrent statements, the VHDL source code may be shortened, and thus, it is easier to read. The Component instantiation statements make the use of analyzed VHDL models within an architecture possible. The referenced entity and the bound architecture are executed as a concurrent statement. The actual parameters are handed over to the formal parameters in the entity declaration. The generate statements if-generate and for-generate are the concurrent counterparts of the if and for statements. Unlike the sequential statements, the generate statements can occur in every concurrent body of code. Similar to blocks, the bodies of generate statements contain only concurrent statements. Combining the generate and the component instantiation statements, regular structures may easily be modelled. Using if-generate, the first and the last element of such a structure can be slightly different from standard elements. G1: for I in 1 to 8 generate g2 if 1=1 generate... end generate 82; g3: if (b1 and 14) generate... end generate 83; g4: if I=8 generate... end generate 84; end generate G1; All the concurrent statements have to be extracted from the VHDL source code for a parallel simulation (see elaboration). In the following, the VHDL simulation cycle and its effect on the distribution of a VHDL model will be explained. 4 VHDL simulation The simulation flow of a VHDL simulation is defined in the VHDL Language Reference Manual [15][16]. To help understand the description of the simulation cycle, some terms will be explained: - driver - a driver of a signal is a container for a projected output waveform. The signal s value is a function of the current values of its drivers. - active signal - a signal will become active during the simulation cycle if the driver of a signal gets a new value, regardless of whether the value is the same or different from the old value. A VHDL simulation consists of an initialization phase followed by the repetitive execution of process statements of the model. Each such repetition is said to be a simulation cycle. During the initialization phase, the simulation time is assumed to be 0 ns, all signal values are set to a definite value and all processes in the model are executed until they suspend. To get the time of the next simulation cycle, the time is set to the first signal driver which becomes active or to the next process which resumes. The cycle itself consists of the following steps: - Each active, explicit and implicit signal in the model is updated. If the new value is different from the old value, an event has occurred. - For each process P, if P is currently sensitive to a signal S, and an event has occurred on S, then P resumes execution. - Each process that has resumed is executed until it suspends again. - The time of the next simulation cycle is set to the first signal driver which becomes active or to the next process which resumes. The simulation continues until no process resumes or a maximum simulation time is reached (Fig. 4). + Start simulation +- Initialization Update signals Figure 4: Execute processes u t End simulation The VHDL simulation cycle This simulation cycle must be guaranted, regardless of the simulation method (sequential or parallel). That means for a distributed simulation, all signal changes need to be exchanged between the workstations before the next cycle. 5 Distributed VHDL simulation For a distributed circuit simulation using VHDL, the model is divided into parts of nearly the same execution time and with little communication between these parts. The following steps are needed to distribute a VHDL model: - Syntactic and semantic analysis of the VHDL source code; - Extraction of processes and signals (elaboration) to get the necessary information for a partitioning; - Distribution of the processes and signals, depending on the execution time and the connections (and thereby communication) between the parts (partitioning); - Synchronizing the parts of the model during simulation. 317

6 The syntatic and semantic analysis of the VHDL source code can be done independent of the simulation (see VHDL basics). The analysed VHDL model parts are stored in a model data base. Each model part is analyzed once, regardless of the simulation method (sequential or parallel) and the number of simulations. We use different VHDL analysis tools to test our VHDL source files [31[61[111[181. For example the CLSI system provides a software interface which can be used to access the analyzed VHDL models in the model data base [CLSW]. So, a standard tool is used in this step of preparation. 5.1 Elaboration To estimate the execution time of a VHDL model and the structure of the interconnections within the model, an overview of all of the statements and signals of the model is necessary. To get this information, the general preprocessing (elaboration) of a VHDL model is not sufficient [ 151. Additional elaboration steps convert the different concurrently running VHDL statements into sequential statements, that means au statements are transformed into processes. After the transformation, all signals and the dependencies between the processes are known, so that the communication between the processes can be determined. Normally, the conversion results are stored in the format of the model data base. Here we use source code in the examples to show the transformations: Concurrent statements are replaced by processes with all inputs as parameters in a sensitivity list. As an example, we use a process converted from a concurrent assignment statement (see (2)): process q <= il nand i2 after 5 ns; wait on il, i2; end process; Converting a block statement, a process is necessary for the concurrent statements within the block and an ifstatement for the guarded option. Every concurrent statement may be represented by a separate process (1): process if (cs = '0') then douto <= din0 after 5 ns; end ;f; wait on cs, din0; end: To replace component instantiations, the real component is included from the library. Since the real component is also elaborated, only processes are included. The generate statement may be simply replaced including the necessary processes as much as they are needed. 5.2 Partitioning After elaboration of the VHDL source code there are processes with different lengths and thus with different execution times. For a partitioning into parts of nearly the same execution time, the processes need to be weighted depending on the functions they include. The problem using such an assessment is that only the execution time of the process is known, but not the number of cycles per simulation. Another way is to weight all processes equally and to count the cycles in an initial simulation. Depending on the results, a new partitioning can be calculated. Another important factor for partitioning a VHDL simulation in a workstation cluster is the communication time between the machines. This communication time depends on the granularity of the parallelism. For example, Vellandi chooses fine-grained parallelism for the distribution of a circuit simulation on a connection machine (CM) using VHDL. After elaboration, each process is assigned to one processing element (PE) of the CM [23]. As the number of signals per process is not taken into account there is a lot of local communication between the PES. To reduce the communication in a workstation cluster, we use coarse-grained parallelism. Thereby, the VHDL model is decomposed in relatively big parts with minimal connections between the parts. For a distribution using PVM, we consider the speed of the workstations in the cluster. For a homogeneous cluster, W parts will be created (W is the number of workstation), in a heterogenous cluster more than one part may be created depending on the speed factor of the machines, e.g.: SUN4 ELC/IPX SUN4 SI0 1 Pm 3 parts Furthermore, we need to consider another structure within a complex architecture, the loops. If a loop is distributed among the machines, it causes additional traffic on the communication lines, because an event generated by the last stage of a loop is used as an input of its first stage. The change at the first stage can generate a new transition at the last stage and so on. Besides the additional communication time, a synchronization between the involved machines is also necessary. So the aim of the partitioning must be to generate parts with the loops restricted to a single workstation. 318

7 There are different approaches to decompose a VHDL model. For a parallel simulation only fast algorithms with at most linear complexity are useful. We show two ways: - Partitioning using the hierarchy of the architecture: Thereby, the model is decomposed naturally in functional blocks. This is the easiest way of a model partitioning. The disadvantage is that the execution time of the parts and the connections between them are not incorporated as criteria for distribution. - Partitioning using signal flow graphs: In this case, the model is distributed by generating the signal flow graph (SFG) of the architecture from the VHDL source code. The partitioning of the graph is done using a min-cut algorithm [21]. Thereby, the connections of the processes are used as criteria for distribution. To optimize the partitioning for coarse-grained parallelism, we use the signal flow graph and a min-cut algorithm with static-weighted processes. The number of connections between the processes and thereby the communication between them is used as the major criterion. After partitioning the model, all pre-simulation steps are done. Now we will look at the special extensions of a distributed VHDL simulator. 5.3 Communication To exchange signal data between the model parts the operating system extension parallel virtual machine (PVM) is used. PVM is a software package that allows a network of computers to appear as a single concurrent computational resource [20]. PVM consists of two parts: a daemon process that any user can install on a machine and a user library that contains routines for initiating processes on other machines and for communicating between the processes. So it is not necessary to start processes on the server machines manually nor to use the rudimentary remote process calls (RF'C) for communication programming. To start and to kill the simulation processes on different machines, PVM needs a list of the workstations only. The library provides functions for sending and receiving different data types. The most important data to transmit are signals. A signal is a pair of time and value: signal clk(100 ns, '1') info = pvm-pklong (cktime, 1, 1); info = pvmskbyte (clk.value, 1, 1); info = pvm-send (destination-process-id, msgtag); After the collection of the data using pvm-pk*, the whole data packet is sent to the destination machine (destination process) using pvm-send. A detailed description of PVM is given in [20]. 5.4 Synchronization The synchronization of processes is the major problem of distributed simulation. Using coarse-grained parallelism, most of the data exchange takes place locally on one of the simulators, but some events (signals) need to be transmitted to other machines. To carry out an event driven simulation in parallel, each event list must have all necessary information for the next simulation step (next simulation cycle). That means in VHDL, all signal drivers have to collect the events for the next cycle. To guarantee this, two major approaches are possible: Conservative method - using this method, proposed by Chandy and Misra, each simulation process waits for extemal entries in the signal driver until it is guaranteed that no other extemal entry with a lower time stamp appears [51[191 (Fig. 5). 1 runningupto f (loons, '1') loo ns simulation time 75 ns I Figure 5: Synchronization (Conservative method) The disadvantage using this approach is the possibility of deadlocks, if the sending process suspends for the rest of simulation. Then the destination node is also waiting. It is possible to solve this problem by using null messages A null message tells a destination process that for x ns no value change will happen. So the destination process can simulate until simulation time + x ns. A drawback is the additional traffic in the network generated by null messages. To reduce this traffk, Bain and Scott propose a demanddriven approach [l]. Thereby, a process requests time information from its predecessors before advancing its time. Using this approach, the time consuming null messages are not necessary. Optimistic method (time warp) - using the time warp method, proposed by Jefferson, normally each simulation progresses independently from each other. There is no waiting for other processes. If a signal with a time stamp lower than the simulation time of the destination process 319

8 arrives at the destination process, the simulation will be rolled back until the time of the signal is reached. All calculations in the whole network based on the wrong values are discarded by antimessages and the simulation continues from the new time value [10][13]. Using additional messages, the simulation time in the whole network is updated to shorten the lists that are necessary to save the elder states. This is called global virtual time In our approach, we use the optimized conservative method proposed by Bain and Scott for synchronization to avoid the necessity to save all the elder states of simulation. A second implementation with the time warp method is under development, to compare the influence of synchronization for a distributed VHDL simulation within a workstation cluster. To summarize the explained steps, the flow of the distributed VHDL simulation is given in Figure 6. I I VHDL source code 1 + I partitioning distribution VHDL data base I Figure 7: i"l 25 VHDL data base VHDL compiler simulator library 5.5 Examples C source code The structure of the VHDL simulator To give an impression of the possible acceleration by using the distributed VHDL simulator, we show the results of some simulations using VHDL models of different sizes and complexities. First, we look at a simulation of a small architecture, approximately up to 500 gates (Fig. 8). 4 Time simulation cumulating the results e Normal simulation (1 WS) Figure 6: The flow of the distributed VHDL simulation The simulator itself is implemented using a compiled simulator. That means, the analyzed and elaborated VHDL code is translated into C-code. The C-code is compiled with additional libraries containing the simulation support functions and communication programs [22]. A compiler generates executable simulator parts which are distributed among the machines (Fig. 7). The user may use all workstations within the cluster or specify the needed workstations, so that PVM and the partitioning algorithm can recognize them. The simulation results are saved in an ASCII-file. Figure 8: Distributed VHDL simulation (500 gates) In this case, the sequential simulation on a single workstation is faster than the distributed simulation, because: a) the granularity of the model increases depending on the number of workstations, and b) the time needed to distribute and initialize the simulators on the machines is the major factor compared with the true simulation time. Simulating circuits with approximately 5,000 Gates, the time for the distributed simulation including the time for the additional tasks to distribute the simulation equals the time for the sequential simulation (Fig. 9). 320

9 ttme Figure 9: Normal simulation Distributed simulation ws Distributed VHDL simulation (5,000 gates) If the model is distributed among more than four or five processors, depending on the model structure, the communication slows down the simulation, because the simulated model parts are too small as compared to the necessary communication between them. A Time -\ - Normal e \ - simulation Distributed simulation - I I I I I I + '1 ' 2 5 ' 4 ' s ws Figure 10: Distributed VHDL simulation (more than 10,000 gates) An architecture with more than l0,ooo gates is simulated 2-3 times faster using 5 workstations (Fig. 10). Depending on the model, a distribution for more than 5-6 machines can require much additional communication, so that no further speed up is achievable. Thus, the structure of the model is an important factor for a distributed simulation. For very large models, a higher speed up can be achieved dependent upon the number of workstations. Signals with more than one source (resolved signals) generate a lot of traffic, because for every signal change the signal value must be calculated for all sources. So the calculation of a resolved signal should be done on the workstation with the most sources of the signal. 6 Conclusion and future work To meet the requirements for adequate and fast simulation and verification using a modem hardware description language like VHDL, we propose the acceleration of this design step by distributing the simulation within a cluster of general purpose workstations. In this case, no expensive hardware extensions like hardware accelerators are necessary. To adapt a VHDL simulation for the distribution within a workstation cluster, a coarse-grained partitioning of the elaborated VHDL model is used. The connections between the machines and the locality of loops are the main criteria for the partitioning. The aim is to minimize the communication between the machines involved in the simulation. The conservative method has been implemented to synchronize the processes and to avoid the problem of saving the elder states of simulation. The examples show that the results vary widely, depending on the structure and the size of the models. For large models with some independent parts and several parallel units, a good acceleration can be achieved. To optimize the distribution within a workstation cluster, additional studies are necessary to examine the influence of module grain and synchronization algorithms on such a simulation. Especially the use of resolution functions within a distributed discrete event simulation will be investigated. Just so, new algorithms for the distribution of support functions (e.g., event list administration) will be developed and analyzed. Further steps will be to consider the workstation load from other users or applications for partitioning the model data within a cluster in order to get a better load balancing between the machines in the network. 7 References [ 11 Bain, W. L.; Scott, D. S.: "An algorithm for time synchronization in distributed discrete event simulation," Distributed Simulation, Vo1.19, No.3, 1988, p (21 Baitinger, U. G.; Lanch&s. P.: "Hardwareunterstubte parallele Simulation von VHDL- Beschreibungen," Workshop S ynthese- und Verifiitionsverfahren auf der Basis von VHDL, Dortmund, March 1991 [3] Cadence: MIDLXL. 1.0 VHDL system Users Manual, 1991 [4] Cadence: Leapfrog simulator product information, 1993 [5] Chandy, K. M.; Misra, J.: "Asynchronous Distributed Simulation via a Sequence of Parallel Computations," Com. of the ACM, Vol.24, No.11, April 1981, p [6] CAD Language Systems Inc., VTW Users Manual,

10 (71 CAD Language Systems Inc., Software Procedural Interface Manual, 1990 [SI Coelho, D. R.: "The VHDL Handbook," Kluwer Academic Publishers, 1989 [9] Corbin, J. R.: "The Art of Distributed Applications," Springer 1991 [ 101 Fujimoto, R. M.: "Parallel Discrete Event Simulation," Communications of the ACM, k1.33, No.10, October 1990, p [ll] GenRad: System Hilo 4 Users Manual, 1992 (121 IKOS System: VHDL Accelaator product information, 1992 [ 131 Jefferson, D. R.: "Viual Time," ACM Transactions on Programming Languages and Systems, Vol. 7, No.3, July 1985, p [ 141 Lipsett, R.; Schaefer, C.; Ussay, C.: "VHDL: Hardware Description and Design," Kluwer Academic Publishers, 1991 [ 151 IEEE Std VHDL Language Reference Manual, New York, (161 IEEE P UA. IEEE Standards Draft VHDL Language Reference Manual, 1992 [ 171 Mazor, S.;Langstraat, P.: "A guide to VHDL," KIuwer Academic Publishers, 1993 [18] Mentor Graphics: Autologic VHDL Usels Manual, 1992 [19] Misra, J.: "Distributed Discrete-Event Simulation," Computing Surveys, vo1.18, No.1, March 1986, p [20] Geist, A.; Sunderam, V. et al.: "PVM 3.0 User's Guide and Reference Manual," Oak Ridge, 1993 [21] Tavangarian, D.: "Simulation gemischta analoger und digitaler Netzwerke d t mfe des Signalflubgraphen," Mangen 1982 [22] Tavangarian, D.; Koch, M.; Macke, H.: "VHDL-CAL -A VHDL-Simulator for Education," Proceedmgs of the 2.EUROCHIP Workshop on VLSI Design Training, Grenoble Vellandi, B. A.; Lightner, M.: "Parallelism extraction and program restructuring of VHDL for parallel simulation," European Conf. on Design Automation, Brussels, 1992, p