WO2001035283A2 - System for performing parallel circuit simulation in a high level description language - Google Patents

System for performing parallel circuit simulation in a high level description language Download PDF

Info

Publication number
WO2001035283A2
WO2001035283A2 PCT/CA2000/001342 CA0001342W WO0135283A2 WO 2001035283 A2 WO2001035283 A2 WO 2001035283A2 CA 0001342 W CA0001342 W CA 0001342W WO 0135283 A2 WO0135283 A2 WO 0135283A2
Authority
WO
WIPO (PCT)
Prior art keywords
hdl
sub
simulation
block
program
Prior art date
Application number
PCT/CA2000/001342
Other languages
French (fr)
Other versions
WO2001035283A3 (en
Inventor
Eric Bourget
Eric Gauthier
John J. Haughey
Marcelo A R. De Maria
Original Assignee
Hyperchip Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hyperchip Inc. filed Critical Hyperchip Inc.
Priority to AU13754/01A priority Critical patent/AU1375401A/en
Publication of WO2001035283A2 publication Critical patent/WO2001035283A2/en
Publication of WO2001035283A3 publication Critical patent/WO2001035283A3/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking

Definitions

  • the present invention relates to the simulation of circuit designs which are specified in a high level description language such, as VHDL and Verilog, and, in particular, to a system for performing such simulations in parallel so as to increase the speed at which such simulations can be performed.
  • a high level description language such as VHDL and Verilog
  • VHDL VHSIC High Level Description Language
  • Verilog VHSIC High Level Description Language
  • Both VHDL and Verilog provide a computer language in which a circuit designer can describe a circuit either in terms of the behavior of the circuitry, i.e., what information various of its components communicates at what time, or the structure of the circuit, i.e., what its inputs and outputs are, what its sub-components are, and how it is connected to those sub- components.
  • These description languages also allow more detailed, gate- level, description of a circuit to be designed.
  • HDL simulation program are provided by several commercial vendors, including
  • test harness When a circuit is tested by an HDL simulator it is placed inside a "test harness" or “test bench".
  • test bench is computer code, either written in HDL or some other computer language such as C or C++ which simulates providing the inputs necessary to test the HDL circuit designs behavior.
  • a computerized method of simulating HDL circuit designs includes running multiple instances of an HDL simulation program, each of which is capable of simulating an HDL block in a test bench without other simulation software.
  • the Method has each instance of the simulation program simulate an HDL sub-block of a larger HDL design within a test bench, and has the test benches communicate port values and clock synchronization between themselves, so the simulation of the separate sub-blocks function to create a parallel simulation of the larger HDL design.
  • the method executes software which parses the HDL description of each separately simulated sub-block to find the external ports of each such sub- block.
  • the method then generates computer code which defines the test bench with which each such sub-block is separately simulated.
  • the computer code generated for each test bench includes internal ports corresponding to, and connected to, the external ports of its associated sub-block.
  • the code generated for each such test bench also includes instructions for communicating the values of those ports and clock synchronization information with the simulation of other sub-blocks.
  • each test bench generated by the method has two parts, a test bench written in HDL; and non-HDL parallelization code.
  • the HDL test bench and the non-HDL parallelization code communicate port values and synchronization information using a language interface provided in HDL to support communication between HDL and non-HDL code, and the parallelization code relays such information with the parallelization code associated with other HDL sub-blocks.
  • the separate non-HDL parallelization code associated with separate HDL sub-blocks communicate with each other through a master program running on one processor.
  • each separate instance of the HDL simulation program includes a user interface which allows a user to monitor and control the simulation of an HDL block by each such instance of that program, if desired.
  • a computerized method for simulating HDL circuit designs composed of a plurality of HDL sub-blocks.
  • the method comprises responding to a selection by a user of which of a given design's sub-blocks have been selected for separate simulation on different processors by parsing the HDL code of each such selected sub-block to determine its external ports. Then the method automatically creates a test bench to drive a separate simulation of each such selected sub-block, with the test bench created for each selected sub-block having interfaces for communicating the value of the sub-block's external ports and clock synchronization information between the sub-block and the simulation of other selected sub-blocks. Once the test benches have been created, the method runs a separate instance of an HDL simulation program for each selected sub-block and its associated test bench.
  • the method further includes first parsing HDL code of the HDL circuit design to determine the hierarchy of HDL sub-blocks defined by the design; providing the user with a graphic representation of the sub-block hierarchy; and then allowing the user to make the selection of which sub-blocks are to be selected for separate simulation by using a point and click interface.
  • information obtained in a parse of the HDL code of the circuit is used to generate an HDL dummy top-block which has ports corresponding to the external and internal ports of the top block in the HDL circuit design.
  • This dummy top-block includes code for communicating the values of each of the top block's external ports between a test bench created to drive the simulation of the top block and corresponding ports of individual test benches generated by the method to drive the simulation of the selected sub-blocks.
  • a computerized method of simulating HDL circuit designs includes running multiple instances of an HDL simulation program, each capable of simulating an HDL block in a test bench without other simulation software.
  • Each instance of the HDL simulation program is used to simulate an HDL sub-block of a larger HDL design.
  • the simulation of each separately simulated sub-block uses a language interface supported by the HDL simulation program to allow communication between the HDL and another programming languages. It uses this language interface to communicate port values and clock synchronization information between the HDL simulation of each sub-block and non-HDL parallelization code running on the same processor.
  • the parallelization code associated with simulations running on different processors is used to communicate such port values and clock synchronization information between the separate simulations.
  • the simulation of individual sub-blocks includes performing gate level logic simulation which calculates gate level delays associated with the propagation of signals though logic gates in the simulated circuitry of the sub-blocks.
  • the external output ports of the separately simulated sub-blocks are the outputs of clocked latches in the HDL circuit design, so that their values only change at the time of clock signals during simulation. The communication of port values over the language interface does not simulate gate level signal delays.
  • synchronization of separate simulations is controlled by having each HDL simulation make a call using the language interface to the non-HDL parallelization code running on the same processor. This call does not return until the non-HDL parallelization code receives information derived from the parallelization code on other processors that the simulations of all the sub-blocks of the larger HDL design being simulated are ready to advance to simulation of a subsequent clock event.
  • the instances of the non-HDL parallelization code on different processors can be slave programs which communicate with others through a master program running on one processor. This master program can be used to instruct the separate instances of the parallelization code when to the returns from such call, so as to allow the separate HDL sub-block simulations to advance to simulation of a subsequent clock event.
  • This decision by the master program can be made by having each slave program sends a message to the master program when its associated HDL simulation is done simulating its response to a given clock signal.
  • the master program can then send the instruction to each slave program to return from such a call once the master program has received such a done message from each slave program participating in the simulation of the HDL circuit for the previous clock signal.
  • a computerized method of simulating HDL circuit designs includes the following: running multiple instances of an HDL simulation program, each of which is capable of performing an independent simulation of an HDL block; having each instance of the simulation program simulate an HDL sub-block of a larger HDL design within an HDL test bench; and having the HDL test benches communicate port values and clock synchronization between themselves using an HDL language interface supported by the simulation program, so the simulations of the separate sub-blocks by separate instances of the simulation program function to simulate the larger HDL design.
  • the HDL code of the circuit design to be simulated is parsed to determine the external port connections of each sub-block being separately simulated. Then the method generates a separate HDL test bench for each sub-block.
  • Each such test bench has an internal port for each of its sub-block's external ports, and code for making calls with an HDL language interface supported by the simulation program to non-HDL code running on the same processor which communicates the value of those ports with the test benches generated for the other separately simulated HDL blocks.
  • synchronization between the separate test benches is achieved by having language interface calls to the non-HDL code not return until all the test benches separately simulating sub-blocks have indicated that they have completed their response to a previous clock event.
  • the multiple instances of an HDL simulation program are instances of a commercially available HDL serial simulation program, each of which is capable of simulating an HDL block in a test bench without other simulation software.
  • Each instance of this simulation program perform a serial simulation of a sub-block of a larger HDL design within a test bench on the same processor as that instance.
  • At least a part of the test bench is additional software, which is not part of the commercially available simulation program. This additional software communicates port values and clock synchronization between the test benches associated with different sub-blocks.
  • the commercially available HDL simulation program does not include programming which enable different processors connected by a computer network to simulate an HDL circuit by using different processors to simulate different parts of the circuit, but the additional software provides the functionality to necessary to enable separate instances of the HDL simulation program to communication with each other over a computer network and operate in parallel to simulate the different parts of an HDL circuit description.
  • the HDL simulation program is produced by one legal entity, and the part of the test bench which communicates port values and clock synchronization information is additional software is produced by a different legal entity.
  • a method of simulating HDL circuit designs includes the following: running multiple instances of an HDL simulation program, each of which is capable of simulating an HDL block in a test bench on separate processors; dividing the design into sub-blocks having only clocked external ports; simulating the separate sub-blocks on separate instances of the simulation program running on separate processors with individual instances of the simulation program calculating gate level delay times within the part of the HDL circuit design represented by its associated sub-block; having parallelization software run on each processor running an instance of the simulation program which synchronizes clock times between the separate simulations; and having the parallelization software communicate the external port values of the separately simulated sub-block at the synchronized clock times without gate delay information.
  • FIG. 1 is a schematic representation of a hypothetical integrated circuit, illustrating the hierarchy of blocks within such a circuit
  • FIG. 2 is a representation of the hierarchy of blocks within the circuit of FIG. 1 ;
  • FIG. 3 is a partial representation of an HDL description of the circuit shown in FIG. 1 ;
  • FIG. 4 is a schematic block diagram of a multi-processor computer system which is capable of performing parallel simulations of an HDL circuit description using many aspects of the present invention
  • FIG. 5 is a highly schematic pseudo-code description of that part of the master program shown in FIG. 4 which configures the software and data structures necessary to cause the system shown in FIG. 4 to run a given parallel simulation;
  • FIG. 6 is a highly simplified pseudo-code description of that part of the master program shown in FIG. 4 which sets up the system shown in FIG. 4 to run a parallel simulation previously configured by the code shown in FIG. 5;
  • FIG. 7 is a simplified illustration of a computer screen display which is generated by the programming of FIG. 5 to enable a used to select which sub-blocks of an HDL circuit design are to be separately simulated
  • FIG. 8 is a schematic block diagram similar to that of FIG. 4, used to illustrate what happens if multiple sub-blocks are to be separately simulated on one processor;
  • FIG. 9 is a highly simplified pseudo-code description of that part of the master program shown in FIG. 4 which operates during the actual parallel simulation performed by the system of FIG. 4 so as to communication port values between the separate simulations and synchronize their operation
  • FIG. 10 is a highly simplified pseudo-code description of the HDL imitation, shown in FIG. 4, of the top block of the circuit being simulated, which imitation top block is designed to be simulated within an external test bench written to drive the simulation of the actual top block of the circuit and is designed to communicates values from the external test bench to the rest of the parallel simulation;
  • FIG. 11 is a highly simplified pseudo-code description of the imitation top Block's non-HDL slave program, shown in FIG. 4, which runs on the same processor as the simulation of the imitation top block shown in FIG. 10, and which is used to communicate port values and synchronization information between the simulation of the imitation top block and other parts of the parallel simulation;
  • FIG. 12 a highly simplified pseudo-code description of the HDL test bench, shown in FIG. 4, which is generated by the configuration code of FIG. 5 to drive the simulation of each separately simulated sub-block in the parallel simulation;
  • FIG. 13 a highly simplified pseudo-code description of a non-HDL sub-block slave program, shown in FIG. 4, which runs on the same processor as an associated separate sub-block simulation, and which is used to communicate port values and synchronization information between the separate processes of the parallel simulation;
  • FIG. 14 is an alternate schematic block diagram of the system shown in FIG. 4, which illustrating how the separate user interfaces of each separate instance of the simulation program can be used on one computer screen to control and observe the operation of the parallel simulation;
  • FIG. 15 is a highly schematic illustration of a method by which one can create a parallel simulation system similar to that shown in FIG. 4 by purchasing simulation software from one entity and then obtaining parallelization code produced by another entity;
  • FIG. 16 is a highly schematic illustration of a method of developing an HDL design for a circuit and its test bench, including performing serial simulation of the circuit and its test bench and then performing a parallel simulation on the circuit using the same simulation program and the same test bench.
  • FIG. 1 is a schematic representation of an integrated circuit 100.
  • This circuit is made up of a hierarchical arrangement of components or "blocks".
  • the entire circuit 100 is labeled B1.
  • B1 is the top, or highest, block of this circuits hierarchy of blocks, and, as such, it represents the entire circuit.
  • the top block B1 includes 5 sub-blocks, including four identical sub- blocks B2, B3, B4, and B5, and one additional, but differently designed sub-block B6.
  • Sub-block B2 includes sub-blocks B8 through B11.
  • Sub- block B3 includes sub-blocks B13 through B16.
  • Sub-block B4 includes sub-blocks B18 through B21
  • sub-block B5 includes sub-blocks B23 through B26.
  • Sub-block B6 is not shown as having any sub-blocks in FIG. 1.
  • FIG. 2 represents the hierarchy 110 of block and sub-blocks shown in FIG. 2. It should be understood that in many circuits the hierarchy of circuit blocks extends much deeper than the three levels shown in FIGS. 1 and 2.
  • FIG. 3 is a part of an HDL description file 120 for the circuit 100 shown in FIG. 1. This partial description is in the VHDL language.
  • This code includes entity declarations 122A, 122B, and 122C which declare the blocks B1 , B2, and B3 shown in FIG. 1.
  • each such entity declaration includes a listing of all of each block's ports, that is, its inputs and outputs.
  • the HDL description also includes an architecture structure statement 124 for the top block B1 of the circuit of FIG. 1. This statement lists each sub-blocks of which the block B1 is made with an "entity work" statement 126, several of which are shown in FIG. 3.
  • Each entity work statement includes a "port map” statement which includes a mapping of the ports of each of B1 's sub-blocks to the ports of B1 itself.
  • FIG. 4 illustrates a system 130 which performs parallel HDL simulations using one embodiment of the present invention.
  • a plurality of instances of a serial HDL simulation program are run on different computers 132, of which the computers 132A, 132B, and 132C shown in FIG. 4 are examples.
  • Each of these computers has a network interface 133 which enables it to communicate with other computers of the system through a computer network 134.
  • a plurality of the system computers (computers 132B and 132C in FIG. 4) each run and instance of an HDL simulation program 136.
  • One of these computers, computer 132B in FIG. 4 simulates a dummy HDL block 138, which has external ports 139 and internal ports 141 corresponding, respectively, to all of the external and internal ports of the top-block of the entire HDL circuit which is being simulated by the multiple computers of the system 130.
  • the top block 138 is simulated inside a test bench 140 identical to that which could be used to perform a normal serial simulation upon the HDL code of the real top block of which the dummy top-block 138 is an imitation.
  • This external test bench has internal ports 143 which correspond to all of the external ports of the HDL top block 138, and which deliver simulated inputs to, and receive simulated output from, the top block's ports.
  • the top block's test bench is shown as an HDL test bench, but other types of test benches could be used as well.
  • the HDL top block 138 shown in FIG. 4 is a "dummy" in the sense that its simulation on the computer 132B does not include the simulation of the sub-blocks of which it's design is composed, as would normally be the case. Instead those sub-blocks are separately simulated on other computers 132C and the inputs and outputs which the top block provides to those sub-blocks are communicated through HDL calls through a language interface 145 to a non-HDL slave program 147, as will be explained below.
  • Each of the computers 132C includes an instance of the HDL simulation program 136 which simulates a separate sub-block 144 of the top block 138. Each such HDL sub-block is simulated within a sub-block test bench 140A written in HDL code.
  • the external test bench 140 performs the function normally associated with the phrase "test bench” in that it drives the simulation by provided test input values and clock signals.
  • the sub- block test benches 140A act as test benches only in that they drive the simulation of separate sub-blocks, but they do not independently generate test vectors or timing signals. Instead they merely relay port values and timing information received from the external test bench through the dummy top block and received from the simulation of other sub-blocks
  • Each such test bench includes a set of internal ports 146 which supply input to and receive output from the external ports 148 of their associated HDL sub-block.
  • the values communicated with the internal ports of the HDL test bench 140A are communicated to other parts of the parallel simulation through HDL calls through a language interface 145A to a slave program 147A which runs on the same processor as the test bench, but which is not part of the serial HDL simulation program 136.
  • each sub-block slave program 147A like the top block slave program 147 of the processor running the simulation of the top block is written in general purpose programming language like C or C++.
  • Each of the slave programs 147 and 147A include instructions for receiving output values from, and supplying input value to, their associated top-block or sub-block.
  • Each slave program 147 and 147A receives the input values it sends to its associated simulation from, and sends the output values it receives from its associated simulation to, a master program 150 shown in computer 132A of FIG. 4.
  • Each such slave program also communicates synchronization information with its associated simulation program and with the master program 150, as will be described in more detail below.
  • This synchronization information includes the value of a master clock variable 152 shown in FIG. 4.
  • the master program 150 includes a configuration routine 154, shown in more detail in FIG. 5, which responds to a users selection of which sub-blocks are to be separately simulated. It does so by automatically creating the test benches and data structures necessary to perform the parallel simulation of such sub-blocks.
  • the master program also includes a set-up routine 156, shown in more detail in FIG. 6, which automatically prepares the system 130 to perform a parallel simulation.
  • the master program also includes a main loop 158 which operates during an actual parallel simulation to relay port values between the top-block and the various sub-blocks of such a parallel simulation, and to synchronized the separate serial simulations which make up such a parallel simulation.
  • FIG. 5 is a highly simplified pseudo-code representation the master program's config routine 154, mentioned above.
  • This routine performs a step 160 which parses the HDL file 120, shown in FIG. 4, which describes the circuit to be to simulated. It performs this parse to determine the hierarchy of sub-blocks which form the top block to be simulated. As was illustrated above with regard to FIG. 3, HDL code is designed to explicitly show such hierarchy, and, thus, such a parsing process is relatively straight forward.
  • step 160 display this hierarchy 110 of sub-blocks to user in a graphical user interface window 182 on a computer screen 184 shown in
  • a step 162 records the user's selection of which one or more sub- blocks are to be assigned to each processor.
  • the configuration routine includes code to allow the use to make such a selection by using a cursor 186 shown in FIG. 7 to drag the representation 190 of each of the HDL file's sub-blocks which he wants run on a separate processor to a graphical representation 192 of that processor in the GUI window 194.
  • the motion of such a drag is illustrated in FIG. 7, by the dotted line 196 between the two images of the cursor 188.
  • FIG. 7 the processor representation 192B has had two sub-blocks dragged into it.
  • the system will simulate each of these two sub-block 144 in a separate instance 136 of the HDL simulation program on a single processor 132C, as is indicated in FIG. 8.
  • Each such simulation will be identical to the separate simulations shown in processor 132C of FIG. 4, except that there are two of them on one processor.
  • the configuration routine performs steps 164-178 which configure the system to perform the specified parallel simulation.
  • Step 164 parses the HDL file of the top block of the circuit to be simulated to determine all of the top block's input and output ports. Then step 166 creates a dummy HDL topBlock 138, shown in FIG. 4, with the same external and internal ports as the original top block of the HDL file 120. Next step 168 creates code in the dummy HDL topBlock for FLI, or Foreign Language Interface, calls to the top block's slave program 147 shown in FIG. 4.
  • the Foreign Language Interface is an interface which is provided as part of VHDL to enable VHDL code to make calls to routines which are written in other languages, such as C or C++. In Verilog versions of the invention the language interface used for such calls can be the PLI, or Programming Language Interface, which performs a similar function.
  • step 170 creates a wire values table data structure with entries corresponding to top block's ports. This data structure will be used by the top block's slave program 147 shown in FIG. 4 once the parallel simulation starts.
  • step 172 performs an iteration of a loop comprised of steps 174 and 176 for each sub-block to be separately simulated.
  • Step 174 parses the portion of the HDL file 120 shown in FIG. 4 corresponding to the current sub-block to be separately simulated to determine sub-block's external ports. Then step 176 creates an HDL test bench for the current sub-block with an internal port corresponding to each of the sub-block's external ports.
  • This test harness also includes HDL clock control code (shown as step 330 of FIG. 12), and HDL code for making FLI calls to the sub-block's slave program 147A, shown in FIG. 4. These calls will be used to communicate between the simulation of the given sub-block and the rest of the parallel simulation.
  • step 178 of the configuration program creates and saves a data structure indicating number of sub-block slave programs, the wire values tables for each of them, and the block wiring table 200 and wire values tables 194, both shown in FIG. 4, required for the operation of the master program 150.
  • FIG. 6 is a highly simplified pseudo-code description of the setup routine 156 which is run before the start of a given simulation previously configured by the code of FIG. 5 to enable to the system 130 to execute such a parallel simulation.
  • the setup routine performs separate iterations of a loop 202 for each block to be separately simulated in the parallel simulation, including the top block.
  • This loop is comprised of the steps 204 through 212.
  • Step 204 causes an instance of the HDL simulation program to be run on each slave computer on which a block is to be simulated. If two or more blocks are to be simulated on a given computer, as is shown in FIG. 8, then two or more corresponding instances of the program are started on that computer.
  • Step 206 load HDL test bench code 140 or 140A for the given block to be simulated by a particular instance of the simulation program into the computer running that instance of the simulation program.
  • step 208 creates an corresponding instance of the non-HDL slaveProgram 147 or 147A, shown in FIG. 4, for the given block on its associated slave computer 132B or 132C.
  • step 210 downloads the block's specific wire values tables, created in 178 of the configuration routine, to the given block's slaveProgram.
  • step 212 instructs the given block's slaveProgram to initialize and run simulation of its block's test bench 140 or 140A shown in FIG. 4.
  • FIGS. 9 through 13 provide a relatively detailed description of the operation of the system's parallel simulation. Before starting such a detailed discussion a brief overview of this process will be described with reference to FIG. 4.
  • the simulation of the top block 138 is driven by the external test bench 140 shown in FIG. 4.
  • the clocking and inputs provided by this external test bench which drives the simulation, just as it were driving a serial simulation of the actual top block.
  • the input and output ports of all blocks which can be separately simulated, including the top block are all clocked ports which respond to data only on rising clock edges.
  • each slave program 147 or 147A When the master program 150 receives an indication that the top block's test bench 140 has generated a rising clock edge, it sends a rising edge signal to each slave program 147 or 147A, which relays this information to each separate HDL simulation 136. After receiving this rising clock edge message, each separate simulation latches the input port values previously supplied to wire values table 149 of its associated slave program by the master program. Each simulation will then produce any changes in it output port values caused by the latching of such inputs, once it has had time to simulate all of the logic involved in the generation of such responses.
  • the master program When the master program receives such a falling edge signal, it sends a falling edge message to each slave program. This message contains the values of all port connected to the slave program's associated HDL block which were calculated in response to the previous rising edge.
  • each slave When each slave has received such a message containing port values and placed those port values in its wire values table 149, it sends a message to the master saying that it is done processing the falling clock edge.
  • the master program has received such messages from all slave programs it will be again ready to start another clock cycle by responding to the external test benches next rising edge.
  • FIG. 10 illustrates the dummy HDL code created for the top block of the circuits simulation, the topBlockHDL code 138.
  • This code includes a main loop 280 which is repeated during the successive clock cycles of the simulation of the top block.
  • step 282 and 284 cause an externalClockFallingEdge FLI call to be made to the topBlockSlaveProgram 147, shown in FIG. 4.
  • This call will not return until the topBlockSlaveProgram receives a fallingEdgeAIIDone message from the masterProgram 150 of FIG. 4.
  • This fact is used to cause the clocking of the top block by its external test bench to remain synchronized with the rest of the parallel simulation, since the serial simulation of the top block within that test bench cannot advance until this call returns.
  • FIG. 11 illustrates topBlockSlaveProgram 147, the slave program 147 shown in FIG. 4 for the HDL simulation of the top block.
  • This slave program has a main loop 300 which is repeatedly executed for each clock cycle of the parallel simulation.
  • steps 302 and 304 send an externalClockFallingEdge message to the masterProgram.
  • FIG. 9 illustrates the masterProgram's main loop 158.
  • this main loop gets this externalClockFallingEdge message from step 304 of the topBlockSlaveProgram, its step 220 causes steps 222 and 224 to be performed.
  • Step 222 sets the master program's extemalClock variable 223, shown in FIG. 4, to 0, representing the lower half of the clock cycle.
  • step 224 sends a wireValue message to each slaveProgram 147 or 147A, shown in FIG. 4, including the topBlockSlaveProgram, with each such message containing the value of each port which provides an input to block associated with the slaveProgram to which it is sent.
  • Steps 306 through 310 of FIG. 11 and steps 352 through 358 of FIG. 13 show the responses of the topBlockSlaveProgram and each subBlockSlaveProgram to such wireValue messages.
  • each slave program receives such a message, it stores the port values it contains in the slave program's wire values table. If the slaveProgram is a sub-block slave program, it sets the slaveProgram's masterClock variable 152 shown in FIG. 4, to 0 to represent that a failing edge is being processed, and then the slaveProgram sends a fallingEdgeDone message to masterProgram, indicated that the slave is done processing the falling edge.
  • steps 226 and 228 will set a fallingEdgeDone flag 229, shown in FIG. 4, corresponding to the slaveProgram from which the message came.
  • steps 230 and 232 of FIG. 9 cause a fallingEdgeAIIDone message to be sent to the topBlockSlaveProgram.
  • topBlockSlaveProgram when the topBlockSlaveProgram receives this fallingEdgeAIIDone message, its steps 312 and 314 cause it to return from the topBlock's externalClockFallingEdge FLI call made by step 284 of FIG. 10. As is indicated in steps 286 and 288 of FIG. 10, when this call returns to the topBlock HDL code, the simulation of the topBlock's response to the falling edge generated by its external test bench is complete, and the simulation of the topBlock's HDL code returns program control to the external test bench. At this time the simulation of the falling edge will be complete for the entire HDL circuit, and the parallel simulation is ready to start simulating the entire circuit's response to the next rising clock edge.
  • steps 290 and 292 cause an extemalClockRisingEdge FLI call to be made to the topBlockSlaveProgram.
  • This call will contain all of the input port values which the topBlock has latched from its test bench upon receipt of the rising edge from that external test bench.
  • This FLI call will not return until the topBlockSlaveProgram receives a risingEdgeAIIDone message from masterProgram, indicating the entire parallel simulation is done responding the rising clock edge.
  • the clocking of the top block's external test bench stays synchronized with the entire parallel simulation's processing of the positive clock edge.
  • Step 236 sets the masterProgram's extemalClock variable 223, shown in FIG. 4, to 1 , indicating that a positive edge is being processed.
  • Step 240 stores top block's input port values received in the externalClockRisingEdge message in the masterProgram's wire values table 149 shown in FIG. 4.
  • steps 242 and 244 of the masterProgram send a imasterClockRisingEdge message to each subBlockSlaveProgram.
  • FIG. 12 shows the HDL code of each subBlockTestBench which is generated by the system to drive the separate simulation of each separately simulated sub block.
  • This code includes a main loop 324 which is iterated for each clock cycle of the simulation. It also includes clock generator code indicated at step 330.
  • Step 328 makes a subBlockFallingEdge FLI call to the test bench's associated subBlockSlaveProgram. This call will not return until the master clock of that slave program is set to one, since, in the positive clocked logic used with the embodiment of the invention being described, neither the HDL code of each sub-block nor the HDL code of each such block's test bench have any functions to perform during the negative part of the simulated clock cycle except to wait for the next positive edge.
  • FIG. 13 shows, when such a subBlockFallingEdge FLI call is made to the subBlockSlaveProgram, that program's step 360 will cause the subBlockSlaveProgram to wait in a step 362 until a masterClockRisingEdge message is received from the masterProgram.
  • step 362 When the next masterClockRisingEdge message is received, step 362 will cause steps 364 and 366 of FIG. 13 to be performed.
  • Step 364 sets the subBlockSlaveProgram's masterClock variable to 1 , and step 366 returns from the subBlockFallingEdge FLI call previously made by step 328 of the subBlockTestBench of FIG. 12.
  • step 330 of that figure causes the slaveBlockTestBench's internal clock to generate one complete clock cycle. It does this by causing the test bench to generate a clock value of one after a first simulated period, PERIOD1 , and then after a second subsequent simulated period, PERIOD2, to generate a clock value of zero.
  • step 332 of FIG. 12 will cause steps 334 through 342 to be executed.
  • Step 334 makes a subBlockRisingEdge FLI call to the corresponding subBlockSlaveProgram.
  • subBlockSlaveProgram when the corresponding subBlockSlaveProgram receives this call, it communicates the value of all the subBlock's input ports contained in the slave program's wire values table to the sub-block's test bench, and then it returns to the test bench.
  • step 336 places each such input port value on the corresponding wire, or internal port of the test bench. Then step 338 sends a rising edge to the sub-block being simulated within the test bench.
  • Step 374 writes the sub-block's output values to the slave program's wire values table, and step 376 sends a risingEdgeDone message to the masterProgram, which includes all of the output values generated in response to the rising edge by the sub-block.
  • Step 246 When the masterProgram of FIG. 9 receives a risingEdgeDone message from a given subBlockSlaveProgram its step 246 causes steps 248 and 250 to be performed.
  • Step 248 stores the sub-block output port values received in the message in the masterProgram's wire values table.
  • Step 250 sets a risingEdgeDoneFlag 251 , shown in FIG. 4, corresponding to the subBlockSlaveProgram from which the message came.
  • steps 252 and 254 send a risingEdgeAIIDone message to the topBlockSlaveProgram.
  • topBlockSlaveProgram when the topBlockSlaveProgram receives such a risingEdgeAIIDone message, it steps 320 and 322 return from the topBlock's externalClockRisingEdge call.
  • step 292 of FIG. 10 When the externalClockRisingEdge call in step 292 of FIG. 10 returns, the simulation of the performance of top block in response to the last rising edge clock signal from its external test bench is complete, and steps 294 and 296 of FIG. 10 return program execution to the external test bench, enabling it to advance to the generation of the next clock edge.
  • FIG. 14 is another schematic representation of the parallel computer system 130 shown in FIG. 4.
  • the features shown in FIG. 14 are slightly different than those shown in FIG. 4, because FIG. 14's emphasis is on the user interfaces 400 which are included in each of the instances of the HDL simulation programs 136 used in the parallel simulations.
  • the user interface 400 is a compete interface, including software for creating graphical user interface windows 402. These windows provide interface capabilities for selective single stepping, the setting of breakpoints, and the display of the logic states of selected ports associated with an HDL block being simulated.
  • the system 130 is configured to have the user interface of each separate simulation sends the information necessary to generate its graphical interface window 402 through the computer network 134 to the display monitor 404 of the master computer 132A. When input is supplied to any such interface window 402 through the master computer's keyboard 406 or mouse 408, the corresponding information is relayed through the network to the debug interface of the corresponding HDL simulation.
  • the output on all the user interface windows 402 will be synchronized.
  • the user is free to use the user interface of any simulation to stop the entire simulation process, either by single stepping or setting a breakpoint. This is because, as is indicated above, the stopping of any simulation will prevent all other simulations from advancing to the processing of the next clock edge.
  • FIG. 15 show one method 500 of creating the system 130 described above. This method involves the step 502 of purchasing or otherwise obtaining rights to use the HDL simulation software 136 from an entity 138 which sells it.
  • step 504 of obtaining parallelization software 506 from an entity other than the company 138.
  • the parallelization software 506 would include the master program 150 described above, which includes or creates all of the code and data structures needed to perform parallel simulation with the HDL simulation software 136. This software could be obtained either by purchasing it or writing it.
  • step 508 is performed, which includes the running of the master program so as to perform parallel simulation with combination of the HDL simulation software and the parallelization software.
  • FIG. 16 illustrates that one aspect of the present invention includes the method of performing both serial and parallel simulations upon the same HDL circuit design using the same test bench.
  • the HDL simulation software 136 can be used to perform a standard serial simulation upon an HDL circuit design, which simulates the circuits top block 138A, complete with all its sub-blocks, within a test bench 140 on one computer, the computer 132D shown in FIG. 16.
  • the user can also perform a parallel simulation of the same circuit on the parallel system 130 described above, using the same test bench 140.
  • synchronization of the parallel simulation could be achieved by using a distributed synchronization scheme rather than by using a master program.
  • distributed synchronization schemes include the use of time stamps or time barriers.
  • the present invention could be used on many different types of computers, using many different operating systems and communication schemes. For example, it is not limited to use on so-called shared nothing computers, that is, one parallel computers where each separate processor is part of a separate fully-independent computer connected by a network.
  • the invention can also be run on other types of multiprocessor systems, including ones using symmetric multiprocessing.
  • many aspects of the invention do not require that communication between separate simulation processes be carried out over a computer network.
  • communication between separate simulation processes could be carried out through shared memory, or interprocess communication schemes. It would be possible in some situations for some simulation processes to communicate in one manner and other simulations processes to communicate in a different manner.
  • the invention could be used to simulate a circuit on a network of computers, each of which is a symmetric multiprocessing computer.
  • the separate simulations running on the separate processors of each symmetric multiprocessing computer might communicate through shared memory, but processes running on different SMP computers might communicate over a network.
  • the simulator program used is a serial program which provides no support at all for parallel processing of its functions.
  • the simulator program could itself be a partially or completely parallel program.
  • Some aspects of the invention relate to the fact that the parallelization code comes from a different source than the simulation code, i.e., that the code which allows parallel instances of a simulation program to operate together as part of a larger simulation comes from a separate source than the simulation program itself.
  • Other aspects of the invention do not rely on this distinction, and, thus, some aspects of the invention cover parallelization code which comes from the same source as the simulation program, and even embodiments of the invention in which the parallelization code has been directly incorporated into the simulation code.
  • HDL simulation processes used are instances of one simulation program. In other embodiments of the invention different HDL simulation processes could be instances of different HDL simulation programs, possibly even coming from different vendors.
  • the language interface used to interface between the HDL code and the non-HDL parallelization code running on the same processor uses FLI calls.
  • PLI calls could be used instead.
  • other language interface methods for communicating between the HDL and non-HDL code For example, the MTI interface, which lets non-HDL code call HDL code, could be used as such a language interface.
  • non-HDL parallelization code such as that used in the slave programs was C or C++ code. It should be understood that in other embodiments of the invention the parallelization code could be written virtually any computer language.
  • test benches In the description above the non-HDL master and slave programs form a part of the complete test bench which drives each separate simulation. In all of the test benches described above, however, the part of the test bench which actually directly interfaces with the block being simulated is written in HDL. It should be understood, however, that none of the test benches used in alternate embodiments of the invention need contain any HDL code, since most HDL simulators support entirely non- HDL test benches. It should also be understood that one can practice many aspects of the invention without creating the dummy top block 138 shown in FIG. 4. Instead test benches created for each sub-block could collectively supply all of the inputs needed to drive the simulation.
  • FLI calls could be inserted into the internal ports of a test bench designed to drive the simulation of a circuit's top block. Such calls would communicate port values and synchronization information much like the FLI calls in the dummy top block 138 described above. The insertion of such FLI calls into the top block's test bench could be done automatically by code similar to that described above which is used to create the dummy top block 138.
  • the embodiment of the invention described above is designed to simulate HDL designs in which all latching is done on a rising clock edge. It should be appreciated that after reading this disclosure those skilled in the art would understand how the system described above could be extended to simulate HDL logic using more complicated clocking schemes, such as those in which some logic latches input values on rising clock edges and some logic latches input values on falling clock edges. Similarly, other embodiments of the invention could be created which did not require that all separately simulated sub-blocks have clocked input and output ports. Also, other embodiments of the invention can be created which simulate time at substantially finer time intervals than the system described above, which simulates time at the resolution of just one rising and one falling edge per clock cycle.
  • the user selects which sub-blocks are to be simulated on which processors using a graphical user interface.
  • the system could automatically decide which sub-blocks are to be simulated on which processors as a function of the complexity of block.
  • a user could code into the various test benches and slave programs information about which sub-blocks are to be simulated on which processors.
  • Alternate embodiments could also include code for keeping track of which sub-blocks are taking the longest to complete there response to each clock cycle and use this information to decide which sub-block should be separately simulated and which sub-blocks should be simulated on separate processors so as to cause the overall simulation to progress at the fastest rate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

HDL circuit designs are simulated in parallel by running multiple instances of a stand alone HDL simulation program. Each instance simulates a sub-block of a larger HDL design within a test bench, and the separate test benches communicate port values and clock synchronization information to create a parallel simulation of the larger HDL design. Preferably software parses the HDL description the larger circuit so it can determine and then display the hierarchy of sub-blocks within that design. A user can then select which sub-blocks are to be separately simulated. The system then parses the HDL description of each such sub-block to find its input and output ports. The system generates a test bench to drive the simulation of each separately simulated sub-block. Each such test bench includes internal ports corresponding to, and connected to, the external ports of its sub-block, and instructions for communicating the values of those ports and clock synchronization information with the simulation of other sub-blocks. Each such test bench can have two parts, a test bench written in HDL; and a non-HDL parallelization program. These two parts can communicate port values and synchronization information using an language interface, such as FLI or PLI. The parallelization code of different simulations can communicate with each other through a master program which synchronizes the operation of all the simulations. In many embodiments the simulation program is a serial VHDL or Verilog simulation program purchased from one vendor and the parallelization code is obtained from a separate source.

Description

SYSTEM FOR PERFORMING PARALLEL CIRCUIT SIMULATION IN A HIGH LEVEL DESCRIPTION LANGUAGE
Field of the invention
The present invention relates to the simulation of circuit designs which are specified in a high level description language such, as VHDL and Verilog, and, in particular, to a system for performing such simulations in parallel so as to increase the speed at which such simulations can be performed.
Background of the invention
As the miraculous advances in microelectronic technology have made it possible to put more and more electronic components onto an integrated circuit, integrated circuits have become increasingly complex. As a result the job of designing such circuits has become increasingly difficult.
On of the major ways in which circuit designers have been able to keep pace with this increasing complexity is the advent of high level description languages, or "HDLs". These languages allow a designer to describe a circuit at a high level using a description language which is somewhat like a high level computer programming language. The two most common high level description languages are VHDL and Verilog. VHDL stands for VHSIC High Level Description Language, where VHSIC is an acronym for the DARPA funded Very High Speed Integrated Circuit program of the 1980's. VHDL was developed with the assistance of DARPA to help the U.S. semiconductor industry deal with the problem of how to design increasingly complex integrated circuits. Verilog was developed by a private company for similar purposes.
Both VHDL and Verilog provide a computer language in which a circuit designer can describe a circuit either in terms of the behavior of the circuitry, i.e., what information various of its components communicates at what time, or the structure of the circuit, i.e., what its inputs and outputs are, what its sub-components are, and how it is connected to those sub- components. These description languages also allow more detailed, gate- level, description of a circuit to be designed.
Programming exists which can take an HDL description of a circuit and automatically create a layout of the circuit and photolithographic masks for use in creating an actual chip embodying the circuit. This greatly reduces the amount of human effort required to produce an integrated circuit.
Another benefit of high level description languages is that once a circuit has been described in an HDL, programming exists which can simulate the operation of that circuit. This is extremely beneficial since it allows a circuit designer to catch almost all of his design errors before the expensive steps are taken of actually producing photolithographic masks and producing and testing physical integrated circuits using the design. As a result of such HDL simulation programs, it is common for very complex circuits having hundreds of thousands or millions of components to work as intended the first time they made.
Such HDL simulation program are provided by several commercial vendors, including
Mentor Graphics 8005 S.W. Boeckman Rd., Wilsonville, Oregon 97070 or
Model Technology, 10450 SW Nimbus Avenue, Bldg. R, Portland, Oregon
When a circuit is tested by an HDL simulator it is placed inside a "test harness" or "test bench". Such a test bench is computer code, either written in HDL or some other computer language such as C or C++ which simulates providing the inputs necessary to test the HDL circuit designs behavior.
Current HDL simulators work very well. They have debugging interfaces which allow a user to single step through the simulated performance of the circuit, or to set breakpoints at which continuous simulation will stop. They allow users to see the logic values of selected lines at various times during the simulated performance of the chip. One of the major limitations of current HDL simulation is its relatively slow speed. This is not surprising considering the complexity of many of the circuits being simulated. It would be very desirable to be able to more rapidly simulate complex circuits. This would speed up the rate at which proposed circuit designs could be tested and, thus, significantly speed up their performance. This is particularly true since proper simulated testing of most complex circuits require driving the simulated circuit through a large number of simulated inputs.
The desire to increase the speed of circuit simulation has existed for many years. Parallel processors have been used in the prior art as one way to increase the speed of circuit simulations. But for some reason most of the major HDL simulators have not been parallelized, perhaps because of the major amount of work which it was believed would be required to make such software operate on multiprocessors.
Summary of the invention
It is an object of the present invention to provide a method and/or system of increasing the speed of HDL simulation.
It is a further object of the present invention to provide a method and/or system of increasing the speed of such HDL simulation which does not require expensive rewrites of commercially available serial HDL simulation software.
It is yet another object of the present invention to provide a method and/or system of increasing the speed of HDL simulation which can run on networked serial computers.
According to a first aspect of the invention a computerized method of simulating HDL circuit designs is provided. The method includes running multiple instances of an HDL simulation program, each of which is capable of simulating an HDL block in a test bench without other simulation software. The Method has each instance of the simulation program simulate an HDL sub-block of a larger HDL design within a test bench, and has the test benches communicate port values and clock synchronization between themselves, so the simulation of the separate sub-blocks function to create a parallel simulation of the larger HDL design.
In some embodiments of this first aspect of the invention, the method executes software which parses the HDL description of each separately simulated sub-block to find the external ports of each such sub- block. The method then generates computer code which defines the test bench with which each such sub-block is separately simulated. The computer code generated for each test bench includes internal ports corresponding to, and connected to, the external ports of its associated sub-block. The code generated for each such test bench also includes instructions for communicating the values of those ports and clock synchronization information with the simulation of other sub-blocks. In many such embodiments, each test bench generated by the method has two parts, a test bench written in HDL; and non-HDL parallelization code. The HDL test bench and the non-HDL parallelization code communicate port values and synchronization information using a language interface provided in HDL to support communication between HDL and non-HDL code, and the parallelization code relays such information with the parallelization code associated with other HDL sub-blocks. In many embodiments the separate non-HDL parallelization code associated with separate HDL sub-blocks communicate with each other through a master program running on one processor. In some embodiments, each separate instance of the HDL simulation program includes a user interface which allows a user to monitor and control the simulation of an HDL block by each such instance of that program, if desired.
According to a second aspect of the invention a computerized method is provided for simulating HDL circuit designs composed of a plurality of HDL sub-blocks. The method comprises responding to a selection by a user of which of a given design's sub-blocks have been selected for separate simulation on different processors by parsing the HDL code of each such selected sub-block to determine its external ports. Then the method automatically creates a test bench to drive a separate simulation of each such selected sub-block, with the test bench created for each selected sub-block having interfaces for communicating the value of the sub-block's external ports and clock synchronization information between the sub-block and the simulation of other selected sub-blocks. Once the test benches have been created, the method runs a separate instance of an HDL simulation program for each selected sub-block and its associated test bench.
In some embodiments of this second aspect of the invention the method further includes first parsing HDL code of the HDL circuit design to determine the hierarchy of HDL sub-blocks defined by the design; providing the user with a graphic representation of the sub-block hierarchy; and then allowing the user to make the selection of which sub-blocks are to be selected for separate simulation by using a point and click interface.
In some embodiments of this second aspect of the invention information obtained in a parse of the HDL code of the circuit is used to generate an HDL dummy top-block which has ports corresponding to the external and internal ports of the top block in the HDL circuit design. This dummy top-block includes code for communicating the values of each of the top block's external ports between a test bench created to drive the simulation of the top block and corresponding ports of individual test benches generated by the method to drive the simulation of the selected sub-blocks.
According to a third aspect of the invention a computerized method of simulating HDL circuit designs is provided which includes running multiple instances of an HDL simulation program, each capable of simulating an HDL block in a test bench without other simulation software. Each instance of the HDL simulation program is used to simulate an HDL sub-block of a larger HDL design. The simulation of each separately simulated sub-block uses a language interface supported by the HDL simulation program to allow communication between the HDL and another programming languages. It uses this language interface to communicate port values and clock synchronization information between the HDL simulation of each sub-block and non-HDL parallelization code running on the same processor. The parallelization code associated with simulations running on different processors is used to communicate such port values and clock synchronization information between the separate simulations.
In some embodiments of this third aspect of the invention the simulation of individual sub-blocks includes performing gate level logic simulation which calculates gate level delays associated with the propagation of signals though logic gates in the simulated circuitry of the sub-blocks. In such embodiments the external output ports of the separately simulated sub-blocks are the outputs of clocked latches in the HDL circuit design, so that their values only change at the time of clock signals during simulation. The communication of port values over the language interface does not simulate gate level signal delays.
In such embodiments, synchronization of separate simulations is controlled by having each HDL simulation make a call using the language interface to the non-HDL parallelization code running on the same processor. This call does not return until the non-HDL parallelization code receives information derived from the parallelization code on other processors that the simulations of all the sub-blocks of the larger HDL design being simulated are ready to advance to simulation of a subsequent clock event. The instances of the non-HDL parallelization code on different processors can be slave programs which communicate with others through a master program running on one processor. This master program can be used to instruct the separate instances of the parallelization code when to the returns from such call, so as to allow the separate HDL sub-block simulations to advance to simulation of a subsequent clock event. This decision by the master program can be made by having each slave program sends a message to the master program when its associated HDL simulation is done simulating its response to a given clock signal. The master program can then send the instruction to each slave program to return from such a call once the master program has received such a done message from each slave program participating in the simulation of the HDL circuit for the previous clock signal. According to a fourth aspect of the invention a computerized method of simulating HDL circuit designs includes the following: running multiple instances of an HDL simulation program, each of which is capable of performing an independent simulation of an HDL block; having each instance of the simulation program simulate an HDL sub-block of a larger HDL design within an HDL test bench; and having the HDL test benches communicate port values and clock synchronization between themselves using an HDL language interface supported by the simulation program, so the simulations of the separate sub-blocks by separate instances of the simulation program function to simulate the larger HDL design.
In some embodiments of this fourth aspect of the invention the HDL code of the circuit design to be simulated is parsed to determine the external port connections of each sub-block being separately simulated. Then the method generates a separate HDL test bench for each sub-block. Each such test bench has an internal port for each of its sub-block's external ports, and code for making calls with an HDL language interface supported by the simulation program to non-HDL code running on the same processor which communicates the value of those ports with the test benches generated for the other separately simulated HDL blocks. In some such embodiments synchronization between the separate test benches is achieved by having language interface calls to the non-HDL code not return until all the test benches separately simulating sub-blocks have indicated that they have completed their response to a previous clock event. According to another aspect of the invention the multiple instances of an HDL simulation program are instances of a commercially available HDL serial simulation program, each of which is capable of simulating an HDL block in a test bench without other simulation software. Each instance of this simulation program perform a serial simulation of a sub-block of a larger HDL design within a test bench on the same processor as that instance. At least a part of the test bench is additional software, which is not part of the commercially available simulation program. This additional software communicates port values and clock synchronization between the test benches associated with different sub-blocks. In some such embodiments the commercially available HDL simulation program does not include programming which enable different processors connected by a computer network to simulate an HDL circuit by using different processors to simulate different parts of the circuit, but the additional software provides the functionality to necessary to enable separate instances of the HDL simulation program to communication with each other over a computer network and operate in parallel to simulate the different parts of an HDL circuit description. According to another aspect of the invention the HDL simulation program is produced by one legal entity, and the part of the test bench which communicates port values and clock synchronization information is additional software is produced by a different legal entity.
According to yet another aspect of the invention a method of simulating HDL circuit designs includes the following: running multiple instances of an HDL simulation program, each of which is capable of simulating an HDL block in a test bench on separate processors; dividing the design into sub-blocks having only clocked external ports; simulating the separate sub-blocks on separate instances of the simulation program running on separate processors with individual instances of the simulation program calculating gate level delay times within the part of the HDL circuit design represented by its associated sub-block; having parallelization software run on each processor running an instance of the simulation program which synchronizes clock times between the separate simulations; and having the parallelization software communicate the external port values of the separately simulated sub-block at the synchronized clock times without gate delay information.
Other aspects of the invention include computer systems or programming recorded in machine readable media capable of performing operations similar to those described above. Description of the drawings
These and other aspects of the present invention will become more evident upon reading the following description of the preferred embodiment in conjunction with the accompanying drawings, in which FIG. 1 is a schematic representation of a hypothetical integrated circuit, illustrating the hierarchy of blocks within such a circuit;
FIG. 2 is a representation of the hierarchy of blocks within the circuit of FIG. 1 ;
FIG. 3 is a partial representation of an HDL description of the circuit shown in FIG. 1 ;
FIG. 4 is a schematic block diagram of a multi-processor computer system which is capable of performing parallel simulations of an HDL circuit description using many aspects of the present invention;
FIG. 5 is a highly schematic pseudo-code description of that part of the master program shown in FIG. 4 which configures the software and data structures necessary to cause the system shown in FIG. 4 to run a given parallel simulation;
FIG. 6 is a highly simplified pseudo-code description of that part of the master program shown in FIG. 4 which sets up the system shown in FIG. 4 to run a parallel simulation previously configured by the code shown in FIG. 5;
FIG. 7 is a simplified illustration of a computer screen display which is generated by the programming of FIG. 5 to enable a used to select which sub-blocks of an HDL circuit design are to be separately simulated; FIG. 8 is a schematic block diagram similar to that of FIG. 4, used to illustrate what happens if multiple sub-blocks are to be separately simulated on one processor;
FIG. 9 is a highly simplified pseudo-code description of that part of the master program shown in FIG. 4 which operates during the actual parallel simulation performed by the system of FIG. 4 so as to communication port values between the separate simulations and synchronize their operation; FIG. 10 is a highly simplified pseudo-code description of the HDL imitation, shown in FIG. 4, of the top block of the circuit being simulated, which imitation top block is designed to be simulated within an external test bench written to drive the simulation of the actual top block of the circuit and is designed to communicates values from the external test bench to the rest of the parallel simulation;
FIG. 11 is a highly simplified pseudo-code description of the imitation top Block's non-HDL slave program, shown in FIG. 4, which runs on the same processor as the simulation of the imitation top block shown in FIG. 10, and which is used to communicate port values and synchronization information between the simulation of the imitation top block and other parts of the parallel simulation;
FIG. 12 a highly simplified pseudo-code description of the HDL test bench, shown in FIG. 4, which is generated by the configuration code of FIG. 5 to drive the simulation of each separately simulated sub-block in the parallel simulation;
FIG. 13 a highly simplified pseudo-code description of a non-HDL sub-block slave program, shown in FIG. 4, which runs on the same processor as an associated separate sub-block simulation, and which is used to communicate port values and synchronization information between the separate processes of the parallel simulation;
FIG. 14 is an alternate schematic block diagram of the system shown in FIG. 4, which illustrating how the separate user interfaces of each separate instance of the simulation program can be used on one computer screen to control and observe the operation of the parallel simulation;
FIG. 15 is a highly schematic illustration of a method by which one can create a parallel simulation system similar to that shown in FIG. 4 by purchasing simulation software from one entity and then obtaining parallelization code produced by another entity; FIG. 16 is a highly schematic illustration of a method of developing an HDL design for a circuit and its test bench, including performing serial simulation of the circuit and its test bench and then performing a parallel simulation on the circuit using the same simulation program and the same test bench.
Detailed description of preferred embodiments FIG. 1 is a schematic representation of an integrated circuit 100.
This circuit, as are most integrated circuits of any complexity, is made up of a hierarchical arrangement of components or "blocks". In FIG. 1 the entire circuit 100 is labeled B1. Thus, B1 is the top, or highest, block of this circuits hierarchy of blocks, and, as such, it represents the entire circuit. In FIG. 1 the top block B1 includes 5 sub-blocks, including four identical sub- blocks B2, B3, B4, and B5, and one additional, but differently designed sub-block B6. Sub-block B2 includes sub-blocks B8 through B11. Sub- block B3 includes sub-blocks B13 through B16. Sub-block B4 includes sub-blocks B18 through B21 , and sub-block B5 includes sub-blocks B23 through B26. Sub-block B6 is not shown as having any sub-blocks in FIG. 1.
FIG. 2 represents the hierarchy 110 of block and sub-blocks shown in FIG. 2. It should be understood that in many circuits the hierarchy of circuit blocks extends much deeper than the three levels shown in FIGS. 1 and 2.
Representing circuits as a hierarchy of blocks has many advantages. It allows the top level of an entire circuit or of a sub-block to be described in terms of a relatively small number of relatively complex components, thus simplifying the top level description of circuits or sub- blocks. It allows multiple identical components to be defined by reference to a common description. In addition, it facilitates the reuse of circuit components from earlier designs, since it allows the incorporation of previously defined elements merely by referencing them, and copying or including their previous description. FIG. 3 is a part of an HDL description file 120 for the circuit 100 shown in FIG. 1. This partial description is in the VHDL language. This code includes entity declarations 122A, 122B, and 122C which declare the blocks B1 , B2, and B3 shown in FIG. 1. Note that each such entity declaration includes a listing of all of each block's ports, that is, its inputs and outputs. The HDL description also includes an architecture structure statement 124 for the top block B1 of the circuit of FIG. 1. This statement lists each sub-blocks of which the block B1 is made with an "entity work" statement 126, several of which are shown in FIG. 3. Each entity work statement includes a "port map" statement which includes a mapping of the ports of each of B1 's sub-blocks to the ports of B1 itself.
An HDL circuit description normally includes much more than the few lines shown in FIG. 3, as is indicated by the ellipses contained in that figure, and HDL circuit descriptions can describe their components and connections with different constructs than those shown in FIG. 3, but FIG. 3 show that HDL code can shows the hierarchical structure of a circuit design and the interconnection of the ports of the circuit block and sub-blocks of such a design. FIG. 4 illustrates a system 130 which performs parallel HDL simulations using one embodiment of the present invention. In this embodiment, a plurality of instances of a serial HDL simulation program are run on different computers 132, of which the computers 132A, 132B, and 132C shown in FIG. 4 are examples. Each of these computers has a network interface 133 which enables it to communicate with other computers of the system through a computer network 134.
A plurality of the system computers (computers 132B and 132C in FIG. 4) each run and instance of an HDL simulation program 136. One of these computers, computer 132B in FIG. 4, simulates a dummy HDL block 138, which has external ports 139 and internal ports 141 corresponding, respectively, to all of the external and internal ports of the top-block of the entire HDL circuit which is being simulated by the multiple computers of the system 130. The top block 138 is simulated inside a test bench 140 identical to that which could be used to perform a normal serial simulation upon the HDL code of the real top block of which the dummy top-block 138 is an imitation. This external test bench has internal ports 143 which correspond to all of the external ports of the HDL top block 138, and which deliver simulated inputs to, and receive simulated output from, the top block's ports.
In FIG. 4 the top block's test bench is shown as an HDL test bench, but other types of test benches could be used as well. The HDL top block 138 shown in FIG. 4 is a "dummy" in the sense that its simulation on the computer 132B does not include the simulation of the sub-blocks of which it's design is composed, as would normally be the case. Instead those sub-blocks are separately simulated on other computers 132C and the inputs and outputs which the top block provides to those sub-blocks are communicated through HDL calls through a language interface 145 to a non-HDL slave program 147, as will be explained below.
Although only one computer 132C is shown in FIG. 4, the elipses
142 are meant to indicate that the system 130 includes other such computers, as is shown FIG. 14. Each of the computers 132C includes an instance of the HDL simulation program 136 which simulates a separate sub-block 144 of the top block 138. Each such HDL sub-block is simulated within a sub-block test bench 140A written in HDL code.
It should be noted that the external test bench 140 performs the function normally associated with the phrase "test bench" in that it drives the simulation by provided test input values and clock signals. The sub- block test benches 140A act as test benches only in that they drive the simulation of separate sub-blocks, but they do not independently generate test vectors or timing signals. Instead they merely relay port values and timing information received from the external test bench through the dummy top block and received from the simulation of other sub-blocks
Each such test bench includes a set of internal ports 146 which supply input to and receive output from the external ports 148 of their associated HDL sub-block. The values communicated with the internal ports of the HDL test bench 140A are communicated to other parts of the parallel simulation through HDL calls through a language interface 145A to a slave program 147A which runs on the same processor as the test bench, but which is not part of the serial HDL simulation program 136. In the embodiment shown in FIG. 4 each sub-block slave program 147A, like the top block slave program 147 of the processor running the simulation of the top block is written in general purpose programming language like C or C++. Each of the slave programs 147 and 147A include instructions for receiving output values from, and supplying input value to, their associated top-block or sub-block. These values are temporarily stored by each slave program in a wire values table 149. Each slave program 147 and 147A receives the input values it sends to its associated simulation from, and sends the output values it receives from its associated simulation to, a master program 150 shown in computer 132A of FIG. 4. Each such slave program also communicates synchronization information with its associated simulation program and with the master program 150, as will be described in more detail below. This synchronization information includes the value of a master clock variable 152 shown in FIG. 4. The master program 150 includes a configuration routine 154, shown in more detail in FIG. 5, which responds to a users selection of which sub-blocks are to be separately simulated. It does so by automatically creating the test benches and data structures necessary to perform the parallel simulation of such sub-blocks. The master program also includes a set-up routine 156, shown in more detail in FIG. 6, which automatically prepares the system 130 to perform a parallel simulation.
In addition, the master program also includes a main loop 158 which operates during an actual parallel simulation to relay port values between the top-block and the various sub-blocks of such a parallel simulation, and to synchronized the separate serial simulations which make up such a parallel simulation.
FIG. 5 is a highly simplified pseudo-code representation the master program's config routine 154, mentioned above. This routine performs a step 160 which parses the HDL file 120, shown in FIG. 4, which describes the circuit to be to simulated. It performs this parse to determine the hierarchy of sub-blocks which form the top block to be simulated. As was illustrated above with regard to FIG. 3, HDL code is designed to explicitly show such hierarchy, and, thus, such a parsing process is relatively straight forward.
Once this parse has determine the sub-block hierarchy of the circuit to be simulated, step 160 display this hierarchy 110 of sub-blocks to user in a graphical user interface window 182 on a computer screen 184 shown in
FIG. 7, which is generated by the computer 132A on which the master program is run.
Next a step 162 records the user's selection of which one or more sub- blocks are to be assigned to each processor. The configuration routine includes code to allow the use to make such a selection by using a cursor 186 shown in FIG. 7 to drag the representation 190 of each of the HDL file's sub-blocks which he wants run on a separate processor to a graphical representation 192 of that processor in the GUI window 194. The motion of such a drag is illustrated in FIG. 7, by the dotted line 196 between the two images of the cursor 188.
In FIG. 7 the processor representation 192B has had two sub-blocks dragged into it. In such a case, the system will simulate each of these two sub-block 144 in a separate instance 136 of the HDL simulation program on a single processor 132C, as is indicated in FIG. 8. Each such simulation will be identical to the separate simulations shown in processor 132C of FIG. 4, except that there are two of them on one processor.
Once the user has made his selection of which sub-blocks are to be processed on which processors, the configuration routine performs steps 164-178 which configure the system to perform the specified parallel simulation.
Step 164 parses the HDL file of the top block of the circuit to be simulated to determine all of the top block's input and output ports. Then step 166 creates a dummy HDL topBlock 138, shown in FIG. 4, with the same external and internal ports as the original top block of the HDL file 120. Next step 168 creates code in the dummy HDL topBlock for FLI, or Foreign Language Interface, calls to the top block's slave program 147 shown in FIG. 4. The Foreign Language Interface is an interface which is provided as part of VHDL to enable VHDL code to make calls to routines which are written in other languages, such as C or C++. In Verilog versions of the invention the language interface used for such calls can be the PLI, or Programming Language Interface, which performs a similar function.
The FLI calls programmed into the dummy topBlock HDL code are designed to have that HDL code communicate the values of internal ports and synchronization information with the master program 150 shown in Fig. 4. Next step 170 creates a wire values table data structure with entries corresponding to top block's ports. This data structure will be used by the top block's slave program 147 shown in FIG. 4 once the parallel simulation starts.
Once all these preparations have been made for the simulation of the top block, step 172 performs an iteration of a loop comprised of steps 174 and 176 for each sub-block to be separately simulated.
Step 174 parses the portion of the HDL file 120 shown in FIG. 4 corresponding to the current sub-block to be separately simulated to determine sub-block's external ports. Then step 176 creates an HDL test bench for the current sub-block with an internal port corresponding to each of the sub-block's external ports. This test harness also includes HDL clock control code (shown as step 330 of FIG. 12), and HDL code for making FLI calls to the sub-block's slave program 147A, shown in FIG. 4. These calls will be used to communicate between the simulation of the given sub-block and the rest of the parallel simulation.
Once the loop 172 has been performed for each sub-block to be separately simulated, step 178 of the configuration program creates and saves a data structure indicating number of sub-block slave programs, the wire values tables for each of them, and the block wiring table 200 and wire values tables 194, both shown in FIG. 4, required for the operation of the master program 150.
FIG. 6 is a highly simplified pseudo-code description of the setup routine 156 which is run before the start of a given simulation previously configured by the code of FIG. 5 to enable to the system 130 to execute such a parallel simulation.
The setup routine performs separate iterations of a loop 202 for each block to be separately simulated in the parallel simulation, including the top block. This loop is comprised of the steps 204 through 212.
Step 204 causes an instance of the HDL simulation program to be run on each slave computer on which a block is to be simulated. If two or more blocks are to be simulated on a given computer, as is shown in FIG. 8, then two or more corresponding instances of the program are started on that computer.
Step 206 load HDL test bench code 140 or 140A for the given block to be simulated by a particular instance of the simulation program into the computer running that instance of the simulation program. Next step 208 creates an corresponding instance of the non-HDL slaveProgram 147 or 147A, shown in FIG. 4, for the given block on its associated slave computer 132B or 132C. Then step 210 downloads the block's specific wire values tables, created in 178 of the configuration routine, to the given block's slaveProgram. Finally step 212 instructs the given block's slaveProgram to initialize and run simulation of its block's test bench 140 or 140A shown in FIG. 4.
Once these steps have been performed, the system 130 is ready to execute the parallel simulation, and, thus, the master program 150 advances to its main loop 158 shown in FIG. 4, as is shown in greater detail in FIG. 9. FIGS. 9 through 13 provide a relatively detailed description of the operation of the system's parallel simulation. Before starting such a detailed discussion a brief overview of this process will be described with reference to FIG. 4.
In the embodiment of the invention shown in the figures, the simulation of the top block 138, and, thus, of the entire circuit, is driven by the external test bench 140 shown in FIG. 4. Thus, it is the clocking and inputs provided by this external test bench which drives the simulation, just as it were driving a serial simulation of the actual top block. Furthermore, in this embodiment the input and output ports of all blocks which can be separately simulated, including the top block, are all clocked ports which respond to data only on rising clock edges.
When the master program 150 receives an indication that the top block's test bench 140 has generated a rising clock edge, it sends a rising edge signal to each slave program 147 or 147A, which relays this information to each separate HDL simulation 136. After receiving this rising clock edge message, each separate simulation latches the input port values previously supplied to wire values table 149 of its associated slave program by the master program. Each simulation will then produce any changes in it output port values caused by the latching of such inputs, once it has had time to simulate all of the logic involved in the generation of such responses. Once all the responses of a given HDL block to the previous rising edge have been calculated, they will be communicated to the simulation's associated slave program, which will send all of the block's output port values to the master program as part of a message saying that its associated simulation is done responding to the rising edge. Once the master program has received such a message from each slave program, it will be ready to advance to the simulation of the subsequent falling clock edge generated by the top block's test bench.
When the master program receives such a falling edge signal, it sends a falling edge message to each slave program. This message contains the values of all port connected to the slave program's associated HDL block which were calculated in response to the previous rising edge. When each slave has received such a message containing port values and placed those port values in its wire values table 149, it sends a message to the master saying that it is done processing the falling clock edge. When the master program has received such messages from all slave programs it will be again ready to start another clock cycle by responding to the external test benches next rising edge.
Now the process will be explained in more detail with regard to FIGS. 9 through 13. FIG. 10 illustrates the dummy HDL code created for the top block of the circuits simulation, the topBlockHDL code 138. This code includes a main loop 280 which is repeated during the successive clock cycles of the simulation of the top block. When the topBlockHDL code receives a falling edge from its external test bench 140, shown in FIG. 4, step 282 and 284 cause an externalClockFallingEdge FLI call to be made to the topBlockSlaveProgram 147, shown in FIG. 4. This call will not return until the topBlockSlaveProgram receives a fallingEdgeAIIDone message from the masterProgram 150 of FIG. 4. This fact is used to cause the clocking of the top block by its external test bench to remain synchronized with the rest of the parallel simulation, since the serial simulation of the top block within that test bench cannot advance until this call returns.
FIG. 11 illustrates topBlockSlaveProgram 147, the slave program 147 shown in FIG. 4 for the HDL simulation of the top block. This slave program has a main loop 300 which is repeatedly executed for each clock cycle of the parallel simulation. When this slave program gets the externalClockFallingEdge FLI call from step 284 of FIG. 10, steps 302 and 304 send an externalClockFallingEdge message to the masterProgram.
FIG. 9 illustrates the masterProgram's main loop 158. When this main loop gets this externalClockFallingEdge message from step 304 of the topBlockSlaveProgram, its step 220 causes steps 222 and 224 to be performed. Step 222 sets the master program's extemalClock variable 223, shown in FIG. 4, to 0, representing the lower half of the clock cycle. Then step 224 sends a wireValue message to each slaveProgram 147 or 147A, shown in FIG. 4, including the topBlockSlaveProgram, with each such message containing the value of each port which provides an input to block associated with the slaveProgram to which it is sent.
Steps 306 through 310 of FIG. 11 and steps 352 through 358 of FIG. 13 show the responses of the topBlockSlaveProgram and each subBlockSlaveProgram to such wireValue messages. When each slave program receives such a message, it stores the port values it contains in the slave program's wire values table. If the slaveProgram is a sub-block slave program, it sets the slaveProgram's masterClock variable 152 shown in FIG. 4, to 0 to represent that a failing edge is being processed, and then the slaveProgram sends a fallingEdgeDone message to masterProgram, indicated that the slave is done processing the falling edge.
Returning to FIG. 9, when the masterProgram receives a fallingEdgeDone message from a slaveProgram steps 226 and 228 will set a fallingEdgeDone flag 229, shown in FIG. 4, corresponding to the slaveProgram from which the message came. Once a fallingEdgeDone flag has been set for each slaveProgram, steps 230 and 232 of FIG. 9 cause a fallingEdgeAIIDone message to be sent to the topBlockSlaveProgram.
As shown in FIG. 11 , when the topBlockSlaveProgram receives this fallingEdgeAIIDone message, its steps 312 and 314 cause it to return from the topBlock's externalClockFallingEdge FLI call made by step 284 of FIG. 10. As is indicated in steps 286 and 288 of FIG. 10, when this call returns to the topBlock HDL code, the simulation of the topBlock's response to the falling edge generated by its external test bench is complete, and the simulation of the topBlock's HDL code returns program control to the external test bench. At this time the simulation of the falling edge will be complete for the entire HDL circuit, and the parallel simulation is ready to start simulating the entire circuit's response to the next rising clock edge.
When the topBlock code of FIG. 10 receives the next rising edge from its external test bench, steps 290 and 292 cause an extemalClockRisingEdge FLI call to be made to the topBlockSlaveProgram. This call will contain all of the input port values which the topBlock has latched from its test bench upon receipt of the rising edge from that external test bench. This FLI call will not return until the topBlockSlaveProgram receives a risingEdgeAIIDone message from masterProgram, indicating the entire parallel simulation is done responding the rising clock edge. Thus, the clocking of the top block's external test bench stays synchronized with the entire parallel simulation's processing of the positive clock edge. When the topBlockSlaveProgram of FIG. 11 receives an externalClockRisingEdge call, its steps 316 and 318 cause an extemalClockRisingEdge message to be sent to the masterProgram. This message includes all input port values which the topBlock received from its test bench at the test bench's simulated rising edge.
When the masterProgram of FIG. 9 receives this externalClockRisingEdge message from the topBlockSlaveProgram, its steps 236 causes its steps 238 and 240 to be performed. Step 238 sets the masterProgram's extemalClock variable 223, shown in FIG. 4, to 1 , indicating that a positive edge is being processed. Step 240 stores top block's input port values received in the externalClockRisingEdge message in the masterProgram's wire values table 149 shown in FIG. 4.
When the masterProgram's extemalClock variable is 1 and all of its fallingEdgeDoneFlags 229 have been set, steps 242 and 244 of the masterProgram send a imasterClockRisingEdge message to each subBlockSlaveProgram.
FIG. 12 shows the HDL code of each subBlockTestBench which is generated by the system to drive the separate simulation of each separately simulated sub block. This code includes a main loop 324 which is iterated for each clock cycle of the simulation. It also includes clock generator code indicated at step 330.
When this clock generator code cause the test bench to generate a negative edge the test bench's internal clock will switch to zero state, and step 326 will cause steps 328 and 330 to be performed. Step 328 makes a subBlockFallingEdge FLI call to the test bench's associated subBlockSlaveProgram. This call will not return until the master clock of that slave program is set to one, since, in the positive clocked logic used with the embodiment of the invention being described, neither the HDL code of each sub-block nor the HDL code of each such block's test bench have any functions to perform during the negative part of the simulated clock cycle except to wait for the next positive edge.
As FIG. 13 shows, when such a subBlockFallingEdge FLI call is made to the subBlockSlaveProgram, that program's step 360 will cause the subBlockSlaveProgram to wait in a step 362 until a masterClockRisingEdge message is received from the masterProgram.
When the next masterClockRisingEdge message is received, step 362 will cause steps 364 and 366 of FIG. 13 to be performed. Step 364 sets the subBlockSlaveProgram's masterClock variable to 1 , and step 366 returns from the subBlockFallingEdge FLI call previously made by step 328 of the subBlockTestBench of FIG. 12.
As shown in FIG. 12, when this call of step 328 returns, step 330 of that figure causes the slaveBlockTestBench's internal clock to generate one complete clock cycle. It does this by causing the test bench to generate a clock value of one after a first simulated period, PERIOD1 , and then after a second subsequent simulated period, PERIOD2, to generate a clock value of zero.
When the slaveBlockTestBench's internal clock generates a rising edge in response to step 330, step 332 of FIG. 12 will cause steps 334 through 342 to be executed. Step 334 makes a subBlockRisingEdge FLI call to the corresponding subBlockSlaveProgram.
As indicated by steps 368 and 370 of FIG. 13, when the corresponding subBlockSlaveProgram receives this call, it communicates the value of all the subBlock's input ports contained in the slave program's wire values table to the sub-block's test bench, and then it returns to the test bench.
As indicated in Step 334 of FIG. 12, the subBlockTestBench reads each of these input values, and step 336 places each such input port value on the corresponding wire, or internal port of the test bench. Then step 338 sends a rising edge to the sub-block being simulated within the test bench.
This causes the HDL logic of the sub-block to simulate latching the values of the input ports at that time.
When the HDL sub-block being simulated within a subBlockTestBench has completed the simulation of its response to all of the values it has latched at the simulated rising edge sent to it in step 338 of FIG. 12, program control will return back to the simulation of subBlockTestBench's HDL code from the simulation of the sub-block's HDL code, and step 340 and 342 of FIG. 12 will be performed. These steps will make a risingEdgeDone FLi call to the sub-block's associated subBlockSlaveProgram. This call will include all of the output values which exist on the output ports of the sub-block at the completion of the sub- block's response to the rising edge.
As shown in FIG. 13, when a subBlockSlaveProgram receives such risingEdgeDone call, its steps 372 causes steps 374 and 376 to be performed. Step 374 writes the sub-block's output values to the slave program's wire values table, and step 376 sends a risingEdgeDone message to the masterProgram, which includes all of the output values generated in response to the rising edge by the sub-block.
When the masterProgram of FIG. 9 receives a risingEdgeDone message from a given subBlockSlaveProgram its step 246 causes steps 248 and 250 to be performed. Step 248 stores the sub-block output port values received in the message in the masterProgram's wire values table. Step 250 sets a risingEdgeDoneFlag 251 , shown in FIG. 4, corresponding to the subBlockSlaveProgram from which the message came.
When the masterProgram's risingEdgeDoneFlags for each of the subBlockSlavePrograms have been set, steps 252 and 254 send a risingEdgeAIIDone message to the topBlockSlaveProgram.
As is shown in FIG. 11 , when the topBlockSlaveProgram receives such a risingEdgeAIIDone message, it steps 320 and 322 return from the topBlock's externalClockRisingEdge call.
When the externalClockRisingEdge call in step 292 of FIG. 10 returns, the simulation of the performance of top block in response to the last rising edge clock signal from its external test bench is complete, and steps 294 and 296 of FIG. 10 return program execution to the external test bench, enabling it to advance to the generation of the next clock edge.
The process described above is repeated for each successive pair of negative and positive clock edges generated by the top block's external test bench, during the entire simulation process.
FIG. 14 is another schematic representation of the parallel computer system 130 shown in FIG. 4. The features shown in FIG. 14 are slightly different than those shown in FIG. 4, because FIG. 14's emphasis is on the user interfaces 400 which are included in each of the instances of the HDL simulation programs 136 used in the parallel simulations.
Since each instance 136 of the HDL simulator has been designed to operate as a stand alone simulation program, the user interface 400 is a compete interface, including software for creating graphical user interface windows 402. These windows provide interface capabilities for selective single stepping, the setting of breakpoints, and the display of the logic states of selected ports associated with an HDL block being simulated. The system 130 is configured to have the user interface of each separate simulation sends the information necessary to generate its graphical interface window 402 through the computer network 134 to the display monitor 404 of the master computer 132A. When input is supplied to any such interface window 402 through the master computer's keyboard 406 or mouse 408, the corresponding information is relayed through the network to the debug interface of the corresponding HDL simulation.
Since the system 130 causes all of its parallel simulations to process the same falling or rising edge at the same time, the output on all the user interface windows 402 will be synchronized. The user is free to use the user interface of any simulation to stop the entire simulation process, either by single stepping or setting a breakpoint. This is because, as is indicated above, the stopping of any simulation will prevent all other simulations from advancing to the processing of the next clock edge.
Since the windows 402 are graphical user interface windows, a user is free to select which of such windows, he or she wants to see displayed at any given time, and to size, resize, position, reposition, maximize, and/or minimize such windows as desired. This enables a user to desired interface windows from a relatively large number of simulation processes to see the information current desired. The user interface on each instance of the simulation program is also capable of writing information about its simulation to a file or a pipe, and software can be written to automatically consolidate and display or print such information from different simulations as desired. FIG. 15 show one method 500 of creating the system 130 described above. This method involves the step 502 of purchasing or otherwise obtaining rights to use the HDL simulation software 136 from an entity 138 which sells it. It also involves a step 504 of obtaining parallelization software 506 from an entity other than the company 138. The parallelization software 506 would include the master program 150 described above, which includes or creates all of the code and data structures needed to perform parallel simulation with the HDL simulation software 136. This software could be obtained either by purchasing it or writing it. Once step 504 has been performed, step 508 is performed, which includes the running of the master program so as to perform parallel simulation with combination of the HDL simulation software and the parallelization software.
FIG. 16 illustrates that one aspect of the present invention includes the method of performing both serial and parallel simulations upon the same HDL circuit design using the same test bench. As is shown in FIG. 15 one instance of the HDL simulation software 136 can be used to perform a standard serial simulation upon an HDL circuit design, which simulates the circuits top block 138A, complete with all its sub-blocks, within a test bench 140 on one computer, the computer 132D shown in FIG. 16. As is also shown in FIG. 16, the user can also perform a parallel simulation of the same circuit on the parallel system 130 described above, using the same test bench 140.
This ability to use the same test bench when performing both serial or parallel simulation is particularly important since it is not uncommon for a person developing a circuit to spend as long developing a test bench to properly test that circuit as is spent writing the HDL code for the circuit itself.
It should be understood that the foregoing description and drawings are given merely to explain and illustrate the invention and that the invention is not limited thereto except insofar as the interpretation of the appended claims are so limited. Those skilled in the art who have the disclosure before them will be able to make modifications and variations therein without departing from the scope of the invention.
For example, the broad functions described in the claims below, like virtually all computer functions, can be performed by many different programming and data structures, having very different organization and sequencing of operations. This is because programming is an extremely flexible art form in which a given idea of any complexity, once understood by those skilled in the art, can be manifested in a virtually unlimited number of ways. In all the embodiments described above, all communication of port values goes through a common master program. In other embodiments of the invention, other communications schemes could be used. For example, the simulation of separate sub-blocks could communicate port values directly to the simulations of other sub-blocks, without having such values go through a common master program. This could be important in simulations with a very large number of processors to prevent communications through the master program from becoming a bottleneck.
In some embodiments of the invention synchronization of the parallel simulation could be achieved by using a distributed synchronization scheme rather than by using a master program. Examples of such distributed synchronization schemes include the use of time stamps or time barriers.
Similarly in simulations with a large number of processors, it might be desirable to cause communication between sub-blocks to reflect the hierarchical arrangement of such sub-blocks discussed above with regard to FIG. 2. Thus, the communication of all blocks which are sub-blocks of a given block could be largely limited to communications with each other and/or with their parent block. Separate networks or communication paths could be provided for the communications between the sub-blocks of a given block, so as the further restrict system-wide bandwidth consumption. A hierarchical set of master programs could be used, with one overall master program synchronizing the simulation of the top block and its sub- components and with one or more layers of sub-ordinate master programs synchronizing the simulation of more subordinate sub-blocks.
The present invention could be used on many different types of computers, using many different operating systems and communication schemes. For example, it is not limited to use on so-called shared nothing computers, that is, one parallel computers where each separate processor is part of a separate fully-independent computer connected by a network. The invention can also be run on other types of multiprocessor systems, including ones using symmetric multiprocessing. Furthermore, many aspects of the invention do not require that communication between separate simulation processes be carried out over a computer network. In some embodiments of the invention, for example, communication between separate simulation processes could be carried out through shared memory, or interprocess communication schemes. It would be possible in some situations for some simulation processes to communicate in one manner and other simulations processes to communicate in a different manner. For example, the invention could be used to simulate a circuit on a network of computers, each of which is a symmetric multiprocessing computer. In such a case, the separate simulations running on the separate processors of each symmetric multiprocessing computer might communicate through shared memory, but processes running on different SMP computers might communicate over a network.
In the embodiments of the invention described above the simulator program used is a serial program which provides no support at all for parallel processing of its functions. In other embodiments of the invention the simulator program could itself be a partially or completely parallel program.
Some aspects of the invention relate to the fact that the parallelization code comes from a different source than the simulation code, i.e., that the code which allows parallel instances of a simulation program to operate together as part of a larger simulation comes from a separate source than the simulation program itself. Other aspects of the invention do not rely on this distinction, and, thus, some aspects of the invention cover parallelization code which comes from the same source as the simulation program, and even embodiments of the invention in which the parallelization code has been directly incorporated into the simulation code.
In the embodiment of the invention described above all of the HDL simulation processes used are instances of one simulation program. In other embodiments of the invention different HDL simulation processes could be instances of different HDL simulation programs, possibly even coming from different vendors.
It should be understood that the present invention is not limited to use with VHDL and Verilog simulator, but also could be used with other HDL simulators as well.
In the embodiments of the invention described above, the language interface used to interface between the HDL code and the non-HDL parallelization code running on the same processor uses FLI calls. As stated above, in Verilog versions of the invention PLI calls could be used instead. It would also be possible to use other language interface methods for communicating between the HDL and non-HDL code. For example, the MTI interface, which lets non-HDL code call HDL code, could be used as such a language interface.
In the description above it was stated that the non-HDL parallelization code, such as that used in the slave programs was C or C++ code. It should be understood that in other embodiments of the invention the parallelization code could be written virtually any computer language.
In the description above the non-HDL master and slave programs form a part of the complete test bench which drives each separate simulation. In all of the test benches described above, however, the part of the test bench which actually directly interfaces with the block being simulated is written in HDL. It should be understood, however, that none of the test benches used in alternate embodiments of the invention need contain any HDL code, since most HDL simulators support entirely non- HDL test benches. It should also be understood that one can practice many aspects of the invention without creating the dummy top block 138 shown in FIG. 4. Instead test benches created for each sub-block could collectively supply all of the inputs needed to drive the simulation. This could be done by placing special code in each test bench to supply such test inputs, or the master program could be programmed to deliver such input values to the various sub-block test benches. In other embodiments of the invention, FLI calls could be inserted into the internal ports of a test bench designed to drive the simulation of a circuit's top block. Such calls would communicate port values and synchronization information much like the FLI calls in the dummy top block 138 described above. The insertion of such FLI calls into the top block's test bench could be done automatically by code similar to that described above which is used to create the dummy top block 138.
The embodiment of the invention described above is designed to simulate HDL designs in which all latching is done on a rising clock edge. It should be appreciated that after reading this disclosure those skilled in the art would understand how the system described above could be extended to simulate HDL logic using more complicated clocking schemes, such as those in which some logic latches input values on rising clock edges and some logic latches input values on falling clock edges. Similarly, other embodiments of the invention could be created which did not require that all separately simulated sub-blocks have clocked input and output ports. Also, other embodiments of the invention can be created which simulate time at substantially finer time intervals than the system described above, which simulates time at the resolution of just one rising and one falling edge per clock cycle.
In the embodiment of the invention described above, the user selects which sub-blocks are to be simulated on which processors using a graphical user interface. In other embodiments, the system could automatically decide which sub-blocks are to be simulated on which processors as a function of the complexity of block. In yet other embodiments, a user could code into the various test benches and slave programs information about which sub-blocks are to be simulated on which processors.
Alternate embodiments could also include code for keeping track of which sub-blocks are taking the longest to complete there response to each clock cycle and use this information to decide which sub-block should be separately simulated and which sub-blocks should be simulated on separate processors so as to cause the overall simulation to progress at the fastest rate.

Claims

1. A computerized method of simulating HDL circuit designs comprising:
-running multiple instances of an HDL simulation program, each of which is capable of simulating an HDL block in a test bench without other simulation software;
-having each instance of the simulation program simulate an HDL sub-block of a larger HDL design within a test bench; and
-having the test benches communicate port values and clock synchronization between themselves, so that the simulation of the separate sub-blocks on separate instances of the simulation program function to create a parallel simulation of the larger HDL design.
2. A computerized method as in Claim 1 , further comprising: -running software which parses the part of an HDL description of the larger HDL design which describes each separately simulated sub-block to find the external ports of each such sub-block; and
-generating computer code which defines the test bench with which each such sub-block is separately simulated; including providing that test bench with:
-internal ports corresponding to, and connected to, the external ports of its associated sub-block; and
-instructions for communicating the values of those ports and clock synchronization with other instances of the simulation program which are simulating other sub-blocks.
3. A computerized method as in Claim 2 wherein: -each test generated bench is comprised of two parts:
-a test bench written in HDL; and
-non-HDL test-bench-parallelization programming code; and -the HDL text bench and the non-HDL parallelization code communicates port values and synchronization information using a language interface provided in HDL to support communication between HDL and non-HDL code, and the test-bench-parallelization code of each test bench communicates such information with the test-bench- parallelization code associated with the other test benches of associated with other HDL sub-blocks.
4. A computerized method as in claim 3 wherein the non-HDL test- bench-parallelization code associated with each test bench driving the simulation of a separate HDL sub-block communicates with the test-bench- parallelization code associated with each other test bench driving the simulation of another HDL sub-block through a master program running on one processor.
5. A computerized method as in Claim 1 wherein each separate instance of the HDL simulation program includes a user interface which allows a user to monitor and control the simulation of an HDL block by each such instance of that program, if desired.
6. A computerized method of simulating HDL circuit designs, each of which is composed of a plurality of HDL sub-blocks, said method comprising:
-responding to a selection by a user of which sub-blocks of a given HDL circuit designs have been selected for separate simulation on different processors, by parsing the HDL code of each such selected sub-block to determine its external ports;
-automatically creating a test bench to drive a separate simulation of each such selected sub-block, with the test bench created for each selected sub-block having interfaces for communicating the value of the sub-block's external ports and clock synchronization information between the sub-block and the simulation of other selected sub-blocks; and
-running a separate instance of an HDL simulation program for each selected sub-block and its associated test bench.
7. A computerized method as in Claim 6 further comprising: -parsing HDL code of an HDL circuit design to determine the hierarchy of HDL sub-blocks defined by the design;
-providing the user with a graphic representation of said hierarchy of sub-blocks; and
-allowing the user to make the selection of which sub-blocks are to be selected for separate simulation by using a point and click interface.
8. A computerized method as in Claim 6 further comprising using information obtained in a parse of the HDL code of the circuit to generate an HDL dummy top-block having ports corresponding to the external and internal ports of the top block in the HDL circuit design and which includes code for communicating the values of each of the top block's external ports between a test bench created to drive the simulation of the top block and corresponding ports of individual test benches generated by the method to drive the simulation of the selected sub-blocks.
9. A computerized method of simulating HDL circuit designs comprising:
-running multiple instances of an HDL simulation program, each capable of simulating an HDL block in a test bench without other simulation software;
-having each instance of the HDL simulation program simulate an HDL sub-block of a larger HDL design;
-having the simulation of each separately simulated sub-block use a language interface supported by the HDL simulation program for the purpose of communicating between HDL and another programming languages to communicate port values and clock synchronization information between the HDL simulation of each sub-block and non-HDL parallelization code running on the same processor as the HDL simulation of that sub-block; and -having the non-HDL parallelization code running on different processors communicate such port values and clock synchronization information between processors.
10. A computerized method as in Claim 9 wherein:
-the separate simulation of individual ones of said sub-blocks includes performing gate level logic simulation which calculates gate level delays associated with the propagation of signals though logic gates in the simulated circuitry of the sub-block; and
-all the external output ports of the separately simulated sub-blocks are the outputs of clocked latches in the HDL circuit design, so that their values only change upon clock signals during simulation; and
-the communication of port values over the language interface does not simulate gate level signal delays.
11. A computerized method as in Claim 9 wherein the synchronization of separate sub-block simulations is controlled by having a call using the language interface from each HDL simulation to the non-HDL parallelization code running on the same processor not return until the non- HDL parallelization code receives information derived from the parallelization code on other processors that the simulations of all the sub- blocks of a larger HDL design being simulated are ready to advance to simulation of a subsequent clock event.
12. A computerized method as in Claim 11 wherein:
-each instance of the non-HDL parallelization code associated with each instance of the HDL simulation program is a slave program which communicate with other instances of the non-HDL parallelization code through a master program running on one processor; and
-the master program determines when to send a instances of the non-HDL parallelization code a message allowing them to make said return from the language interface calj which allows the associated HDL sub-block simulations to advance to simulation of a subsequent clock event.
13. A computerized method as in Claim 12 wherein each slave program sends a message to the master program when its associated HDL simulation is done simulating its response to a given clock signal, and the master program sends a message to each slave program to cause it to return from the language interface call once the master program has received such a done message from each slave program participating in the simulation of the HDL circuit for a previous clock signal.
14. A computerized method of simulating HDL circuit designs comprising:
-running multiple instances of an HDL simulation program, each of which is capable of performing an independent simulation of an HDL block in a test bench;
-having each instance of the simulation program simulate an HDL sub-block of a larger HDL design within an HDL test bench; and
-having the HDL test benches communicate port values and clock synchronization between themselves using an HDL language interface supported by the simulation program, so that the simulation of the separate sub-blocks on separate instances of the simulation program functions to simulate the larger HDL design.
15. A computerized method as in Claim 14 further comprising: -parsing the HDL code of the circuit design to be simulated to determine the external port connections of each sub-block being separately simulated; and
-generating a separate HDL test bench for each sub-block which has:
-an internal port for each sub-block's external ports; and -code for making calls with an HDL language interface supported by the simulation program to non-HDL code running on the same processor as the simulation of the sub-block which communicates the value of those ports with the test benches generated for the other separately simulated HDL blocks.
16. A computerized method as in Claim 15 wherein synchronization between the separate test benches simulating different HDL sub-blocks is achieved by having at least some of said language interface calls to the non-HDL code associated with the simulation of a given sub-block not return until all of the test benches separately simulating sub-blocks of the HDL circuit have indicated that they have completed their response to a previous clock event.
17. A computerized method of simulating HDL circuit designs comprising:
-running multiple instances of a commercially available HDL serial simulation program, each of which is capable of simulating an HDL block in a test bench without other simulation software;
-having each instance of the simulation program perform a serial simulation of an HDL sub-block of a larger HDL design within a test bench on the same processor as that instance; and
-providing as at least a part of the test bench, additional software, which is not part of the commercially available simulation program which communicates port values and clock synchronization between the test benches associated with said sub-blocks, so that the serial simulation of the separate sub-blocks on separate instances of the simulation program function together to perform a parallel simulation of the larger HDL design.
18. A computerized method as in Claim 17, wherein the commercially available HDL simulation program does not include programming to have different processors connected by a computer network simulate an HDL circuit by using different processors to simulate different parts of the circuit, but the additional software provides the functionality to necessary to enable separate instances of said HDL simulation program to communication with each other over a computer network and operate in parallel to simulates different parts of an HDL circuit description.
19. A computerized method of simulating HDL circuit designs comprising:
-running multiple instances of the HDL simulation program produced by one legal entity, with different ones of said instances running on different processors;
-having each instance of the simulation program simulate an HDL sub-block of a larger HDL design within a test bench running on the same processor as that instance; and
-providing as at least a part of the test bench, additional software produced by a different legal entity, which is not part of the commercially simulation program from the first entity which communicate port values and clock synchronization between the test benches associated with said sub- blocks, so that the simulations of the separate sub-blocks on separate instances of the simulation program from the first entity function in parallel to simulate the larger HDL design.
20. A computerized method of simulating HDL circuit designs comprising:
-running multiple instances of an HDL simulation program, each of which is capable of simulating an HDL block in a test bench, on separate processors;
-dividing the design into sub-blocks having only clocked external ports;
-simulating the separate sub-blocks on separate instances of the simulation program running on separate processors with individual instances of the simulation program calculating gate level delay times within the part of the HDL circuit design represented by its associated sub- block; -having parallelization software run on each processor running an instance of the simulation program which synchronizes clock times between the separate simulations; and
-having the parallelization software communicate the external port values of the separately simulated sub-block at the synchronized clock times without gate delay information.
21. A computer system for simulating HDL circuit designs comprising:
-multiple processors;
-multiple instances of an HDL simulation program running on each processors, each of instances which is capable of simulating an HDL block in a test bench without other simulation software;
-separate HDL sub-block of a larger circuit design defined in HDL code, and a separate test bench which interfaces to the external ports of each HDL such sub-block, loaded on each processor for simulation by the instance of the HDL simulation program on the processor; and
-software within the test bench on each processor which communicates port values and clock synchronization information between the test benches on different processors, so simulations of separate sub- blocks by separate instances of the simulation program function together to perform a parallel simulate of the larger HDL design.
PCT/CA2000/001342 1999-11-10 2000-11-10 System for performing parallel circuit simulation in a high level description language WO2001035283A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU13754/01A AU1375401A (en) 1999-11-10 2000-11-10 System for performing parallel circuit simulation in a high level description language

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US43775199A 1999-11-10 1999-11-10
US09/437,751 1999-11-10

Publications (2)

Publication Number Publication Date
WO2001035283A2 true WO2001035283A2 (en) 2001-05-17
WO2001035283A3 WO2001035283A3 (en) 2002-05-30

Family

ID=23737732

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2000/001342 WO2001035283A2 (en) 1999-11-10 2000-11-10 System for performing parallel circuit simulation in a high level description language

Country Status (2)

Country Link
AU (1) AU1375401A (en)
WO (1) WO2001035283A2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2364798A (en) * 1999-12-03 2002-02-06 Sgs Thomson Microelectronics Processing the output of a design tool
CN100395758C (en) * 2002-10-14 2008-06-18 英业达股份有限公司 Method for setting and activating group display of circuit distribution engineering
WO2009118731A2 (en) 2008-03-27 2009-10-01 Rocketick Technologies Ltd Design simulation using parallel processors
US7860540B2 (en) 2001-10-03 2010-12-28 Nec Corporation Slide-type portable communication apparatus
US8082141B2 (en) 2003-09-20 2011-12-20 Mentor Graphics Corporation Modelling and simulation method
WO2011109707A3 (en) * 2010-03-04 2011-12-22 Synopsys, Inc. Mixed concurrent and serial logic simulation of hardware designs
US9032377B2 (en) 2008-07-10 2015-05-12 Rocketick Technologies Ltd. Efficient parallel computation of dependency problems
US9128748B2 (en) 2011-04-12 2015-09-08 Rocketick Technologies Ltd. Parallel simulation using multiple co-simulators

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5649164A (en) * 1994-12-30 1997-07-15 International Business Machines Corporation Sets and holds in virtual time logic simulation for parallel processors
US5805867A (en) * 1994-04-06 1998-09-08 Fujitsu Limited Multi-processor simulation apparatus and method
US5905883A (en) * 1996-04-15 1999-05-18 Sun Microsystems, Inc. Verification system for circuit simulator

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5805867A (en) * 1994-04-06 1998-09-08 Fujitsu Limited Multi-processor simulation apparatus and method
US5649164A (en) * 1994-12-30 1997-07-15 International Business Machines Corporation Sets and holds in virtual time logic simulation for parallel processors
US5905883A (en) * 1996-04-15 1999-05-18 Sun Microsystems, Inc. Verification system for circuit simulator

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KOCH M ET AL: "Distributed VHDL simulation within a workstation cluster" SYSTEM SCIENCES, 1994. VOL.II: SOFTWARE TECHNOLOGY, PROCEEDINGS OF THE TWENTY-SEVENTH HAWAII INTERNATIONAL CONFERENCE ON WAILEA, HI, USA 4-7 JAN. 1994, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, 4 January 1994 (1994-01-04), pages 313-322, XP010096998 ISBN: 0-8186-5060-5 *

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6618838B1 (en) 1999-12-03 2003-09-09 Stmicroelectronics Limited Method and apparatus for processing an output of a design tool
GB2364798B (en) * 1999-12-03 2004-04-28 Sgs Thomson Microelectronics A processing method
GB2364798A (en) * 1999-12-03 2002-02-06 Sgs Thomson Microelectronics Processing the output of a design tool
US7860540B2 (en) 2001-10-03 2010-12-28 Nec Corporation Slide-type portable communication apparatus
CN100395758C (en) * 2002-10-14 2008-06-18 英业达股份有限公司 Method for setting and activating group display of circuit distribution engineering
US8082141B2 (en) 2003-09-20 2011-12-20 Mentor Graphics Corporation Modelling and simulation method
US10409937B2 (en) 2003-09-20 2019-09-10 Mentor Graphics Corporation Modelling and simulation method
US9323873B2 (en) 2003-09-20 2016-04-26 Mentor Graphics Corporation Modelling and simulation method
EP2257874A2 (en) * 2008-03-27 2010-12-08 Rocketick Technologies Ltd Design simulation using parallel processors
WO2009118731A2 (en) 2008-03-27 2009-10-01 Rocketick Technologies Ltd Design simulation using parallel processors
US10509876B2 (en) 2008-03-27 2019-12-17 Rocketick Technologies Ltd Simulation using parallel processors
EP2257874A4 (en) * 2008-03-27 2013-07-17 Rocketick Technologies Ltd Design simulation using parallel processors
US8751211B2 (en) 2008-03-27 2014-06-10 Rocketick Technologies Ltd. Simulation using parallel processors
US9032377B2 (en) 2008-07-10 2015-05-12 Rocketick Technologies Ltd. Efficient parallel computation of dependency problems
US9684494B2 (en) 2008-07-10 2017-06-20 Rocketick Technologies Ltd. Efficient parallel computation of dependency problems
US8738350B2 (en) 2010-03-04 2014-05-27 Synopsys, Inc. Mixed concurrent and serial logic simulation of hardware designs
WO2011109707A3 (en) * 2010-03-04 2011-12-22 Synopsys, Inc. Mixed concurrent and serial logic simulation of hardware designs
US9128748B2 (en) 2011-04-12 2015-09-08 Rocketick Technologies Ltd. Parallel simulation using multiple co-simulators
US9672065B2 (en) 2011-04-12 2017-06-06 Rocketick Technologies Ltd Parallel simulation using multiple co-simulators

Also Published As

Publication number Publication date
AU1375401A (en) 2001-06-06
WO2001035283A3 (en) 2002-05-30

Similar Documents

Publication Publication Date Title
Hoffmann et al. A novel methodology for the design of application-specific instruction-set processors (ASIPs) using a machine description language
Edwards et al. SHIM: A deterministic model for heterogeneous embedded systems
KR100483636B1 (en) Method and apparatus for design verification using emulation and simulation
US8136065B2 (en) Integrated prototyping system for validating an electronic system design
US8473269B1 (en) System-level hardware and software development and co-simulation system
US6883147B1 (en) Method and system for generating a circuit design including a peripheral component connected to a bus
JPH06208602A (en) Verification method of testable design rule
JP2003529848A (en) Automatic design of digital signal processing integrated circuits
KR20080055913A (en) Development of assertions for integrated circuit design simulation
US7606694B1 (en) Framework for cycle accurate simulation
WO2001035283A2 (en) System for performing parallel circuit simulation in a high level description language
US7228513B2 (en) Circuit operation verification device and method
JP2009223661A (en) Verification support program, recording medium with the program recorded therein, verification support apparatus, and verification support method
US20040153301A1 (en) Integrated circuit development methodology
JP3779651B2 (en) Simulation model generation method, simulation method, and recording medium therefor
Brown et al. Experience in designing a large-scale multiprocessor using field-programmable devices and advanced CAD tools
Aubury et al. Advanced silicon prototyping in a reconfigurable environment
US7634396B2 (en) Method and computer program product for generation of bus functional models
Schirrmeister et al. Hardware-assisted verification and software development
TWI427496B (en) Method and system of generating a model of an integrated circuit
Tsasakou et al. High-level co-simulation based on the extension of processor simulators
Nagendra et al. Simulation Bridge: a framework for multi-processor simulation
Maillet-Contoz et al. Leveraging Transaction-Level Models in an SoC Design Flow
Overman et al. Developing a SARA building block-the 8080
Hamblen et al. Using Rapid Prototyping in Computer Architecture Design Laboratories

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase