The present invention relates to the simulation of complex circuit designs and, in particular, discloses a system and method for the efficient simulation of clocked circuits.
The continued increase in the complexity of electronic circuitry has lead to continued demands for simulators that can simulate, to a high degree of accuracy and at great speeds, the complex interactions going on within a complex circuit. Further, the circuits are growing more and more complex with “System On Chip” (SOC) designs now being implemented containing hundreds of millions of logic circuits. Thus, the need for extensive simulation of circuitry is becoming increasingly important.
Various methods are used for the simulation of complex electronic circuits. The circuit to be simulated is normally described in a top down manner using a hardware description language (HDL) such as VHDL or Verilog. VHDL is described, for example, in IEEE Computer Society “IEEE Standard VHDL Language Reference Manual” New York, USA, June 1994, and Verilog is described, for example, in IEEE Computer Society, “IEEE Standard Hardware Description Language Based on the Verilog Hardware Description Language, New York, USA, 1996. These are commonly referred to as synthesis based approaches as the same circuit description may also be used in the generation of the physical circuit layout. As circuit complexity continues to increase, there is a trend to move away from these, synthesis based, approaches to ones using higher level hardware descriptions usually based on languages such as behavioral VHDL, Verilog with behavioral extensions, C and C++. An example of such a high-level simulation language is SystemC which uses C++ as a system description language. For more on SystemC, see, for example, www.systemc.org.
Once the circuit to be simulated is described in one of the above languages, simulators are available for extensively simulating the operation of the hardware device. For example, standard C++ compilers together with System C libraries can be used to simulate SystemC coded models. Complex circuits are often constructed using a high level languages such as Verilog, SystemC, VHDL or the like and extensively simulated using cycle accurate simulators to verify operation. Subsequently, after satisfactory verification, the model, if coded using a synthesizable HDL may be directly synthesized into lower level circuit designs. The model is extremely useful in allowing verification of the design and target software to proceed long before and even after the design has been implemented.
FIG. 1A shows an exemplary operating environment for operating a simulator. The simulator is run on a processing system, shown as host computer 101. The processing system 101 includes at least one processor 104, a memory subsystem 102, a display subsystem 105, a keyboard 107, a pointing and selecting device such as a mouse or another input device, all such input devices collectively shown as 110, local storage 106, and a network interface (NIC) 108 coupling the processor system to the network. The elements of the processing system are coupled via a bus subsystem 109 that is shown for the sake of simplicity as a single bus. The processing system (host computer 101) may include more or fewer components as is known. A simulator in the form of software 103 is used to simulate hardware and in one embodiment, also to simulate one or more processors running user software. The simulator is typically provided as a set of computer readable code segments to instruct the processor or processors of host 101 to implement a method of simulating. For the sake of simplicity, the simulator 103 is shown in the memory subsystem 102. Those skilled in the art will understand that at any time, most of the simulator is carried in the storage subsystem 106 or other carrier media, and not all of the simulator code will be present in the memory 102 at the same time.
While an arrangement such as shown in FIG. 1A is in general prior art, when one or more aspects of the invention are included in the simulator 103, FIG. 1A is not prior art.
FIG. 1B shows in functional form a simulation system that is of a structure known in the art. The simulation system includes a hardware simulator 111 that operates on a hardware model 112 of the circuit to be simulated, and that includes an event scheduler 113. In the shown implementation, the simulator operates in a co-simulation environment with other simulators 114, some of which, for example, simulate a processor running a user program. The event scheduler maintains a data structure 115 containing at least a main, time-ordered, time-scheduled event queue. The data structure 115 is shown in exemplary form as contained in the scheduler 113, but can be a separate structure. The scheduler places events that are in the future in the main time-ordered time-scheduled event queue in structure 115. For example, any change that is known to occur at a future simulation time is placed as an event for that future simulation time in the main event queue. The main queue is ordered in time. Other queues, e.g., for events that are to be processed at the present simulation time as a result of processing one or more events, also are included in the structure 115.
With a structure such as shown in FIG. 1B, each and every time event in the future is placed in the main queue in structure 115, and processed at the appropriate time. The inventors have found that this sometimes leads to a lot of processing, especially with repetitive signals such as clocks. There is a need in the art to speed up simulation so as to aid in the effective creation of more and more complex circuitry. For example, there recently have been developed “co-simulator” systems that abstract core components of a hardware design such as a microprocessor core device, while accurately simulating digital circuitry coupled to the code device. Examples of co-simulator systems are described in U.S. Pat. No. 6,263,302 to Hellestrand et al. Such co-simulator systems are able to achieve substantial speedups in the overall simulation time. There still however, is a need to further speed up the simulation of digital circuits.
Example simulation systems include those described in U.S. Pat. No. 6,751,583 to Clarke et al., U.S. Pat. No. 6,263,302 to Hellestrand et al., U.S. Patent Application Publication No. 2002/0083420 to Zammit et al., U.S. Patent Application Publication No. 2004/0088150 to Gay, and U.S. Patent Application Publication No. 2004/0111247 to Berevoescu et al.
A common feature of modern digital circuits is the presence of clocking circuits and clock signals (“Clocks). Some such clocking arrangements may be complex. The clock signals typically serve to synchronize activity within the various subsystems within a digital circuit design.
When simulating such a circuit, a model of the circuit is built, e.g., in a hardware description language. It is desired in such a model to provide for such clock signals to be stopped and re-started, and to otherwise be modified so as to change the frequency or phase or both frequency and phase of their repetitive behavior.
In order to accurately model such clock signals, existing hardware simulators model these clock signals as logic signals, e.g., as logic nets of type wire. A hardware simulator such as simulator 111 typically effect a change of state in a logic signal by scheduling an event in a time-scheduled event queue such as the main time-ordered event queue in data structure 115. Thus, in existing simulators, each significant transition of the clock signal is scheduled as an event in 115, regardless of whether or not events that affect the circuit, e.g., that cause significant changes in the circuit occur as a consequence of such a clock signal transition.
Scheduling events in a time-scheduled event queue and processing them is time consuming. Consider for example, the hardware simulator 111 of FIG. 1B. Suppose events are scheduled by the scheduler 113 by placing such events to be processed in the future into the time-ordered event queue. The hardware simulator 111 advance time to the next event time in the main queue, determined by the scheduler 113, and at a current event time, processes all the events in the time-scheduled event queue(s) 115 which have been scheduled to occur at the current event time. These events are processed in some arbitrary order. The events themselves may cause further events to be scheduled to occur at the current event time and/or at some future time. In a typical simulator 111, those events that are scheduled to occur at the current event time are typically put on to another queue in data structure 115, called a “delta” queue. Furthermore, the hardware model 112 being simulated may have a change of state at that simulation time. Each potential change of state is placed on an update queue in data structure 115, and the potential changes of state are propagated and resolved. Such changes of state to the model 112 being simulated are propagated prior to processing of the delta queue in 115. Some of the updates may lead to new events needing to be scheduled, including events that are scheduled to occur at the present time. Those new present time events also are placed in the delta queue in structure 115. Those events that are generated for processing at a future time are placed by the scheduler into the main event queue. Once all changes are propagated, events in the delta queue are processed. Such processing of the events on the delta queue may give rise to more events that are scheduled to occur at the current event time, and/or in the future. Events for the present time are placed on a second delta queue of events in structure 115, and so on. At the end of the processing of the first delta queue, changes of state to the model being simulated are propagated. Now events in the next delta queue are processed, and so forth. Changes of state are propagated only between the processing of these delta queues and after the final delta queue is processed until there are no more delta queues. Once all the delta queues have been processed for the current event time, the scheduler moves time to the next scheduled event in time according to the main time-scheduled event queue in structure 115.
Those in the art will recognize that such processing is time consuming.
Typical existing hardware simulators such as shown in FIG. 1B do not distinguished between clock signals that are predictable, and other logic signals. Furthermore, typical existing hardware simulators have not provided a mechanism to accurately model transitions of these clock signals other than as standard logic signals.
The need for dealing with clock signals other than as ordinary logic signals is best illustrated by example.
FIG. 3 shows an exemplary timer circuit that is used to explain the inconvenience of simulating clock signals as logic signals. The exemplary circuit including a four-tick timer circuit 333, a clock gate circuit 332 and a clock generator circuit 331. The clock generator produces a variable clock signal as an input to the clock gate circuit 332 that gates the input clock and provides an output clock to a clock input of the four-tick timer circuit 333. The four-tick timer circuit 333 counts significant clock edges (called ticks herein) at its clock input and, after a predetermined number of four clock edges, outputs a signal 334.
FIG. 4 illustrates a series of logic timing diagrams 441, 442, 443, and 444 describing the clock generator output, and operation of the clock gate circuit for the variable clock input signal denoted and connected to the clock generator output. For the purpose of illustration, assume logic ON (logical 1) is high and OFF (logical 0) is low. Timing diagram 441 shows the passage of hardware simulation time for a range of time in simulation time units. The clock generator 331 generates a clock signal denoted Clock of significant edges that start at periodicity of 10 time units. A significant edge of a repetitive clock signal is called a tick herein, and the time between repetitive periodic ticks is called the period herein. After time 70, the clock period of Clock changes to 30 time units, with the first tick (significant clock edge) at time 90 time units. Note that for illustrative purposes, the 0 to 1 edges are considered the significant edges—the ticks—of the clock signal Clock. In between the clock edges, the clock changes to 0 as indicated by dotted lines in timing diagram 442 that shows the clock generator output denoted Clock, equal to the input of circuit 332, denoted Clock in. Timing diagram 443 illustrates the clock enable input signal to the clock gate circuit 332, denoted Clock enable. Timing diagram, 444 illustrates the clock output signal from the clock gate 332, denoted Clock out. Note that transitions are clocked, such that the 1 to 0 transition of the Clock enable signal (diagram 443) occurs after the clock edge of Clock in at time 50, so that the Clock in signal at time 50 does appear at the Clock out output at this time 50, while the 0 to 1 transition of the clock enable signal (443) occurs after the clock edge at time 60, so that the Clock in signal at time 60 does not appear at the Clock out output at this time 60.
To simulate this behavior, a prior-art event-based simulator such as shown in FIG. 1B would schedule events in the main time-scheduled event queue in structure 115 at each of the clock edges at simulation times 230, 40, 50, 60, 70, 90 and 120. The Clock signal returning to 0 would also be scheduled in the time-scheduled event queue in 115. In this example, the return occurs two simulation units after the rising edge. The Clock enable signal would cause events to be scheduled at times 50 and 60 in the time-scheduled event queue in 115. Therefore, many events would be scheduled in the main queue even for this relatively simple circuit. It would be desirable to be able to define the clock signals Clock in in an alternate way to a logic signal so that events need not be scheduled in the time-scheduled event queue(s) 115 at all clock times. The inventors have noted that these clock signals Clock in and Clock out are predicable given the hardware model and the attributes of the clock, and in particular that each is “incrementally predictable” in that given the present state, and such attributes as the period and phase of the clock, and whether the clock is enabled or stopped, the next clock edge that can cause an effect is predictable.
FIG. 5 shows an exemplary set of timing diagrams 551, 552, 553, 554 and 555 that describe the operation of the four-tick timer circuit 333 for this example, with the input clock of circuit 333, denoted Timer clock and obtained directly from the output clock of the timer gate circuit 332 denoted Clock out. The timing scale 551 illustrates the passage of hardware simulation time. The timing diagram 552 illustrates the reset input signal to the four-tick timer circuit 333 denoted Timer reset, and this Timer reset signal is used to start the timer 333. The timing diagram 553 illustrates the output Clock out from the clock gate circuit 332, and is used as the input clock Timer clock to the four-tick timer circuit 333. Timing diagram 553 is identical to timing diagram 444 of FIG. 4. The number sequence 554 shows the count of the four-tick timer circuit and is only shown here to explain the internal operation of the timer 333. Timing diagram 555 illustrates the output signal—denoted Timer out—from the four-tick timer 333 for the described signals.
Notice that at time 40, the reset signal (diagram 552) is still asserted (=1) because a change, e.g., the change to 0 occurs as a result of a clock edge in Timer clock shown in timing diagram 553. Therefore, the internal count (554) is still 0 after time 40, and only increments to 1 after the significant edge of the clock signal Timer clock at time 50. The count becomes 4 after the clock edge of Timer clock at time 120, at which time the Timer out output jumps to 1.
The operation described in FIG. 5 is simulated in a prior art event-driven hardware simulator such as that shown in FIG. 1B by a set of logic signal events scheduled by scheduler 113 in the main time-scheduled queue in structure 115 evidencing the transitions from low to high (0 to 1) and high to low (1 to 0) of each of the above signals including the clock signals. However, the Clock in signal that has relatively many transitions, and therefore that results in relatively many scheduled events in queue that need to be processed in a prior art simulator, is a clock signal that is derived from another clock signal, that is input to the clock gate 332. The inventors have noted that the clock transitions are therefore predicable, in particular, incrementally predicable. It would be desirable to model such incrementally predicable clock signals in a manner other than logic events so that fewer events need to be scheduled.
Furthermore, the increase in the internal count shown in 554 is, in the case of a prior art event-driven hardware simulator such as that of FIG. 1B, the result of processing of scheduled events in structure 115, e.g., the Timer clock signal edges, which themselves are the result of events scheduled in simulating the Clock gate 332. The inventors have noticed that the count is of predictable clock signals. It is desirable to schedule events based on counts of clock edges without needing to process each clock edge if no significant events other than increase in count occur. Typical prior-art hardware simulators such as shown in FIG. 1B do not provide such events to be scheduled with respect to transition counts of accurately modeled transitions on such repetitive clock signals.
Thus there is a need in the art for a method and for a hardware simulator, and for a language that includes instructions for the simulator to enable clock signals to be modeled other than as logic signals, so as to reduce the amount of traditional event scheduling, so as to reduce the amount of processing needed to simulate circuits involving such clocks.