System for Combining Independently Clocked Simulators

1. Field of the Invention

The present invention is directed generally to the problem of interconnecting independently clocked simulators and more particularly to the interconnection of event driven simulators.

2. Description of the Relevant Art

Simulators enable engineers to model and test designs (i.e. electronic circuit schematics) before such designs are implemented in tangible (i.e., hardware) form. Various levels of definitional detail may be utilized to model the designed structure. By way of example, models of digital processing units may be defined at one or more of a behavioral level, a logic gate level and a transistor level. Each level of definitional detail has its unique idiosyncrasies with respect to the actual speed at which simulation of the model will run, the size of memory needed for creating the model on a specific data processing machine, the accuracy of the model in simulating the end product, and so forth.

It is generally found that if a simulator is optimized to operate at maximum speed and/or maximum efficiency in one definitional level (i.e., gate level), it will not operate as efficiently in simulating designs at other modeling levels (i.e., behavioral level). Accordingly, it is desirable from the price versus performance viewpoint to build a level-specific simulator which is optimized for modeling at one specific level (i.e., the gate level) rather than to attempt the building of a generic simulator that will on average become optimized for all levels of modeling (i.e., both gate and behavioral levels) but will fail to provide peak performance for the computationally most demanding of the definitional levels.

By way of a first example of this phenomenon, there is an event-driven simulator, commercially available from Ikos Systems Inc. of Sunnyvale, Calif., which is optimized for modeling structures at the gate level, and no other level. Similarly, as a second example, there is a gate level optimized simulation engine known as AcceLSI.TM. which is available from LSI Logic Inc. of Milpitas, Calif. The structure of the IKOS engine is disclosed in U.S. Pat. No. 4,787,061, "Duel Delay Mode Pipelined Logic Simulator" issued Nov. 22, 1988 to Nei et al., the disclosure of said patent being incorporated here by reference.

While the Ikos engine is efficient in preforming gate level simulation, it does not include means for simulation at the behavioral level. To overcome this drawback, designers use a so-called "B-sim" mixed level simulator available from LSI Logic of Milpitas, Calif. under the trade name MBSIM.TM., for performing mixed level simulation. The B-sim engine is optimized primarily for behavioral level simulation but it can perform simulation at other levels although not with the same speed or efficiency as that of a simulator which is level specific, i.e., an Ikos engine which provides only gate level simulation. Thus, when a design is to be modeled entirely at the gate level, it is preferable to use the Ikos engine rather than the B-sim engine; and when a design is to be modeled entirely at the behavioral level, it is preferable to use the B-sim engine. When a design includes both behavioral and gate level parts, the mixed level simulator mode of the B-sim engine is used but simulation speed and efficient utilization of resources is lost as more and more of the model is converted from behavioral level to gate level. Heretofore, a simple method for maximizing simulation speed and extracting peak efficiency from available resources has not been available for mixed level simulation. The invention disclosed herein seeks to overcome this problem.

Aside from the problem posed by mixed level simulation, there is also present in the industry the problem of compatibility between the software libraries of different simulators. It should be understood that in addition to the above-mentioned Ikos and LSI Logic B-sim simulators, there are other simulators available from different vendors and that these other machines can be structured differently both hardware-wise and software-wise. By way of further examples, Zycad Corporation of St. Paul, Minn. provides an event driven simulator such as disclosed in U.S. Pat. No. 4,769,817 issued Sept. 6, 1989 to Krohn et al., the disclosure of said patent being incorporated herein by reference. Another simulator is disclosed in U.S. Pat. No. 4,527,249, "Simulator System For Logic Design Validation" issued July 2, 1985 to Van Brunt, the disclosure of said patent being also incorporated herein by reference.

The different simulators of different vendors generally require incompatible software input files for modeling a particular piece of hardware. If an exchange of model parts between the libraries of different simulators is contemplated, such an exchange typically calls for substantial modification to the model defining software contained in the source library before it can be ported to a new simulator. Accordingly, when a first library of software descriptions has already been developed on a first type of simulator for a first set of model parts and a designer wishes to perform a simulation including the first set of model parts on a second type of simulator whose library contains a second, different set of model parts, such a switch over to a new simulator (porting) requires substantial work to convert the input files of the first simulator to match the compatibility requirements of the second simulator. As the number and/or complexity of the model parts grows, an ever increasing danger is created that bugs (flaws) will be introduced into the model definitions when they are ported from one simulator to the next.

