US 4,872,125 AGrant
Multiple Processor Accelerator for Logic Simulation
Issue Date:1989-10-03
•7 Claims
•5 Drawing Sheets
Abstract
Computer for implementing an event driven algorithm which utilizes a master processor and a plurality of processors arranged in modules, wherein the processors within the module are capable of operating independently of each other. The various modules are also capable of operating independently of each other and communicate with each other and the host unit by a unidirectional token ring bus. A specialized hardwired processor design is implemented to provide a pipelined flow of data to provide a more rapid simulation algorithm.
Metadata
Assignee
- Daisy Systems Corporation
Inventor
- Gary M. Catlin
Application Information
Application Number:US 1427210
Filing Date:1988-01-11
Priority Date:1987-06-26
Art Unit:234
Classifications
IPC:
G06F 1516
Field of Search:
364340578;132;131;200;900825.05
Patent Drawings (5 sheets)
Description
Background of the Invention
1. Field of the Invention
The present invention relates to the field of computer-aided design and more particularly to computer-aided design systems using event driven simulation algorithms.
2. Prior Art
Computer-aided design has become a commonly used tool in the design of complex electrical designs. Computer-aided design work stations are almost a necessity in designing high density electrical circuits and semiconductor device layouts. These computer-aided design work stations not only provide a design tool but are capable of providing diagnostics to detect design errors quickly.
Typically, the more advanced and large computer-aided design work stations for logic simulation are capable of simulating circuits having over a million components. Instead of evaluating every input and output, event driven algorithms evaluate only those inputs and outputs which change their states from one time period to the next. One such digital computer system which implements an event driven simulation algorithm is described in U.S. patent application Ser. No. 594,533; filed Mar. 28, 1984; entitled Digital Computer for Implementing Event Driven Simulation Algorithm; which issued as U.S. Pat. No. 4,751,637 on June 14, 1988, and is implemented in a work station commercially available and sold under the trademark "MEGALOGICIAN" by Daisy Systems Corporation of Mountain View, California. However, this prior art system utilizes a microcodable simulation processor which tends to limit the processing speed capability due to a single ALU used with each processor.
The present invention implements an event driven simulation algorithm by utilizing a more complex architecture which permits a large number of processors to operate simultaneously in parallel, as well as a new streamlined hardwired processor, for providing simulation capability at a much faster pace.
Prior art references known to the Applicant which disclose special purpose computers for implementing simulation algorithms are:
(i) "A Logic Simulation Machine" by Abramovici, M. et al; IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems Vol. CAD-2, No. 2; April 1983. The present invention implements an algorithm similar to that described in this article. However, the partitioning used in the present invention is substantially different than that discussed in the article.
(ii) "ZYCAD Logic Evaluator" as described in ZYCAD Corporation's manual dated November, 1982. This apparatus employs different partitioning than the present invention. Moreover, it does not offer the flexibility of the presently described invention where the computer is microcode programmable.
(iii) "Parallel Processing Interactively Simulates Complex VSLI Logic" by Howard, J. et al; Electronics Dec. 15, 1983; beginning at p. 147. This article describes the implementation of a different algorithm which is not event driven. Different architecture and partitioning are employed. (Applicant does not concede that this particular article is prior art, however, Applicant believes that there are prior art computers employing the teachings of this article.)
(iv) U.S. Pat. No. 4,527,249.
Summary of the Invention
A computer for implementing an event driven algorithm and used to simulate a digital system or a digital circuit is described. The computer system is comprised of a host unit and an accelerator. The host unit is comprised of a multiple user master processor, such as a 80386 microprocessor chip manufactured by Intel Corporation of Santa Clara, California; a memory; and an interface to the accelerator. The master processor is coupled to various remote users by a networking system, such as Ethernet. The host unit provides the main control of data distribution between the various users and the accelerator.
The accelerator is comprised of a number of modules and the communication between the various modules and the host unit is provided by a unidirectional token ring bus. Each module is comprised of a plurality of processors and each module is capable of providing independent processing of information it stores. Further processors arranged within each module are also capable of providing substantially independent processing.
In a typical situation, a given user will attempt to simulate a large number of circuit components. The master processor of the host unit will distribute the circuit elements to be simulated to various processors located in the modules. The allocation is accomplished to provide approximately equal computation time by each processor such that no one module is burdened with excessive processing requirements.
Prior to each processing cycle, information is passed along the unidirectional ring bus to the various module units in information packets. Each module includes an interface board coupled to the ring bus. The interface board will determine if the received information packet on the ring bus is destined for its module. If the information is not destined for its module then the information is bypassed and transmitted back on the token ring bus. If the information is destined for its module, the interface board, which is termed an event buffer, distributes the information to the appropriate processor. Similarly, if an information packet is to be sent from one of the processors within its given module, the event buffer also controls the acceptance of the information from the processor and distributes the information packet onto the ring bus according to the protocol of the token ring bus.
Once the input information for the various circuit elements are placed in to the various processors, computation of the various inputs associated with the circuit elements are computed for this given time cycle. The results of the computation determine the output from the various circuit elements and these are stored within the processors. The accelerator then is prepared to advance to the next time cycle to utilize the stored outputs as inputs to the next stage of the circuit.
In line with the novel architecture of the present invention, a special hardwired processor is utilized to provide a more rapid streamlined processing of more primitive circuits elements, such as logic gates. The hardwired processor is arranged to provide a pipelined computation of logic gates stored within itself. The hardwired processor accepts input state changes for circuit elements stored within itself and stores this information in a flat queue. The flat queue is then addressed and the input state changes associated with the appropriate circuit element is evaluated using a simulation algorithm for that circuit element. Next, the delay table is accessed to determine the delay of this given circuit element and the result is stored in an event queue. The event queue is later accessed to determine any output changes, which would be transmitted as input state changes to the next circuit stage, and is sent to a fanout pointer and a fanout list to determine the circuit elements which require updating during the next time phase. An output means determines if the next circuit element is on this same processor or if update data is to be transmitted to one of the other processors.
This pipelined architecture permits each pipeline stage to operate substantially independent of other stages such that each is capable of pipelining information as long as the subsequent stage is free to accept the information. The hardwired processor is not programmed by microcode and functions much faster than the microcode programmed simulation processors of the prior art.
Other advantages to the described computer system will be apparent from the following description.
Brief Description of the Drawings
FIG. 1 is an overall system block diagram showing the architecture of the present invention.
FIG. 2 is an expanded block diagram showing one example of a processor module of the present invention.
FIG. 3 shows data stored in an information packet used with the preferred embodiment.
FIG. 4 shows mapping of a memory associated with processors of the present invention.
FIG. 5 shows a time wheel which is part of the memory of FIG. 4.
FIG. 6 is a circuit block diagram showing the pipelining stages of a hardwired processor of the present invention.
FIG. 7 is a flow diagram of the hardwired processor of FIG. 6.
Detailed Description of the Invention
The present invention provides for a computer which implements a simulation algorithm. The computer is utilized in providing computer aided engineering design by simulating various circuit elements, such as logic gates, etc. In the following description, numerous specific details are set forth such as specific number of processors, memory size, word length, etc., in order to provide a thorough understanding of the present invention. It will be obvious, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known circuits, structures, and methods have not been described in detail in order not to unnecessarily obscure the present invention. Moreover, while the present invention is described in connection with a particular algorithm for circuit simulation, the apparatus of the present invention, namely the architecture, may be used with other algorithms, even though a particular algorithm is described with the preferred embodiment.
Architecture
Referring to FIG. 1, a computer system 18 of the present invention is shown comprised of two sections, main processor section 19 and an accelerator 20. Main processor section 19 is comprised of a host unit 21, a user bus 14 and a plurality of designated users numbered 1, 2, and 3. Although only three users are shown in FIG. 1, many more users can be coupled to the user bus 14 for accessing host unit 21. Further, although multiple users are shown in FIG. 1, a single user system can be implemented with the computer system of the present invention. User bus 14 is a bidirectional bus transferring information between the various users and the host unit 21. The preferred embodiment uses a networking bus architecture, which is well known in the art as Ethernet, for user bus 14.
Host unit 21 includes a main processor 15, memory 16, and an Accelerator Interface Processor (AIP) 17. The processor 15 of the present invention is a multiple user/multiple-tasking microprocessor based device and the particular processor used with the preferred embodiment is the 80386 integrated circuit microprocessor manufactured by Intel Corporation of Santa Clara, California. Processor 15 is coupled to the various users through the Ethernet network of user bus 14. Processor 15 also provides the multi-tasking which permits each user to access Processor 15 without the concern of interfering or being interfered by other users.
Memory 16 of host unit 21 is coupled to the processor 15 and AIP 17, and provides the necessary storage of data which is accessed by processor 15 and AIP 17. Memory 16 may be comprised of any of a variety of prior art memories, however, the preferred embodiment uses 8 megabytes of random access memory (RAM) and a hard disk. AIP 17 is a high speed device for providing direct memory access (DMA) between host unit 21 and accelerator 20. AIP 17 of the preferred embodiment is capable of transferring data at a maximum rate of 30 megabytes per second to or from the accelerator 20.
As used in the preferred embodiment, the host unit 21 is physically located in the same equipment assembly as accelerator 20. However, the users are physically located at a distance from the host unit 21 and the accelerator 20, and the users use a remote system for their simulation. The user bus 14, which is part of the Ethernet network, provides remote networking to couple the various users to host unit 21 which is also on the Ethernet network.
The accelerator 20 is a multiple processor accelerator and in the configuration of the preferred embodiment is capable of having a maximum of 254 processors; however, such limitation being a design choice and not a limitation of the present invention. The accelerator 20 is comprised of at least one module 22 and a unidirectional ring bus 23. Each module 22 is designed for configuring from 1 to 12 processors within itself. However, again such number being a design choice and not a limitation. Ring bus 23 is a unidirectional bus for coupling host unit 21 to the various modules 22 of accelerator 20. Although a variety of unidirectional buses can be utilized for transporting data between the various modules 22 and the host unit 21, the preferred embodiment utilizes a token ring bus system, wherein information is passed between the various units by a method of transferring a token along ring bus 23. One of a variety of prior art token ring bus schemes can be utilized to provide the protocol for transferring information unidirectionally on ring bus 23.
Each module 22 is capable of containing from 1 to 12 processors. However, the maximum number of processors which may exist within accelerator 20 is limited to 254 for the configuration as used in the preferred embodiment. Any combination of processors may be placed in these various modules 22, as long as the maximum is not exceeded. Therefore, if one processor is placed in each module 22, then 254 modules would be required if all 254 processors are used. However, in most simulation applications only a fraction of the maximum allowable 254 processors will be needed. Typically, a total required number of processors is first calculated and these are distributed into module groupings for optimum speed. For example, a system requiring eight processors will be distributed into two modules of four processors each. As will be shown later, each module 22 will be comprised of a number of processors and a given module 22 will operate independently from every other module 22, such that each module 22 is capable of providing parallel processing from every other module 22.
In functional terms, accelerator 20 is comprised of a plurality of modules 22, wherein each module 22 is capable of containing from 1 to 12 processors. Communication between the various modules 22 and the host unit 21 is provided by the ring bus 23.
A packet of information is sent on ring bus 23 from host unit 17 or one of the modules 22. The packet is given a destination address and this packet is transferred unidirectionally on ring bus 23 until the destination device is reached. Although only one packet of information can be on the bus 23 at any given instant, each device 21 or 22 is capable of independently processing information stored in itself.
Therefore, while a packet is being circulated to its destination on ring bus 23, each device 21 or 22 is providing simultaneous processing of information stored in itself. Further, while the simultaneous processing is occurring, data is put into packets for interdevice transfer on ring bus 23 as the token ring protocol will permit. It is to be stressed that although single data transfer on ring bus 23 is possible, a preferred method is to use packets of data to allow for a more timely transfer of information.
Referring to FIG. 2, a typical module 22, having a certain pre-defined hypothetical configuration, is shown and designated as module N. For each module 22, twelve slots are allocated for various processing devices and the slots are provided with a slot number to designate the actual physical location of the slot for plugging in various circuit cards.
For each module 22, an event buffer (EVB) 30 board is configured in one of the slots. In FIG. 2 EVB 30 is located within Slot 1. The EVB 30 couples module 22 to the ring bus 23 and also provides a circular RAM buffer to store at high speed the gate output changes occurring in the module 22 during simulation. An object of the RAM buffer is to store gate output changes for the user to examine when simulation is complete. The buffer scheme avoids sending these results to the host unit during simulation. Therefore, a purpose of the EVB 30 is to speed the event storage in the simulator without the requirement of accessing the memory 16 or other modules 22 frequently in the middle of a simulation to obtain data and provides data transfer with the ring bus 23. The EVB 30 includes 8 megabytes of RAM and is necessary for the interfacing of each module 22 to ring bus 23. The other slots, 2-12, are comprised of one of the processors mentioned in reference to FIG. 1 and discussed below or a specialized simulation device which operates in conjunction with one of the processors. It is appreciated that a variety of different types of processors can be configured to operate in slots 2-12.
Two types of processors are configured to operate with the module 22 of the present invention. A software processor (SP) 31 and a hardwired processor (HP) 32 are the two types available with the accelerator 20 of the present invention. An interprocessor bus (IP bus) 33 couples the various SP and HP processors 31 and 32 to the EVB 30. Although the number of actual physical circuit boards utilized with each processor unit within Module 22 is up to the preference of the designer, the present invention uses a single circuit board for SP 31 and two circuit boards for HP 32. Each board physically occupies one slot, however, in the electrical connection of HP 32, only one slot connection is needed to IP bus 33.
In the example of FIG. 2, an SP 31 in slot 12 is shown coupled to a specialized device known as a Physical Modeling Extension (PMX) 34 board to provide a physical reference element for simulation when used in conjunction with the SP 31 in slot 12. Although a variety of PMX 34 units can be utilized, one such PMX is described in application Ser. No. 651,427, filed Sept. 17, 1984, entitled Physical Modelling Device For Use With Computer-Aided Design, and assigned to the assignee of the present invention.
Information from the host unit 21, which may include information received from users on user bus 14, is transferred to the various modules in packets transmitted on ring bus 23. For example, in a three module system shown in FIG. 1, for a packet of information to be sent from host unit 21 to module C, the packet must be transferred through modules A and B before it is passed onto module C. Packets may originate from one module and be destined for another. For example, information originating from module A and destined for module C will pass through module B. Because of the unidirectional nature of ring bus 23, information originating from module C and destined for module A will be transferred through AIP 17. In this instance, AIP 17 will function to bypass the packet from module C for destination to module A. As used in the preferred embodiment the ring bus protocol permits only one packet to be on the ring bus 23 at any given time.
During the initialization phase, when the host unit 21 is activated prior to performing any simulation algorithm, host unit 21 will interrogate various modules 22 to determine the extent of the processor cards physically affixed to each of the modules 22. After interrogating each potential slot for each module, host unit 21 will designate a logical address for each of the active slots of each module 22 of accelerator 20. That is, logical addresses will not be given to any empty card slots of any module and different logical addresses will be given to similar slot numbers of two different modules so that each card or device coupled to a slot of a given module is given a unique address within accelerator 20. The logical address information is stored within memory 16 of host unit 21 and in the various EBVs 30.
Once the initial configuration has been achieved, the host unit 21 will accept inputs from various users on user bus 14. The input from User No. 1 is allocated to the various processors in Accelerator 20. The allocation management function is provided by the host unit 21 such that the simulation being run by a particular user is distributed optimally to all the appropriate processors in accelerator 20. For example, if an algorithm to simulate a circuit element requires the use of HPs 32, then the host unit 21 will distribute the circuit elements to be simulated substantially equally to all of the HPs 32 in accelerator 20. Circuit elements which cannot be handled by the HP 32 are distributed to the SPs 31, and the algorithm requiring a special device such as PMX 34, is allocated to the special device or to the associated SP 31 operating in conjunction with the special device.
The SP 31 of the present invention is comprised of a memory, a processor (ALU) and a microcode addressing means to provide a software simulation of the task at hand. One such implementation of an event driven simulation algorithm as implemented in the SP 31 is disclosed in U.S. patent application Ser. No. 594,533, filed Mar. 28, 1984, and entitled Digital Computer for Implementing Event Driven Simulation Algorithm, which is assigned to the assignee of the present invention. However, because of the microcode processor architecture of the SP 31, the SPs 31 operate at a much slower speed than the HPs 32. The SPs 31 of the preferred embodiment have three megabytes of onboard RAM which permit the SPs to simulate approximately 12 million bits of ROM or 6 million bits of RAM. The SPs 31 are capable of simulating complex circuit components such as ROMs, RAMs, PLAs, BXFRs (bidirectional transfer gates), DABLs ("behavioral languge" that allows an engineer to describe a design using statements instead of schematics), and PMXs. However, because the architecture of the SPs 31 and its associated algorithm are designed to simulate complex circuit components, it requires substantially more processing time to provide the simulation.
The HPs 32 of the present invention are designed to provide faster processing for simulation of simpler circuit components. Analysis of circuit simulation systems have shown that typically 95 percent of the elements in a circuit design simulation fall within the category of simple circuit components such as gates, flip-flops and delay circuits. The remaining 5 percent fall within the more complex circuit component category such as ROMs, RAMs, PLAs, BXFRs, DABLs, and PMXs, which are simulated by the SPs 31 of the present invention as described above. The HPs 32 of the present invention are capable of simulating simple gates having five inputs or less, tri-state gates having 5 inputs or less, flip-flops, UXFRs (unidirectional transfer gates), and delay components. Because a significant percentage of the circuit components fall within these primitive categories, the HPs 32 are capable of simulating these simpler components at a much faster processing speed than that of the more complex elements which are handled by the slower processing SPs 31.
Each HP 32 of the preferred embodiment, is capable of simulating up to 65,535 gates. On the other hand, each micro codable SP 31 of the preferred embodiment is capable of simulating only 16,384 gates. The actual number of HPs 32 and SPs 31 within a given module 22 is left to the design choice of the designer. However, it has been determined through reduction to practice, that an optimum configuration frequently results when equal number of SPs 31 and HPs 32 are present within a given module 22.
Still referring to FIG. 2, information transfer occurs external to modules N on ring bus 23. Packets of information are transmitted on ring bus 23 from other modules 22 or host unit 21 of FIG. 1 and are received by an input register 37, of EVB 30 of a given Module N. If the received data is destined for other than module N, the information is passed to bypass register 38 and then to output register 39 for further transmission on ring bus 23. However, if the data received is destined to this given module N, then the information is passed to input FIFO 40. FIFO 40 stores the information until IP bus 33 is free to receive the stored information. The information stored within FIFO 40 is then distributed onto IP bus 33 for final distribution to one of the 11 remaining slots coupled to IP bus 33.
For transmitting information from one of the processors coupled to IP bus 33, the information is transmitted from the appropriate processor onto IP bus 33. If the destination of the information is within module N, then the data is accepted in an intra-module transfer. Simply, the destination processor receives the information placed on IP bus 33.
However, when the destination is outside of module N, an inter-module transfer must occur. Data placed on the IP bus 33 is stored within FIFO 41 of EVB 30. When module N has access to ring bus 23, data is passed from FIFO 41 to output register 39 and onto ring bus 23.
A primary function of EVB 30 is to provide the necessary arbitration for both the ring bus 23 and its associated IP bus 33. The accessing of ring bus 23 and the transference of data packets between various modules have been described earlier. The IP bus 33 arbitration for each module 22 is also accomplished by the EVB 30. In this instance, an IP bus arbitration logic 49 is hard-wired coupled to each of the processors 31 and 32 within its same module 22 by request lines 44. Arbitration logic 49 determines which processor places data on the IP bus 33 at any given time. Reference table 42 contains a list of logical addresses for the processors in the given module N for the purpose of identifying whether data transfers originating within the module are destined for processors in other modules. It is accessed to also determine if data arriving at the given module N on ring bus 23 is destined for a processor within the same given module N.
When the EVB 30 is transferring information from FIFO 40 to one of the processors 31 or 32, the EVB 30 will take control of the IP bus 33 for transmitting data from FIFO 40 to its respective processor 31 or 32. When one of the processors requires access to the IP bus 33, that processor generates a request signal on its applicable request line 44 and that signal is received by the arbitration logic 49. The requesting processor is known to the arbitration logic 49 by the particular request line being activated. If the IP bus 33 is free, EVB 30 permits the requesting processor to access IP bus 33. The processor which has accessed IP bus 33 will then transfer information onto IP bus 33 for transmission to one of the other processors located in one of the other slots coupled to IP bus 33, or to the output FIFO 41 for transmission of data onto ring bus 23.
By achieving IP bus 33 arbitration, each processor within a given module 22 is capable of transferring information to another processor within the same module or in the alternative, passing the information to the EVB 30 for eventual transmission onto ring bus 23. Equivalently, incoming data on ring bus 23 is controlled by EVB 30 for arbitration onto IP bus 33 for distribution to the appropriate processor. It is appreciated that the EVB 30 permits independent operation of ring bus 23 and IP bus 33. That is, one set of data can be transmitted on the IP bus 33 while a different set of data is being transmitted or transferred on the ring bus 23, wherein both of these operations can occur simultaneously.
An IP hold circuit 45 within EVB 30 is coupled to the processors 31 and 32 of its same module through IP hold line 46. The purpose of the hold line 46 is to prevent a lock-up condition from occurring. A lock-up condition can occur when two processors, each in a different module, are transferring information to each other through its respective EVB on ring bus 23. For example, if HP 32 of slot 4 of module N accesses IP bus 33 for loading FIFO 41 for transmission onto ring bus 23, the slot 4 HP 32 will continue to hold IP bus 33 for transferring data to FIFO 41. However, if the second processor in the different module is transmitting on ring bus 23 and the destination is to the slot 4 HP 32, then the data will be coupled as input to FIFO 40. However, FIFO 40 cannot access IP bus 33 for further transfer of data, because slot 4 HP 32 is still controlling IP bus 33 for its transmission purpose. In this instance, FIFO 41 cannot access ring bus 23 for transmission of its packet and FIFO 40 cannot access IP bus 33 due to the control exerted by the slot 4 HP 32.
If the packet being transmitted on ring bus 33 to FIFO 40 is lengthy, then the transmitting processor will not free ring bus 23, so that FIFO 41 can access ring bus 23 for its transmission. In this instance a lock-up condition will occur, wherein FIFO 41 cannot release information onto ring bus 23 because of the non-idle state of ring bus 23, and at the same time ring bus 23 cannot transition to an idle state because information cannot be completely removed from ring bus 23 due to the blockage occuring at FIFO 40. To overcome this lock-up condition, hold circuit 45 will detect when this lock-up condition occurs. Hold circuit 45 will generate a signal on hold line 46 to cause all processors coupled to the IP bus 33 to revert to a listen mode. Once in the listen mode, slot 4 HP 32 will free IP bus 33 and permit information from FIFO 40 to be released to it. This will free ring bus 23 permitting FIFO 41 to transmit data onto ring bus 23. Once the lock-up condition has cleared, slot 4 HP 32 can now regain access to IP bus 33 for transmission of data to FIFO 41.
The host unit 21 does not include an EVB 30 or an IP bus 33 as shown in FIG. 2. However, AIP 17 of host unit 21 includes equivalent means for permitting data to be passed to and from ring bus 23 and is treated equivalently as one of the modules for data transfer to and from the ring bus.
The simulator of the present invention is an event-driven simulator, wherein an event is defined as a change in the output state of a circuit element, appropriately termed a "gate". A simulator which implements such an event-driven algorithm for determining the performance of simulated gates is disclosed in the aforementioned U.S. patent application Ser. No. 594,533.
FIG. 3 shows a double-word format which represents a packet of data of the preferred embodiment for updating the input states of various gates stored in the system. The most significant 8 bits of the first word 51 of packet 50 provide the eight-bit logical address number of the destination processor. The remaining 16 bits of the first word 51 provide a unique gate number associated with a particular gate stored within that processor. The most significant 8 bits of the second word 52 contain the new state information for a particular input for that gate number. The least significant 16 bits of second word 52 contain the information as to which input of the gate the new state applies to. Therefore, when an output changes for a given gate, packet 50 provides the state change for an input of a fanout of the given gate; and for each input change, a unique packet 50 is generated. As described earlier, the processor containing that particular gate number can be located within the same module or in the alternative it can be located in a separate module. Because of the unique logical addressing scheme, the processor number of each packet 50 determines the destination of the information contained in that packet 50.
It is to be appreciated that the concept of "fan-out" and "fan-in" in reference to circuit elements are known in the prior art. For example, if an output of element A is coupled as input to elements B and also to element C, A is a fan in of both elements B and C. Therefore, elements B and C are fanouts of element A. When an event occurring at element A changes its output, both elements B and C are notified by separate data packets to update their corresponding input states.
Referring to FIG. 4, a memory 56 allocated to each processor 31 and 32 of accelerator 20 is shown in a mapped form. Memory 56 is comprised of user section 57 and time wheel section 58. User section 57 is mapped to allocate memory space for each user 1 through m. The segmentation of section 57 permits multiple user access of accelerator 20 by storing a portion of each user's simulation data in each memory 56. However, the time wheel segment 58 is not segmented for each user. Although segmentation can be achieved for designating the timing sequence for simulating each user program, the preferred embodiment utilizes a single time wheel 58 for each processor within accelerator 20.
The host unit 21 of FIG. 1 maintains master control of the time wheel segment 58 for each memory 56. Memory 16 of host unit 21 of FIG. 1 stores the time wheel information for each user coupled to host unit 21. However, host unit 21 does load all of the simulation data in segment 57 for all users coupled to host unit 21.
In operation, when User 1 program is to be run, host unit 21 loads the time wheel 58 of each memory 56 with information relating to the timing of the program associated with User 1. When User 2 is to obtain access, host unit 21 will unload the contents of time wheel 58 from each memory 56 and stores this information in memory 16 of host unit 21. Then, host unit 21 will load time wheel 58 with timing information for User 2. Once the time wheel information for User 2 has been loaded in each memory 56, then User 2 area of segment 57 is accessed for running the User 2 simulation. Therefore, the contents of time wheel 58 are unloaded and loaded each time a different user program is to run.
A significant advantage is obtained in the scheme described above. The present invention loads and unloads contents of time wheel 58 when a different user program is to run. However the simulation data for each user is always present in segment 57 and need not be loaded or unloaded when a different user is chosen. Instead, a different area of segment 57 is accessed. The scheme permits fast switching between users in a multiple user accelerator system. The bulk of the data is stored in segment 57 and time wheel 58 contains comparatively less data for loading and unloading.
Referring to FIG. 5, an expanded example of the time wheel 58 of FIG. 4 is shown. The hypothetical example of FIG. 5 shows a particular time wheel 58a. Time wheel 58a contains event information for a particular gate only if its state is to change. Assuming that state change to a given gate occurs at time t, time wheel 58a will determine which gate or gates are affected at time t. Each time period change, referred to as a time tick, will continue until the next event change occurs for one of the gates stored within a particular memory 58a. In the example of FIG. 5, this second event change occurs at time t+15. Because several gates can be affected at a given time tick, each time tick in Time Wheel 58 is linked together through a double link list known as an event queue. In this particular example three gates are affected at time t+15 and are shown as gates 36, 43 and 53. Therefore, time wheel 58a for a given user program stores information pertaining to event changes occurring to gates which are being stored in its associated user segment 57 of memory 56.
Another advantageous feature of the accelerator of the present invention is a special circular memory 35 located in EVB 30 of each module 22. Memory 35 stores a limited time history of output changes of all gates in the given module 22. When memory 35 is full, the circular nature of memory 35 permits the oldest events to be overwritten by the newest events. By maintaining such a history of output changes, a user need not specify a particular gate, which output history is desired for observation, prior to executing the simulation. Prior art systems without such a memory 35 required a user to identify a particular gate prior to running the simulation, since these outputs would have to be sent back to the host during simulation, significantly degrading simulation speed. However, because of memory 35, all the output state changes are stored and these various stored output changes can be reviewed at any point in the simulation. This unique feature aids in debugging a simulated circuit. The preferred embodiment uses a RAM for memory 35.
It is to be appreciated that in the prior art not all output changes can be stored due to bus bandwidth and memory/sisk size constraints. For example, a single processor, such as the HP 32 of the present invention, generates 500,000 events per second. At 4 bytes per event, 2 million bytes per second must be stored if all output changes are to be recorded. With multiple HPs 32, the transfer rate to the host to record all events may be in the order of 100+M bytes/sec.
Further, taking this example, a ten minute simulation will generate data transfers of 60 billion bytes. Not only would this require significant storage space but hard disk storage units cannot store information at a rapid enough rate. This is typically the reason for prior art systems storing only selected outputs, such as 1% of all outputs. The present invention uses a circular memory to store all outputs of a limited time history.
Hardwired Processor
FIG. 6 is an expanded block diagram schematic showing elements for pipelining information through each HP 32 of a given module 22 shown in FIG. 2. The HP 32 is physically divided into two boards 61 and 62, shown by dotted line 60. The HP 32 of the preferred embodiment is a hardwired logic simulation board (actually two boards) providing a 9 stage pipeline machine for processing the more primitive circuit components as described earlier. The hardware configuration of HP 32 is to provide serial pipelining of various functions of the simulation through the stages 1-9. That is, information entering stage 1 will transition to stage 2 and then to stage 3 and etc. until it completes its pipelining at stage 9.
Also referring to FIG. 7, it illustrates the pipelining sequence for performing the simulation in a flow diagram. The pipelining sequence is comprised of an update phase and an evaluation phase. The two phases of the simulation activate different data flows in the pipeline of FIG. 6.
During the update phase, the HP 32 performs dual tasks. The first task is performed by the input evaluation bit logic 71, shown as stage 1, wherein information received from other processors are inputted from the IP bus 33 to stage 1 of HP 32. The evaluation bit logic 71 receives fanout packets which are sent to this particular processor and updates the input states of the gates and also puts the gate numbers in the flat queue 72 of stage 2. The addition of the gate numbers to the flat queue 72 is only accomplished if it has already not been done so, so that a particular gate number appears at most once in the flat queue 72.
The second task of HP 32 during the update phase is being performed by the event queue 76 of stage 6. The time wheel 76a, which is equivalent to time wheel 58a of FIG. 5, will select gates from the event queue 76 if an event has occurred for this given time tick. The event queue 76 will address a fanout pointer from fanout pointer 77 of stage 7 for each of the gates sent from the event queue 76. The fanout pointer 77 will then address the appropriate fanout information from fanout list 78 of stage 8. The fanout list 78 is basically a cross reference table for providing the gate numbers and input numbers of the gates which are fanouts of the gate whose output has changed.
Fanout pointer 77 it utilized so that the gate selection from the event queue 76 will address a single pointer, wherein this pointer will point to a number of fanouts for each gate. The fanout list 78 will allow 0 to 65,535 fanouts for each gate. The fanout information is sent to stage 9 wherein one of two conditions will occur. Stage 9 includes an identification comparator 79 which looks at the destination of the fanout information. If the fanout (destination) gate is on the same HP boards 61 and 62, then that information is passed to stage 1. However, if the destination of the fanout gate is on another processor, then the information is stored in the output FIFO of stage 9 and will later be sent on the IP bus 33 when this HP 32 acquires IP bus 33 for transmission of data.
During the evaluation phase, stages 2, 3, 4, 5 and 6 are active. The flat queue 72 takes gate data out of the flat queue, along with gate input information. Gate type stage 73 of stage 3 finds the gate type and the evaluation pointer for that particular gate. The evaluation process occurs in stage 4 wherein the evaluation stage 74 performs a lookup of simulation algorithms stored in a memory according to the evaluation pointer and a current state of the inputs for that gate. Then at stage 5 the delay table 75 is accessed to determine the rising or the falling delay for that given gate according to the evaluated output from stage 4. The event queue 76 of stage 6 then compares the old and evaluated outputs and schedules an event and stores that in the event queue 76 if the two do not agree, signifying an output state change is required.
Each pipeline stage in the HP 32 is 400 nsec. long. The exception is this is the event queue 76 which can sometimes generate 500 nsec. cycles. The HP 32 also includes an evaluation counter that counts the number of evaluations that occurs and the HP 32 is capable of reaching 1.75 million evaluations per second under optimum conditions. This will require that all of the pipeline stages, Stages 1-9, be busy most of the time. Separate memory units are utilized for storing information for each of the stages 2, 3, 4, 5, 6, 7 and 8. In the preferred embodiment, separate memory units are also used for stages 1 and 9.
A master control 65 is coupled to the different stages to permit the transfer of information from one stage to the next. The master control 65 is configured such that information can be pipelined at different rates. For example, if the evaluation algorithm in stage 4 causes a clog in the pipelining system, master control 65 will cause gate type stage 73 to stop sending information to stage 4 until the pipelining opens again. However, the master control 65 will continue to allow other stages to function as long as the next stage in the pipeline is capable of receiving information. Therefore, master control 65 permits each stage to operate independently in processing information, but will prevent the transfer of information if a clog occurs in the pipeline.
The SP 31 of the preferred embodiment is a 10 MHz microcodable processor with 3 megabytes of onboard memory. It simulates more complex elements which cannot be simulated by the HP 32. To reach maximum simulation speed, parallelism of execution should be achieved among the various processors. This requires that the amount of time it takes the SP to process a time tick, should be the same as a that of the HP. This fact and the internal memory size of each of the SPs will put a limiting factor in the number of gates that an SP should simulate.
The hardwired processor of the preferred embodiment is designed to have a typical capacity of 64K gates. Assuming that on the average 0.2% of the gates are scheduled at every time tick, at an average speed of 500,000 events per second, each average time tick will take 256 microseconds. The SP can perform at an average of 30,000 events per second which means that in 256 microseconds the SP can process 8 events. Therefore, an equivalent capacity of the SP will be around 4K gate versus 64K for the HP. But since most of the simulated elements in the SP are of a type involving a large gate attribute structure, a 16K gate capacity for the SP is more realistic.
It is to be appreciated that the size of the memory of the various processors is a matter of design choice and a specific size is stated for exemplary purpose only.
Thus a computer which utilizes a hardwired pipelined processor for implementing an event driven simulation algorithm is described.
Claims
I claim:
1. A computer system coupled to a plurality of users for implementing an event driven algorithm of each of the users, comprising: (1) a master processor coupled to the users for providing overall control of the computer system and for executing the event driven algorithm of each of the users, wherein the master processor further includes a master memory; (2) a unidirectional ring bus coupled to the master processor; (3) a plurality of processor modules coupled to the unidirectional ring bus, wherein the unidirectional ring bus transfers data among the processor modules and the master processor, and wherein each processor module includes: (a) a plurality of simulation processors for independently operating on a portion of the event driven algorithm, wherein the plurality of simulation processors function substantially simultaneously to each other, and wherein each simulation processor further includes a simulation memory for storing simulation data for circuit elements being simulated by that respective simulation processor; (b) an interprocessor bus coupled to the plurality of simulation processors for transferring the simulation data among the plurality of simulation processors; (c) an interface means coupled to the unidirectional bus and the interprocessor bus for transferring the simulation data between the unidirectional bus and the interprocessor bus, wherein the interface means further includes: (i) an event memory that stores a history of event changes of the circuit elements being simulated by the simulation processors of that respective processor module; (ii) a first storage means for storing data for the ring bus that is destined for a simulation processor of the simulation processors of that respective processor module; (iii) a second storage means for storing data from a simulation processor of the simulation processors of that respective module, wherein the data is destined for transfer to the ring bus; (vi) a reference table for storing a logical address for each of the simulation processors of that respective processor module, wherein the reference table is accessed to determine if that respective processor module is a destination of simulation data arriving on the ring bus; wherein an intramodule transfer of data on the interprocessor bus occurs independently of a transfer of data on the unidirectional bus.
2. The computer system of claim 1, wherein each interface means of each processor module further includes a bypass means for bypassing data from the ring bus back to the ring bus for further transmission on the ring bus if the data is not destined for that respective processor module.
3. The computer system of claim 2, wherein the master memory stores timing information for all the users, wherein each simulation memory stores simulation data for all the users, and wherein each simulation memory stores timing information for only a respective user whose algorithm is being executed.
4. The computer system of claim 3, wherein the plurality of simulation processors include a software processor and a hardwired processor.
5. The computer system of claim 4, wherein the event memory is a random access memory.
6. The computer system of claim 1, wherein the event memory is a circular memory that stores a predetermined number of historic cycles of the events, and wherein when the predetermined number of historic cycles is exceeded, then an earliest event change is replaced by a newest event change.
7. The computer system of claim 5, wherein the event memory is a circular memory that stores a predetermined number of historic cycles of the events, and wherein when the predetermined number of historic cycles is exceeded, then an earliest change is replaced by a newest event change.
Patent Citations (27)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US3701976 | 1972-10-01 | Shively | |
| US4123794 | 1978-10-01 | Matsumoto | |
| US4306286 | 1981-12-01 | Cocke et al. | |
| US4334305 | 1982-06-01 | Girardi | |
| US4335426 | 1982-06-01 | Maxwell et al. | |
| US4339793 | 1982-07-01 | Marenin | |
| US4347564 | 1982-08-01 | Sugano et al. | |
| US4351025 | 1982-09-01 | Hill, Jr. | |
| US4365297 | 1982-12-01 | Grisham, Jr. | |
| US4396978 | 1983-08-01 | Hammer et al. | |
| US4412303 | 1983-10-01 | Barnes et al. | |
| US4466063 | 1984-08-01 | Segarra et al. | |
| US4468734 | 1984-08-01 | Lanier et al. | |
| US4527249 | 1985-07-01 | van Brunt | |
| US4584642 | 1986-04-01 | Fudanuki | |
| US4594655 | 1986-06-01 | Hao et al. | |
| US4602365 | 1986-07-01 | White et al. | |
| US4622550 | 1986-11-01 | O'Connor et al. | |
| US4656580 | 1987-04-01 | Hitchcock, Sr. et al. | |
| US4697241 | 1987-09-01 | Lavi | |
| US4700292 | 1987-10-01 | Campanini | |
| US4725975 | 1988-02-01 | Sasaki | |
| US4751637 | 1988-06-01 | Catlin | |
| EPX21404 | 1981-07-01 | ||
| GBX2096369 | 1982-10-01 | ||
| GBX2156550A | 1985-10-01 | ||
| WOX8101066 | 1981-04-01 |
Non-Patent Literature (22)
- M. Abramovici, et al.; "A Logic Simulation Machine"; IEEE Transactions on Computer-Aided Design of Integrated Circuits & Systems; vol. CAD-2, No. 2; 4/83 Zycad Logic Evaluator as described in ZYCAD Corporation's manual dated Nov., 1982.
- J. Howard, et al., "Parallel Processing Interactively Simulates Complex VSLI Logic"; Electronics Dec. 15, 1983; pp. 147-150.
- B. Milne, Simulation Accelerator Checks Out 65,000 Gates; Checks In at $80,000, Electronic Design, p. 173 (Jun. 27, 1985).
- S. Macomber & G. Mott, Hardware Acceleration for Layout Verification, VLSI Design, pp. 18-19, 22-23, 26-27 (Jun. 1985).
- Firm Unveils Simulation Engine, Computerworld, pp. 93 & 103 (Jul. 15, 1985).
- I. Michaels, Hardware Accelerators Are Up in Speed, Down in Price, Computer Design, pp. 52, 54, 56, 58 etc. (Sep. 15, 1985).
- G. Mott & R. Hall, The Utility of Hardware Accelerators in the Design Environment, VLSI Systems Design, pp. 62, 66 & 70 (Oct. 1985).
- J. Newkirk, A Perspective on Combining General-Purpose and Point Acceleration, Proceedings of the Technical Sessions, Automated Design and Engineering for Electronics West, pp. 163-164 (Mar. 11, 1986).
- G. Mott, A Computational Supernode For Electronic Design Verification, Proceedings of the Third Silicon Design Conference, pp. 277-284 (Jul. 15, 1986).
- J. Newkirk, Fault Simulation in the CAE Era, Proceedings of the Technical Sessions, Automated Design and Engineering for Electronics East, pp. 171-172 (Sep. 30, 1986).
- G. Mott & J. Newkirk, Eliminating Failures in the Field, VLSI Systems Design, pp. 88-90 (Oct. 1986).
- J. Rhodes, Hardware-Assisted Fault Simulation in a Silicon Compiler Environment, Proceedings of the Technical Sessions, Automated Design and Engineering for Electronics West pp. 289-290 (Mar. 31, 1987).
- Silicon Solutions brochure for the MX Interface (Jun. 1987).
- B. Milne, Put the Pedal to the Metal with Simulation Accelerators, Electronic Design, pp. 39-42, 44, 46, 50 & 52 (Sep. 1987).
- The MACH 1000 Product Description Manual by Zycad (Nov. 1987).
- J. Howard et al., Introduction to the IBM Los Gatos Logic Simulation Machine, Proceeding of the IEEE International Conference on Computer Design: VLSI in Computers pp. 580-583 (Oct. 31, 1983).
- T. Burggraff et al., The IBM Los Gatos Logic Simulation Machine Hardware, Proceedings of the IEEE International Conference on Computer Design: VLSI in Computers, pp. 584-587 (Oct. 31, 1983).
- J. Kohn et al., The IBM Los Gatos Logic Simulation Machine Software, Proceedings of the IEEE International Conference on Computer Design: VLSI in Computers, pp. 588-591 (Oct. 31, 1983).
- G. Pfister, The IBM Yorktown Simulation Engine, Proceedings of the IEEE, vol. 74, No. 6 (Jun. 1986) (pp. 850-859).
- G. Pfister, The Yorktown Simulation Engine: Introduction, ACM IEEE 19th Design Automation Conference Proceedings, pp. 51-54 (Jun. 14, 1982).
- M. Denneau, The Yorktown Simulation Engine, ACM IEEE 19th Design Automation Conference Proceedings, pp. 55-59 (Jun. 14, 1982).
- E. Kronstadt & G. Pfister, Software Support for the Yorktown Simulation Engine, ACM IEEE 19th Design Automation Conference Proceedings, p. 60 (Jun. 14, 1982).