Apparatus and method for performing spike analysis in a logic simulator

Abstract: A logic circuit simulator for detecting a spike condition at the output of a simulated gate. A plurality of autonomous devices are arranged for parallel pipeline operation. Each device is designed to perform only a part of the overall simulation function. One of the devices is responsive to signals representing gate input stimuli and to gate propagation delay data primarily for performing the spike analysis function. Another device performs the function of gate output signal scheduling in response to gate input stimuli for transmitting messages containing said signals to the spike analyzing device and other devices of the simulator. When the spike analyzing device detects a spike condition, it transmits into the pipeline signals indicating the scheduling of an unknown output event on the gate in question.

Description: This invention relates to event-driven logic circuit simulators and to methods of simulating a logic circuit. In logic circuit design, it is known that under certain conditions the outputs of logic devices will assume unknown states for short periods of time. For example, if a logic gate has output different rise and fall delays, then it is possible for the output to contain undesirable spikes, or glitches. This occurs, for example, when a gate output pulse results due to input signal changes that occur faster than the inertial delay propagation through the device. This problem has been known for some time now in the logic circuit simulation art. It has been quite expensive in terms of run time overhead to provide spike analysis in logic simulators. In most cases, the problem is handled in one of two ways. One solution is to ignore the problem. In this case, the problem does not occur during simulation. This solution results in an overly optimistic simulation in which such spikes might occur in practice, but in which the designer has no indication during simulation and design of the potential problem. The other solution is to assume that fully developed output pulses develop at the output of a device in response to every impulse, irrespective of the duration of the input pulse. This solution is overly pessimistic. The two solutions are sometimes referred to as the pulse suppress and pulse pass modes of simulation, respectively. As mentioned, the need and methods for performing spike analysis have been known in the logic simulation art for some time. U.S. Patent 4,787,062 to Nei, et al discusses one solution in the context of a hardware simulator. In brief, the method used to perform spike analysis in the patent is as follows. If the spike analysis mode is in effect for a device when an input event is scheduled for the device, then an event queue is searched and if there are other events scheduled in an event queue for the device, an appropriate output register is forced to a state defined as UNKNOWN. However, as mentioned, the overhead in terms of simulation time to perform this analysis, can become quite large. A system that has been found useful for logic circuit simulation is described by P. Agrawal et al. in "Architecture and Design of the MARS Hardware Accelerator," 24th Design Automation Conference Proc., 1987, pages 101-107. The MARS Hardware Accelerator uses multiple processors connected in a series pipeline arrangement. The program and data for the simulation application are partitioned into modules and each module is assigned to a processor. Simulation is event driven by messages passed from processor to processor in the pipeline. Thus, the processors operate in parallel to speed up the simulation. For best performance, the partitioning should be arranged to minimize data movement between processors and balance the processing load among processors so that no one processor becomes a bottleneck. According to one aspect of this invention there is provided an event-driven logic circuit simulator as claimed in claim 1. According to another aspect of this invention there is provided a method as claimed in claim 6. A logic circuit simulator embodying the invention may be arranged for detecting a spike condition at the output of a simulated gate without substantial additional overhead in terms of speed of performance. A spike condition occurs when a gate output pulse results due to input changes that occur faster than the inertial delay propagation through the device. The simulator comprises a plurality of autonomous devices arranged for parallel operation, with each device being designed to perform only a part of the overall simulation function. One of the devices is responsive to signals representing gate input stimuli and to gate propagation delay data primarily for performing the spike analysis function. In a preferred embodiment, a first device performs the function of gate output signal scheduling in response to gate input stimuli for transmitting messages containing said signals to the spike analyzing device and both the signal scheduling and spike analyzing devices are programmable processors programmed to perform their specified function of the overall simulation. When the spike analyzing device detects a spike condition, it transmits into the plural devices arranged in a series connected pipeline signals indicating the scheduling of an unknown output event on the gate in question. To accomplish the above, both of the signal scheduling and the spike analyzing devices maintain separate time wheels. Each time wheel contains a plurality of time slots for storing scheduled times of occurrences of gate output events. In particular, the spike analyzing device stores in its time wheel scheduled unknown state output events that represent its detection of a spike condition at a gate output. Spike conditions are determined by calculating the time between successive gate input signal transitions and comparing these results to stored data representing gate propagation delays. Data for both rise times and fall times are stored. The scheduled times of event occurrences are determined and spike analysis is performed by referring to the appropriate rise or fall delay depending on the gate output events in question. The level of sensitivity of spike analysis is controllable by a user. This is accomplished by allowing a user to specify a spike factor which is used to multiply nominal gate rise and fall delays to establish weighted rise and fall delays. The factor can vary between 0 and 1. This corresponds to a continuum of delay values representing user optimism or pessimism between the so-called pulse suppress and pulse pass mode of prior art systems that also perform spike analysis. Brief Description of the Drawing Fig. 1 shows an illustrative block diagram of the simulator, including a plurality of processors, one of which performs general signal scheduling and another performs spike analysis, connected in a pipeline and each being programmed to perform a specified part of the overall simulation function; Fig. 2 shows a gate input pulse pattern that leads to event cancellation in the signal scheduling processor of Fig. 1; Fig. 3 shows a gate input pulse pattern that leads to detection of and scheduling of a spike condition by the spike analyzing processor of Fig. 1; Fig. 4 shows an illustrative data structure of the signal scheduling processor, including a time wheel comprising a plurality of scheduling time slots; Fig. 5 shows more details of the data structure of Fig. 4; and Fig. 6 shows an illustrative data structure of the spike analyzing processor of Fig. 1, including its time wheel for scheduling spike output events. Detailed Description Fig. 1 shows the architecture of a hardware multiple delay logic simulator. Timing analysis algorithms for event scheduling, cancellation, spike and other modes of analysis are implemented on a set of reconfigurable processing elements, arranged in a pipeline configuration. This hardware consists of a cluster of processing elements (PEs) connected by a crossbar switch that can be reconfigured each clock cycle. The crossbar switch and other details of the configuration are described in a co-pending U.S. patent application serial number 066,921, entitled MICROPROGRAMMABLE HARDWARE ACCELERATOR. Each PE is a 16-bit microprogrammed processor with special features for message passing, list and table manipulation, and bit field operations. Each PE has its own local memory. Communication between PEs is performed entirely by message passing. Logic simulation is performed by partitioning the simulation algorithm over the PEs within the cluster. The partitioning is done to balance evenly the load among the PEs and to achieve performance characteristics and simulation accuracy heretofore not available. The local memories of the PEs contain the connectivity and other pertinent information of a circuit under simulation. The illustrative simulator has a circuit processing capacity of 65,536 4-input gates. It generates one of four values 0, 1, X and U for the output states of each device being simulated. X represents an unknown output state value, which includes the state for a spike condition. U represents the state of an unused pin on a simulated gate. U is also interpreted as high impedance states of devices, such as transmission gates and buses. In Fig. 1, the housekeeper 102 interacts with the individual pipeline PEs to manage the simulation process. Housekeeper 102 may be implemented by any number of general purpose computers, microprocessors or workstations. In the specific embodiment, it is a SUN 3 Model 160 or 260 workstation. At the start of a simulation, housekeeper 102 loads the memories of each PE with circuit data and an appropriate microprogram for the particular function performed by the PE. The microcode describes the simulation algorithm, while the data represent the partitioned data structure of the circuit under simulation. The data structure consists of fanout pointers, fanout list, gate type, delay table, truth tables corresponding to the various logic primitives and an input table which describes the input states for each gate of the simulated circuit. In addition, housekeeper 102 specifies the total number of simulation time steps to be carried out to the signal scheduler PE (SS) 102 and the vector period to the output log (OL) stages of the pipeline. The vector period is a constant interval that reflects how often in a simulation a set of new external test inputs are applied to primary gate inputs of the simulated circuit. During simulation, the housekeeper 102 responds to interrupts from the PEs that indicate a full output buffer, an oscillating signal, or the end of simulation (an empty input buffer). The SS PE 104 is a multiple delay scheduler incorporating a 4096-slot time-wheel. The SS 104 performs scheduling and cancellations of gate events it receives from other PEs as a result of evaluating the states and times of the states of gate output transitions according to stored gate rise and fall times and gate input stimuli. It enters this information in linked lists of a gate record and points to the information by entering a pointer into the appropriate time slot of the time wheel. Event cancellations occur, as will be described below, when more than one future output event is scheduled to occur on a gate. Spike analysis is accomplished in SA 106 by dynamically calculating the time between input signals and comparing the results with appropriate gate delay information. The oscillation detector (OD) PE 108 detects zero-delay oscillations by counting the number of times each signal has changed state during a present time slot and interrupts the housekeeper 102 when the count exceeds a preset value. An output log (OL) PE 110 records transitions at user specified output points of the simulated circuit. These transitions are recorded in a buffer as they are received. When this buffer is full, OL 110 interrupts the housekeeper to empty the buffer. Two buffer areas in its local memory are used to log signal transitions. These buffers are emptied by the housekeeper when so requested by the OL. The fanout list (FL) PE 114 contains a list of fanouts of each gate in the simulated circuit. The pointer list (PL) PE 112 contains pointers to each gate's fanout list in FL 114. The behaviour of each gate is represented by data structures in the gate type (IT-GT) PE 118, truth table (TT) PE 122, and the delay table (DT) PE 130. The input vector (IV) PE 134 inserts test vectors, representing primary input signal changes, to the pipeline beginning at SS 104. Input vectors are stored in the IV 134 and are scheduled at the appropriate time slot in the time-wheel of SS 104. In addition, changes in outputs of gates due to gate fanout must also be scheduled in SS 104. For this purpose, event detector (ED) PE 132 detects changes in the output states of fanout gates and passes only those events that change the value of an output state to SS 104 via IV 134. ED 132 also forwards the appropriate rise or fall gate delays obtained from the DT 130 for these events. IV 134 adds these delays to the present time (obtained from SS 104) and forwards it to again to SS 104 for further processing. In conventional event driven logic simulators, fanout update and evaluation phases are performed in two phases. In the present simulator, these phases are combined into a single phase. Gates are evaluated by ED 132 immediately after an input signal changes and a message representing the evaluation is put immediately into the pipeline. Thus, a gate may be evaluated several times in one time step if multiple inputs change at the same time. However, because the evaluation is done by a separate stage in the pipeline, evaluating a gate will not increase the time it takes for an event to be processed by the pipeline. Spurious events generated from multiple gate evaluations are canceled using the event cancellation algorithm described below. Having briefly discussed the architecture of the simulator, we now proceed to a more detailed discussion of the related problems of event cancellation and spike analysis. In a multiple-delay simulator in which the simulated devices have separate rise and fall delays, it is possible for a new event to be scheduled at the output of a gate before a pending event is scheduled to occur. In such a case, the pending event must be canceled. Consider the example shown in Figure 2. The AND gate 20 is assumed to have rise and fall delays of 10 and 4, respectively. At time 5 a rising input event is detected and a rising output event is therefore scheduled for time 15. Before this event can occur, a falling input event arrives at time 8 and a falling output event is therefore scheduled at time 12. The event scheduled for time 15 must be canceled or it will leave the circuit in an incorrect steady state with B low and C high. For proper circuit simulation, all but the most recently scheduled pending events must be canceled. Now consider, for example, the circuit in Figure 3. At time 5, a pulse of width 6 is applied to gate 40 on input B. Conventional event cancellation cancels the first output event scheduled to occur at 15 and filters the second scheduled for time 19, producing no output pulse. In reality, due to the interdependence of the inertial delay of gate 40 and the times at which the gate output transitions take place, the value of the gate output from time 15 to time 19 (the spike interval) cannot be determined and should be set to an unknown state (X). To determine whether to schedule an X or not in the simulator, a spike factor, S, that ranges between 0 and 1, is introduced. A weighted delay, T d , of a gate for rising or falling pulse edges is T d =T r ×S or T d =T f ×S, respectively, where T r and T f is the rise and fall time, respectively, of the gate. An unknown state X is scheduled during the spike interval whenever an input signal separation interval is greater than T d . Separation intervals narrower than T d are ignored. This spike factor allows the user to control the degree of optimism in the simulation. When S=1, the weighted delay equals the rise/fall delay and spikes are always ignored (as with event cancellation). This is similar to the pulse suppression simulation mode known in the prior art. When S=0, the weighted delay is zero and events are always scheduled. This is similar to the pulse pass simulation mode of known prior art. The details of the operation of SS 104 and SA 106 are now discussed. The data structure of SS 104 is shown in Fig. 4 A time-wheel 400 contains 4,096 time slot entries. Each time slot entry of the time-wheel contains a pointer to the beginning of a linked list in the event list 402. This event list 402 is a linked list of gate numbers on which an event is scheduled for each time slot, as shown in Fig. 5. The cycle count 404 is loaded with a number from the housekeeper which specifies how many time steps for which the circuit is to be simulated. The gate record 406 is indexed by a gate number obtained from the event list 402 or from an incoming event message from IV 134. Each entry in the gate record specifies additional information about an event that is scheduled in the event list 402. For example, a time entry 408 stores the time of the last determined output event of a gate in question. The value field 412 contains the resulting output state of a pending state transition. A flag 410 is described below. SA 106 has a data structure, shown in Fig. 6, which is similar to the data structure of SS 104. For example, it has a time-wheel 600 and event list 602 identical to that of SS 104. In addition, the data structure of SA 106 includes a weighted delay table 610 which includes the rise and fall times in respective fields 622 and 624 for the gates of the simulated circuit multiplied by the S factor discussed above. Each gate record contains a field PREV_CUR-TIME 620 that contains the time slot at which the last input change took place at the gate, a PREV_SCH_TIME field 612 that contains the time slot at which the last output change took place at the gate, a value field 614 and two flags PE_FLAG (616) and X_FLAG (618). The meanings of the fields CUR-TIME and PREV_SCH_TIME are shown in Figs. 2 and 3. These fields, together with the PREV_CURR_TIME and SCH_TIME as shown in Figs. 2 and 3 are used for measuring the width of an input signal interval. The pending event flag PE_FLAG, indicates whether there is any pending event that has been scheduled on this gate. The X_FLAG indicates that a spike condition is scheduled for a gate. The time wheel 600 is the keeper of events that make a transition from 0 or 1 to the unknown value X whenever a spike condition has to be scheduled. Basically, SS 104 and SA 106 operate as follows. First, while in a receive mode, SS 104 receives from IV 134 messages containing gate number, time at which a gate output event is to be scheduled, output state value for each event detected by ED 132 or input test vector events inserted into the pipeline by IV 134. SS 104 updates its event list 402 and gate record 406 and schedules an event in its time-wheel for every event that is received from IV 134 since the execution of its last receive mode. It also sends a message to SA 106, which is also in a receive mode, for every such new event so that SA 106 can update its data structure accordingly. While it is updating this information, SA 106 also performs a spike analysis if there is already a pending event on the gate. The spike analysis is performed separately and concurrently by SA 106 with the receive mode processing of SS 104. Next, SS 104 enters a transmit mode in which it processes entries scheduled to occur in the present time slot. Before beginning this processing, it sends a message to SA 106 causing it also to enter a transmit mode. For presently scheduled entries, SS 104 either cancels spurious gate events in its gate record 402 or, if a presently scheduled event is a valid event, it transmits a corresponding routine event message to SA 106. When it enters the transmit mode, SA 106 first transmits messages forward to OD 108 specifying known spike conditions (X_state) for every event on its event list that is scheduled for the present time slot. It then merely forwards the routine messages received from SS 104 while SS 104 is processing its transmit mode to OD 108. A more detailed description of the above operations of SS 104 and SA 106 is now made with reference to Appendices A and B. These Appendices contain pseudo code of the operations of SS 104 and SA 106. This pseudo code is written using syntax similar to that of the well known C programming language. In this language, the operator! means "not", !=means "not equal," the operator && means logical AND, and the operator II stands for the logical OR operation. Appendix A is a listing of the pseudo code that controls the above summarized operations of SS 104. Appendix B shows the pseudo code for SA 106. In Appendix A, RECEIVE_event is executed by SS 104 when it is in its receive mode. In this mode, all new gate output events are processed. For each new event, the gate record is updated by setting flag 410 to "1", time 408 to the future scheduled time of the event and value 412 to the scheduled output state of the gate. Next, the event list 402 is updated. The scheduled time is used to select the correct time slot in time-wheel 400 and the link list associated with this time slot is updated with the gate number. Finally, a message including the gate number, current time, the future scheduled time in 408 and value 412 is sent to SA 106 for each new event. RECEIVE_MODE in Appendix B is the portion of the SA 106 algorithm that processes messages received from SS 104 in receive mode. For each such message received from SS 104, SA 106 retrieves information from its gate record, including the previous current time PREV_CUR_TIME (see Fig. 2), the previous scheduled time PREV_SCH_TIME and the PE_FLAG. Next, the gate record is updated to store the present scheduled time and current time as the new entries PREV_SCH_TIME and PREV_CUR_TIME. The PE_FLAG associated with the gate in question is checked. If PE_FLAG is not set, meaning that there are no presently scheduled events for this gate, the PE_FLAG is set and the next message, if any is processed. If the PE_FLAG is set when the message is received and no spike condition has already been detected (!X_FLAG) and the contents SCH_TIME is greater than the contents of PREV_SCH_TIME, then spike analysis, is performed. First, the input signal interval is determined by subtracting from the present time (CUR_TIME) at which an input transition has occurred the previous time (PREV_CURR_TIME) at which an earlier transition occurred. If the input signal interval is less than the weighted delay from either 622 or 624, no spike condition is present and the vent is ignored. Otherwise, an unknown output state (X) is scheduled by entering and X_event in the time wheel 600 at the previous scheduled time obtained from the gate record. The weighted delay that is used depends upon the direction of transition of the output pulse. If the transition is from "0" to "1" or "0" to "X", the weighted rise delay in field 622 is used. Otherwise, the weighted fall delay in field 624 is used. The X_FLAG is used to handle multiple transitions at a gate. This flag indicates whether an X_event has already been scheduled. If so, nothing further is done by SA 106. The effect is merely to stretch the duration of the X state. When SS 104 completes its receive mode, it executes its transmit mode to cancel spurious events in the event_list 402 for the present time slot or to pass event information on to SA 106 for the present time slot. This is shown as TRANSMIT_event in Appendix A. For each entry in the gate record 406 scheduled for the present time slot either an event message is transmitted to SA 106 or the event is cancelled if the present time is not equal to the scheduled time stored in 408. This occurs if an event previously entered into the event list, has been overwritten by a subsequent event. Thus, an event message is transmitted if and only if the present time is the same as the entered time in the field SCH_TIME of a gate record and the one-bit flag 410 is set. This flag means that there is a valid pending event which has yet to be transmitted forward. The flag 410 is reset upon transmitting a valid event. Its use prevents the transmission of multiple redundant messages which can occur due to simultaneous input changes at the gate. TRANSMIT_to_OD is the portion of the SA 106 algorithm that transmits messages to OD 108 after completion of its receive mode. In this transmitting mode, initially SA 106 receives the present time from the SS 104. All pending X events resulting from spike analysis in the SA time wheel 600 are first transmitted to the OD 108. Next, SA 106 transmits all routine event messages received from the SS 104 while SS 104 is in its transmit mode to the OD 108. Notice that a routine event message which represents a transition from X to 0 or 1 need not be handled by the SA 106. This is because SS 104 continuously updates the value of the gate whenever there is an input change. The last event on a gate output is always transmitted down the pipeline due to the LIFO ordering of the SS event list 402. Thus all these routine events received from the SS are legitimate (uncanceled) events. Finally, the PE_FLAG and X_FLAGS are reset in preparation for receiving new events. For the example of Fig. 3, the SA 106 generates and sends the event transition from 0 to X on gate 40 at time 15, whereas at time 19 it merely forwards the event corresponding to the transition from X to 0 from the SS 104 directly to the OD 108. It is to be understood that the above described arrangements are merely illustrative of the invention and that other arrangements may be devised by workers skilled in the art.