Because of this danger, there is a long-felt but unfulfilled desire in the industry to be able to share model parts developed on a first simulator with a simulation being run on a second simulator without having to port the model definitions of the first simulator over to the second simulator. Especially during the initial development of a new design, it is often desirable to construct the overall design definition from model parts whose individual definitions have already been developed on different simulators. It would be highly advantageous to be able to interconnect the pre-defined model parts of such different simulators so that the software definition of each model part can continue to reside during simulation in the simulator of its origin. This would avoid the time, cost and bug-introducing dangers associated with converting the definitions of the different model parts into a common form and/or porting them all into a universally compatible simulator. The invention disclosed herein seeks to overcome these problems.

Besides the problem of porting designs from one simulator to another, it is at times advantageous to model one part of an overall design at a first level of definitional detail, i.e., the gate level, and another part at a second level of detail, i.e., the behavioral level, and to study interactions between the first and second level parts.

Under all of the above mentioned situations (porting designs and simulating with mixed levels) it would be desirable, from the price/performance standpoint, to be able to devise a cross-coupled combination of simulators wherein each simulator is specifically optimized for a different level of modeling (i.e., transistor, gate or behavioral) and/or a different model-part providing library, and wherein the level-specific or library-specific simulators are operatively interconnected to one another such that each harmoniously simulates its corresponding part of the overall design at its own peak speed and/or maximum resource-utilization efficiency and such that error-free modelling of the overall design takes place.

