[go: up one dir, main page]

WO2007043786A1 - Appareil de verification a base dynamique permettant une verification a partir d'un niveau de systeme electronique au niveau grille, et procede de verification utilisant cet appareil - Google Patents

Appareil de verification a base dynamique permettant une verification a partir d'un niveau de systeme electronique au niveau grille, et procede de verification utilisant cet appareil Download PDF

Info

Publication number
WO2007043786A1
WO2007043786A1 PCT/KR2006/004059 KR2006004059W WO2007043786A1 WO 2007043786 A1 WO2007043786 A1 WO 2007043786A1 KR 2006004059 W KR2006004059 W KR 2006004059W WO 2007043786 A1 WO2007043786 A1 WO 2007043786A1
Authority
WO
WIPO (PCT)
Prior art keywords
simulation
model
duv
abstraction
level
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2006/004059
Other languages
English (en)
Inventor
Seiyang Yang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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
Priority claimed from KR1020060068811A external-priority patent/KR20070108303A/ko
Priority claimed from KR1020060092574A external-priority patent/KR101328263B1/ko
Priority claimed from KR1020060092573A external-priority patent/KR20070062399A/ko
Application filed by Individual filed Critical Individual
Priority to US12/089,665 priority Critical patent/US20090150136A1/en
Publication of WO2007043786A1 publication Critical patent/WO2007043786A1/fr
Anticipated expiration legal-status Critical
Priority to US12/987,481 priority patent/US8781808B2/en
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 is to increase the verification performance and efficiency for systematically verifying digital systems with more than multi- million gates by using simulation and prototyping from electronic system level (ESL) down to gate level(GL) through register transfer level(RTL).
  • ESL electronic system level
  • RTL register transfer level
  • simulation is to build a pair of computer-executable models which consists of DUV(Design Under Verification) or one or more than one design object(to be defined later) inside of DUV, and TB(testbench) which drives it, to translate it into a sequence of machine instructions of a computer through a simulation compilation process, and to execute it on the computer. Therefore, simulation execution is basically accomplished by the sequential execution of machine instructions of a computer, and there are many simulation methods (event-driven simulation, cycle-based simulation, compiled simulation, interpreted simulation, co-simulation, algorithmic-level simulation, instruction-level simulation, transaction-level simulation, RTL simulation, gate-level simulation, transistor-level simulation, circuit-level simulation, etc).
  • simulation represents a variety of processes in which DUV and TB, that are executable SW models built in a computer at a proper abstraction level (there are many abstraction level existed in IC design such as circuit-level, transistor-level, gate-level, RTL, transaction-1eve1 , instruction-level (if the design object is a processor), algorithmic-level, etc) by a modeling process, are executed in a computer to realize its functional specification or functional characteristic in SW.
  • the advantage of simulation is to virtually evaluate the functional specification or functional characteristic of design object before the design objects is actually implemented and fabricated, to provide a high flexibility due to the SW nature, and to obtain high visibility and controllability on DUV or TB which is critical for debugging.
  • the simulation execution is a sequential execution of machine instructions sequence. If the design complexity is large alike to the modern designs having 100 million or more gates, the simulation speed becomes extremely slow (for example, it will take 3.2 years to simulation an 100 million gates design for 100,000,000 cycles by an event- driven simulation whose speed is 1 cycle/sec).
  • the simulation is defined as any SW modeling and SW execution method of DUV and TB at the proper abstraction level.
  • the simulation is defined as the process including implementing the behavior of DUV and TB at a specific abstraction level as a specific computer data structure and its well defined operations on it so that it is computer-executable, and performing a series of computations and processing of the operations on the data structure with input values in computer (Therefore, in this present invention, the simulation can be carried out by not only any commercial simulator, but also internally built simulators. Also, any process including a series of computation or processing the operations on the data structure with input values in computer is considered as the simulation if the process meets the above definition of simulation).
  • the traditional prototyping is to build a system on PCB(Printed Circuit Board) by using manufactured semiconductor chips (for example, sample chips) or FPGA(Field Programmable Gate Array) chips, which implement DUV, and other components necessary to the construction of the entire system (in simulation, other components are modeled as TB), and to verify the DUV in either in-circuit or in-system environment while the entire system is running a real or almost real operation speed. If DUV and TB are not modeled virtually in SW, but physically implemented for verification, it is advantageous to verify at the extremely high speed. However, as in the prototyping environment the visibility and controllability are very low, the debugging is very difficult when it operates incorrectly.
  • VP also plays a critical role in platform-based design(PBS), which is widely adopted in SOC designs, because VP can be made of transaction-level on-chip bus models and other transaction-level component models (these are called TLM models), which can be simulated at much higher simulation speed (about 100 to 10,000 times faster than RTL model).
  • PBS platform-based design
  • TLM models transaction-level component models
  • VP can provide many benefits in SOC designs.
  • SOC designs as the most important factor of VP is its fast execution speed suitable to develop some softwares, it is modeled not at RTL using Verilog or VHDL, but at higher abstraction level such as transaction-level or algorithmic-level using SystemC or C/C++.
  • the abstraction level which is the most important concept in system-level designs, is the level of the representation detail of corresponding design object (explained in detail later).
  • Digital systems can be classified into 1ayout-1eve1 , transistor-level, gate-level, RTL, transact ion-1eve1 , algorithmic-level, etc from the low level of abstraction to the high level of abstraction.
  • gate-level is a lower abstraction than RTL
  • RTL is a lower abstraction than transact ion-1eve1
  • transact ion-level is a lower abstraction than algorithmic-level. Therefore, if the abstraction level of a specific design object A is transact ion-level and its abstraction level of a design object B refined from A is RTL, then it is defined design object A is at higher level of abstraction than design object B. Also, if a design object X has design objects A and C, and a design object Y has design objects B, which is a refined design object from A, and C, it is defined design object X is at higher level of abstraction than design object Y.
  • the accuracy of delay model determines the level of abstraction at same gate level or same RTL. That is, even though there are at same gate-level, the net-list with zero-delay model is at higher abstraction than the net-list with unit-delay model, and the net-list with unit-delay model is at higher abstraction than the net-list with full timing model using SDF(Standard Delay Format).
  • Recent SOC designs can be thought as a progressive refinement process of an initial design object, which must be implemented as a chip eventually, from the initial abstraction level, e.g. transact ion-1eve1 , to the final abstraction level, e.g. gate-level (refer Fig. 14).
  • the core of design methodology using progressive refinement process is to refine the design blocks progressively existed inside a design object MODELJ)UV(HIGH) modeled at high level of abstraction so that a refined design object MODEL_DUV(LOW) modeled at low level of abstraction is obtained automatically (for example, through logic synthesis or high-level synthesis), manually, or by both.
  • the ESL model is MODEL_DUV(HIGH) and the implementable RTL model is MODELJ)UV(LOf)
  • the RTL model is MODEL_DUV(HIGH) and the GL model is MODELJ)UV(LOW)
  • the GL model can become a timing accurate GL model if the delay information in SDF(Standard Delay Format) , which is extracted from the placement and routing, is back-annotated.
  • a model at the specific level of abstraction is a model at any level of abstraction (not only ESL, RTL, and GL, but also any mixed levels of abstraction such as a mixed level of ESL/RTL, a mixed level of RTL/GL, a mixed level of ESL/RTL/GL, etc) that can be existed in a refinement process from ESL to GL.
  • the "abstraction level” includes not only ESL, RTL, and GL, but also any mixed levels of abstraction such as a mixed level of ESL/RTL, a mixed level of RTL/GL, a mixed level of ESL/RTL/GL, etc.
  • a DUV consists of four design objects, A, B, C, and D, A and B are at ESL, C is at RTL, and D is at GL
  • the DUV is a mixed ESL/RTL/GL model of abstraction and can be called a model at the specific level of abstraction (Also, it is possible to be called a model at mixed ESL/RTL/GL of abstraction).
  • model at mixed levels of abstraction if we must clearly mention that the model is represented at the mixed levels of abstraction (Arbitrary design object, such as DUV or TB, can be called a model, but if there is no specific mention, a model is defined as a design object including DUV(Design Under Verification) and TB(Testbench)) .
  • Transaction which is the most important concept at ESL, represents an information that is defined over logically related multiple signals or pins as a single unit, and uses function calls to communicate among design objects.
  • the information on the signals or pins at RTL is represented by bit or bit vector only.
  • Transaction can be defined cycle by cycle (we'll call this type of transaction cycle-accurate transaction, and ca-transaction in short), over multiple cycles (we'll call this type of transaction timed transaction, cycle-count transaction, or PV-T transaction and timed-transaction in short), or without the concept of cycles (we'll call this type of transaction untimed-transaction in short).
  • the timed-transaction is represented by Transaction_name(start_time, end_time, other_attributes.
  • the refinement process is incremental so that the design objects at TL(Transact ion-level) in VP are progressively refined into the design objects at RTL which have at least signal-level cycle accuracy.
  • design objects at TL are translated into design objects ar RTL, therefore the transact ion-level VP is refined into the implementable RTL model.
  • the design objects at RTL(Transact ion-level) in the RTL model are progressively refined into the design objects at GL which have at least signal-level timing accuracy.
  • design objects at RTL are translated into design objects ar GL, therefore the RTL model is refined into an GL model.
  • Fig. 14 shows the example of the refinement process explained above.
  • DUV Design Under Verification
  • TB a SW model which represents an environment in which the chip is mounted and operated.
  • TB is for simulating DUV.
  • DUV and TB has a hierarchy so that there may be one or more lower modules at inside, each of these lower module can be called design block.
  • design block there may be one or more design modules inside, and a design module there may be one or more submodules inside.
  • design object any of design blocks, design modules, submodules, DUV, TB, some part of design blocks, design modules, submodules, DUV, or TB, or any combination of design blocks, design modules, submodules, DUV, and TB.
  • design object any module or part of the module in Verilog is a design object, any entity or part of the entity in VHDL is a design object, or any scjiiodule or part of the scjnodule in SystemC is a design object). Therefore, VP can be seen as a design object.
  • the definition of single simulation includes not only using one siniuIaLors, but also using more than one simulators, e.g. using one Verilog simulator and one Vera simulator, and running these simulators on a single CPU), there is a distributed parallel simulation method using two or more simulators for increasing the simulation speed.
  • the examples of the simulator are HDL(Hardware Description Language) simulators (such as NO Verilog/Veri log-XL and X-sim from Cadence, VCS from Synopsys, ModelSim from Mentor, Riviera/Act ive-HDL from Aldec, FinSim from Fintronic, etc), HVL(Hardware Verification Language) simulators (such as e simulator from Cadence, Vera simulator from Synopsys, etc), SDL(System Description Language) simulators (e.g. SystemC simulator such as Incisive simulator from Cadence, etc), and ISS( Instruct ion-Set Simulator)(such as ARM RealView Development Suite Instruction Set Simulator, etc).
  • HDL(Hardware Description Language) simulators such as NO Verilog/Veri log-XL and X-sim from Cadence, VCS from Synopsys, ModelSim from Mentor, Riviera/Act ive-HDL from Aldec, FinSim from Fintronic, etc
  • the simulators in this present invention include any of these simulators. Therefore, when two or more simulators use in this present invention, each of simulators can be any of simulators mentioned above.
  • Distributed parallel simulation (or parallel distributed simulation, or parallel simulation in short), which is to perform a simulation in a distributed processing environment, is the most general parallel simulation technique, in which DUV and TB, i.e. a model at specific level of abstraction, are partitioned into two or more design objects, and each of design objects is distributed into a simulator and executed on it (see Fig. 5). Therefore, the distributed parallel simulation requires the partitioning step at which divides a simulation model into two or more design objects. In this present invention, we will call the design object that should be executed in a specific local simulation (to be defined later) through the partition a "local design object".
  • distributed parallel simulation can be possible by connecting two or more computers with a high speed computer network such as giga ⁇ bit ethernet and running a simulator on each computer, or using multiprocessor- computer which has two or more CPU cores (in this present invention, local simulation is the simulation executed by each of those simulators that is called a local simulator in the distributed parallel simulation).
  • a high speed computer network such as giga ⁇ bit ethernet
  • multiprocessor- computer which has two or more CPU cores
  • local simulation is the simulation executed by each of those simulators that is called a local simulator in the distributed parallel simulation.
  • the performance of traditional distributed parallel simulation severely suffer from the communication and synchronization overhead among local simulators. Therefore, two basic methods are known for synchronization, one conservat ive(or pessimistic) the other optimistic.
  • the conservative synchronization guarantees the causality relation among simulation events so that these is no need to roll-back, but the speed of distributed parallel simulation is dictated by the slowest local simulation and these is too much synchronizations.
  • the optimistic synchronization temporally allows the violation of the causality relation, but corrects it later by roll-back so that the reduction of roll-backs is very critical for the simulation speed. But, because current distributed parallel simulation using optimistic synchronization does not consider to minimize the roll-back by maximizing the simulation periods when a local simulation does not require any synchronization with other local simulations, the simulation performance degrades significantly due to the excessive roll-backs.
  • the progressive refinement process from ESL to GL is considered as two-step process, at the first step an implementable RTL model (hereafter it will be call a RTL model) is obtained from a transaction- level model (hereafter it will be called an ESL model) and at the second step a GL model (a GL model is a gate-level netlist which represents an interconnection structure of cells in a specific implementation library with which the placement and routing can be carried out) is obtained from a RTL model.
  • a GL model is a gate-level netlist which represents an interconnection structure of cells in a specific implementation library with which the placement and routing can be carried out
  • a RTL model is a gate-level netlist which represents an interconnection structure of cells in a specific implementation library with which the placement and routing can be carried out
  • a design by a progressive refinement can be thought as the process in which one or more design objects in a model at higher level of abstraction are replaced by their corresponding design objects in a model at lower level of abstraction that have said partial hierarchy matching relation.
  • the verification for correct refinement of B(i)_refined is needed. But it is possible that other design objects are not refined yet.
  • the design object B(i)_refined replaces the corresponding design object B(i)_abst in a model at high level of abstraction MODEL_DUV(HIGH) to make a model at mixed level of abstraction MODELJ)UV(MIXED) (we will call this kind of progressive refinement "partial refinement", where as the refinement process from MODELJ)UV(HIGH) to MODELJ)UV(LOW) is called “complete refinement"), and MODELJ)UV(MIXED) is executed for comparing its result with that of MODELJ)UV(HIGH).
  • a model MODEL_DUV(MIXED) there are already refined design object B(i)_refined and un-refined design objects B(k)_abst . But as the input/output port of B(i)_refined has different abstraction from those ports of B(k)_abst , the additional interface may be needed to connect those ports between B(i)_refined and B(k)_abst .
  • transactors are needed because the port at ESL is transaction-level on the transaction and the port at RTL is cycle-level on the pins or signals.
  • the transactors can be different upon the degree of abstraction of the transaction, for example if a transaction at ESL is cycle accurate, the transactor may be simple, and if a transaction is cycle-count accurate, then the transactor may be relatively quite complex.
  • timing adjuster may be needed to generate some signals with correct timing at the port boundaries if the verification at GL is to verify the timing (The delay values used in the timing adjustor can be obtained by analyzing SDF or delay parameters in the library cells, performing a very short gate-level timing simulation using SDF or a static timing analysis, or both).
  • This simulation speed degradation is one of main problems of the verification in the progressive refinement process.
  • the speeds of simulation with MODELJ)UV(MIXED) or MODELJ)UV(LOW) drop significantly compared to the speed of simulation with MODEL_DUV(HIGH) , and this results in the increase of total verification time.
  • the speed of a RTL model is 10 to 10,000 times slower than that of a ESL model
  • the speed of a GL model is 100 to 300 times slower than that of a RTL model.
  • the object of present invention is to provide a systematic verification method through the progressive refinement from the system level to the gate
  • Another object of present invention is to provide a systematic verification method which can solve the degradation of verification performance as the progressive refinement goes down to the low level of abstraction.
  • another object of present invention is to allow the entire design and verification process using progressive refinement from the high level of abstraction to the low level of abstraction in a systematic and automatic way.
  • another object of present invention is to provide a verification method in which the model consistency is effectively maintained among two or more models existed at different levels of abstraction.
  • another object of present invention is to provide an efficient verification method through progressive refinement, in which a model at the low level of abstraction is efficiently verified using a model at the high Lo
  • Another object of present invention is to provide a method for increasing the speed of distributed parallel simulation by eliminating synchronization overhead and communication overhead.
  • Another object of present invention is to provide a systematic and consistent fast debugging method for correcting design errors (these design errors are not only HW design errors, but also SW design errors) in the entire verification phase from simulation-based verification to physical prototype-based verification.
  • Another object of present invention is to provide a high visibility and controllability throughout virtual prototypes or simulators for debugging the incorrect behavior of physical prototype in which DUV is operated in the in-circuit or in-system environment where DUV has one or more user clocks (in the case of two or more user clocks, these are asynchronous with no phase relation).
  • the verification includes not only HW-centric verification, but also SW-centric verification so that it must be a system-level design verification. Therefore, in the present invention, the design verification covers not only traditional HW verification, but also HW/SW co-verification verifying SW as well as HW.
  • the design verification apparatus that can be used for applying the design verification method in the present invention can be consisted of a verification software, and one or more computers, which install one or more simulators.
  • Another design verification apparatus that can be used for applying the design verification method in the present invention can be consisted of a verification software, one or more computers, which install one or more simulators, and one or more simulation accelerators (FPGA boards having simulation acceleration capability are seen as the simulation accelerator), hardware emulators, or physical prototyping boards having one or more FPGA chips or ASIC chips (hereafter, prototyping board in short).
  • simulation accelerators, hardware emulators, and prototyping boards as hardware-based verification platforms.
  • the verification software is running on the computer, and if there are 2 or more computers, then they are connected by a network (for example, Internet or giga-bit ethernet) so that the files or data are transferred among them through the network.
  • a network for example, Internet or giga-bit ethernet
  • One or more simulators for design verification can be consisted of various simulators mentioned before.
  • PDES Parallel Discrete Event Simulation
  • the distributed parallel simulation runs in co-simulation mode such a way that some design objects are run by event-driven simulation and other design objects are run by cycle-based simulation.
  • said two or more simulators consist of event-driven simulators, cycle-based simulators, and transaction- based simulators
  • the distributed parallel simulation runs in co-simulation mode such a way that some design objects are run by event-driven simulation, some other design objects are run by cycle-based simulation, and remaining design objects are run by transaction-based simulation.
  • the distributed parallel simulation runs in co-simulation mode if said two or more simulators consist of different kinds of simulators.
  • one or more hardware-based verification platforms can be used together with different kinds of simulators in the distributed parallel simulation for running in co-simulation mode (In this case, we will call this co-simulation too even though it can be also called co-emulation).
  • a RTL verification run with an implementable RTL model at RTL can be executed in parallel or partially (partially execution can be possible by the incremental simulation method which will be explained later) by using the result of ESL verification runs with an ESL model at ESL or the result of ESL/RTL verification runs with a mixed ESL/RTL model MODEL_DUV(MIXED)_i at mixed ESL/RTL of abstraction, which is made of in the progressive refinement process.
  • a GL verification run with a GL model at GL can be executed in parallel or partially (partially execution can be possible by the incremental simulation method which will be explained later) by using the result of RTL verification runs with a RTL model at RTL or the result of RTL/GL verification runs with a mixed RTL/GL model MODELJDUV(MIXED)_i at mixed RTL/GL of abstraction, which is made of in the progressive refinement process.
  • a ESL verification run with an ESL model at the specific transaction-level can be executed in parallel or partially (partially execution can be possible by the incremental simulation method which will be explained later) by using the result of ESL verification runs with an ESL model at higher transaction-level or the result of ESL verification runs with a mixed ESL model MODEL_DUV(MIXED)_i at mixed high transaction and low transaction level of abstraction, which is made of in the progressive refinement process.
  • the verification runs mentioned above are basically executed by simulation using one or more simulators, but it is also possible to execute them by simulation acceleration using one or more simulation accelerators, hardware emulators, or prototyping boards with simulators.
  • the simulation acceleration is simply to increase the speed of simulation by using hardware- based verification platform such as simulation accelerators, hardware emulators, or prototyping boards (in this case, the prototyping boards are controlled to operate in simulation acceleration mode by software, and are not in the in-circuit or in-system environment), we will include it (simulation acceleration) in simulation too in this present invention.
  • simulation acceleration is simply to increase the speed of simulation by using hardware- based verification platform such as simulation accelerators, hardware emulators, or prototyping boards (in this case, the prototyping boards are controlled to operate in simulation acceleration mode by software, and are not in the in-circuit or in-system environment), we will include it (simulation acceleration) in simulation too in this present invention.
  • the verification in this present invention actually means the simulation. Therefore, in this present invention, the verification can be thought as
  • the parallel or partial run of simulation at the low level of abstraction is carried out by using the simulation results at the high level of abstraction or the high/low mixed level of abstraction in the progressive refinement process, or by using the simulation results at the same level of abstraction which are obtained from the previous earlier simulation runs.
  • the parallel or partial run of simulation at the high level of abstraction can be carried out by using the simulation results at the low level of abstraction, too (this is in the case when the design iteration occurs).
  • an important thing in this present invention is to perform a present simulation fast by using the result of previous earlier simulation. Normally, the present simulation is carried out at the lower level of abstraction than that of the previous earlier simulation. But, in rare cases, the present simulation is carried out at the higher level of abstraction than that of the previous earlier simulation. Moreover, there can be one or more design modifications between the current simulation and the previous earlier simulation.
  • the input/output information (defined later) of one or more design objects in a model at the high level of abstraction saved at the entire or partial simulation time during the simulation run with a model at the high level of abstraction is used in the simulation at the low level of abstraction (we will call this "usage method-3").
  • the input/output information of one or more design objects in one or more models at the mixed high/low level of abstraction saved at the entire or partial simulation time during two or more simulation runs with models at the mixed high/low level of abstraction is used in the simulation at the low level of abstraction (we will call this "usage method- 4").
  • each of local simulations executes not only each of local design objects, but also a complete model of DUV and TB at higher level of abstraction or a complete model of DUV and TB optimized for faster simulation (for example, a model for cycle-based simulation is optimized for 1Ox faster simulation than a model for event-driven simulation) on each of local computers (by contrast, in traditional distributed parallel simulation, each of local simulations executes each of local design objects only) for obtaining the dynamic information from the complete model of DUV and TB, which is used as the expected inputs and expected outputs of the local design object to eliminate the synchronization overhead and communication overhead with other local simulations of the distributed parallel simulation, and to increase the speed of each of local simulations by each of local simulations (More detailed explanation will be later).
  • the dynamic information of a model or design object is the logic values of one or more signals, values of one or more variables, or constants at one or more specific simulation times or periods (the period can be the entire simulation time) in the model or design object during the simulation.
  • An example to get the dynamic information during the simulation is to use Verilog built-in system tasks, $dumpvars, $dumpports, $dumpall, $readmemb, $readmemh, etc, or user-defined system tasks (more detail can be found in Korean patent application 10-2005-95803, 10-2005- 116706, 10-2006-19738).
  • the dynamic information can be saved in VCD, SHM, VCD+, FSDB, or user-defined binary or text format.
  • the state information of a model is the dynamic information containing values of all flipflop output signals or variables, all latch output signals or variables and all combinational feedback signals or variables if there are any closed combinational feedback loops in the model at a specific simulation time (for example, at 29,100, 511 nano-second simulation time) or for a specific simulation period (for example, 1 nano-second period from 29,100,200 nano-second to 29,100,201 nano-second).
  • the state information of a design object is the dynamic information containing values of all flipflop output signals or variables, all latch output signals or variables and all combinational feedback signals or variables if there are any closed combinational feedback loops in the design object at a specific simulation time or for a specific simulation period.
  • the input information of a design object is values of all inputs and inouts of the design objects for a specific simulation time interval (this simulation time interval can be the entire simulation time).
  • the output information of a design object is values of all outputs and inouts of the design objects for a specific simulation time interval (this simulation time interval can be the entire simulation time).
  • the input/output information of a design object is values of all inputs, outputs and inouts of the design objects for a specific simulation time interval (this simulation time interval can be the entire simulation time).
  • the parallel simulation execution using a model at the specific level of abstraction in this present invention includes both distributed-processing- based parallel execution (hereafter, it will be called DPE in short), and time-sliced parallel execution (hereafter, it will be called TPE in short) (In other words, DPE and TPE are our unique parallel simulation methods in this present invention).
  • DPE distributed-processing- based parallel execution
  • TPE time-sliced parallel execution
  • t-DCP(Temporal Design Check Point) and s-DCP(Spatial Design Check Point) are defined first.
  • t-DCP is defined as the dynamic information of DUV or one or more design objects in DUV which is necessary for starting the simulation for DUV or one or more design objects in DUV from the arbitrary simulation time Ta, not the simulation time 0. Therefore, the state information of a design object is a specific example of t ⁇ DCP. But, a model for simulation must have both DUV and TB. Therefore, to start the simulation at the arbitrary simulation time Ta, other than simulation time 0, considering not only DUV but also TB is necessary. There are about three ways to do it. First, TB is executed from simulation time 0, and DUV from Ta.
  • the output information of DUV drives TB to run TB only from the simulation time 0 to Ta, and both DUV and TB are simulated together from Ta. If TB is non-reactive, executing TB alone from the simulation time 0 to Ta and executinf both TB and DUV from Ta is possible. Second, to restart TB at the simulation time Ta, TB is saved for restart. That is to save the TB state, which are values of all variables and constants at a specific simulation time or period in TB, or the simulation state, and restore it later.
  • the description style of TB must be confined (for example, synthesizable TB) or some manual TB modification may be needed.
  • the algorithmic-based input generation subcomponent in TB which is difficult to start the execution at Ta, may be replaced with the pattern- based input generation subcomponent, which is easy to start the execution at Ta using a pattern pointer.
  • the instrumentation code may need to be instrumented into a model for simulation or the simulation environment.
  • Such instrumentation code can be automatically instrumented by the verification software in this present invention (the specific examples of such instrumentation code are given in Fig. 16, 17, and 18).
  • s-DCP is defined as the dynamic information of the equivalent model at different abstraction level of DUV or TB, the dynamic information of one or more design objects in the equivalent model at different abstraction level, the dynamic information of DUV and TB, the dynamic information of one or more design objects in DUV and TB, a model of DUV and TB at the higher level of abstraction than that of DUV and TB, or a model of DUV and TB optimized for faster simulation (for example, in VCS from Synopsys there are methods for obtaining faster simulation models such as two-state simulation option or using Radiant Technology, and NC-sim or ModelSim also has similar methods).
  • Such s-DCP will be simulated together with the specific local design object in a local simulation by a local simulator in the distributed parallel simulation so that it(s-DCP) serves as the expected input and expected output of said local simulation S_l(k) for said local design object or is used for obtaining the expected input and expected output of said local simulation S_l(k) for said local design object.
  • the expected input as the input stimulus
  • said local design object is simulated to produce the corresponding actual output without interacting with other local simulations. And then, the produced actual output is compared with the expected output.
  • the corresponding local simulation can proceed further without interacting with other local simulations, therefore avoiding synchronization overhead and communication overhead, by being stimulated by next expected input and producing next corresponding actual output until the mismatch between the expected output and the actual output occurs
  • the expected input and the expected output for the execution of local simulation means the expected input values and the expected output values which are obtained before the actual execution or being obtained during the actual execution.
  • the expected something obtained before the actual execution or being obtained during the actual execution includes the expected one already available before the actual simulation starts, the expected one dynamically generated at the earlier than or the same time when the corresponding input has to be given or the corresponding output is produced during the actual simulation is running, or both.
  • s-DCP could be a model of DUV and TB at the higher level of abstraction than that of DUV and TB, an optimized model of DUV and TB for faster simulation, an input/output information for one or more design objects saved in the previous simulation runs).
  • s-DCP information which can be used for expected input and expected output of said local design object in said local simulation and control the execution of the simulation (such as run with expected input/output mode, run with actual input/output mode, roll-back mode, etc will be explained later)
  • the extra code must be instrumented into a design code (normally written in HDL, C/C++, SystemC, HVL, or any combination of these) or a simulation environment.
  • instrumentation code in short
  • HDL such as Verilog, SystemVeri log, or VHDL so that it is included into a model written in HDL, in C/C++/SystemC so that it is interfaced with a model in HDL using PLI/VPI/FLI or directly, or in the combination of them.
  • instrumentation code is normally instrumented outside of DUV, possibly in C/C++. But, if necessary, the instrumentation code can be instrumented into DUV.
  • Such instrumentation can be done automatically by the verification software in this present invention, which can read all design source files containing the codes of DUV and TB, and all simulation environment files (For a specific example, refer Fig. 16, 17, 18, and 19.
  • instrumentation code should play the role which includes to apply the expected input to the local design object for a local simulation, to compare the actual output of the local design object produced in the simulation run with the expected output, and apply the next expected input if they match. As this is pretty similar to the primary role of normal testbench, automatic generation of such instrumentation code is not difficult.
  • the local simulation S(t_c) should stop temporally and inform the mismatch to other local simulations. Therefore, the roll-forward is not different from the run with expected input/output for the local simulation S(t_c)), then the roll-back is performed, and from this roll-back point the traditional distributed local simulation is performed with actual input and actual output, (hereafter, we will call this "the run with actual input and actual output mode" in this present invention, and the run with actual input and actual output mode actually performs the transfer of simulation data - input to each of local simulations from some other local simulations or output from each of local simulations to some other local simulations - among local simulations in the distributed parallel simulation.
  • Each of local design objects executed by each of local simulators in the distributed parallel simulation environment uses the expected input obtained from s-DCP as the input for independently simulating the local simulation and obtaining the output of each of local simulations, compares this actual output with the expected output obtained from s-DCP, and if these two matches the corresponding local simulation can proceed with no synchronization overhead and communication overhead at all or minimal overheads (we'll call this mode of operation "the run with expected input and expected output mode") so that the simulation speed can be greatly increased.
  • the distributed parallel simulation should be carried out while the communication and synchronization among local simulators are being established after roll-back. Even after the simulation switches to the run with actual input and actual output mode in which the communication and synchronization occur, the actual inputs produced during the simulation are kept on being compared with the expected inputs obtained from s-DCP or the actual outputs produced during the simulation are kept on being compared with the expected outputs obtained from s-DCP.
  • the simulation can switch back to the simulation with expected input and expected output, i.e. the run with expected input and expected output mode, from this simulation time (we will call this time a "cancellation time of run with actual input/output") so that the communication overhead and synchronization overhead are again eliminated for high speed distributed parallel simulation (For the efficiency of comparison, the expected values, e.g. expected output or expected input, can be compared with the actual values, e.g. actual output or actual input by aligning the abstraction level. Alignment of the level of abstraction can be done by adaptor modules or transactor modules.
  • the abstraction level of actual values can be raised to ca-transaction level same as the level of expected values, or both the RTL abstraction level of actual values and the TL abstraction level of expected values can be raised to timed- transaction level as well).
  • the exact time for applying the run with actual input/output could be any time t_advance_lock earlier than t_lock, which is the earliest time of mismatch between expected output and actual output among those of local simulations in distributed parallel simulation.
  • the time for applying the run with actual input/output should be close to t_lock as much as possible.
  • each of local simulations in the distributed parallel simulation must save the simulation state (the simulation state is the run-time image of simulation process at a specific simulation time for checkpointing.
  • s-DCP Some specific examples of s-DCP are; the input/output information for one or more design objects in DUV and TB, a simulation model includes DUV and TB which are described at higher level of abstraction than that of said DUV and TB consisting of local design objects, or an optimized model for faster simulation includes DUV and TB. If the boundaries of local design objects for local simulations in a distributed parallel simulation are not same as the boundaries of design objects (for examples, modules in Verilog, entities in VHDL, scjnodules in SystemC, etc) in DUV, s-DCP could be the input/output information of said local design objects for said local simulations.
  • One is to save the simulation state at regular interval, or at one or more specific times during the simulation, and reload it later for restart.
  • the other is to save the design state (the design state is the state information of corresponding design objects) at regular interval, or at one or more specific times during the simulation, and reload it later for restart.
  • More detail can be founded in Korean patent applications, 10-2005- 116706 and 10-2006-19738. We will call this saving process of the simulation state or design state for restarting checkpointing. Those one or more simulation times or simulation periods, which the checkpointing are made, are called checkpoints. Therefore, the roll-back point in time for said roll-back is not the earliest mismatch point in time, t_est , but the checkpoint, which is closest but no later than t_est.
  • the expected inputs/expected outputs used in the distributed-processing-based parallel simulation of the present invention for minimizing communication overhead and synchronization overhead can be represented in signals with bit/bit-vector type, or transactions with abstracted data structure (such as record type).
  • transaction it can be cycle-by-cycle transaction or cycle-count transaction. Therefore, such comparison between expected input and actual input, or expected output and actual output could be in cycle-by-cycle at signal, cycle-by-cycle at transaction, or cycles-by- cycles at transaction. Therefore, in the case of comparison between expected input and actual input, or expected output and actual output, it includes cycle-by-cycle comparison at signal, cycle-by-cycle comparison at transaction, or cycles-by-cycles comparison at transaction.
  • the distributed parallel simulation method described above is called a distributed parallel simulation using s-DCP, distributed-processing-based parallel execution method, or distributed-processing-based parallel simulation (Distributed-processing-based parallel execution method, or distributed-processing-based parallel simulation only represents the distributed parallel simulation proposed in this present invention for minimizing communication overhead and synchronization overhead of distributed parallel simulation with expected inputs and expected outputs obtained from s-DCP, and does not represent the conventional distributed parallel simulation).
  • distributed-processing-based parallel execution method or distributed-processing-based parallel simulation only represents the distributed parallel simulation proposed in this present invention for minimizing communication overhead and synchronization overhead of distributed parallel simulation with expected inputs and expected outputs obtained from s-DCP, and does not represent the conventional distributed parallel simulation).
  • distributed-processing-based parallel execution method or distributed-processing-based parallel simulation only represents the distributed parallel simulation proposed in this present invention for minimizing communication overhead and synchronization overhead of distributed parallel simulation with expected inputs and expected outputs obtained from s-DCP, and does not represent the conventional distributed parallel
  • the accuracy of s-DCP used for obtaining expected inputs and expected outputs for local simulations is also very important. That is, more accurate s ⁇ DCP is, less the simulation periods by run with actual input/output are and more simulation periods by run with expected input/output are for eliminating communication overhead and synchronization overhead among local simulations in a distributed parallel simulation.
  • the accuracy of s-DCP is important, but also the time to get s-DCP is important. This is because the highest accuracy of s-DCP for expected input, expected output, or expected input and expected output can be obtained from the simulation with a model at the same level of abstraction as that of the model for distributed parallel simulation, but this takes very long time so that it is not practical in most situations.
  • regression test when the design is modified locally, or when s-DCP previously obtained is reused if the simulation with a same testbench should be repeated.
  • regression test where the back-ward compatibility is examined, most of tests are passed without detecting design errors. Therefore, the regression test can be performed with a high performance by a distr iados-processing-based parallel simulation or a combination of distributed-processing-based parallel execution/singular execution (explained later) using s-DCP obtained from the simulation prior to the regression test, because the accuracy of s-DCP is high so that the number of cancellations of run with actual input/output and the total simulation time for run with actual input/output is highly minimized.
  • the simulation can be executed with a high performance if a combination of distr iaded-processing-based parallel execution/singular execution or distr imped-processing-based parallel execution using incremental simulation (explained later) is used.
  • the distr iados-processing-based parallel simulation is executed for minimizing synchronization overhead and communication overhead, and at the end of above distr iados-processing-based parallel simulation t ⁇ DCP of DUV (it is the union of all t-DCP's of local design objects in local o
  • s ⁇ DCP for each of local simulation could be a RTL model or a RTL/GL mixed model, an optimized GL model for faster simulation, the dynamic information collected in a RTL simulation, or the dynamic information collected in a RTL/GL mixed simulation (For example, the input/output information of all gate-level design objects gathered from each of one or more RTL/GL mixed models.
  • DUV(MIXED)_4 (B(l)_rtl, B(2)_rtl, B(3)_rtl, B(4)_gl)
  • DUV(MIXED)_3 (B(l)_rtl, B(2)_rtl, B(3)_gl, B(4)_rtl)
  • M0DEL_DUV(MIXED)_2 (B(l)_rtl, B(2)_gl , B(3)_rtl, B(4)_rtl)
  • MODEL_DUV(MIXED)_1 (B(l)_gl,
  • s-DCP for each of local simulation could be an ESL model or an ESL/RTL mixed model, an optimized RTL model for faster simulation, the dynamic information collected in an ESL simulation, or the dynamic information collected in an ESL/RTL mixed simulation (For example, the input/output information of all RTL design objects gathered from each of one or more ESL/RTL mixed models.
  • DUV(MIXED)_4 (B(ILtIm, B(2)_tlm, B(3)_tlm, B(4)_rtl)
  • DUV(MIXED)_3 (B(ILtIm, B(2)_tlm, B(3)_rtl, B(4)_tlm)
  • M0DEL_DUV(MIXED)_2 (B(ILtIm, B(2)_rtl, B(3)_tlm, B(4)_tlm)
  • MODEL_DUV(MIXED)_1 (B(l)_rtl,
  • s-DCP for each of local simulation could be a ESL model at higher level of abstraction, an optimized ESL model for faster simulation, the dynamic information collected in a ESL simulation at higher level of abstraction, or the dynamic information collected in a ESL- at-higher-level/ESL-at-present-level mixed simulation (For example, the input/output information of all ESL design objects gathered from each of one or more t imed-transaction/ca-transact ion mixed models.
  • ⁇ 56> Using a model at higher level of abstraction, an optimized model for faster simulation at same level of abstraction, the dynamic information collected from the simulation with a model at higher level of abstraction, or the dynamic information collected from the simulation with an optimized model at same of abstraction for faster simulation for s-DCP, the process for getting expected inputs and expected outputs is fast as the simulation is fast.
  • a model at higher level of abstraction at the beginning, enhancing the accuracy of s-DCP from the dynamic information by simulating a more accurate model modified from an original inaccurate model at higher level of abstraction, obtaining s-DCP with high accuracy by modifying the dynamic information by simulation an incorrect model at higher level of abstraction, or obtaining s-DCP with high accuracy by statically or dynamically modifying the dynamic information by simulation an less accurate model at higher level of abstraction is possible.
  • One example of easily building a model with high accuracy at the high level of abstraction is to decompose a model into a communication module, which is responsible for interfacing to other blocks in a model, and a computation module, which is a model method widely used for TLM(Transact ion-Level Model).
  • the input/output timing accuracy can be provided at a computation module by annotating data-independent timing data expected while the internal computation module untouched (for example, the internal computation module is written at untimed TLM, and attaching data-dependent timing data only if necessary)-
  • the timing accuracy necessary to a model for example, cycle-by-cycle accuracy or cycle-count accuracy
  • s-DCP with high accuracy can be obtained from such a model.
  • ⁇ 59> it is possible to convert the specific abstraction level of a model at the input/output boundary into a different abstraction level model by attaching a transactor to transaction-level communication module, If high- level synthesis tools (such as TLM synthesis of Cynthesizer from Forte Design) is used, corresponding TLM communication module could be synthesizable and have a signal-level accuracy. From these, s ⁇ DCP with high accuracy can also be obtained.
  • high- level synthesis tools such as TLM synthesis of Cynthesizer from Forte Design
  • s-DCP accuracy can be enhanced by modifying s ⁇ DCP so that it satisfies the bus protocol correctly.
  • s-DCP can be modified by the annotation of an exact delay information (for example, clock skew delay of flipflop, clock—to-Q(high_to_low) delay and clock-to-Q(low_to_high) delay of positive-edge sensitive flipflop, clock-to-Q(high_to_low) delay and clock-to-Q(low_to_high) delay of negative-edge sensitive flipflop, asynchronous-set_to_Q delay, asynchronous-reset_to_Q delay, etc) on specific signals (for example, clock signals, output signals of f1 ipf lops contributing the input information of each local simulation, etc) in some design objects, which can come from analyzing SDF or delay parameters of cells in a library, performing
  • s-DCP can be modified by the annotation of exact timing information (for example, clock-to-Q delay of flipflop, phase difference among asynchronous clocks, etc) on specific signals in some design objects, which can come from performing a RTL timing simulation for a short period.
  • exact timing information for example, clock-to-Q delay of flipflop, phase difference among asynchronous clocks, etc
  • ⁇ 6i> modification of s-DCP obtaining can be done statically, but also dynamically during the execution of distributed parallel simulation.
  • dynamic modification of s-DCP and its use for expected input or expected output in the case of a distributed-processing- based event-driven parallel simulation at RTL, as a back-end simulation, which uses expected input and expected output collected from a front-end simulation performed at ca-transaction level, at the early stage of the simulation the distributed-processing-based parallel simulation at RTL is performed with expected inputs and expected output obtained from less accurate s-DCP, which is produced from the less accurate dynamic information.
  • Such a technique can also be used in a distributed-processing-based parallel timing simulation at GL.
  • a back-end simulation at GL uses expected input and expected output collected from a front-end simulation performed at RTL, at the early stage of the simulation the distributed-processing-based parallel timing simulation at GL is performed with expected inputs and expected output obtained from less accurate s-DCP, which is produced from the less accurate dynamic information.
  • said less accurate s-DCP becomes accurate s-DCP by reflecting the simulation result dynamically so that the distributed-processing-based parallel simulation can be performed with expected inputs and expected output obtained from said accurate s-DCP after the early stage of the simulation.
  • ⁇ 62> Therefore, in this present invention, we will call any of processes, which increase the accuracy of s-DCP, a process for s-DCP with enhanced accuracy. But, if original s-DCP is not the dynamic information collected during the earlier simulation, but a model at higher level of abstraction, said process for s-DCP with enhanced accuracy is a process in the simulation, which enhances the accuracy of dynamic information collected during the simulation with original s-DCP, i.e. a model at higher level of abstraction.
  • any of processes for increasing the accuracy of s-DCP dynamically during the execution of back-end simulation from original less accurate s-DCP which could be the simulation result of earlier front-end simulation, a model at higher level of abstraction, or an optimized model for faster simulation, is called a "process for s-DCP accuracy enhancement by dynamic learning”.
  • the simulations for each of said design objects with 1st s ⁇ DCP as the input can produce the outputs from each of said design objects, and 2nd s-DCP can be obtained from those outputs and it has higher accuracy.
  • a simulation with a model at lower level of abstraction using 1st t-DCP obtained from earlier simulation with a model at higher level of abstraction is performed in temporally parallel by divided simulation time slices (TPE-based parallel simulation), and input values and output values of each design objects in DUV are collected to produce 2nd s-DCP with enhanced accuracy.
  • s-DCP with enhanced accuracy can be obtained from the time alignment of two or more dynamic informations of design objects, whose union forms a model at lower level of abstraction, collected during two or more simulations with two or more models at mixed level of abstraction run in parallel s ⁇ DCP (The time alignment of dynamic informations means to align every dynamic informations in time because each of dynamic informations gathered may be skewed with other due to the model inaccuracy at higher level of abstraction. This time alignment can be done efficiently at transaction level, because the beginning of a specific transaction could be a reference point).
  • the comparisons between expected inputs and actual inputs, or expected outputs and actual outputs in local simulation of distributed-processing-based parallel simulation are done at transaction level. Comparing actual values with expected values at transaction level can easily detect any on-chip protocol violation of expected values so that they can be corrected accordingly (For a specific example of comparison, the comparison can be done in the unit of transaction first, and in the unit of cycle next for finding an expected transaction matched with an actual transaction. Therefore, when the comparison is made in the unit of transaction, the absolute lime of simulation is not used for the comparison between an expected transaction and 3b
  • the transaction semantic should be used for matching. For example, even though the start time and end time of a specific expected transaction is 1,080 ns and 1,160 ns respectively and the start time and end time of its corresponding actual transaction is 1,000 ns and 1,080 ns, two transactions should be matched if their transaction semantic is same.
  • the mismatch in the absolute time of simulation may come from a less accurate model at higher level of abstraction, or the lost of corresponding information by abstraction. Therefore a matching between an expected value and an actual value can take count of it. Also, between transactions at different levels, or transaction at a specific level and its refined RTL sequence, their appearing order could be different as well as the simulation time.
  • T3 U31, t32 ⁇
  • Tl ⁇ til, tl2, tl3, tl4 ⁇ , T4 - ⁇ t41, t42 ⁇
  • T2 ⁇ t21, t22, t23 ⁇ Ct i j - cycle-unit ca-transaction, e.g. a timed-transaction T3 is made of two ca-transaction, t31 and t32), their order and their simulation times are different. But they can be matched with each other semantical Iy at timed-transaction level. A matching between an expected value and an actual value should take count of it, too).
  • Such a process for s-DCP with enhanced accuracy using transaction-level s-DCP is called "s-DCP accuracy enhancement by transaction transformation".
  • Such s- DCP enhancement by transaction transformation is possible with the dynamic information obtained from a simulation model at higher level of abstraction during the execution of a local simulation if s-DCP is a simulation model at higher level of abstraction.
  • a local design object for a local simulation is executed on a hardware-based verification platform (for example, an FPGA board connected to a computer with simulation acceleration capability) and s-DCP of said local simulation is a DUV and TB at higher level of abstraction
  • a hardware-based verification platform for example, an FPGA board connected to a computer with simulation acceleration capability
  • s-DCP of said local simulation is a DUV and TB at higher level of abstraction
  • it is more general said s-DCP is not simulated in said hardware-based verification platform, but simulated in a computer connected to it for generating expected inputs and expected outputs.
  • the communication between said hardware-based verification platform where said local design object exists and said computer where TB exists is possible in either signal level or transaction level (for the case of transaction level, a transactor should be realized in said hardware-based verification platform).
  • Said simulation method with expected input and expected output can increase not only the simulation performance of distributed parallel simulation using two or more processors, but also the performance of simulation with a single processor which has two or more processes or threads so that there are inter ⁇ process communication overhead and process synchronization overhead because those overheads are also greatly reduced.
  • TPE-based parallel simulation is possible.
  • s-DCP DPE-based parallel simulation is possible.
  • TEP-based parallel simulation the entire simulation time is decomposed into two or more simulation-time sub-intervals (we'll call these slices), and each of slices is simulated independently.
  • DEP-based parallel simulation the entire design object(DUV and TB) is partitioned into two or more smaller design objects, and each of these design objects are simulated by each of local simulators in distributed parallel fashion.
  • usage method 1 the state information of a model at higher level of abstraction is collected at one or more specific simulation points or periods in time and translated into the state information of a model at lower level of abstraction at one or more those specific simulation points or periods (for detail on the translation, see Korean patent application 10-2005-116706), and the simulation with a model at lower level of abstraction is performed in parallel over entire slices or for some special slice.
  • the state information of two or more models at mixed level of abstraction is collected at one or more specific simulation points or periods in time and the state information of a model at lower level of abstraction is extracted from it (the state information of two or more models at mixed level of abstraction) at one or more those specific simulation points or periods, and the simulation with a model at lower level of abstraction is performed in parallel over entire slices or for some special slice (See Fig. 6).
  • the detailed explanation for TPE will be omitted in this present invention because the detailed can be found in Korean patent application 10-2005-116706 and 10-2006-19738.
  • the accuracy of t-DCP obtained at higher level of abstraction could be low, therefore it may be necessary to increase its accuracy.
  • the state information of a model at higher level of abstraction saved in front-end simulation from simulation time T_f to simulation time T_r needs to set at T_f (or at earlier than t_f), i.e. forcing the state value, and release at T_jr, i.e. releasing the state value, for the model while maintaining its input information unchanged after T_r as the simulation time advances to a certain time T_s.
  • the design state information at T_s is t-DCP with enhanced accuracy (if there are a source of an user clock in DUV, e.g. PLL, the value of this signal at T_r should be unchanged after T_r). If there are two or more asynchronous user clocks and there is some event in an user clock between T_r and T_s, the above process should be repeated.
  • the simulation method proposed in the present invention can increase the simulation speed at the simulation with a model at lower level of abstraction using the simulation result from the simulation with a model at the higher level or mixed level of abstraction, but also examine the model consistency between a model at higher level of abstraction and a model at lower level of abstract ion.
  • both front-end simulation and back-end simulation can use same design at a specific level of abstraction, but in general two designs at two different levels of abstraction.
  • front-end simulation whose purpose to obtain s ⁇ DCP or t-DCP fast as much as possible
  • a model at higher level of abstraction is used.
  • back-end simulation which is for the original simulation
  • a model at lower level of abstraction is used (But, as already mentioned, front-end simulation is not mandatorily necessary because s-DCP for a distributed-processing-based parallel simulation could be a model at higher level of abstraction, or an optimized model for faster simulation).
  • ⁇ 72> For executing a simulation, i.e. front-end simulation, executed in advance fast, it is possible to run a distributed-processing-based parallel simulation using s-DCP obtained from even earlier simulation, or a conventional distributed parallel simulation.
  • the active local simulations (this could be even a single simulation S_s) in a distributed- processing-based parallel simulation could be only for those local design objects modified (and possibly some local design object such as TB design object) from the beginning of simulation, i.e. simulation time 0, to the simulation time ts, and then all local simulations (including local simulation S 1 Ci) changed from S_s without simulation compilation) become active for all local design objects only after ts.
  • each of inactive local simulations should restore the state information of corresponding local design objects saved in the previous simulation performed before the design modification (It is very important to decide the right time for ts, which should be located far from the simulation time 0 as much as it can, and up to which the simulation result of unmodified local design objects should be same as one performed before the design modification.
  • Korean patent application 10-2004- 93310 Korean patent application 10-2004- 93310.
  • we will call this kind of simulation method using both distributed-processing-based parallel simulation and incremental simulation “distributed-processing-based parallel simulation using incremental simulation” or “distributed-processing-based parallel simulation method using incremental simulation”. The detail of incremental simulation can be found in Korean patent application 10-2004-93310.
  • a physical prototype instead of VP is built for verifying in the in-circuit or in-system environment instead of with TB.
  • the verification speed with physical prototypes is very high (for example, VP can run at 1 MHz at most, but physical prototype can run at multiple MHz at least and more than 100 MHz at best), but the debugging becomes extremely difficult due to the very limited visibility and controllability.
  • the main reason for limited visibility and controllability of physical prototypes basically comes from the fact that they are operated in the in-circuit or in-system environment so that the control for getting the visibility and controllability is much more difficult than simulation or simulation acceleration.
  • the debugging for DUV in the prototype which is running in the in-circuit or in-system environment needs to set the debugging window for the visibility in which there is a debugging reference point in time, and to examine the values of one or more signals in DUV within the debugging window.
  • the debugging reference point in time must be located at the end part of the debugging window (hereafter, we'll call this pre-trigger debugging mode), at the middle part of the debugging window (hereafter, we'll call this mid-trigger debugging mode), or at the beginning part of the debugging window (hereafter, we'll call this post-trigger debugging mode) to debug a particular design error, Therefore, in the verification using physical prototypes, one of three debugging modes (pre-trigger debugging mode, mid-trigger debugging mode, or post-trigger debugging mode) could be chosen arbitrarily during the debugging process. Also, it is necessary to provide 100% visibility for the fast debugging of DUV or one or more design objects in DUV where there are one or more user clocks having no phase relationship.
  • the debugging method in the verification using physical prototypes instruments an instrumentation circuit for debugging or instrumentation code for debugging (to be defined later) into DUV, which is implemented in one or more FPGA or non-memory IC chips on the target board so that the input information (the values of all inputs and inouts of a specific design object for a specific time period) can be saved, and simultaneously the design state information (the values of all flipflop outputs, latch outputs, memory contents, and combinational feedback signals or variables in each of all closed combinational feedback loops at a specific time in the execution) can be saved while the target board is running at speed, and they (the input information and the design state information) are obtained later (for a simulation in a computer).
  • the input information the values of all inputs and inouts of a specific design object for a specific time period
  • the design state information the values of all flipflop outputs, latch outputs, memory contents, and combinational feedback signals or variables in each of all closed combinational feedback loops at a specific time in the execution
  • Saving design state information means to save the state information of DUV or one or more design objects in DUV into a separate storage in said FPGA or non-memory chips at the specific time while the target board is running at full speed in the in-circuit or in-system environment.
  • Obtaining design state information means to read the design state information saved in said chips into a computer so that it can be used for simulating DUV or one or more design objects in DUV (with Verilog simulator, VHDL simulator, SystemVeri log simulator, SystemC simulator, virtual prototype, etc). Saving input information and obtaining input information are similarly defined.
  • said chips and said computer are connected with a cable (for example, a USB cable connection between a JTAG port of FPGA and a USB port of computer, or a parallel cable connection between a JTAG port of FPGA and a parallel port of computer) and said chips are controlled by a software running in said computer (For detail, refer to JTAG interface document for Xilinx FPGA or Altera FPGA).
  • a cable for example, a USB cable connection between a JTAG port of FPGA and a USB port of computer, or a parallel cable connection between a JTAG port of FPGA and a parallel port of computer
  • the design state information of said design object is the values of all sequential elements at the specific time if there is no closed combinational feedback loop.
  • a specific design object is constructed by excluding memories, the design state information of said design object does not have any memory value, but if some outputs and inouts of memories are inputs and inouts of said design object, then the values of some outputs and inouts of memories are used for constructing the input information of said design object.
  • the input information is defined for a specific time period (tl, t2) (that is, from tl Io t2), and the design state information is defined at a specific time ti (Therefore, the every input event changes are recorded in the input information).
  • the method to determine the saving time of design state information is to use trigger IP( Intellectual Property) or some logic module providing similar feature (For example, ILA/IBA core provided in ChipScope from Xilinx, or trigger module provided SignalTap from Altera. Those can include some assertion logic which will be explained later). Also, the firing time of one or more triggers can be determined by the assertion logic, which is synthesized and implemented from one or more assertion statements using 0VL(0pen Verification Library), PSL(Property Specification Language), SVA(SystemVerilog Assertion), or proprietary assertion technique. In this case, it can be thought the assertion logic does the role of trigger module, and the time at which the assertion is fired could be the debugging reference point in time.
  • the debugging reference point in time in HW/SW co- verification could be determined by the occurrence of special situation (for example, a privilege instruction executed) which is resulted from the SW execution, or one (for example, an interrupt occurred) which is resulted from the HW execution. If the debugging reference point in time is determined by the occurrence of special situation from SW side or HW side, 100% visibility for HW part implemented in one or more FPGA or non-memory chips is provided within a debugging window.
  • special situation for example, a privilege instruction executed
  • one for example, an interrupt occurred
  • the debugging reference point in time could be a reference point for both HW part and SW part so that 100 visibility for HW part (by the method in this present invention) and 100% visibility for SW part (by any of the traditional in-circuit debuggers for processor) could be synchronized.
  • Said logic module for trigger handling that is included in the instrumentation circuit for debugging or the instrumentation code for debugging, can be generated automatically for the software in a computer which reads and analyzes a DUV. Or, if FPGA chips on a target board are Xilinx FPGA, saving the design state information without stopping the operation of the target board and obtaining the design state information is to use the readback capture capability of Xilinx, that uses Readback Capture Library Primitive such as CAPTURE_VIRTEX of Xilinx Virtex series.
  • the advantage of using Xilinx's readback capture capability for saving and obtaining the design state information is to decrease the overhead of extra logic for debugging because that capability is already built-in in FPGA chips, and make saving and obtaining the design state information of DUV or one or more design objects in DUV easier when there are more than one user clocks with no phase relation in DUV.
  • a paral lel-load/serial-scanout method is used for a general method for saving/obtaining the design state information, the parallel loading operation for a paral lel-load/serial- scanout register(see Fig.
  • each of user clocks must use each of user clocks as a loading clock for capturing the corresponding outputs of flipflops or latches in each clock domain without any timing errors.
  • the scan-out operation for the register must use single scan clock. Therefore the register should be consisted of flipflops having dual clock inputs (we'll call this kind of flipflop FF-dclk, in short), one for capturing and the other for scanning- out.
  • every FPGAs in the market do not have such flipflops. In this situation, the readback capture capability of Xilinx FPGA are very useful for debugging when erroneous behavior is non-deterministic, which is un ⁇ repeatable, or there are two or more user clock with no phase relation (More detailed explanation is given later).
  • CAP input port which is one of inputs of Readback Capture Library Primitive
  • one or more FPGA flipflop state information capturing times can be determined.
  • CAP input can be driven by a trigger output of a trigger module in the in-circuit or in-system environment.
  • the other way capturing and obtaining the design state information is to use two-level parallel-load/serial-scanout register.
  • the first level of this register is a parallel-loadable register (see Fig. 37) for parallel load, and its second level is a parallel-load/serial-scanout register for parallel load and serial scanout .
  • two-level parallel-load/serial-scanout register can be useful for debugging when erroneous behavior is non-deterministic, which means it is un-repeatable, or there are two or more user clock with no phase relation (More detailed explanation is given later).
  • FPGA flipflop state information represents the logic state of all FPGA flipflops in a chip
  • FPGA flipflop/meory state information FPGA flipflop/memory state information represents the logic state of all FPGA flipflops and BlockRAMs in a chip
  • partial memory reconstruction method the logical values of minimal memory input/output signals (such as memory address input, memory data input, memory read/write input, memory clock input, memory data out) of memories, which are either one or more FPGA embedded memories or one or more external memories attached to FPGA, are saved and obtained for a specific time period from ta to tb while FPGA is running at speed (the specific method for saving and obtaining is same as the method for saving and obtaining the input information explained later), and analyzed it later for partially reconstructing the contents of memories from ta to tb (For example, let's assume a memory have addresses from 00 to FF, and the data is 8 bit wide. Let's assume there are memory operations from ta to tb as follows.
  • the data 16 in hex is written at the address 04, the data 19 in hex written at the address 06, the data 21 in hex read from at the address 07, and the data 20 in hex written at the address 03 in the order.
  • the partial memory reconstruction method in this present invention reconstruct 19 in hex at the address 06, 21 in hex at the address 07, and XX(X: unknown) at all remaining addresses at ta).
  • the partially reconstructed memory contents at ta is used together with the design state information of DUV or, one or more design objects in DUV excluding the memory for the simulation with i t (the memory).
  • the technology transformation is needed for changing a gate-level net list using a specific standard cell library or gate-array library to a gate-level net list using a FPGA library, it is also not difficult to co-relate those signals or variables names as those names are unchanged or only changed with a specific name changing rules.
  • the corresponding IP of ChipScope from Xilinx or SignalTal from Altera the logic module of Identify from Synplicity providing the corresponding feature, the logic module of other commercial embedded logic analyzers providing the corresponding feature (such as ClearBlue from DAFCA, etc), or some logic module providing similar feature (basically, this logic module has a memory writing capability with an input data stream coming into an input port of DUV, or one or more design objects for a specific verification time period in the entire verification time, and a memory reading capability for reading written contents later, and this logic module is the part of said instrumentation logic for debugging or instrumentation code for debugging in this present invention) are instrumented to DUV in an automatic way, and then the input information is saved into the embedded memories(for example, BlockRAM) inside chip or massive external memories(one or more DDR-SDRAM's, SDRAM's, DRAM's, SRAM's, etc) first, and retrieved into a computer later.
  • the embedded memories for example, BlockRAM
  • BlockRAM embedded memories
  • Said logic module can be created by executing a SW in a computer so that it can be done automatically by reading and analyzing a DUV for debugging, or made as IP in a library and reused.
  • DUV in FPGA or non-memory chips on a target board is executed at speed in the in-circuit or in-system environment while the input sequence is provided from the outside of chips.
  • said instrumentation circuit for debugging or instrumentation code for debugging is also executing with DUV, it collects (in this present invention collecting means saving and obtaining) the input information of DUV, or one or more design objects in DUV for a specific time period from Ts to Te, (Ts, Te), and the design state information of DUV, or one or more design objects in DUV at one or more specific time Tr between Ts and Te in real time
  • Tr includes Ts and additionally one or more arbitrary time points between Ts and Te, or one or more one or more arbitrary time points between Ts and Te. But for specific example it is desirable Tr may be two time points between Ts and Te in the in-circuit or in-system environment, as explained later).
  • An example of method to determine the times of saving the design state information is to use a binary counter and a trigger module in said instrumentation circuit for debugging or instrumentation code for debugging, and its time is determined by the specific condition of the counter (for example, when the counter reaches its terminal count) and the use of event trigger or sequence trigger feature of trigger module.
  • Trigger module can be implemented by using ILA/IBA core (ILA, ILA/ACT, IBA/OPB, IBA/PLB) provided in ChipScope from Xilinx, trigger module provided SignalTap from Altera, or some logic module providing similar triggering feature.
  • Said logic module (the part of instrumentation logic for debugging or instrumentation code for debugging) can be created by executing a SW in a computer so that it can be done automatically by reading and analyzing a DUV for debugging. Therefore, in this present invention, we will call each of instrumented circuit to DUV, IP module, library cell, synthesizable HDL code, or any combination of these for collecting the input information and design state information, the instrumentation circuit for debugging or instrumentation code for debugging.
  • the instrumentation circuit for debugging or instrumentation code for debugging probing the design state information, which is consisted of flipflops and latches only in DUV, or one or more design objects in DUV, the flipflop/latch-probing instrumentation circuit for debugging or instrumentation code for debugging.
  • the instrumentation circuit for debugging or instrumentation code for debugging in this present invention could be classified into the instrumentation circuit for debugging or instrumentation code for debugging already built-in during the manufacturing of FPGA, SOC, or ASIC chips, and the instrumentation circuit for debugging or instrumentation code for debugging instrumented into DUV and programmed with DUV during FPGA programming.
  • TB and DFS Design For Simulation
  • DFS Design For Simulation
  • the visibility for all clock domains can be made by a single simulation execution, not multiple simulation executions for each clock domain if force/release statement, assign/deassign statement, force/release simulation command, or assign/deassign simulation command available in most of commercial simulators (such as NC-Verilog, VCS, ModelSim, etc) is used for driving said design state information and input information.
  • SDF which has an exact timing information about DUV
  • said simulation could be a timing simulation so that a debugging for timing error is even possible.
  • Fig. 1 is a schematic diagram of an example of the design verification apparatus in this present invention.
  • Fig. 2 is another schematic diagram of an example of the design verification apparatus in this present invention.
  • Fig. 3 is a schematic diagram of an example of the hierarchy of an ESL model and its corresponding hierarchy of a RTL model.
  • Fig. 4 is a schematic diagram of an example of the hierarchy of a RTL model and its corresponding hierarchy of a GL model.
  • a design object 387 which has boundary scan cells, shows the additional hierarchy at
  • Fig. 5 is a schematic diagram of an example of the execution of a distributed parallel simulation whose environment is consisted of two or more computers connected a computer network.
  • Fig. 6 is a schematic diagram of an example of the execution of a time-sliced parallel simulation, where t-DCP is obtained at the front-end simulation with a model of higher level of abstraction, and back-end simulation is executed in temporal Iy paral IeI .
  • Fig. 7 is a schematic diagram of an example of the execution of a distributed-processing-based parallel simulation, where s ⁇ DCP is obtained at the front-end simulation with a model of higher level of abstraction, and back-end simulation is executed in spatially parallel.
  • Fig. 8 is a schematic diagram of an example of the components consisting of a behavior of the instrumentation code added for a parallel-processing-based distributed simulation in this present invention.
  • the figure shows the components consisting of a behavior of the instrumentation code(62) added to a part of a model for verification(404) (if each part is combined together, then a complete model M is formed) executed in each local simulator or local hardware-based verification platform(in this present invention
  • the hardware- based verification platform includes hardware emulators, simulation accelerators, or prototyping boards such as Palladium/Extreme series from Cadence, Vstation series, Hammer series from Tharas, Gemini series from Fortelink, SystemExplorer series from Aptix, ZeBu series from EVE, HES series from Aldec, CHIPit series from ProDesign, HAPS series from HARDI, IP porter series fromS2Cinc, Nitro-Sim from Liga-Systems, etc) in the distributed parallel simulation environment.
  • said instrumentation code(62) should be added to a model so that its functionality should be one provided by those components(control module of run-with-expected-input&output/run-with-actual-input&output(54) , selection module of expected-input/actual-input(56) , compare module of expected- output/actual-output(58) , compare module of expected-input/actual-input(59), s-DCP generation/save module(60)) in Fig. 8.
  • a control module of run- with-expected-input & output / run-with-actual-input & output produces an output to a selection module of expected-input/actual-input(56) so that it selects either expected input or actual input, or an control for a roll-back if roll-back is required before selecting actual input, by using the inputs from a compare module of expected-output/actual-outputC ⁇ ) , a compare module of expected-input /actual-input (59) , and a communication and synchronization module for distributed parallel simulation(64) and the its current status (therefore, a control module of run-with-expected-input & output / run-with- act ⁇ al-input & output (54) has its own status variable inside to know the current running mode of the local simulation is either the run with expected input and expected output mode or the run with actual input and actual output mode) .
  • a control module of run- with-expected-input & output / run-with-actual-input & output(54) sends an output to a selection module of expected-input/actual-input(56) so that it selects expected input) and received an input from a compare module of expected-output/actual-output (58) such that the current actual output and expected output does not match
  • a control module of run-with-expected- input & output / run-with-actual-input & output(54) produces an output to a selection module of expected-input/actual-input(56) so that it selects actual input, and switches its current status variable from the run with expected input and expected output mode to the run with actual input and actual output mode.
  • a control module of run-with- expected-input & output / run-with-actual-input & output(54) sends an output to a selection module of expected-input/actual-input(56) so that it selects actual input) and received an input from a compare module of expected- input/actual-input (59) such that the actual outputs and expected outputs match more than a certain number of times
  • a control module of run-with- expected-input & output / run-with-actual-input & output(54) produces an output to a selection module of expected-input/actual-input(56) so that it selects expected input, and switches its current status variable from the run with actual input and actual output mode to the run with expected input and expected output mode.
  • a control module of run-with-expected-input & output / run-with-actual- input & output sends two outputs(possibi lity of run_with_expected_data, and necessity of run_with_actual_data) to a communication and synchronization module for distributed parallel simulation(64) for notifying its current status to other local simulations, and controls an s-DCP generation/save module(60) so that an s-DCP generation/save module(60) produces expected input or expected output with a right timing.
  • a compare module of expected-output/actual-output compares the expected output stored in an s-DCP generation/save module(60) with the actual output generated from a part of a model for design verification executed in a local simulator(404) during the local simulation. If the comparison matches, it informs of the match to a control module of run-with-expected-input & output / run-with-actual-input & output(54).
  • the comparison If the comparison does not match, it informs of the mis-match to a control module of run-with-expected-input & output / run-with-actual-input & output(54), and sends the present local simulation time for possible roll-back to a communication and synchronization module for distributed parallel simulation(64) so that a communication and synchronization module for distributed parallel simulation(64) can send it to other local simulations.
  • a compare module of expected-input/actual-input compares the expected input stored in an s-DCP generation/save module(60) with the actual input driven by other local simulations, which are coming from a communication and synchronization module for distributed parallel simulation(64) during the local simulation. If the comparison matches to certain number of times, it informs of the match to a control module of run-with-expected-input & output / run-with-actual-input & output (54).
  • a compare module of expected- output/actual-output (58) or a compare module of expected-input/actual-input (59) can compare the expected values with actual values not only in the unit of bit signal and the unit of absolute simulation time, but also in the unit of transaction and the unit of relative simulation time by time alignment method and s-DCP accuracy enhancement by transaction transformation method.
  • a selection module of expected-input/actual-input selects one of the actual input from a communication and synchronization module for distributed parallel simulation(64) and the expected input from an s-DCP generation/save module(60), and applies this to a part of a model for design verification executed in a local simulator(404) as input.
  • the instrumentation code(62) must be synthesizable, or a part of a model for design verification executed in a local simulator(404) is executed in a local simulator, the instrumentation code(62) must be simulation-executable. Therefore the instrumentation code could be written in HDL(for example, Verilog, VHLD, etc), SDL(for example, SystemC, SystemVerilog, etc), C/C++, or any combination of those. Moreover, the verification software in this present invention automatically generates the instrumentation code(62). In the example depicted in Fig.
  • the instrumentation code(62) is written in C/C++ or systemC so that it is interfaced with a part of a model for design verification executed in a local simulator(404) through VPI/PLI/FLI. But, as already explained, it is possible that the instrumentation code(62) can be written partially in HDL, and the rest of it in C/C++ or SystemC.
  • Fig. 9 is a schematic diagram of an example of a cycle-accurate bus operation in the unit of signal at RTL and its corresponding cycle-accurate bus operation in the unit of transaction at TL.
  • Fig. 10 is a schematic diagram of an example showing design objects in the ESL model and its corresponding design objects in the RTL model depicted in Fig. 3.
  • Fig. 11 is a schematic diagram of an example of a generation of design objects D0_t_mixed(i ) at mixed level of abstraction such that each of design objects in the ESL model depicted in Fig. 10 is replaced a corresponding design object in the RTL model.
  • Fig. 12 is a schematic diagram of an example of an execution of a distributed-processing-based parallel simulation with a RTL model as back-end simulation by using the design state information collected at one or more simulation times and periods when six independent parallel front-end simulations with six mixed design objects D0_t_mixed(l) , D0_t_mixed(2), .., D0_t_mixed(6) depicted in Fig. 11 are being executed.
  • Fig. 13 is a schematic diagram of an example of the design and verification process using progressive refinement from the initial level of abstraction to the final level of abstraction.
  • Fig. 14 is a schematic diagram of an example of a progressive refinement process from a RTL model to a GL model .
  • Fig. 15 is a schematic diagram of an example of a distributed-processing- based parallel simulation or time-sliced parallel simulation with a model at lower level of abstraction using s-DCP or t-DCP when the verification progresses from the verification with a TL model to the verification with a GL model through the verification with a RTL model by progressive refinement.
  • DCP is either s-DCP or t-DCP.
  • Fig. 16 is a schematic diagram of an example of a part of a model for the simulation method in this present invention.
  • Fig. 17, Fig. 18 and Fig. 19 are schematic diagrams of an example of parts of the instrumentation code added to the model partially depicted in Fig. 16 for a distributed-processing-based parallel simulation by the verification software in this present invention.
  • Fig. 20 is a schematic diagram of an example of a combined method of distributed-processing-based parallel execution/singular execution.
  • FIG. 21 is a schematic diagram of an example of the situation in which the synchronization overhead and communication overhead between a simulator and a hardware-based verification platform of simulation acceleration is reduced by distributed-processing-based parallel execution in this present invention.
  • the conventional simulation acceleration can be thought as a distributed parallel simulation which has two local simulations.
  • One of these two local simulation is the local simulation acceleration using a local hardware-based verification platform, in which a synthesizable design object in a model (DUV, in general) is implemented on one or more FPGA or Boolean processors
  • the other is the local simulation using a local simulator, in which a non- synthesizable design object in a mode1(TB, in general) is executed.
  • the local hardware-based verification platform and the local simulator are connected physical ly(for example, with PCI) so that they are co-simulated. Therefore, the distributed-processing-based parallel simulation proposed in this present invention can be applied to the conventional simulation acceleration for reducing the communication overhead and synchronization overhead between a hardware-based verification platform and a simulator without any modi ficat ion.
  • ⁇ 129> For roll-back of design objects executed in a hardware-based verification platform, the roll-back feature of commercial hardware-based verification platforms (for example, Palladium series/Extreme series from Cadnece, Vstation series from Mentor, ZeBu series from EVE, Gemini series from Fortelink, Hammer series from Tharas, etc) can be used, the output- probing/input-probing method in US. patent 6,701,491 can be used, or the shadow register for flipflops and latches in said design objects can be used for saving and restarting the corresponding design state information.
  • commercial hardware-based verification platforms for example, Palladium series/Extreme series from Cadnece, Vstation series from Mentor, ZeBu series from EVE, Gemini series from Fortelink, Hammer series from Tharas, etc
  • the output- probing/input-probing method in US. patent 6,701,491 can be used
  • the shadow register for flipflops and latches in said design objects can be used for saving and restarting the corresponding design
  • Each of local simulations in the distributed parallel simulation presented in this present invention could be executed by a simulator, or a hardware-based verification plat form(simulat ion accelerator, hardware emulator, or prototyping board) if the model for verification is entirely or partially synthesizable.
  • the simulator could be an event-driven Verilog simulator, SystemVeri log simulator, VHDL simulator or SystemC simulator, a cycle-based SystemC simulator, VHDL simulator, Verilog simulator or SystemVeri log simulator, an instruct ion-level simulator, a Vera simulator, an e simulator, or any arbitrary simulator for IC.
  • one or more local simulations in a distributed parallel simulation could be event-driven simulation, and other local simulation could be cycle- based simulation (For example, the on-chip bus design object(420) in Fig. 5 is executed by a cycle-based simulation, other design objects(380, 381, 382, 383, 384, 385) are executed by event-driven simulations. Or, some design object, say 381, can be implemented in FPGA and executed in simulation acceleration mode, and other design objects are executed by event-driven simulations). Of course, all local simulations can be executed by event- driven simulation (such event-driven distributed parallel simulation is called PDES(Parallel Distributed Event-driven Simulation)), or all local simulations can be executed by cycle-based simulation, etc.
  • the distributed parallel simulation environment in this present invention could be configured in various forms.
  • Fig. 22 is a schematic diagram of an example of logical connection topology among two or more local simulators installed in two or more computers for a distributed-processing-based parallel simulation in this present invention. There could be other logical connection topology among two or more local simulators installed in two or more computers for a distributed-processing- based paral IeI simulation.
  • Fig. 23 is a schematic diagram of an example of a distributed parallel simulation environment which is consisted of two or more computers and two or more simulators. This environment could be an environment of distributed- processing-based parallel simulation in this present invention.
  • Fig. 24 is an example of the overall flow diagram of the conventional distributed parallel simulation. Therefore, it is possible to exist other flow diagrams for the distributed parallel simulation.
  • Fig 25 is an example of the overall flow diagram of the distributed- processing-based parallel simulation in this present invention.
  • Fig. 25 the overall flow diagram of the distributed-processing-based parallel simulation is explained, and it consists of eight sub-blocks excluding start and end.
  • step S200 .a model for distributed-processing-based parallel simulation is imported.
  • step S202 the design objects for each of local simulations are produced by partitioning a model for distributed-processing-based parallel simulation.
  • the instrumentation code for design object of each local simulation or simulation environment(for example, SW server module that exists in the central computer in the logical connecting structure of star topology) in the distributed parallel simulation is generated.
  • step S204 the front- end simulation model for obtaining S-DCP is imported.
  • step S206 the simulation model for the front-end simulation is compiled.
  • step S208 the simulation model for the front-end simulation is compiled.
  • step S208 S- DCP is collected in the execution of front-end simulation.
  • the flow proceeds to the step S210.
  • step S210 each of design objects for each of local simulations in the distributed-processing-based parallel simulation are compiled.
  • step S212 the instrumentation codes added at step S202 are also compiled together.
  • Fig. 33 is another example of the overall flow diagram of the distributed- processing-based parallel simulation. Therefore, it is possible to exist other flow diagrams for the execution of distributed-processing-based parallel simulation. Also, the execution order of the sub-blocks can be changed if it is not disturb the correct execution of the entire processes, or more than one sub-block(for example, S201, S203, S211, or S213 in Fig. 33) can be executed at the same time if it is also not disturb the correct execution of the entire processes.
  • Fig 33 The flow diagram of Fig 33 is consisted of four sub-blocks excluding the start and end.
  • step S201 a model for the distributed-processing-based parallel simulation is imported.
  • step S203 the design objects for each of local simulations are produced by partitioning a model for distributed-processing-based parallel simulation.
  • the instrumentation code for design object of each local simulation or simulation environment (for example, SW server module that exists in the central computer in the logical connecting structure of star topology) in the distributed parallel simulation is generated.
  • the flow proceeds to the step S211.
  • the instrumentation code added at step 203 includes DUV and TB at higher level of abstraction than that of any of design objects for local simulation in s-DCP.
  • step S211 each of design objects for each of local simulations in the distributed-processing-based parallel simulation are compiled.
  • step S213. the instrumentation codes added at step S203 are also compiled together.
  • Fig. 26 is an example of the overall flow diagram for the execution of the local simulation for the execution of distributed-processing-based parallel simulation (sub-block S212 in Fig. 25) in this present invention. Therefore, it is possible to exist other flow diagrams for the execution of distributed- processing-based parallel simulation. Also, the execution order of the sub- blocks can be changed if it is not disturb the correct execution of the entire processes, or more than one sub-block can be executed at the same time if it is also not disturb the correct execution of the entire processes.
  • step S398 the present simulation time is set to 0, and the flow proceeds to step S402.
  • step S402 if a checkpoint should be generated at the present simulation time and there is no checkpoint generated earlier, then a checkpoint is generated at the present simulation time. After generating a checkpoint, examine the occurrence of any possible rollback from other local simulation and go to step S410 if occurred. Otherwise, the flow proceeds to step S418 if the present simulation time of local simulation is equal to the actual roll-forward time, or it proceeds to step S422 if it is greater than or equal to the simulation end time.
  • step S406 if the correct output and the expected output obtained at step S402 match, proceed to step S404, or proceed to step S408 if no match.
  • step S404 set the present simulation time of the local simulation to the event time of actual output (the time of actual output change happening), and proceed to step S402.
  • step S408 pause the simulation temporarily, send an occurrence of possible rollback and the present simulation timeCthe possible roll-back time) to other local simulations, then proceed to step S410.
  • step S410 all present simulation times of local simulations, in which the possible roll-back occurred, are obtained and the necessity of roll-back/roll-forward and the roll-back/roll-forward time for the local simulation is determined, from the all rollback produce possibility local simulations. Then, the flow proceeds to step S412.
  • every local simulation times T_rb (t_rb(l), t_rb(2), .., t_rb(N ⁇ l) , t_rb(N)), (where, t_rb(i) indicates the possible roll-back time for local simulation i, in which the possible roll-back occurred) become a set of possible roll-back times.
  • the actual roll-back time T_rb(FINAL) is the smallest value among t_rb(l), t_rb(2), .., t_rb(N-l) , and t_rb(N) . i.e.
  • T_rb(FINAL) min(t_rb(l), t_rb(2), .., t_rb(N-l), t_rb(N))). If the present simulation time of a specific local simulation LP(k) , t_c(k), is equal or greater than T_rb(FINAL), a roll-back requires for said local simulation LP(k) . It t_c(k) is smaller than T_rb(FINAL), then a roll-forward requires for LP(k) .
  • step S412 if roll-back is needed, the flow proceeds to S414. Or, the flow proceeds to S416.
  • step S416 if roll-forward is needed, the flow proceeds to step S402, otherwise, the flow proceeds to step S418.
  • step S414 the roll-back for the local simulation is executed, and then the flow proceeds to step S418.
  • step S4108 the simulation with actual input is performed, and pass its actual output, that is the result of the simulation, to other local simulation which is the actual output as its input. At the same time, the comparison is made with the actual input and the expected input. If the present simulation time of local simulation is equal to the simulation end time, then the flow proceeds to the end for termination. If not, the flow proceeds to step S420.
  • step S420 the number of matches of the comparison between the actual input and the expected input made at step S418 is equal to a predetermined number (for example, three times), then the flow proceeds to step S421. Otherwise, the flow proceeds to step S418. At step S422, if all of other local simulations end, then terminate the local simulation. Otherwise, the flow proceeds to step S424. At step S424, if the roll-back is required, then the flow proceeds to step S426. Otherwise, the flow proceeds to step S422. At step S426, the roll-back is performed after determining the actual roll-back time, then proceed to step S418.
  • a predetermined number for example, three times
  • Fig. 27 is an another example of the overall flow diagram for the execution of the local simulation for the execution of distr iados-processing-based parallel simulation (sub-block S212 in Fig. 25). Therefore, it is possible to exist other flow diagrams for the execution of distr iaded-processing-based parallel simulation. Also, the execution order of the sub-blocks can be changed if it is not disturb the correct execution of the entire processes, or more than one sub-block can be executed at the same time if it is also not disturb the correct execution of the entire processes.
  • step S298 the present simulation time is set to 0, and the flow proceeds to step S300.
  • step S300 if the possible roll-back is occurred in other local simulation, the flow proceeds to step S310, otherwise proceeds to step S302.
  • step S302 if a checkpoint should be generated at the present simulation time and there is no checkpoint generated earlier, then a checkpoint is generated at the present simulation time.
  • the flow proceeds to step S318 if the present simulation time of local simulation is equal to the actual roll-forward time, or it proceeds to step S322 if it is greater than or equal to the simulation end time.
  • step S306 if the correct output and the expected output obtained at step S302 match, proceed to step S304, or proceed to step S308 if no match.
  • step S304 set the present simulation time of the local simulation to the event time of actual output (the time of actual output change happening), and proceed to step S302.
  • step S308 pause the simulation temporarily, send an occurrence of possible rollback and the present simulation time(the possible roll-back time) to other local simulations, then proceed to step S310.
  • step S310 all present simulation times of local simulations, in which the possible roll-back occurred, are obtained and the necessity of rol 1-back/rol 1-forward and the roll-back/rol 1- forward time for the local simulation is determined, from the all rollback produce possibility local simulations. Then, the flow proceeds to step S312.
  • every local simulation times T_rb (t_rb(l), t_rb(2), .., t_rb(N-l), t_rb(N)), (where, t_rb(i) indicates the possible roll-back time for local simulation i, in which the possible roll-back occurred) become a set of possible roll-back times.
  • the actual roll-back time T_rb(FINAL) is the smallest value among t_rb(l), t_rb(2) , .., t_rb(N-l), and t_rb(N) . i.e.
  • T_rb(FINAL) min(t_rb(l), t_rb(2), .., t_rb(N-l) , t_rb(N))). If the present simulation time of a specific local simulation LP(k) , t_c(k), is equal or greater than T_rb(FINAL), a roll-back requires for said local simulation LP(k) . It t_c(k) is smaller than T_rb(FINAL), then a roll-forward requires for LP(k) .
  • step S312 if roll-back is needed, the flow proceeds to S314. Or, the flow proceeds to S316.
  • step S316 if roll-forward is needed, the flow proceeds to step S302, otherwise, the flow proceeds to step S318.
  • step S314 the roll-back for the local simulation is executed, and then the flow proceeds to step S318.
  • step S318 the simulation with actual input is performed, and pass its actual output, that is the result of the simulation, to other local simulation which is the actual output as its input. At the same time, the comparison is made with the actual input and the expected input. If the present simulation time of local simulation is equal to the simulation end time, then the flow proceeds to the end for termination. If not, the flow proceeds to step S320.
  • step S320 the number of matches of the comparison between the actual input and the expected input made at step S318 is equal to a predetermined number (for example, three times), then the flow proceeds to step S321. Otherwise, the flow proceeds to step S318. At step S322, if all of other local simulations end, then terminate the local simulation. Otherwise, the flow proceeds to step S324. At step S324, if the roll-back is required, then the flow proceeds to step S326. Otherwise, the flow proceeds to step S322. At step S326, the roll-back is performed after determining the actual roll-back time, then proceed to step S318.
  • a predetermined number for example, three times
  • Fig. 28 and Fig. 29 show other examples of the flow diagrams of the execution of the distributed- processing-based parallel simulation using a SW sever module, which exists in a central computer that is in charge of controlling and connecting local simulation during the execution of the distributed-processing-based parallel simulation(S212 in Fig. 25) in the star connection topology (refer Fig. 22).
  • Fig 28 is an example of the overall flow diagram for the execution of a local simulation by a local simulator.
  • Fig.29 is an example of the overall flow diagram of the SW sever module in said central computer.
  • the execution order of the sub-blocks can be changed if it is not disturb the correct execution of the entire processes, or more than one sub- block can be executed at the same time if it is also not disturb the correct execution of the entire processes.
  • step S598 the present simulation time is set to 0, and the flow proceeds to step S502.
  • step S502 the information of present simulation time is generated. If a checkpoint should be generated at the present simulation time and there is no checkpoint generated earlier, then a checkpoint is generated at the present simulation time.
  • step S518 the present simulation time of local simulation is equal to the actual roll-forward time, or it proceeds to step S522 if it is greater than or equal to the simulation end time. If none of these holds, run forward a local simulation with an expected input, obtain an actual output, and compare the actual output with an expected output. Then, the flow proceeds to step S506.
  • step S506 if the correct output and the expected output obtained at step S502 match, proceed to step S504, or proceed to step S508 if no match.
  • step S504 set the present simulation time of the local simulation to the event time of actual output (the time of actual output change happening), and proceed to step S502.
  • step S508 pause the simulation temporarily, send an occurrence of possible rollback and the present simulation timeCthe possible roll-back time) to SW server module, then proceed to step S510.
  • step S510 actual roll-back/roll-forward is determined from SW server module. Then, the flow proceeds to step S512.
  • step S512 if roll-back is needed, the flow proceeds to S514. Or, the flow proceeds to S516.
  • step S516 if roll- forward is needed, the flow proceeds to step S502, otherwise, the flow proceeds to step S518.
  • step S514 the roll-back for the local simulation is executed, and then the flow proceeds to step S518.
  • step S5108 the simulation with actual input is performed, and pass its actual output, that is the result of the simulation, to other local simulation which is the actual output as its input through SW server module. At the same time, the comparison is made with the actual input and the expected input. If the present simulation time of local simulation is equal to the simulation end time, then the flow proceeds to the end for termination. If not, the flow proceeds to step S520.
  • step S520 the number of matches of the comparison between the actual input and the expected input made at step S518 is equal to a predetermined number (for example, three times), then the flow proceeds to step S521. Otherwise, the flow proceeds to step S518. At step S522, if all of other local simulations end, then terminate the local simulation. Otherwise, the flow proceeds to step S524. At step S524, if the roll-back is required, then the flow proceeds to step S526. Otherwise, the flow proceeds to step S522. At step S526, the roll-back is performed after determining the actual roll-back time, then proceed to step S518.
  • a predetermined number for example, three times
  • Fig. 29 is a schematic diagram of an example of a flow for SW server module of for local simulations in distributed-processing-based parallel simulation.
  • the flow diagram is consisted of ten sub-blocks excluding start and end.
  • the present simulation time is set to 0, and the flow proceeds to step S602.
  • step S602 a control is given to run all of local simulations in expected-input/expected-output run mode, and to obtain present simulation time of each of local simulations. Then, the flow proceeds to step S606.
  • step S606 if any possible roll-back occurs in any of local simulations in expected-input/expected-output run mode, the flow proceeds to step S608. Otherwise, the flow proceeds to step S604.
  • step S604 if the present simulation time of every local simulations reaches to the simulation end time, proceed to the termination. Otherwise, the flow proceeds to step S602.
  • step S608 the actual roll-back/roll-forward time is determined from possible roll-back times from local simulations, in which possible roll-backs are occurred.
  • step S608 the run mode between the expected-input/expected-output run mode and the actual-input/actual-output run mode is determined.
  • roll-back or roll-forward is selected for each of local simulations whose run mode will be the actual-input/actual-output run mode.
  • step S610 if there are one or more local simulations, which satisfy the switching condition of actual-input/actual- output run to expected-input/expected-output run, the flow proceeds to step S612. Otherwise, the flow proceeds to step S614. At step S612, the switch of actual-input/actual-output run to expected-input/expected-output run in the local simulations capable of switching, is occurred. The flow proceeds to step S614.
  • step S614 a control is given to run forward for qualified local simulations in expected-input/expected-output run mode, and for other local simulations in actual-input/actual-output run mode. Also, the control is also given to obtain present simulation time of each of local simulations. Then, the flow proceeds to step S616. At step S616, if any possible roll-back occurs in any of local simulations in expected-input/expected-output run mode, the flow proceeds to step S608. Otherwise, the flow proceeds to step S618. At step S618, if the present simulation time of every local simulations reaches to the simulation end time, proceed to the termination. Otherwise, the flow proceeds to step S610.
  • the SW server module controls individually the execution of local simulation with actual-input/actual-output or expected-input/expected-output in a distributed-processing-based parallel simulation.
  • the execution of local simulation with expected-input/expected-output in a distributed- processing-based parallel simulation is performed only when all of local simulations can be executed with expected-inputs and expected-outputs, which may provide a limited performance improvement, but with simpler control.
  • Fig. 30 and Fig. 31 are schematic diagrams of an example of pseudo code for the behavior of some components in Fig. 8. If such code is added in synthesizable, it can be implemented in a hardware-based verification platform.
  • the simulation in this present invention includes not only the simulation execution using one or more simulators, but also the execution of one or more simulation acceleration execution using one or more hardware- based verification platforms. Therefore, a local simulation in a distributed- processing-based parallel simulation can be executed by a local simulator, a local hardware-based verification platform, or a combination of a local simulator and a local hardware-based verification platform.
  • the distributed-processing-based parallel simulation can be applied not only the in a refinement process from TL to GL, but also in a refinement process from other level of abstraction.
  • Fig. 32 is a schematic diagram of another example of components for the behavior of the instrumentation code of the distributed-processing-based parallel simulation in this present invention.
  • Fig. 32 is similar to Fig. 8, but the difference is the s ⁇ DCP generation/save module(60), which has a design object containing DUV and TB at higher level of abstract ion(53) than that of the local design object, execute it together with the local design object to generate expected inputs and expected outputs dynamically, and use them.
  • the difference of methods between Fig. 32 and Fig. 8 is similar to two automatic simulation result comparison methods in conventional simulation, which are the method using a golden model and the mothod using a golden vector.
  • expected inputs and expected outputs used in a distributed- processing-based parallel simulation in this present invention for reducing the communication overhead and synchronization overhead of local simulations they can be obtained from the dynamic information of previous simulation, or dynamically generated from a model at higher level of abstraction.
  • an optimized design object containing TB and DUV for faster simulation can be used to dynamically generate expected inputs and expected outputs.
  • a model at the specific level of abstraction for example, a RTL model, a RTL/GL mixed model, a TLM/RTL mixed model, a TLM/RTL/GL mixed model, etc
  • the level of abstraction of the model, or one or more design objects in the model can be raised automatically, the model, or one or more ?()
  • design objects in the model can be optimized for faster simulation, or the combination of two methods can be used for obtaining s-DCP (for example, using VSP from Carbon Design Systems, or VTOC from TenisonEDA, or using methods proposed in Korean patent application 10-2005-95803, 10-2005-116706, 10-2006-19738, or code optimization methods in HDL simulators, etc).
  • VSP Carbon Design Systems
  • VTOC TenisonEDA
  • FIG. 34 is a schematic diagram of an example of the design verification apparatus in this present invention.
  • a computer(835) has in-circuit/in-system debugging software(832) and HDL simulator(834), and is connected to an arbitrary target board(827) through a debugging interface cable(828)(for example, USB cable, parallel cable, PCI cable, etc).
  • a debugging interface cable(828) for example, USB cable, parallel cable, PCI cable, etc.
  • One or more FPGA or non- memory IC chips(838) are mounted on said arbitrary target board(827) so that they are operated in the in-circuit or in-system environment.
  • the instrumentation circuit for debugging or instrumentation code for debugging(902) is implemented in said one or more FPGA or non-memory IC chi ⁇ s(838) together with DUV(842) so that the design state information and the input information of DUV, or one or more design objects in DUV are saved and obtained by said instrumentation circuit for debugging or instrumentation code for debugging(902) in the in-circuit or in-system environment of said target board(827), and 100% visibility for DUV, or one or more design objects in DUV is provided by simulation using a simulator(834) .
  • the design state information and input information can be read into a computer(835) by putting a software component in said in-circuit/in-system debugging software(832), and using said software component which controls a JTAG logic inside of said FPGA or non-memory IC chip(838) through a debugging interface cable(28) with JTAG protocol-compatible signals(TDI, TDO, TCK, TMS). More detailed information can be found in technical documents about JTAG of corresponding FPGA or non-memory IC chips, e.g. JTAG-related technical document about Xilinx FPGA or Altera FPGA.
  • JTAG Boundary Scan application note from Xilinx e.g. ChipScope user manual and related technical documents from Xilinx, Altera ⁇ ] SignalTap user manual and related technical documents from Altera, Identify user manual and related technical documents from Synplicity, Configuration and Readback of VIRTEX FPGAs Using JTAG Boundary Scan application note from Xilinx. Also, it can be also found in other patents(US patent 6,182,247, 6,247,147, 6,286,114, 6,389,558, 6,460,148, 6,704,889, 6,760,898, 6,826,717, 7,036,046).
  • Fig. 35 is a schematic diagram of the system structure of ChipScope and ILA core from Xilinx.
  • Fig. 36 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including a parallel-load/serial-scanout register added to a user design.
  • Fig. 37 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including a parallel-load register added to a user design.
  • Fig. 38 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including a two-level parallel-load/serial-scanout register added to a user design.
  • the efficient debugging is possible with the instrumentation circuit for debugging or the instrumentation code for debugging for Xilinx FPGA chips having readback capture capability or other FPGA or non-memory IC chips having similar capability depicted in Fig. 37 as an example, or other FPGA or non-memory IC chips having no such similar capability depicted in Fig. 38 as an example, when said chips are non-deterministically malfunctioning or there are two or more user clocks with no phase relation.
  • ⁇ 19O> For saving the design state information of DUV, or one or more design objects in DUV having one user clock, or two or more user clocks with no phase relation, which are implemented into Xilinx FPGA chips having readback capture capability or other FPGA or non-memory IC chips having similar capability depicted in Fig. 37 as an example, additionally instrumented circuit for debugging or additionally instrumented code for debugging isn't required as the already built-in instrumentation circuit can be used.
  • readback_capture macro (such as CAPTURE_VIRTEX primitive, CAPTURE_SPARTAN primitive, etc) is used in a design state information and input information saving and obtaining controller including a controller for loading time of a parallel-load register(890) , and the 1-2 loading enable signaKto be explained later) is fed to CAP input of readback_capture macro and a user clock m, which drives said 1-2 loading enable signal (said 1-2 loading enable signal is synchronized to said user clock m) , is fed to CLK input of readback_capture macro.
  • readback_capture macro such as CAPTURE_VIRTEX primitive, CAPTURE_SPARTAN primitive, etc
  • the driving user clock must be determined for each of flipflops or latches in DUV, or one or more design objects in DUV with a fully or partially automatic method so that said flipflops and latches in said design objects, which requires 100% signal visibility, are grouped by their driving user clock (we'll call each of groups a region of a clock domain).
  • the driving user clock There are something to consider more in detail. First, if a flipflop or a latch is driven by a combination of two or more usei clocks (e.g. driven by a combinational output from two user clocks), then a combination of two or more user clocks must be declared as a new user clock. Second, the objects for 100% visibility are signals, i.e.
  • the instrumentation circuit for debugging or the instrumentation code for debugging by using the loading signal (load_i-synchronized-to-userclock_i in Fig. 37 and Fig. 38) synchronized to the user clock of corresponding clock domain (In Fig. 37 and Fig. 38, the signal, loadjn-synchronized-to- userclockjn, is an 1-2 loading enable signal).
  • FPGA or non-memory IC chips has a built-in instrumentation circuit, or a serial-scanout register of two-level parallel-load/serial-scanout register as in the case of Fig. 38 where FPGA or non-memory IC chips has no such built-in instrumentation circuit (This is necessary for supporting pre-trigger debugging mode or mid-trigger debugging mode, and more detail will be fol lowed) .
  • the instrumentation circuit for debugging or the instrumentation code for debugging should include a design state information and input information saving and obtaining controller in which has a controller for controlling the loading time(890 in Fig. 37, and 880 in Fig. 38).
  • the debugging with one of three debugging modes should be possible after the execution is over in the in-circuit or in-system environment (but, the debugging mode is selected prior to the execution).
  • Specially useful debugging modes among three are pre-trigger debugging mode and mid-trigger debugging mode because the visibility over the user design is needed much earHer(for example, 1,000 cycles earlier) than a debugging reference point in time W(t) in most of cases (Fig. 42 (a) and (b)).
  • a binary counter with a fixed bit length counts up its number with said user clock selected (such counter can be put in 890 of Fig. 37, or 880 of Fig. 38) in the in-circuit or in-system environment.
  • a specific predetermined value for example, its terminal count value
  • trigger module can be also put in 890 of Fig. 37, or 880 of Fig.
  • the instrumentation circuit for debugging or the instrumentation code for debugging has the design state information of DUV, or one or more design objects in DUV, which requires 100% visibility, at two points in time, L12(tl) and L12(t2) (L12(tl) is earlier than L12(t2)), that are both earlier than the time at which the trigger fires (let's call the time at which the trigger fires the time of trigger-fired) .
  • the pre-trigger debugging mode or mid-trigger debugging mode can be determined by the length of 1-2 loading interval. More specifically, if the bit length of the binary counter is relatively short, then the mid-trigger debugging mode is possible, and if the bit length of the binary counter is relatively long, then the pre-trigger debugging mode is possible
  • 1-2 loading is defined as the saving operation of the design state information of DUV, or one or more design objects in DUV, which requires 100% visibility, at "two points" in time, which both are earlier than the time of erroneous behavior revealed W(t), into a storage location of the instrumentation circuit for debugging or the instrumentation code for debugging by using the instrumentation circuit for debugging or the instrumentation code for debugging.
  • the instrumentation circuit for debugging or instrumentation code for debugging for 1-2 loading is defined as the instrumentation circuit for debugging or the instrumentation code for debugging, with which said 1-2 loading is performed.
  • 1 loading is defined as the saving operation of the design state information of DUV, or one or more design objects in DUV, which requires 100% visibility, at "one point", which is earlier than the time of erroneous behavior revealed W(t), in time into a storage location of the instrumentation circuit for debugging or the instrumentation code for debugging by using the instrumentation circuit for debugging or the instrumentation code for debugging.
  • the instrumentation circuit for debugging or instrumentation code for debugging for 1 loading is defined as the instrumentation circuit for debugging or the instrumentation code for debugging, with which said 1 loading is performed.
  • Fig. 39 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including CAPTURE_VIRTEX primitive for using the readback capture capability of Xilinx.
  • Fig. 40 is a schematic diagram of another example of the design verification apparatus in this present invention.
  • a computer(835) has in-circuit/in-system debugging software(832) and model checker(855) , and is connected to an arbitrary target board(827) through a debugging interface cable(828).
  • One or more FPGA or non-memory IC chips(838) are mounted on said arbitrary target board(827) so that they are operated in the in-circuit or in-system environment.
  • the instrumentation circuit for debugging or instrumentation code for debugging(902) is implemented in said one or more FPGA or non-memory IC chips(838) together with DUV(842) so that the design state information of DUV, or one or more design objects in DUV are saved and obtained by said instrumentation circuit for debugging or instrumentation code for debugging(902) in the in-circuit or in-system environment of said target board(827), and semi-formal verification can be performed for DUV, or one or more design objects in DUV by said model checker(855) .
  • Fig. 41 is a schematic diagram of another example of the design verification apparatus in this present invention.
  • Fig. 42 is a schematic diagram of an example of situations in which a debugging reference point in time is located in a debugging window.
  • Fig. 43 is a schematic diagram of another example of the instrumentation circuit for debugging or instrumentation code for debugging including a paral lel-load/serial-scanout register added to a user design.
  • an advantageous effect of present invention is to reduce the total verification time and increase the verification efficiency by executing the verification for a model at lower level of abstraction fast by using the simulation result of a model at higher level of abstraction when a complex design start at ESL.
  • ⁇ 2i2> Another advantageous effect of present invention is to provide a systematic verification method through the progressive refinement from the system level to the gate level such that the high execution speed and 100% visibility are provided from simulation-based verification to physical-prototype-based verification.
  • Another advantageous effect of present invention is to provide a systematic verification method which can solve the degradation of verification performance as the progressive refinement goes clown to the low / O
  • Another advantageous effect of present invention is to allow the entire design and verification process using progressive refinement from the high level of abstraction to the low level of abstraction in a systematic and automatic way.
  • Another advantageous effect of present invention is to provide a verification method in which the model consistency is effectively maintained among two or more models existed at different levels of abstraction.
  • Another advantageous effect of present invention is to provide an efficient verification method through progressive refinement, in which a model at the low level of abstraction is efficiently verified using a model at the high level of abstraction as a reference model.
  • Another advantageous effect of present invention is to provide a method for increasing the speed of distributed parallel simulation by eliminating synchronization overhead and communication overhead.
  • Another advantageous effect of present invention is to provide a systematic and consistent fast debugging method for correcting design errors in the entire verification phase from simulation-based verification to physical prototype-based verification.
  • Another advantageous effect of present invention is to provide a high visibility and controllability throughout virtual prototypes or simulators for debugging the incorrect behavior of physical prototype in which DUV is operated in the in-circuit or in-system environment where DUV has one or more user clocks.
  • Fig. 1 is a schematic diagram of an example of the design verification apparatus in this present invention.
  • Fig. 2 is another schematic diagram of an example of the design verification apparatus in this present invention.
  • Fig. 3 is a schematic diagram of an example of the hierarchy of an ESL model and its corresponding hierarchy of a RTL model.
  • Fig. 4 is a schematic diagram of an example of the hierarchy of a RTL model and its corresponding hierarchy of a GL model.
  • Fig. 5 is a schematic diagram of an example of the execution of a distributed parallel simulation whose environment is consisted of two or more computers connected a computer network.
  • Fig. 1 is a schematic diagram of an example of the design verification apparatus in this present invention.
  • Fig. 2 is another schematic diagram of an example of the design verification apparatus in this present invention.
  • Fig. 3 is a schematic diagram of an example of the hierarchy of an ESL model and its corresponding hierarchy of a RTL model.
  • Fig. 4 is a schematic diagram of an example
  • FIG. 6 is a schematic diagram of an example of the execution of a time-sliced parallel simulation, where t-DCP is obtained at the front-end simulation with a model of higher level of abstraction, and back-end simulation is executed in temporally parallel.
  • Fig. 7 is a schematic diagram of an example of the execution of a distributed-processing-based parallel simulation, where s-DCP is obtained at the front-end simulation with a model of higher level of abstraction, and back-end simulation is executed in spatially parallel.
  • Fig. 8 is a schematic diagram of an example of the components consisting of the instrumentation code added for a parallel-processing-based distributed simulation in this present invention.
  • Fig. 8 is a schematic diagram of an example of the components consisting of the instrumentation code added for a parallel-processing-based distributed simulation in this present invention.
  • FIG. 9 is a schematic diagram of an example of a cycle-accurate bus operation in the unit of signal at RTL and its corresponding cycle-accurate bus operation in the unit of transaction at TL.
  • Fig. 10 is a schematic diagram of an example showing design objects in the
  • Fig. 11 is a schematic diagram of an example of a generation of design objects D0_t_iiiixecl(i ) at mixed level of abstraction such that each of design objects in the ESL model depicted in Fig, 10 is replaced a corresponding design object in the RTL model.
  • Fig. 12 is a schematic diagram of an example of an execution of a distributed-processing-based parallel simulation with a RTL model as back-end simulation by using the design state information collected at one or more simulation times and periods when six independent parallel front-end simulations with six mixed design objects DO_tjiiixed(l) , D0_t_mixed(2) , .., D0_t_mixed(6) depicted in Fig. 11 are being executed.
  • Fig. 13 is a schematic diagram of an example of the design and verification process using progressive refinement from the initial level of abstraction to the final level of abstraction.
  • Fig. 14 is a schematic diagram of an example of a progressive refinement process from a RTL model to a GL model.
  • Fig. 15 is a schematic diagram of an example of a distributed-processing- based parallel simulation or time-sliced parallel simulation with a model at lower level of abstraction using s-DCP or t-DCP when the verification progresses from the verification with a TL model to the verification with a GL model through the verification with a RTL model by progressive refinement.
  • Fig. 16 is a schematic diagram of an example of a part of a model for the simulation method in this present invention.
  • Fig. 17 is a schematic diagram of an example of a part of the instrumentation code added to the model partially depicted in Fig. 16 for a distributed- processing-based parallel simulation by the verification software in this present invention.
  • Fig. 18 is a schematic diagram of an example of another part of the instrumentation code added to the model partially depicted in Fig. 16 for a distributed-processing-based parallel simulation by the verification software in this present invention.
  • Fig. 19 is a schematic diagram of an example of another part of the instrumentation code added to the model partially depicted in Fig. 16 for a distributed-processing-based parallel simulation by the verification software in this present invention.
  • Fig. 20 is a schematic diagram of an example of a combined method of distributed-processing-based parallel execution/singular execution.
  • Fig. 21 is a schematic diagram of an example of the situation in which the synchronization overhead and communication overhead between a simulator and a hardware-based verification platform of simulation acceleration is reduced by distributed-processing-based parallel execution in this present invention.
  • Fig. 19 is a schematic diagram of an example of another part of the instrumentation code added to the model partially depicted in Fig. 16 for a distributed-processing-based parallel simulation by the verification software in this present invention.
  • Fig. 20 is a schematic diagram of an example of a combined method of distributed-processing-based parallel execution/singular execution.
  • Fig. 21 is a schematic diagram of an example of the situation in which the
  • FIG. 22 is a schematic diagram of an example of logical connection topology among two or more local simulators installed in two or more computers for a distributed-processing-based parallel simulation in this present invention.
  • Fig. 23 is a schematic diagram of an example of a distributed parallel simulation environment which is consisted of two or more computers and two or more simulators.
  • Fig. 24 is an example of the overall flow diagram of the conventional distributed parallel simulation.
  • Fig 25 is an example of the overall flow diagram of the distributed- processing-based parallel simulation in this present invention.
  • Fig. 26 is an example of the overall flow diagram for the execution of the local simulation for the execution of distributed-processing-based parallel simulation in this present invention.
  • Fig. 27 is another example of the overall flow diagram for the execution of the local simulation for the execution of distributed-processing-based parallel simulation in this present invention.
  • Fig 28 is an example of the overall flow diagram for the execution of a local simulation by a local simulator in the star connection topology.
  • Fig.29 is an example of the overall flow diagram of the SW sever module in a central computer in the star connection topology.
  • Fig. 30 is a schematic diagram of an example of pseudo code for the behavior of some components in Fig. 8.
  • Fig. 31 is a schematic diagram of an example of pseudo code for the behavior of the other components in Fig. 8. o
  • Fig. 32 is a schematic diagram of another example of components for the behavior of the instrumentation code of the distributed-processing-based parallel simulation in this present invention.
  • Fig. 33 is another example of the entire flow diagram for a distributed- processing-based parallel simulation in this present invention.
  • Fig. 34 is a schematic diagram of an example of the design verification apparatus in this present invention.
  • Fig. 35 is a schematic diagram of the system structure of ChipScope and ILA core from Xi linx.
  • Fig. 36 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including a parallel- load/serial-scanout register added to a user design.
  • Fig. 37 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including a parallel-load register added to a user design.
  • Fig. 38 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including a two-level parallel-load/serial-scanout register added to a user design.
  • Fig. 39 is a schematic diagram of an example of the instrumentation circuit for debugging or instrumentation code for debugging including CAPTURE_VIRTEX primitive for using the readback capture capability of Xi linx.
  • Fig. 40 is a schematic diagram of another example of the design verification apparatus in this present invention.
  • Fig. 41 is a schematic diagram of another example of the design verification apparatus in this present invention.
  • Fig. 42 is a schematic diagram of an example of situations in which a debugging reference point in time is located in a debugging window.
  • Fig. 43 is a schematic diagram of another example of the instrumentation circuit for debugging or instrumentation code for debugging including a parallel-load/serial-scanout register added to a user design.
  • ⁇ 279> 64 Communication and synchronization module for distributed parallel simulation
  • ⁇ 280> 333 SW server module existed in a central computer, which is responsible for controlling and connecting the local simulations of distributed parallel simulation in the star connection topology
  • ⁇ 292> 404 A part of a model for design verification executed in a local simulator
  • ⁇ 293> 420 0n-chip bus design object including a bus arbiter and an address decoder in a RTL model
  • ⁇ 306> 684 Giga-bit LAN card
  • ⁇ 3i2> 838 FPGA or non-memory IC chip
  • ⁇ 3i8> 848 Flipflop or latch in a design object that requires 100% visibility
  • ⁇ 3i9> 850 Parallel-load/serial-scanout register
  • ⁇ 32i> 854 Two-level parallel-load/serial-scanout register
  • ⁇ 323> 856 Interface between a target board and a computer
  • ⁇ 329> 882 Clock domain of user clock 1 in a two-level parallel-load/serial- scanout register
  • ⁇ 330> 884 Clock domain of user clock 2 in a two-level parallel-load/serial- scanout register
  • ⁇ 33i> 886 Clock domain of user clock m in a two-level parallel-load/serial- scanout register
  • ⁇ 332> 890 State information and input information saving and obtaining controller including a controller for loading time of a parallel-load register
  • ⁇ 336> 900 State information and input information saving and obtaining controller including a controller for loading time of a parallel-load register with a single clock
  • ⁇ 34i> 910 Binary counter ⁇ 342> 912 : Control FSM for saving and obtaining the state information and input information ⁇ 343> 914 : JTAG macro

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)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un appareil de vérification dans lequel le circuit d'instrumentation ou le code d'instrumentation est ajouté à la conception d'origine par le logiciel de vérification, cette opération s'effectuant dans un ordinateur. La simulation comprend une simulation frontale et une simulation dorsale. La simulation frontale peut utiliser un modèle équivalent à un niveau différent d'abstraction, ou un modèle de simulation pour la simulation dorsale. La simulation dorsale utilise le résultat de simulation de la simulation frontale, de sorte qu'elle peut exécuter une ou plusieurs séries de simulation séquentiellement ou en parallèle. En variante, des modèles à un niveau inférieur d'abstraction sont simulés conjointement avec un modèle à niveau plus élevé d'abstraction, en parallèle, au moyen de deux ou plusieurs simulateurs. L'invention concerne également le procédé de débogage à haute visibilité et possibilité de contrôle de vérification, au moyen d'un prototype physique dans l'environnement dans le circuit ou dans le système, procédé caractérisé en ce qu'on effectue une simulation au moyen d'un simulateur ou d'un prototype virtuel, et en ce que l'information dynamique est collectée en temps réel à partir d'un prototype physique.
PCT/KR2006/004059 2005-10-10 2006-10-10 Appareil de verification a base dynamique permettant une verification a partir d'un niveau de systeme electronique au niveau grille, et procede de verification utilisant cet appareil Ceased WO2007043786A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/089,665 US20090150136A1 (en) 2005-10-10 2006-10-10 Dynamic-based verification apparatus for verification from electronic system level to gate level, and verification method using the same
US12/987,481 US8781808B2 (en) 2005-10-10 2011-01-10 Prediction-based distributed parallel simulation method

Applications Claiming Priority (26)

Application Number Priority Date Filing Date Title
KR10-2005-0095803 2005-10-10
KR20050095803 2005-10-10
KR20050098941 2005-10-18
KR10-2005-0098941 2005-10-18
KR20050122926 2005-12-12
KR10-2005-0122926 2005-12-12
KR10-2005-0126636 2005-12-19
KR20050126636 2005-12-19
KR10-2006-0006079 2006-01-20
KR20060006079 2006-01-20
KR10-2006-0019738 2006-03-01
KR20060019738 2006-03-01
KR10-2006-0037412 2006-04-25
KR20060037412 2006-04-25
KR20060038426 2006-04-27
KR10-2006-0038426 2006-04-27
KR20060043611 2006-05-15
KR10-2006-0043611 2006-05-15
KR10-2006-0048394 2006-05-29
KR20060048394 2006-05-29
KR1020060068811A KR20070108303A (ko) 2005-10-10 2006-07-23 체계적 점진적 구체화를 통한 전자시스템수준에서부터게이트수준까지의 검증 방법
KR10-2006-0068811 2006-07-23
KR10-2006-0092574 2006-09-22
KR1020060092574A KR101328263B1 (ko) 2005-10-10 2006-09-22 체계적 점진적 구체화를 통한 전자시스템수준에서부터게이트수준까지의 검증 방법
KR10-2006-0092573 2006-09-22
KR1020060092573A KR20070062399A (ko) 2005-12-12 2006-09-22 시뮬레이션-기반의 타이밍/함수적 디버깅 및 검증 방법

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US12/089,665 A-371-Of-International US20090150136A1 (en) 2005-10-10 2006-10-10 Dynamic-based verification apparatus for verification from electronic system level to gate level, and verification method using the same
US12/987,481 Continuation-In-Part US8781808B2 (en) 2005-10-10 2011-01-10 Prediction-based distributed parallel simulation method

Publications (1)

Publication Number Publication Date
WO2007043786A1 true WO2007043786A1 (fr) 2007-04-19

Family

ID=37942984

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2006/004059 Ceased WO2007043786A1 (fr) 2005-10-10 2006-10-10 Appareil de verification a base dynamique permettant une verification a partir d'un niveau de systeme electronique au niveau grille, et procede de verification utilisant cet appareil

Country Status (1)

Country Link
WO (1) WO2007043786A1 (fr)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012512831A (ja) * 2008-12-18 2012-06-07 ジヤンセン・フアーマシユーチカルズ・インコーポレーテツド ガンマシークレターゼモジュレーターとしての置換二環式イミダゾール誘導体
US8835482B2 (en) 2009-05-07 2014-09-16 Janssen Pharmaceuticals, Inc. Substituted indazole and aza-indazole derivatives as gamma secretase modulators
US8946426B2 (en) 2009-02-06 2015-02-03 Janssen Pharmaceuticals, Inc. Substituted bicyclic heterocyclic compounds as gamma secretase modulators
US8946266B2 (en) 2009-07-15 2015-02-03 Janssen Pharmaceuticals, Inc. Substituted triazole and imidazole derivatives as gamma secretase modulators
US8987276B2 (en) 2011-03-24 2015-03-24 Janssen Pharmaceuticals, Inc. Substituted triazolyl piperazine and triazolyl piperidine derivatives as gamma secretase modulators
US9079886B2 (en) 2010-01-15 2015-07-14 Janssen Pharmaceuticals, Inc. Substituted triazole derivatives as gamma secretase modulators
US9115143B2 (en) 2011-07-15 2015-08-25 Janssen Pharmaceuticals, Inc. Substituted indole derivatives as gamma secretase modulators
US9181245B2 (en) 2012-05-16 2015-11-10 Janssen Pharmaceuticals, Inc. Substituted pyrido[1,2-a]pyrazines and substituted pyrido[1,2-a][1,4]diazepines for the treatment of (inter alia) Alzheimer's disease
US10112943B2 (en) 2012-12-20 2018-10-30 Janssen Pharmaceutica Nv Substituted imidazoles as gamma secretase modulators
US10246454B2 (en) 2013-01-17 2019-04-02 Janssen Pharmaceutica Nv Substituted 3,4-dihydro-2H-pyrido[1,2-a]pyrazine-1,6-diones as gamma secretase modulators
CN110288160A (zh) * 2019-06-27 2019-09-27 北京华如科技股份有限公司 一种基于平行仿真的态势动态预测方法
US10426424B2 (en) 2017-11-21 2019-10-01 General Electric Company System and method for generating and performing imaging protocol simulations
US10562897B2 (en) 2014-01-16 2020-02-18 Janssen Pharmaceutica Nv Substituted 3,4-dihydro-2H-pyrido[1,2-a]pyrazine-1,6-diones as gamma secretase modulators
CN113569476A (zh) * 2021-07-23 2021-10-29 西安中锐创联科技有限公司 一种利用动态参数混合实现混合维联合仿真的方法
CN114021440A (zh) * 2021-10-28 2022-02-08 中航机载系统共性技术有限公司 一种基于matlab的fpga时序仿真验证方法及装置
CN115630485A (zh) * 2022-10-09 2023-01-20 国核自仪系统工程有限公司 基于bfm的仿真系统及其验证方法、设备和介质
CN115906729A (zh) * 2021-08-19 2023-04-04 华润微集成电路(无锡)有限公司 针对存储器异步接口实现预定时序控制电路设计的方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5801938A (en) * 1994-10-03 1998-09-01 Nasser Kalantery Data processing method and apparatus for parallel discrete event simulation
KR20010057800A (ko) * 1999-12-23 2001-07-05 오길록 단일 시스템에서의 병렬 프로그램 시뮬레이션 방법
JP2001256267A (ja) * 2000-03-09 2001-09-21 Hitachi Ltd 並列分散シミュレーション方式
US6345240B1 (en) * 1998-08-24 2002-02-05 Agere Systems Guardian Corp. Device and method for parallel simulation task generation and distribution

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5801938A (en) * 1994-10-03 1998-09-01 Nasser Kalantery Data processing method and apparatus for parallel discrete event simulation
US6345240B1 (en) * 1998-08-24 2002-02-05 Agere Systems Guardian Corp. Device and method for parallel simulation task generation and distribution
KR20010057800A (ko) * 1999-12-23 2001-07-05 오길록 단일 시스템에서의 병렬 프로그램 시뮬레이션 방법
JP2001256267A (ja) * 2000-03-09 2001-09-21 Hitachi Ltd 並列分散シミュレーション方式

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012512831A (ja) * 2008-12-18 2012-06-07 ジヤンセン・フアーマシユーチカルズ・インコーポレーテツド ガンマシークレターゼモジュレーターとしての置換二環式イミダゾール誘導体
JP2015164969A (ja) * 2008-12-18 2015-09-17 ジヤンセン・フアーマシユーチカルズ・インコーポレーテツドＪａｎｓｓｅｎ Ｐｈａｒｍａｃｅｕｔｉｃａｌｓ，Ｉｎｃ． ガンマシークレターゼモジュレーターとしての置換二環式イミダゾール誘導体
US8946426B2 (en) 2009-02-06 2015-02-03 Janssen Pharmaceuticals, Inc. Substituted bicyclic heterocyclic compounds as gamma secretase modulators
US8835482B2 (en) 2009-05-07 2014-09-16 Janssen Pharmaceuticals, Inc. Substituted indazole and aza-indazole derivatives as gamma secretase modulators
US8946266B2 (en) 2009-07-15 2015-02-03 Janssen Pharmaceuticals, Inc. Substituted triazole and imidazole derivatives as gamma secretase modulators
US9079886B2 (en) 2010-01-15 2015-07-14 Janssen Pharmaceuticals, Inc. Substituted triazole derivatives as gamma secretase modulators
US9145399B2 (en) 2010-01-15 2015-09-29 Janssen Pharmaceuticals, Inc. Substituted bicyclic triazole derivatives as gamma secretase modulators
US8987276B2 (en) 2011-03-24 2015-03-24 Janssen Pharmaceuticals, Inc. Substituted triazolyl piperazine and triazolyl piperidine derivatives as gamma secretase modulators
US9115143B2 (en) 2011-07-15 2015-08-25 Janssen Pharmaceuticals, Inc. Substituted indole derivatives as gamma secretase modulators
US9181245B2 (en) 2012-05-16 2015-11-10 Janssen Pharmaceuticals, Inc. Substituted pyrido[1,2-a]pyrazines and substituted pyrido[1,2-a][1,4]diazepines for the treatment of (inter alia) Alzheimer's disease
US10112943B2 (en) 2012-12-20 2018-10-30 Janssen Pharmaceutica Nv Substituted imidazoles as gamma secretase modulators
US10246454B2 (en) 2013-01-17 2019-04-02 Janssen Pharmaceutica Nv Substituted 3,4-dihydro-2H-pyrido[1,2-a]pyrazine-1,6-diones as gamma secretase modulators
US10562897B2 (en) 2014-01-16 2020-02-18 Janssen Pharmaceutica Nv Substituted 3,4-dihydro-2H-pyrido[1,2-a]pyrazine-1,6-diones as gamma secretase modulators
US10426424B2 (en) 2017-11-21 2019-10-01 General Electric Company System and method for generating and performing imaging protocol simulations
CN110288160A (zh) * 2019-06-27 2019-09-27 北京华如科技股份有限公司 一种基于平行仿真的态势动态预测方法
CN113569476A (zh) * 2021-07-23 2021-10-29 西安中锐创联科技有限公司 一种利用动态参数混合实现混合维联合仿真的方法
CN113569476B (zh) * 2021-07-23 2023-12-01 西安中锐创联科技有限公司 一种利用动态参数混合实现混合维联合仿真的方法
CN115906729A (zh) * 2021-08-19 2023-04-04 华润微集成电路(无锡)有限公司 针对存储器异步接口实现预定时序控制电路设计的方法
CN114021440A (zh) * 2021-10-28 2022-02-08 中航机载系统共性技术有限公司 一种基于matlab的fpga时序仿真验证方法及装置
CN114021440B (zh) * 2021-10-28 2022-07-12 中航机载系统共性技术有限公司 一种基于matlab的fpga时序仿真验证方法及装置
CN115630485A (zh) * 2022-10-09 2023-01-20 国核自仪系统工程有限公司 基于bfm的仿真系统及其验证方法、设备和介质

Similar Documents

Publication Publication Date Title
US8781808B2 (en) Prediction-based distributed parallel simulation method
US20090150136A1 (en) Dynamic-based verification apparatus for verification from electronic system level to gate level, and verification method using the same
US20130179142A1 (en) Distributed parallel simulation method and recording medium for storing the method
CN113255267B (zh) 使用现场可编程门阵列fpga重新编程检测仿真中的时序违规
KR100491461B1 (ko) ＳｏＣ 설계 검증을 위한 방법 및 장치
US20080306721A1 (en) Dynamic-Verification-Based Verification Apparatus Achieving High Verification Performance and Verification Efficiency and the Verification Methodology Using the Same
WO2007043786A1 (fr) Appareil de verification a base dynamique permettant une verification a partir d'un niveau de systeme electronique au niveau grille, et procede de verification utilisant cet appareil
TW201003444A (en) Compact circuit-simulation output
EP4298546A1 (fr) Permutation de vues en temps réel dans une simulation à signaux mixtes
KR20040063846A (ko) 다양한 검증 플랫폼들의 통합 사용을 지원하는 검증 장치및 이를 이용한 검증 방법
Mathur et al. Functional equivalence verification tools in high-level synthesis flows
Alexandrescu et al. Towards optimized functional evaluation of see-induced failures in complex designs
US20230409788A1 (en) Synchronizing distributed simulations of a circuit design
US20050076282A1 (en) System and method for testing a circuit design
US11023635B1 (en) Sequence of frames generated by emulation and waveform reconstruction using the sequence of frames
WO2005093575A1 (fr) Appareil de verification dynamique permettant d'obtenir une performance et une efficacite de verification elevees et procede de verification associe
WO2025137300A1 (fr) Procédé de réduction des coûts matériels d'extraction de profils d'énergie dans une émulation à l'aide de techniques statistiques
Tuzov et al. Speeding-up simulation-based fault injection of complex hdl models
Zhang et al. GL0AM: GPU Logic Simulation Using 0-Delay and Re-simulation Acceleration Method
Gong et al. Modeling dynamically reconfigurable systems for simulation-based functional verification
Popescu et al. Innovative verification strategy reduces design cycle time for high-end SPARC processor
KR101328263B1 (ko) 체계적 점진적 구체화를 통한 전자시스템수준에서부터게이트수준까지의 검증 방법
Abadir et al. Formal verification successes at Motorola
KR20060066634A (ko) 검증 성능과 검증 효율성을 높이는 동적검증 기법 방식의검증 장치 및 이를 이용한 검증 방법론
Boyer et al. Multiple SimpleScalar processors, with introspection, under SystemC

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12089665

Country of ref document: US

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS (EPO FORM 1205A OF 160708)

122 Ep: pct application non-entry in european phase

Ref document number: 06799139

Country of ref document: EP

Kind code of ref document: A1