Claims: An event-driven logic circuit simulator (100) comprising a plurality of autonomous devices (104-134) arranged in a series-connected pipeline configuration and comprising means for storing interconnection information for simulated gates in said logic circuit (112,114), means for determining known output states for said simulated gates (118,122), means for determining times of transitions in said known output states (130,132), a first scheduling and storage means (400,402,406 in 104) responsive to said time determining means for scheduling said transitions, and means (in 104) for substituting a newly-determined transition for a particular gate for a pending transition in the gate record (406) for said particular gate, CHARACTERIZED IN THAT said simulator has a spike analyzer comprising: for each simulated gate, storage means for input transition times (620 in 106) and output transition times (612 in 106) containing the time slots at which the last input and output changes took place, and storage means for propagation delay times (622, 624 in 106); spike analyzing means (in 106) for accessing said storage means and, if the scheduled time of a newly-determined transition for a particular gate is later than a pending transition for said particulate gate, for detecting when a spike condition occurs at the output of said particular gate, a spike condition being defined as an output state resulting when input signals for a gate change faster than the propagation delay of said gate; and second scheduling means (600,602 in 106) responsive to said spike analyzing means for scheduling transitions to output states representing said spike conditions. A simulator as claimed in claim 1 wherein said autonomous devices are programmable processors. A simulator as claimed in claim 1 wherein said first scheduling means and said second scheduling means each comprise a time wheel (400,600) having a plurality of time slots (501) for storing scheduled times of occurrences of gate output transitions. A simulator as claimed in claim 1 wherein said storage means for propagation delay times comprises storage means for gate rise times (622) and gate fall times (624), and said spike analyzing means comprises means responsive to the direction of a scheduled gate output transition for accessing the appropriate one of the gate rise time or gate fall time for said gate. A simulator as claimed in claim 1 wherein said storage means for propagation delay times serves to store said propagation delay times weighted by a variable. A method of simulating a logic circuit in which the simulator comprises an event-driven logic circuit simulator (100) having a plurality of autonomous devices (104-134) arranged in a series-connected pipeline configuration with each device being designed to perform part of the overall simulation function, said method comprising the steps of storing interconnection information for simulated gates in said logic circuit, determining known output states for said simulated gates, determining times of transitions in said known output states, scheduling said transitions and, with respect to a particular gate, substituting a newly-determined transition for said particular gate for a pending transition for said particular gate, CHARACTERIZED IN THAT said method comprises the spike analysis steps of: storing input transition times, output transition times and propagation delay times for said simulated gates, wherein said input and output transition times contain time slots at which the last input and output changes took place; accessing said stored times and, if the scheduled time of a newly-determined transition for a particular gate is later than a pending transition for said particular gate, detecting when a spike condition occurs at the output of said particular gate, a spike condition being defined as a condition resulting when input signals for a gate change faster than the propagation delay of said gate; and responsive to said detecting step, scheduling transitions to output states representing said spike conditions. A method as claimed in claim 6 wherein said step of storing propagation delay times comprises storing gate rise times and gate fall times, and said spike detecting step comprises responding to the direction of a scheduled gate output transition and accessing the appropriate one of the gate rise time or gate fall time for said gate. A method as claimed in claim 6 wherein said step of storing propagation delay times comprises the step of weighting the stored propagation delay times by a variable.

Inventors: AGRAWAL PRATHIMA, AGRAWAL, PRATHIMA
Applicants: AT & T CORP, AT&T CORP.
Application year: 1990
Main classification: G06F17
IPC codes: G06F11, G01R31, G06F17