Unfortunately, because each individual simulator is independently clocked in such a combination, a synchronization problem arises. When different level-specific or library-specific simulators are operating concurrently (by multitasking in one computer or by parallel processing in multiple CPU's), the simulated time clock of one simulator may become unsynchronized with the simulated time clock of another simulator. One simulator (i.e., a gate level specific simulator) might be running its part of the design across simulated time at a relatively high speed while another simulator (i.e., a behavioral level specific simulator) might be running its part of the design across simulated time at relatively slow speed, the difference in speed arising from limitations inherent to the operations of the differently optimized simulators. As such, when the model part of the faster simulator needs to send a signal to the model part of the slower simulator or needs to receive a signal from the slower simulator part, some means should be provided for synchronizing the model part of the faster simulator with the model part of the slower simulator so that they are at a common point on the simulated time line when signal exchanges are to take place.

Lock-stepping the clock of a faster simulator with the clock of a slower simulator tends to destroy the price/performance advantage of the faster simulator since the faster machine is forced to always operate at the speed of the slower simulator. Thus, lock-stepping is not a commercially viable solution. It is preferable to be able to somehow maintain the peak performance/price ratio of the high speed simulators, even if only over short bursts of time, rather than forcing the high speed simulators to continuously operate at slow speed. If the latter is done, the resources of the high speed simulators can be used to support in a time-shared manner other simulations having additional model parts that are supported on other slow speed simulators when the resources of the high speed simulators are not needed by a first simulation. The invention disclosed here makes possible such resource distribution.

From the perspective of minimizing actual time spent performing a simulation, it is further desirable to enable the interconnection of model parts which are supported on two or more so-called "event-driven" simulators. Preferably, the individual event-driven simulators are each optimized for operation at a different level of modeling or for operation with a different software library.

Heretofore, there was no clear way of maintaining the peak performance/price ratio of independently clocked simulators. There was no suitable method for making sure that an event list (event-queue) in a first event-driven simulator will be synchronized in the simulated time domain with the event list of a second, independently-clocked event-driven simulator. The invention disclosed here provides a method and system architecture for realizing these goals.

It is an object of the present invention to provide a method and apparatus by which independently clocked simulators may be synchronized without substantially interfering with the maximum running speed of each simulator.

In accordance with the invention, a network of interconnected simulators is provided wherein each simulator transmits to other simulators of the network, information indicating the next known point in simulated time at which the transmitting simulator can generate in its local model part a state change which could affect the model parts of the receiving simulators. Blocking means are provided in each receiving simulator for blocking the receiving simulator from advancing its simulated time clock beyond the next time point of the transmitting simulator. Each receiving simulator is free, however, to advance its respective clock at peak speed over time spans in the simulated time domain which are located before the next time point of the transmitting simulator. Thus, synchronization is maintained without limiting the simulation speed of the interconnected simulators.

FIG. 1A is a block diagram for explaining the operation of an event driven simulator.

FIG. 1B is a plot of a simulated time line having events distributed among various ones of its time points for explaining the operation of the simulator shown in FIG. 1A.

FIG. 2A is a block diagram (extending left to right respectively across sheets 2.1 and 2.2) for explaining a synchronization problem which arises when an attempt is made to interconnect independently clocked simulators.

FIG. 2B is a plot of simulated time (extending left to right respectively across sheets 2.1 and 2.2) for explaining the synchronization problem of FIG. 2A.

FIG. 3A is a block diagram (extending left to right respectively across sheets 3a.1 and 3a.2) for explaining a synchronization scheme in accordance with the invention.

FIG. 3B is a plot of simulated time (extending left to right, respectively, across sheets 3b.1 and 3b.2) for explaining the synchronization scheme shown in FIG. 3A.

FIG. 4 shows a synchronization scheme for a simulation using more than two simulators.

FIGS. 5A and 5B illustrate a flow chart for explaining an algorithm by which synchronization may be achieved without substantially interfering with the speed of each simulator.

FIG. 6 is a block diagram explaining a UNIX.TM. style embodiment of the present invention.

The following is a detailed description of the best modes presently contemplated by the inventor for carrying out the invention. It is to be understood that this description is merely exemplary of the invention and is not to be taken in a limiting sense.

Event driven logic simulators, whether implemented in software or hardware, are a type of simulator in which dynamic state changes occurring within a model are defined as a series of discrete "events" each attributed to a point on a simulated time line and to an identifiable part of the model being simulated. Segments of simulated time that are occupied by static modes of operation in the model are skipped over in order to minimize actual computer time spent for simulation. The only information that is generally processed by the simulation-supporting computer is that indicating the occurrence of a change in state within the model at a definable point along the simulated time line and that identifying the location (i.e., node) in the model where the change occurs.

During event-driven simulation, the events within a model are each temporarily posted onto an event queue (or event list), each event being represented by a corresponding piece of event data. The event data usually defines a net point (node location), a time parameter (event time), and a new state for the net point. The event queue contents are dynamically updated when the simulator determines that the consequences of a first event are to result in the production of a second event not previously posted on the event queue. Events which have already been processed (evaluated) are dynamically removed from the event queue (also sometimes referred to as a "timing wheel").

To better understand the above discussion with respect to how dynamic addition and removal of event data from a queue takes place, let it be assumed that there is a model having a first net point (node) which serves as the input terminal of a first driven device, that an output terminal of the first driven device is coupled to a second net point and the second net point serves in turn as the input terminal of a second driven device whose output terminal is coupled to a third net point, and so on. If a step pulse is applied to the first net point at time zero (input event), there will be a response at the second net point, then at the third net point and the effects of the input pulse will thus ripple through the model. Since each driven device generally has a cause and effect type of time delay (signal propagation delay) attributed to its operation, the output state of each device changes at a simulated point in time spaced apart from that of the input event. There is no need to spend actual time for processing simulated time between the input event and the output event because nothing of interest happens between events. This is the paradigm by which event driven simulators minimize their actual time for modeling. The response of each driven device to an input event is not posted until the actual time when its specific input event is evaluated. Thus, responses at the front of a signal propagation chain are first to be posted on the queue and responses at the end of a chain are last to be posted on the queue. Once an event is processed, it is cleared from the queue and the time gap to the next listed event is in essence, automatically skipped. This helps minimize the size of the queue and the time of simulation. The event-driven simulator keeps track only of the current state of the model being simulated and has no knowledge of previous or future states.

Referring to the block diagram of FIG. 1A, there is shown an event driven simulator 10 for modeling a digital circuit A. The circuit A, which is merely exemplary, comprises an OR gate 12 having a first signal propagation delay, T1, and a logical function block 14 having a second signal propagation delay, T2. Nodes N.sub.1 and N.sub.2 define input terminals of the OR gate 12 while node N.sub.3 is common to the output terminal of the OR gate 12 and an input terminal of the function block 14. Node N.sub.4 defines the output terminal of the function block 14 which is coupled by way of a feedback line 15 to input node N.sub.2 of the OR gate 12.

Referring further to the plot of simulated time, t.sub.sim, shown in FIG. 1B, let it be assumed that the circuit A is initialized prior to a start time t.sub.0 to have all of its nodes, N.sub.1 through N.sub.4 set to a logic low (L). Further, assume that an event queue 11 of the simulator 10 is primed to contain a first entry, E.sub.1, indicating that at simulated time t.sub.3 (i.e., three simulated clock ticks after start time t.sub.0) a logic high (H) is to be applied to input node N.sub.1 and a second entry, E.sub.2, indicating that a logic low (L) is to be applied to input node N.sub.1 at time t.sub.4. No other events are posted on the event list 11 at this time.

When the simulation is started, the simulator 10 automatically searches its event list (queue) 11 for the earliest event and thereby automatically sweeps the (hypothetical) hand 17 of its time simulating clock, SC.sub.10, past all previous time points, i.e., t.sub.0, t.sub.1 and t.sub.2, not listed on the event queue 11.

Input node N.sub.1 is set to a logic H state when the first entry E.sub.1 is processed. The simulator 10 then looks at each device in the circuit A having a terminal that is operatively driven by the changed first node N.sub.1 (i.e., the OR gate 12). Next, the simulator 10 determines whether and when the state of any node coupled to the driven device (OR gate 12) will change as a next immediate result of the first event E.sub.1. In this case, because the OR gate 12 now has a logic high (H) applied to its input node N.sub.1 and because the OR gate 12 has a signal propagation delay T1, which for the sake of example here will be assumed to be seven time units wide, a new third entry E.sub.3 (which was not listed in the queue beforehand) is dynamically posted onto the event queue 11 indicating that at time t.sub.10 (seven simulated clocks ticks after t.sub.3), node N.sub.3 (the output terminal of OR gate 12) will be set to a logic high (H). The first entry E.sub. 1, having been processed, is then cleared off the event queue 11 and only the second and third events E2 and E3 are now posted.

The system event clock SC.sub.10 is next skipped forward in a single step from simulated time point t.sub.3 to time point t.sub.4, this being the next simulated time point listed on the event queue 11. The cycle then repeats with the simulator 10 looking at all devices coupled to the changed node (i.e. N.sub.1) of the new event E.sub.2.

Referring to FIG. 1B, it can be seen that the above described first and second events, E.sub.1 and E.sub.2, in essence define an input pulse at node N.sub.1 ; the dynamically posted third and fourth events E.sub.3 and E.sub.4 define the T.sub.1 delayed output pulse signal of OR gate 12; and later posted events E.sub.5 and E.sub.6 define a T.sub.2 delayed output pulse of function block 12. The example given in FIG. 1B establishes an oscillation in circuit A since the output pulse (E.sub.5 and E.sub.6) of block 14 becomes a new input pulse at input node N.sub.2 of the OR gate 12 and new events, i.e., E7, E8, . . . (not shown), will continue to be dynamically posted on the event queue 11 as the simulation runs.

Referring back to FIG. 1A, it will be noted that the internal structure of function block 14 has been left undefined. This was done intentionally so that FIG. 1A can represent either of a gate level or behavioral level model. It should be apparent that in a case where the internal structure of function block 14 is defined entirely at a gate level that the simulator 10 will be preferably chosen as one optimized for operation at the gate level (i.e., an Ikos engine) in order to minimize the amount of actual time needed to simulate circuit A. On the other hand, if the internal structure of function block 14 is defined mostly at a behavioral level, the simulator 10 should be one optimized for behavioral level operation (i.e., a B-sim engine). The actual rate of simulation, as performed by the simulator 10 is defined in terms of events per second (EPS), and this rate can vary drastically depending on the model type (gate level or behavioral level) and the efficiency of the chosen simulator 10. By way of example, the LSI MBSIM.TM. engine performs gate level simulation at a rate of approximately 8,000 EPS while an Ikos or Zycad engine performs gate level simulation at a rate of 300,000 EPS or better.

Referring to FIG. 2A, which is a schematic drawing extending left to right across respective sheets 2.1 and 2.2, let it be assumed that there are two circuit parts, A' and B', each similar in topology to the circuit A of FIG. 1A. Like references denote like parts. Let it be assumed further with respect to FIG. 2A that circuit parts A' and B' are to be operatively coupled to one another such that they share at least one common component (in this case, node N.sub.4 is to be directly tied to node N.sub.11) Moreover, let it be assumed that one circuit part, i.e., A', is defined entirely at the gate level and that the other circuit part, i.e., B', is defined primarily at the behavioral level. It should be apparent from the above discussion that two different simulators, 100 and 200, will be needed to optimize the price/performance ratio of the overall simulation environment (first simulator 100, second simulator 200 and an inter-simulator communication link 300).

However, it will be quickly seen that when two or more event-driven simulators are used, the dynamic updating of their individual event queues becomes a problem. In FIG. 2A, circuit part B' is shown to contain nodes N.sub.11 through N.sub.14, a three-input OR gate 112 having a third signal propagation delay, T3, and a function block 114 having a fourth signal propagation delay, T4. Delay times T3 and T4 can, of course, be different from T1 and T2.

Since we assume that circuit parts A' and B' are being simulated on different and independently clocked simulators 100 and 200, the simulators 100 and 200 will need to include respective transmission and receiving means 104 and 201 (also labeled as "T" and "R") for allowing each simulator to send and receive messages along an inter-simulator communications link 300 so that an event (i.e., E.sub.5 at node N.sub.4) which is posted on the event list, (111 or 211), of one simulator (100 or 200) can be transferred to the event list (211 or 111) of the other simulator (200 or 100) and nodes can be tied together. Here we are assuming that node N.sub.4 of circuit part A' is to be treated as if it were directly coupled to node N.sub.11 of circuit part B'. Thus, when an event E5=(t.sub.20, N.sub.4, L.fwdarw.H) occurs at node N.sub.4, a twin event E5'=(t.sub.20, N.sub.11, L.fwdarw.H) should occur at node N.sub.11.

If the simulators 100 and 200 ran at identical simulation speeds (events per second rates, EPS-1 and EPS-2, respectively) and both advanced their respective simulated clocks SC.sub.100 and SC.sub.200 simultaneously to identical points along the simulated time line, t.sub.sim, there would be no synchronization problem. However, when one of respective event queues, 111 and 211, in the individual simulators 100 and 200 is made to contain a different entry, the automatic time skipping feature of the event driven simulators 100 and 200 can produce a loss of synchronization after just a few events have been processed.

By way of example, let it be assumed that at initial time t.sub.0 there are only two events, El=(t.sub.3, N.sub.1, L.fwdarw.H) and E2=(t.sub.4, N.sub.1, H.fwdarw.L) posted on the first event list 111 and only two events E21=(t.sub.203, N.sub.15, L.fwdarw.H) and E22=(t.sub.204, N.sub.15, H>L) posted on the second event list 211. (The events are defined here by listing their event time, location and state change in the recited order.)

When simulation begins, each simulator (100 and 200) begins to automatically process the information on its respective event list (111 and 211). Since the second event list 211 includes as its first event, an event E21 occurring at a time point t.sub.203 which time point is positioned much later in simulated time then the time points of the events initially posted in the event queue 111 of the first simulator 100, the simulation of model part B' is immediately made to skip forward in simulated time to the later time point t.sub.203 without waiting for receipt of the event E5 pulse that should appear on its input node N.sub.11 representing the earlier timed changes at the output node N.sub.4 of the first circuit part A'.

As shown in FIG. 2B, events E21 and E22 can establish an oscillatory behavior in the second circuit part B' composed of subsequently posted events E23, E24, E25, E26, . . . . But such responsive behavior assumes there has been no a prior input signal (H) applied to input node N.sub.11 of circuit part B'.

It is only after event E.sub.3 (FIG. 2B) is dynamically posted onto the event list 111 of the first simulator 100 and subsequently, a consequential event E5 is dynamically posted on the first event list 111, that a change of state is seen to occur at the corresponding output node N.sub.4. Ideally, this consequential event E5=(t.sub.20, N.sub.4, l.fwdarw.H) at output node N.sub.4 should have been posted onto the second event list 211 as a twin event E5'=(t.sub.20, N.sub.11, L.fwdarw.H) well before the initially posted event of the second simulator, E21=(t.sub.203, N15, L.fwdarw.H), is processed. However, the second simulator 200 has no way of knowing ahead of time that event E5 will indeed be posted on the first event list 111. So when the event update message E5'=(t.sub.20, N.sub.4, L.fwdarw.H) is finally available for transmission from the first simulator 100 to the second, the second simulator 200 has already swept its simulated clock hand 217 too far forward in simulated time. Moreover, the second simulator 200 has already removed the initially posted event E21 from its queue, and as a consequence, the overall simulation will be erroneous if allowed to proceed in a blindly automatic manner because the simulated clocks SC.sub.100 and SC.sub.200 will not be synchronized (t.sub.sim-1 .noteq. t.sub.sim-2) at the moment of intersimulator signal exchange.

A method is needed for making sure that the clock hand 217 of the second simulation clock SC.sub.200 does not skip prematurely past those simulated time points (i.e., t.sub.20 and t.sub.21) at which there may be events dynamically posted on its event list 211 from an external independently-clocked source (simulator 100).

FIGS. 3A and 3B are respectively a schematic diagram and time plot for explaining how synchronization may be achieved in accordance with the invention. Like references denote components corresponding to those shown in FIGS. 2A and 2B. The respective simulation clocks, SC.sub.100* and SC.sub.200*, of simulators 100.sup.* and 200.sup.* are each equipped with at least one hand sweep limiting block, 118 and 218, for limiting the forward sweeping movement of its respective clock hand, 117 and 217 beyond the next-event time (t.sub.next) of the other (external) simulator. The respective hand sweep limiting block, 118 or 218, of each simulator, 100 or 200, is advanced in simulated time under the control of one or more external simulators, i.e., under control of a t.sub.next signal output from the corresponding external simulator, 200 or 100, as will become understood by the example provided in FIGS. 3A and 3B. It should be understood from the graphic representation of the sweep limiters (118 and 218) that they do not block the advancement of their respective clocks (SC.sub.100* and SC.sub.200*) through time spans located prior in simulated time (t.sub.sim) to the position of the sweep limiters but rather that they only block further advancement of the clock hands (117 and 217). Thus, the clock hands 117 and 217 are free to sweep at their respective maximum speeds before they encounter the blocks 118 and 218.

Referring first to FIG. 3B, upon initialization, both of the simulators, 100.sup.* and 200.sup.*, respectively, have nonevents (NULL events) E0 and E20 posted on their individual event queues together with the initialization pulse information E1, E2, E21 and E22 previously described. No other information is posted at this time. The hand sweep limiters, 118 and 218, are each initially positioned between simulated time points t.sub.0 and t.sub.1 of their respective simulation clocks, SC.sub.100* and SC.sub.200*. This positioning of the hand sweep limiters, 118 and 218, allows each simulator, 100.sup.* and 200.sup.*, to process an event (or nonevent) which is listed on its event queue if the event has a time parameter less than t.sub.1 but blocks the hand (117 or 118) from sweeping further to process later timed events. At the end of processing an event internally, each simulator sends to one or more simulators, external to itself, a signal t.sub.next indicating the next posted time parameter of its individual (internal) event queue.

In the illustrated example of FIGS. 3A and 3B, the first simulator 100.sup.* initially processes the nonevent E0 of its list 111.sup.*, finds that there is no event at any location, but nonetheless sends the time parameter, t.sub.next =t.sub.3, indicating the time of the next listed event on its event queue 111.sup.* to all external simulators; in this case to external simulator 200.sup.*. This message sending step may be done by transmitting an initial information packet P.sub.100-0 =(t.sub.0, .times., .times., t.sub.3) out along the inter-simulator communication link 300. (Here, the "x"'s denote a nonevent at a don't-care location.) Simultaneously (either by parallel-processing or during a time slot assigned to it by a multitasking operating system), the second simulator 200.sup.* searches its queue 211.sup.*, finds the NULL event E20 as the first posted event and transmits its respective t.sub.next =t.sub.203 parameter in an information packet P.sub.200-0 =(t.sub.o,.times.,.times.,t.sub.203) to the first simulator 100.sup.* along inter-simulator communication link 400.

Each external simulator (100.sup.* and 200.sup.*) reads this last transmitted piece of information, t.sub.next, as permission to advance a corresponding at least one hand sweep limiter (118 or 218) provided therein as part of its respective simulation clock (SC.sub.100* or SC.sub.200*) to a point in time just before the indicated next event (i.e., t.sub.3 and t.sub.203). In this example, the last item, t.sub.3, in the initial transmission packet P.sub.100-0 from the first simulator 100.sup.* tells the second simulator 200.sup.* that as far as simulator 100.sup.* is concerned, simulator 200.sup.* is free to move its respective clock hand 217 at whatever speed desired to a point in time just prior to simulated time t.sub.3. The last item, t.sub.next =t.sub.203, in the corresponding initial transmission packet P.sub.200-0 from the second simulator 200.sup.* to the first simulator 100.sup.*, tells the first simulator 100.sup.* that the first simulator is correspondingly free to move its respective clock hand 117 at whatever speed desired to a point in simulated time just prior to simulated time t.sub.203 in so far as the second simulator 200.sup.* is concerned.

Thus, as indicated in FIG. 3B, the first sweep limiting block 118 is moved in one step from an initial position 118-0 just before simulated time t.sub.1 to a new position 118-1 just before simulated time point t.sub.203. The other hand sweep limiting block 218 is concurrently moved in one step from its initial position 218-0 just before time point t.sub.1 to a new position 218-1 just before simulated time point t.sub.3. This movement of the sweep limiters, 118 and 218, blocks the second simulator 200.sup.* from processing the later timed events E21 and E22, even though they might be posted before externally-generated events E5', E6', etc., are posted, but frees the first simulator 100.sup.* to process as quickly as it can those events E1 through E4, etc., on its individual event list which occur in simulated time prior to time point t.sub.203. Simulation in the second simulator 200.sup.* is forced to idle until the first simulator 100.sup.* advances the second sweep limiter 218 to a simulated time point ahead of an event listed on the event list 211.sup.* of the second simulator 200.sup.*.

After processing event E.sub.1, the first simulator 100.sup.* sends a second transmission packet P.sub.100-1 =(t.sub.3, N.sub.1, L.fwdarw.H, t.sub.4) to the second simulator 200.sup.* to thereby advance the sweep limiter 218 of the second simulator to a point in simulated time just before time t.sub.4. When the packet P.sub.100-5 =(t.sub.20, N.sub.4, H.fwdarw.L, t.sub.21) of event E5 is finally transmitted to the second simulator 200.sup.*, the second simulator 200.sup.* is freed to process the corresponding externally-generated event E5' at its node N.sub.11 but is still prevented from processing the next listed event E21=(t.sub.203, N.sub.15, L.fwdarw.H) which continues to be a next posted event on its queue 211.sup.*. (E21 is posted before an earlier timed and next-to-be externally generated event, E6' at node N.sub.11, is posted).

The advantage of the above process becomes obvious if one thinks of the first simulator 100.sup.* as being a high speed engine (i.e., an Ikos engine) and the second simulator 200.sup.* as being a slower simulator (i.e., a BSIM engine). The faster simulator 100.sup.* can zip through all events posted on its queue 111.sup.* having parameters between time points t.sub.0 and t.sub.203 at peak speed without having to worry that the external simulator 200.sup.* might generate a shared event during that time span. The second simulator 200.sup.* cannot generate a shared event within the time span t.sub.0 through t.sub.202 because there is no event having such a time parameter within its event queue 211.sup.*.

In a situation where more than two simulators are involved, as shown in FIG. 4, multiple sweep limiters may be provided for the internal clock of each simulator; each of the multiple sweep limiters being advanced by a corresponding one of the external simulators. This arrangement prevents any one simulator from advancing its simulated clock hand (local current time) to a time point beyond the local next event time, t.next, of any of the other, external simulators. In the example shown in FIG. 4, first simulator S.sub.1 cannot sweep its current time beyond the local next time of simulator S.sub.2. Simulator S.sub.2 cannot sweep its local current time beyond the next event time of simulator S.sub.3. Simulator S.sub.3 cannot advance its local current time beyond the next event time of simulator S.sub.2.

It should be noted that the local next event time (t.next) of each simulator is always greater than its current event time. The global next event time of the overall system (S.sub.1, S.sub.2 and S.sub.3 in combination) is the smallest of the local next event times in the simulators S.sub.1 -S.sub.3. With this arrangement, at least one of the simulators S.sub.1 -S.sub.3 should be able to advance its local current time to the global next event time, thereby preventing a lockup of simulation.

Those skilled in the art will appreciate that numerous steps may be taken to minimize simulation time including deletion of redundant information in transmitted information packets and nontransmission of information not needed by a receiving simulator. Accordingly, the exemplary embodiment shown in FIG. 3A may be improved by transmitting in each information packet, i.e., P.sub.100-1, only one copy of the current time (i.e., t.sub.3) only information representing the state changes of nodes that are shared between the transmitting and receiving simulator (i.e., node N.sub.4 and N.sub.11), and finally, the next event time on the timing wheel of the transmitting simulator.

The preferred operational algorithm (flowchart shown in FIGS. 5A and 5B) for a first simulator S.sub.i which is operatively coupled to a second simulator S.sub.j may be defined as follows:

The terms in the above algorithm are defined as follows:

The above described algorithm may be practiced either in a parallel processing environment or a single CPU environment provided with a multitasking operating system. Referring to FIG. 6, there is shown a structure for carrying out the present invention under the UNIX.TM. operating system. (UNIX.TM. is a trademark name of an operating system package available from American Telephone & Telegraph Corp.) Interconnection between independent simulators is provided by way of a so-called socket pair connection within the UNIX command layer. The illustrated embodiment comprises a Zycad gate level simulating engine and an LSI Logic BSIM behavioral level simulation module. The driving module for each of the independently clocked simulators includes means for comparing the local next event time against the external next event time. If the local next event time is greater than the external next event time, local simulation is halted and only a null message is transmitted to the external simulator. This allows the external simulator to catch up in simulated time with the local simulator. The time for generating a null message is relatively small, so the catch-up time of the external simulator is not substantially delayed by processing the null message. As seen in FIG. 6, each driving module includes means for converting back and forth from an inter-simulator message format to a local simulation-engine format.

In the UNIX implemented embodiment of FIG. 6, the preferred inter-simulator message syntax is a 4-tuple: (partition, pin-offset, state, schedule-time), where "partition" is a partition number determined from a sigma-file, "pin-offset" is the offset of a specified pin within a module-shell, and "scheduled-time" is the simulated time point at which the specified pin is to change its state to the newly specified "state".

Initial benchmark tests with the above strategy indicate that there is a 15%-20% simulation time penalty for the inter-simulator communication overhead. However, with such a structure it is now possible to interconnect model parts developed on different simulators without having to port a model part definition from one type of simulator to another. The ability to interconnect model parts without having to convert their software definitions for compatibility with a target simulator more than makes up for the communications overhead. The burst speed of the faster simulator is not substantially reduced. An overall reduction in design and development time is expected from use of the above described invention.

Various modifications and additions to the above described invention will, of course, become apparent to those skilled in the art after reading this disclosure; some of the variations being immediately apparent and others becoming apparent after prolonged study of the present disclosure. It should be understood that the above disclosure is merely illustrative of the invention and that, as such, it should not be taken in a limiting sense. The scope of the claimed invention is best defined by reference to the following claims.