KR20070039857A - Verification method from electronic system level to gate level using systematic progressive refinement - Google Patents

Abstract

The present invention relates to a verification apparatus for systematically and efficiently performing design verification for the design of a digital system, which is carried out through multiple specification processes from a high level of abstraction, and a systematic and effective verification method using the same. .

In the present invention, the verification software of the present invention, which is executed on any computer, adds additional code or additional circuits to the original design code, and generates a model having a higher level of abstraction than the model dictated by the original design code if necessary. In order to perform the above-described one or more simulations for the high level of abstraction model obtained through an automated or manual modeling process using the verification software of the present invention, the code is different from the original design code. . Simulation performance is divided into front-end simulation using the same model with the same level of abstract model or the end simulation, and the back-end simulation using the model with the same abstract level model or the front-end simulation. Back-end simulation using the simulation results effectively enables one or more simulations to be performed sequentially on one or more computers using one or more simulators, as well as mutually using two or more simulators running on two or more computers. By enabling independent parallel execution as much as possible, two or more computers running on two or more computers can be simulated with models of higher abstraction levels. It enables significant reduction in overall verification time and the verification cost by using a simulator by enabling the maximum cross-independent parallel performed, and able to greatly improve the efficiency of verification.

Hardware verification

Description

Verification Method from Electronic System Level to Gate Level Using Systematic Progressive Refinement}

1 is a diagram schematically showing an example of a design verification apparatus according to the present invention.

2 is a diagram schematically showing another example of the design verification apparatus according to the present invention;

if.

3 is an example of a hierarchical structure of an ESL model, and an example of a hierarchical structure of an RTL model corresponding thereto.

Schematically shown in comparison with FIG.

4 is an example of the hierarchical structure of the RTL model and an example of the hierarchical structure of the GL model corresponding thereto.

Schematically shown in comparison with FIG.

Fig. 5 shows that two or more computers are connected to a computer network by performing distributed parallel simulation.

Figure schematically showing an example of the situation to be carried out in the determined situation.

6, t-DCP is obtained and added in the preceding simulation using the abstraction high-level model.

The post-simulation using the imaginary low-level model is performed by time division parallel execution.

Figure schematically showing an example.

Fig. 7 shows the acquisition and addition of s-DCP in the front-end simulation using the abstraction high-level model.

The post-simulation using the low-level model is performed by distributed parallelism.

Figure schematically showing an example.

8 is an additional code added for the distributed parallelism simulation presented in this patent.

Figure schematically shows an example of the configuration of the components constituting the interior of the card.

Fig. 9 shows cycle-correct bus operation status and signal in signal units at the register transfer level.

Outline an example of a cycle-correct bus behavior in a transaction unit at the transaction level.

As shown.

FIG. 10 shows design objects in the ESL model illustrated in FIG. 3 and corresponding RTL models in FIG.

A schematic representation of design objects.

FIG. 11 shows each of the design objects in the ESL model illustrated in FIG. 10 in the corresponding RTL model.

Replace the intermediate design objects DO_t_mixed (i) with the design object

Figure schematically showing an example of generating.

FIG. 12 is an independent jar of six mixed simulations using the six mixed design objects DO_t_mixed (1), DO_t_mixed (2), .., DO_t_mixed (6) illustrated in FIG.

Column execution and one or more simulation points or intervals in the execution process

The state of the RTL model, which is the post-simulation stage, is obtained using the state information collected from

A diagram schematically showing an example of performing the simulation by time division parallel execution.

Fig. 13 shows the abstraction from the first level of abstraction through a gradual specification process.

A schematic illustration of an example of a design and verification process that proceeds at a level.

Fig. 14 shows the RTL model from the transaction level model through a gradual specification process.

A diagram schematically showing an example of a process of generating a model at the gate level through.

Fig. 15 shows a model of cycle accuracy transaction level through a gradual specification process.

Verification using gate level model through verification using RTL model

In the process up to using s-DCP or t-DCP

Simulations can be performed in either distributed or time-division parallel execution.

Schematically showing an example of the thing.

Figure 16 schematically illustrates a portion of an example model for running a simulation method in the present patent.

As shown.

Fig. 17 is a diagram showing the execution of the example model illustrated in Fig. 16 by distributed parallelism simulation.

An example of a situation where an additional code is added using the verification software of the present patent

Partially schematic drawing

18 is a diagram illustrating the execution of the example model illustrated in FIG. 16 by distributed parallelism simulation.

An example of a situation where an additional code is added using the verification software of the present patent

Another partially schematic drawing

Fig. 19 is a diagram of executing the example model illustrated in Fig. 16 by distributed parallelism simulation.

An example of a situation where an additional code is added using the verification software of the present patent

Another partially schematic drawing

20 schematically shows an example of a performance situation of a distributed processing parallel execution / single performance mixed method.

As shown.

21 shows that the simulation through the acceleration of the simulation is carried out by distributed processing parallel execution.

Sync overhead and communication overhead between the simulator and the hardware-based verification platform.

Schematically illustrating an example of a reducing situation.

Fig. 22 is a schematic of two or more for simulation of a distributed processing parallel execution scheme in the present patent.

Some examples of logical connection schemes of two or more local computers installed on a computer

Schematically showing them.

Fig. 23 shows two or more computers with distributed parallel simulations installed on these computers.

An example of distributed parallel simulation environment constructed using the above HDL simulators

Schematically showing a.

Fig. 24 schematically shows an example of an overall flow chart of a typical distributed parallel simulation.

Figure shown.

25 is an example of an overall flow chart of distributed processing parallel simulation in the present patent.

Schematic drawing.

Fig. 26 shows each local simulator for performing distributed processing parallel simulation in the present patent.

Schematically showing an example of a flowchart of performing a local simulation to be executed in a network.

Fig. 27 shows each local simulator for performing distributed processing parallel simulation in the present patent.

Schematically showing another example of a flowchart of performing a local simulation performed with a

drawing.

28 is a local simulation executed by a local simulator in a star logical connection structure.

Schematically illustrates an example of a flowchart of performance.

29 is performed by the SW server module existing in the central computer in the logical connection structure of the star system.

Figure schematically showing an example of a flow chart of the process.

30 is added for the distributed processing parallel simulation presented in this patent of FIG.

Counterfeit their behavior with respect to some of the components that make up the supplementary code.

Schematically illustrates an example dictated in a format;

FIG. 31 is added for the distributed parallelism simulation presented in this patent of FIG.

The other parts of the components that make up the supplementary code are collected from their behavior.

A diagram schematically showing an example dictated in Joecode format.

32 is an additional code added for the distributed parallelism simulation presented in this patent.

Schematically showing another example of the configuration of the components constituting the interior of the card

33 is another flowchart of the overall flow of the distributed processing parallel simulation in the present patent.

Figure schematically showing an example.

<Description of the symbols for the main parts of the drawings>

32: Verification Software 34: HDL Simulator

35: computer

37: ESL Model 38: Design Object Representing Design Block

39: design object representing the design module

40: RTL model 42: On-chip bus

50: expected input 52: expected output

53: Design objects containing both DUVs and TBs dictated at higher levels of abstraction

54: Expected I / O-run / actual I / O-run control module

56: expected input / actual input selection module

58: expected output / actual output comparison module

59: expected input / actual input comparison module

60: s-DCP generation / storage module

62: additional code added to the design code to be verified by the verification software

64: Communication and Synchronization Module for Distributed Parallel Simulation

333: Local simulations of distributed parallel simulation

SW server module in the central computer that performs the connection of control and local simulations

343: Simulator for Local Simulation in Distributed Parallel Simulation Environment

353: central computer

354: Outer Computer

370: GL model

380: specific design objects in the RTL model

381: Another specific design object in the RTL model

382: Another specific design object in the RTL model

383: Another specific design object in the RTL model

384: Another specific design object in the RTL model

385: Another specific design object in the RTL model

387: A description of a design module that does not exist in the RTL model but exists in the GL model.

Object

404: part of the design verification target model performed in the local simulator

420: On-Chip Bus Designer Including Bus Intermediate and Address Decoder in RTL Model

sieve

606: s-DCP storage buffer

644: Local Simulation Run-Time Module for Distributed Parallel Simulation

646: communication and synchronization module for simulation acceleration

648 Hardware-based Verification Platform

650 simulation acceleration runtime module

660: Installation in a model that is split to be performed on the local simulator in distributed parallel simulation.

Object

670: VPI / PLI / FLI

674: Socket API

676: TCP / IP socket

678: Device API

680: Device Driver

682: Hardware Abstraction Layer (HAL)

684: Giga-bit LAN card

The present invention relates to a technique for systematically verifying a design from an electronic system level (abbreviated to ESL) to a gate level by using a simulation. In this case, the present invention relates to a verification method which increases the performance and efficiency of verification. In semiconductor design verification, simulation is a computer-executable model that is software-based under design (DUV) or one or more design objects in a DUV (defined later) and the test bench that drives it. The computer-implemented model is converted into a sequence of machine instructions of a computer through a simulation compilation process and executed using a computer. Therefore, the execution of the simulation is basically performed through the sequential execution of the machine language of the computer, and at present various simulation techniques (event-driven simulation, cycle-based simulation). simulation, compiled simulation, interpreted simulation, co-simulation, etc. exist. That is, simulation means design objects that are designed or implemented as appropriate abstraction levels (abstraction level, semiconductor transfer design, gate-level, register transfer-level, transaction-level, architecture-level, behavior-level, algorithm-level, etc.). Various processes that simulate the operating function or operation characteristics of the corresponding design object on the computer through software modeling through the modeling process in various levels of abstraction) It is. The advantage of such simulation is that it is possible not only to predict virtually the operation function or operation characteristics of the design object before implementing it physically, but also provide high flexibility in software. The disadvantage is that the simulation is finally performed through the sequential execution of the machine languages, so that the complexity of the design object to be simulated is large. Present), the simulation is very slow (for example, if the 100 million-gate design is performed by event-driven simulation, the simulation speed is 1 cycle / sec and about 3.2 years if the simulation is to be performed 100,000,000 cycles). Is required). Therefore, simulation in this patent refers to all methods of software modeling one or more design objects in a DUV or DUV at an appropriate level of abstraction and executing them in software. More specifically, the behavior of a particular level of abstraction of a DUV or one or more design objects within a DUV ultimately defines a particular computer data structure and certain operations on that particular data structure. Process to make it computer-executable and to operate the computer with input values applied thereto or to include a series of computations or processing in the computer as input values. If it is defined as a simulation, it is defined as a simulation (So, if the process meets the definition as well as the simulation using a commercial simulator, the simulation is performed on the computer through the simulation by the self-made simulator and the modeling through the same process as the simulation process.If a software process which is normally carried out will be both defined by simulation).

With the recent rapid development of integrated circuit (IC) and semiconductor process technology, the scale of digital circuit or digital system design has grown from at least tens of millions of gates to hundreds of millions of gates. It is a trend, and this trend is continuously expanding. In particular, the recent system-class integrated circuits, commonly referred to as SOCs (System On Chip), are mostly embedded with at least one processor core (RISC core or DSP core, for example, ARM11 ARM or CEVA Teak DSP core). A great deal of functionality is being implemented in software. And competition in the market is fierce, so it is necessary to develop a superior product in a short time, and shortening the design period has become a very important factor in determining the success of the product. Therefore, in recent chip design, the ESL design technique is attracting much attention from the industry as a new design method. Chips designed with ESL design techniques that have higher abstraction levels (described later) than the Register Transfer Level (RTL) design techniques that have been used in traditional digital hardware designs are used in addition to the chip design. The development of the running software must also be carried out at the same time. Therefore, in order to proceed with software development at the same time as designing hardware, architecture exploration is made by system level model (ESL model) by creating virtual platform (hereinafter referred to as VP) modeling the hardware. ), Software development, hardware / software co-verification, and system verification are recent trends, which serve as an executable specification (i.e. the role of a reference model). ). Such VPs can be created quickly by increasing the level of abstraction, as well as creating a VP for the DUV before designing a viable DUV. Verification can be done in advance, which is advantageous in many ways. Such VPs play an important role in platform-based design (PBS), which is common in current SOC design methods. VPs are typically on-chip buses at the transaction level. ) Is a core component of the bus model (modeled at the transaction level, called the TLM model) modeled according to the specified bus protocol, and the transaction level of the design blocks connected to this bus. By designing these transaction level design blocks to communicate with the bus model according to the abstracted bus protocol, the simulation performance is relatively high (approximately 100 times -10,000 times compared to that of the RTL model). Make it possible. Currently, commercial tools for creating and executing such VP include ARM MaxSim, CoWare ConvergenSC, Cadence Insicive, Summit Design VisualElite, Vast Systems Technology VSP, Synopsys SystemStudio, TenisonEDA VTOC, Carbon Design Systems VSP, Virutech's VirtualPlatform. In SOC design, the VP is fast enough to develop software, so it is important not to model at the register transfer level (RTL) using languages such as Verilog or VHDL, but to use languages such as C / C ++ or SystemC. Therefore, the model is modeled at the transaction level or algorithm level, which has a higher level of abstraction than RTL. Abstraction level, a very important concept in system design, expresses the degree of dictation of the dictation of the design object (described later). It can be divided into level, transistor-level, gate-level, register transfer-level (RTL), transaction level, and algorithm level. That is, the gate-level has a lower level of abstraction than the RTL, the RTL level has a lower level of abstraction than the transaction level, and the transaction level has a lower level of abstraction than the algorithm level. Therefore, if the level of abstraction of a specific design object A is a transaction, and the design object B expressed in detail is RTL, the design object A is defined as having a higher level of abstraction than the design object B. In addition, if design object X has design object A and design object C inside, and design object Y has design object B and design object C incorporating A inside, design object X is more abstract than design object Y. It is defined as high. In addition, depending on how much more accurate the latency model is at the same gate level or the same RTL, it is possible to determine the high and low level of abstraction. In other words, the accurate latency model is said to have a low level of abstraction. For example, even if the gate level is the same, the netlist of the zero-delay model is better than the netlist of the unit-delay model. The level of abstraction is high, and the netlist of unit time model is higher than the netlist of full-timing model using SDF (Standard Delay Format). Recent SOC design defines the object to be finally implemented in the chip as the initial design object, which targets the initial design object from the initial abstraction level (e.g. transaction level) through the progressive refinement process. It can be defined as the process of shaping to the last level of abstraction (eg gate-level) (see FIG. 14). The design technique through progressive refinement process is the only design technique that can cope with the design complexity of the recent SOC with the platform-based design. It proceeds through. The core of the design technique through the gradual materialization process is to refine the design blocks existing in the design object MODEL_DUV (HIGH) modeled at the upper level of abstraction step by step to designate the design object MODEL_DUV (LOW) modeled at the lower level of abstraction than MODEL_DUV (HIGH). It can be summarized as a process obtained by using an automated method (eg, a logic synthesis or a higher level synthesis) or by a manual method or a mixture of an automated method and a manual method. As an example of this, first of all, the process of obtaining an RTL model that can be implemented from an ESL model, which is an embodiment of ESL to RTL (this process is currently performed manually or in a high-level synthesis method or a mixture thereof), is performed using the MODEL_DUV ( HIGH), and the implementable RTL model becomes MODEL_DUV (LOW), and the process of obtaining the gate-level model (ie, gate-level netlist) from the implementable RTL model, which is the step of specifying from the RTL to the gate level again ( This process is now mostly done in a logic synthesis method), and the RTL model that can be implemented becomes MODEL_DUV (HIGH) and the gate level model becomes MODEL_DUV (LOW). This gate-level model is a timing-accurate gate-level model by back-annotating the delay information (represented in Standard Delay Format) extracted during the placement and routing process. Unless otherwise defined, it includes both DUV (described later as Design Under Verification) and TB (described later as Test Bench).

One thing to note here is that not all design objects within the ESL model must exist at the system level, even for the ESL model, and all design objects within the RTL model must exist at the register transfer level, even for the RTL model. It is not. That is, even in the ESL model, a small number of design objects within this model exist at the register transfer level and are wrapped at the system level by wrapping these design objects in a wrapper for abstraction. It can be treated as an ESL model by matching the model, and even though it is an RTL model, a few of the design objects inside this model can be treated as RTL models like many other design objects that exist at the gate level but exist at the RTL level. have. For the same reason, in the GL model, a small number of design objects (e.g. memory blocks that do not generate gate-level netlists in logical synthesis) may exist at the register transfer level. Therefore, the term "specific abstraction level model" in this patent refers to the various abstraction levels (ESL, RTL, GL abstraction levels as well as their mixed forms of abstraction levels, ESL / RTL, which may exist in the process of gradual materialization from ESL to GL). Abstraction levels, including mixed abstraction level, RTL / GL mixed abstraction level, ESL / RTL / GL mixed abstraction level, etc.). The general term “abstraction level” refers to the various levels of abstraction that can exist in the gradual materialization process, from ESL to RTL and GL as well as from ESL to GL (eg, ESL / RTL mixed abstraction level, RTL / GL mixed abstraction). Levels, ESL / RTL / GL mixed abstraction levels, etc.). For example, four design objects A, B, C, and D exist as submodules inside the DUV, where A and B are dictated at ESL, C at RTL, and D at the GL abstraction level. Even with a mixed level abstraction level model, this DUV can be referred to as a model of a specific level of abstraction (as well as specifically referring to ESL / RTL / GL as a mixed level of abstraction model). In the future, in the case of a model having a mixed level of abstraction, when it is necessary to clearly state that the abstraction level is a mixed form, it will be referred to as an abstract upper / lower mixed level model or an abstract mixed level model.

Transaction, which is an important concept in ESL, corresponds to the RTL signal or pin, and the information represented on the signal or pin can only be expressed as bit or bit vector, whereas transaction is logical. It refers to information represented by defining a plurality of related signals or pins as a unit, and the transfer of information uses a function call. For example, a logical association between a total of (N + M + P) signals consisting of an address signal N-bit, a data signal M-bit, and a control signal P-bit that always exist in a design consisting of any processor module and any memory module. N-bit address bus, M-bit data bus, and P-bit control bus, each cycle consists of (N + M + P) bitvectors. ), DATA (data_value)), or WRITE (ADDR (address_value), DATA (data_value)), or READ-WAIT (ADDR (address_value), DATA (data_value)), or WRITE-WAIT (ADDR (address_value), DATA ( data_value)), and the like, as a symbol that can be interpreted as meaning. Such a thing is called a transaction. Transactions can also be defined not only in one cycle unit (this is called a cycle-accurate transaction, abbreviated as a ca-transaction), and extend to multiple cycle units as well. The transaction is defined as a transaction (which is called by several names such as a timed transaction, a cycle-count transaction, or a PV-T transaction), and in this patent, abbreviated as a single name as a timed-transaction. (A timed-transaction defined in multiple cycles can be expressed as Transaction_name (start_time, end_time, other_attributes)). Transactions also include transactions without time concepts (abbreviated as untimed-transactions). In fact, there is no standardized and consistent definition of transactions, but it is most common to divide them into untimed-transactions, timed-transactions and ca-transactions as described above. As such, even within a transaction, the level of abstraction is highest depending on the level of abstraction, but the time accuracy is lowest, from the untimed transaction with the lowest level of abstraction, but the highest level of time accuracy is ca-transaction, and the level of abstraction and time accuracy The intermediate level can be divided into timed transactions.

The materialization process takes place in a progressive manner so that transaction-level design objects in the VP are at least bit-level cycle-accurate RTL-level design objects through the conversion process for specification. Will change to At the end of this conversion process, all transaction-level design objects in the VP are transformed into RTL-level design objects (and thus converted into an RTL model that can be implemented as a transaction-level VP). In addition, RTL-level design objects in the feasible RTL model are converted to bit-level timing-accurate gate-level design objects through the conversion process for concrete specification. At the end of this conversion process, all RTL-level design objects in the RTL model are converted to gate-level design objects (and thus the RTL model is converted to a gate-level model). Figure 14 shows this process as an example. If you have four transaction-level design objects DO_esl_1, DO_esl_2, DO_esl_3, and DO_esl_4 as sub-blocks within the transaction-level DUV (ESL), these four transaction-level design objects go through the step-by-step gradual refinement process. The design objects of DO_rtl_1, DO_rtl_2, DO_rtl_3, and DO_rtl_4 are replaced with the register transfer level DUV (RTL) consisting of only RTL-level design objects DO_rtl_1, DO_rtl_2, DO_rtl_3, and DO_rtl_4. Also, if there are four design objects DO_rtl_1, DO_rtl_2, DO_rtl_3, and DO_rtl_4 as lower blocks in the register transfer level DUV (RTL), these four RTL design objects undergo a step-by-step gradual specification process to allow gate-level design objects DO_gl_1, It is replaced by DO_gl_2, DO_gl_3, and DO_gl_4, and eventually converted to gate-level DUV (GL) consisting of only gate-level design objects DO_gl_1, DO_gl_2, DO_gl_3, and DO_gl_4.

In SOC design, there are two things that need to be designed, one is Design Under Verification (DUV), and the other is a testbench for simulating DUV (abbreviated as TB). The DUV is the design target ultimately made into a chip through the semiconductor manufacturing process, and the testbench is used to simulate the DUV by modeling the ambient conditions in which the chip is implemented. When simulating a DUV, it is common for the testbench to apply an input to the DUV and accept and process the output from the DUV with the authorized input. These DUVs and testbenches typically have a hierarchical structure with one or more submodules inside them, each of which can be called a design block, with design modules inside the design block, and a submodule inside the design module. Modules exist. Such design blocks, or design modules, or submodules or DUVs, and test benches, respectively, or in part, or combinations thereof, or portions of combinations thereof, are all referred to herein as design objects (specific examples In the case of Verilog, module, VHDL entity, and SystemC sc_module are all examples of design objects). Thus, a VP may also be regarded as one of the design objects, and a part of the VP, one or more design blocks in the VP, a part of the design blocks, the design modules in the block, the parts thereof, or the submodules in the design module All of the parts of the can be viewed as design objects (ie, all of the DUV and TB or any part of the DUT and TB can be seen as design objects).

However, in the current gradual concrete design, the verification at the upper abstraction level can be performed very quickly, but the verification at the lower level of abstraction is performed relatively slowly. There is a problem that the speed is greatly reduced. In general, a single simulation method (a single simulation method is defined in this patent in a broad sense, not only when using one simulator but also when using two or more simulators (for example, using Verilog simulator and Vera simulator simultaneously). In contrast to defining two or more simulators on a single CPU as a single simulation method, there is a method of executing two or more simulators in a distributed parallel manner to increase the verification speed. Examples of this simulator include HDL (Hardware Description Language, NC-Verilog / Verilog-XL and X-sim from Cadence, VCS from Synopsys, ModelSim from Mentor, Riviera / Active-HDL from Aldec, and FinSim from Fintronic) Or HVL (Hardware Verification Language, Cadence's e simulator, Synopsys' Vera simulator, etc.) simulator or SDL (System Description Language, SystemC simulator, Cadence's Incisive simulator, etc.) simulators. Another distinction is the event-driven simulator or the cycle-based simulators, the simulators of which are mentioned in this patent. Thus, in the case of using two or more simulators, it is possible not only to use any kind of simulators mentioned above, but also to freely use these different kinds of simulators. Distributed parallel simulation (also called parallel distributed simulation or simply parallel simulation, which is referred to in this patent as distributed parallel simulation), which is a distributed processing method of simulation. In the most common parallel simulation method, DUV and TB (ie, a model of a certain level of abstraction) to be simulated are divided into two or more design objects, and each of these divided design objects is distributed and executed in a separate simulator. 5). Therefore, for distributed parallel simulation, a partitioning process is needed to divide the model to be simulated into two or more design objects. Therefore, in this patent, a design object to be performed in a specific local simulation (to be defined later) through a division process will be referred to as a local design object.

Recently, two or more computers are connected by a high-speed computer network such as Gigabit Ethernet, and a simulator is performed on each of them (in this patent, simulations performed in each simulator of two or more simulators that enable these distributed parallel simulations) are performed. Multiprocessor computers (eg, Pentium dual-core chips and AMD dual-core chips are called local simulations and are referred to as local simulators), or are equipped with two or more central processing units (CPUs). It is also possible to configure a multiprocessor computer, and to perform a distributed parallel simulation by running a simulator on each of these CPUs in a multiprocessor computer with multiple CPU chips mounted on one or more system boards. end It is. However, such a conventional distributed parallel simulation has a problem in that the performance improvement is very limited due to the communication overhead and synchronization overhead between the simulators. There are two main methods of synchronization in distributed parallel simulations: one is conservative (also called pessimistic) and the other is optimistic. The conservative synchronization is that the causality relation of simulation events is maintained between simulators, so no rollback is required, but distributed parallel simulation is limited to the slowest local simulation. There is a problem of excessive synchronization, and optimistic synchronization can prevent causality between simulation events temporarily between simulators, and rollbacks are required to correct them, so reducing the total number of rollbacks is distributed parallel simulation. Will have a big impact on performance. However, up to now, distributed parallel simulations by optimistic methods have excessive rollbacks because the simulation points in which each local simulation proceeds without synchronization with other local simulations are not specially considered to minimize the rollback. This results in significant consequences for the overall simulation. Since the conventional optimistic distributed parallel simulation or the conservative distributed parallel simulation method and the implementation method thereof are well known in the literature or the literature, detailed description thereof will be omitted. One more thing to mention is that the number of processors performing distributed parallel simulations should be equal to the number of local simulations in order to maximize the performance of distributed parallel simulations. If a networked or multiprocessor computer has more than two processors), even if the number of local simulations is more than two, two or more local simulations can be performed by one processor. In conclusion, both the current conservative synchronization method and the communication method, or the optimistic synchronization method and the communication method have a problem of significantly reducing the performance of distributed parallel simulation using two or more simulators.

In addition, it is very important that the high-level abstraction model serves as a reference model of the low-level abstraction model in the design through the gradual materialization process. It is necessary to maintain model consistency between the model and the low-level model. However, there are no effective ways to maintain model coherence between two or more models present at these different levels of abstraction in current incremental refinement methods.

In addition, the debugging process for removing design errors found in the design process through a gradual materialization process is very time consuming because the system is not systematic.

In the present invention, starting from the transaction level model (hereinafter, abbreviated as ESL model) at the system level, a register transfer level model (hereinafter, abbreviated as RTL model) that can be implemented as a design through a gradual specification process is obtained, and then implemented again. Gate-level model (hereafter abbreviated as GL model) from possible RTL model to design through gradual refinement process (GL model is a gate-level netlist representing the connection structure of cells of a specific implementation library that can perform the layout & wiring process) The ESL-to-Gate design process is divided into two phases. Umbrella The first step is to refine the RTL model from the ESL model. This is called the ESL-to-RTL design process. The second step is to refine the GL model from the RTL model, which will be referred to as the RTL-to-GL design process. In addition, a plurality of various models existing at various levels of abstraction in these progressive concrete processes will be collectively referred to as "different abstract level identical models".

In general, in the process of materializing a high-level abstraction model as a low-level abstraction model, there is a similar or similar hierarchy to both a high level abstraction model MODEL_DUV (HIGH) and a low level abstraction model MODEL_DUV (LOW). It is very important (see FIGS. 3 and 4). In SOC design, the complexity of the DUV to be designed is so high that models at these different levels of abstraction generally have the same or similar hierarchy naturally to some degree from the top to the bottom of the hierarchy. First of all, having the same or similar hierarchical structure from the top level to the constant level, there is a possibility that corresponding design objects exist between models in the same way as DUV among one or more design objects existing in models of these different levels of abstraction. This situation usually exists between the ESL model and the RTL model, and between the RTL model and the gate-level model without breaking down the hierarchy. In addition, the boundary level of the gate level model may be slightly different from that of the RTL model by inserting a boundary scan structure at the gate level or by a manual design process, but the hierarchy is not significantly different. Because the hierarchy of the gate-level model and the hierarchy of the RTL model are very similar, it is easy to find the design objects at the lower abstraction level that correspond to the design objects at the higher abstraction level existing under these hierarchies. In addition, even when the gate-level model is processed to not preserve the hierarchical structure in the logic synthesis process, the design object names (instance names) present in the gate-level model have information on the design object of the corresponding RTL model. In this case, it is easy to find the design object at the lower abstraction level that corresponds to the design object at the upper abstraction level. Therefore, in this patent, models existing at different levels of abstraction maintain the same hierarchy to a certain degree from the highest level to a certain level in the hierarchy, or design objects existing in the abstraction higher level model exist in the abstraction lower level model. It is assumed that the corresponding design objects can be referred to as a partial layer correspondence relationship. For example, there are four design blocks B (1) _tlm, B (2) _tlm, B (3) _tlm, and B (4) _tlm in the TLM model DUV (TLM), and the incremental refinement process from DUV (TLM). In the case of designing a DUV (RTL) as a design, four design blocks B (1) _rtl, B (2) _rtl, B (3) _rtl, and B (4) _rtl are also present in the DUV (RTL). 1) _tlm corresponds to B (1) _rtl, B (2) _tlm corresponds to B (2) _rtl, B (3) _tlm corresponds to B (3) _rtl, and B (4) _tlm corresponds to B (4) Corresponds to _rtl. As another example, there are four design blocks B (1) _rtl, B (2) _rtl, B (3) _rtl, and B (4) _rtl in the RTL model DUV (RTL), and the design is carried out through an incremental specification process from the RTL model. In the case of designing DUV (GL) and the boundary scan cells are added in this process, the hierarchy that exists at the gate level is B (0) _gl, B (1) _gl, B (2) _gl, B (3) _gl, B (4) _gl, B (1) _gl corresponds to B (1) _rtl, B (2) _gl corresponds to B (2) _rtl, and B (3) _gl corresponds to B (3) _rtl And B (4) _gl corresponds to B (4) _rtl. Therefore, the design through the gradual materialization process is a process in which one or more design objects in these high-level abstraction models are converted into design objects in the abstraction low-level model. Examples of such design objects in SOC design include RISC processor core, DSP processor core, memory block, MPEG decoder block, JPEG decoder block, MP3 decoder block, Ethernet core, PCI-X core, DMA controller block and memory controller block. And are generally design blocks that perform very complex functions.

Therefore, in the process of materializing each of the design objects in these DUVs, several designers participate and proceed in parallel, which is required for the process of materializing individual design objects according to the designer's individual ability and experience and the difficulty of the design object. The time it takes is not constant. This specification can be done in a manual way that relies heavily on the designer's know-how. For example, Forte Design's Cynthesizer or Mentor Graphic's Catapult C, or a logic level synthesis tool (for example, Synopsys' DesignCompiler or Synplicity) Synplify, etc.) may be automated. However, in the final stage of the materialization process, it is necessary to verify whether the specific materialized design object is correctly specified. Other design objects are required to specify whether the specific materialized object B (i) _refined is correctly specified when the materialization is not completed yet. The effective verification method is a model with mixed abstraction level by replacing the design object B (i) _abst with B (i) _refined, which corresponds to B (i) _refined that already exists in the higher level model. (MIXED) makes a comparison with the result of MODEL_DUV (HIGH). Using the examples mentioned above, the process of specifying each of B (1) _tlm, B (2) _tlm, B (3) _tlm, and B (4) _tlm in DUV_TLM is paralleled by multiple designers. If the specification is completed in order of B (4) _rtl, B (3) _rtl, B (2) _rtl, and B (1) _rtl in order of time, B (4) _rtl is completed as soon as B (4) _rtl is completed. The designers responsible for specifying (4) construct MODEL_DUV (MIXED) _4 = (B (1) _tlm, B (2) _tlm, B (3) _tlm, B (4) _rtl) and run it (i.e. simulation). MODEL_DUV (HIGH) = (B (1) _tlm, B (2) _tlm, B (3) _tlm, B (4) _tlm) is compared with the simulation execution result and B (4) _rtl is correctly specified. You can verify that it has progressed. In this way, the rest of B (3) _rtl, B (2) _rtl, and B (1) _rtl are also assigned to MODEL_DUV (MIXED) _3 = (B (1) _tlm, B (2) _tlm, B ( 3) _rtl, B (4) _tlm), MODEL_DUV (MIXED) _2 = (B (1) _tlm, B (2) _rtl, B (3) _tlm, B (4) _tlm), MODEL_DUV (MIXED) _1 = ( By configuring B (1) _rtl, B (2) _tlm, B (3) _tlm, and B (4) _tlm), it is possible to verify whether the design block is correctly specified. In another example, the process of specifying each of B (1) _rtl, B (2) _rtl, B (3) _rtl, and B (4) _rtl in DUV_RTL is done in parallel by multiple designers. If the specification is completed in order of B (4) _gl, B (3) _gl, B (2) _gl, and B (1) _gl (gl is a subscript indicating gate level) As soon as (4) _gl is completed, the designers responsible for specifying B (4) specify MODEL_DUV (MIXED) _4 = (B (1) _rtl, B (2) _rtl, B (3) _rtl, B (4) _gl). Configure it and execute it to compare the simulation results of MODEL_DUV (HIGH) = (B (1) _rtl, B (2) _rtl, B (3) _rtl, B (4) _rtl). You can verify that the refinement was done correctly. In this way, the rest of B (3) _gl, B (2) _gl, and B (1) _gl are also completed. MODEL_DUV (MIXED) _3 = (B (1) _rtl, B (2) _rtl, B ( 3) _gl, B (4) _rtl), MODEL_DUV (MIXED) _2 = (B (1) _rtl, B (2) _gl, B (3) _rtl, B (4) _rtl), MODEL_DUV (MIXED) _1 = ( By configuring B (1) _gl, B (2) _rtl, B (3) _rtl, and B (4) _rtl), it is possible to verify whether the design block is correctly specified. However, one thing to mention here is that among the design objects existing in MODEL_DUV (MIXED), the abstraction level of the input / output ports of design object B (i) _refined that is embodied is not specified in the design objects B (k) _abst. Due to the inconsistency of the I / O ports, additional interfaces may be required for the connection between these B (i) _refined and B (k) _abst.

For example, when the ESL is embodied as an RTL, a transaction level is required in the ESL, and the RTL is a cycle level in the unit of a pin signal. Therefore, a translator that functions as an interface between them is required. Such a transaction may vary depending on the degree of abstraction of the ESL transaction. For example, if the level of abstraction of the ESL transaction is a cycle-accurate transaction level, a very simple one may be used. If the degree of abstraction is a timed-transaction level, you will use a relatively complex transaction. Also, when RTL is specified as GL, the I / O port of the RTL and the I / O port of the GL are all the same in the pin signal unit, so a separate port interface is not required. In order to generate signals with correct timing in GL at the interface boundary, a timing adjuster may be required to serve as a timing adjustment between them (delay values used in the timing adjuster may be used to analyze the SDF, or By analyzing delay time parameters of library cells, or performing gate-level timing simulation using SDF in a short simulation time interval, or performing static timing analysis, or using them in combination Can be). As described above, when one or more specific design objects present in the DUV are embodied as B (i) _refined in the process of gradual materialization, the design objects B (i) _abst and the corresponding design objects existing in the model MODEL_DUV (HIGH) of the abstract level are abstracted. Alternatively, the refinement step that creates the abstraction model MODEL_DUV (MIXED) _i will be referred to as the "partial refinement" step and this process will be called the partial refinement process.

After the above partial specification step, all design objects that are specified in the model abstract model MODEL_DUV (HIGH) of the abstraction level can be replaced with the specified design objects (design objects that are not specified or do not need to be specified may exist. In this case, the refinement step that creates the model MODEL_DUV (LOW) at the low level of abstraction by not designating the design object is called the “complete refinement” step. It will be called. That is, in the step of specifying the RTL in ESL, MODEL_DUV (RTL) is obtained during the full specification, and in the step of specifying the GL in the RTL, MODEL_DUV (GL) is obtained during the full specification. In the above example, all four design objects must be specified in the RTL specification in ESL, and B (3) _rtl (e.g., B (3) _rtl is a memory module). If it does not need to be specified, complete the specification process. MODEL_DUV (RTL) = (B (1) _rtl, B (2) _rtl, B (3) _rtl, B (4) _rtl) and MODEL_DUV (GL ) = (B (1) _gl, B (2) _gl, B (3) _rtl, B (4) _gl)

The result obtained by finally executing the model abstract low-level model MODEL_DUV (LOW) obtained through the full refinement process is compared with the simulation execution result of the model abstract high-level model MODEL_DUV (HIGH) or additionally, if necessary, the model abstract low-level model MODEL_DUV (MIXED). By comparing with i), you can verify that the design was done correctly through a gradual refinement process. However, in the process of partial specification in the process of progressive materialization that is naturally applied in the design of the process of progressive specification, the design objects existing in the model MODEL_DUV (MIXED) _i of the abstraction are still mostly abstracted. Because it exists at the level, the verification execution speed for MODEL_DUV (MIXED) _i is considerably lower than the verification execution speed for high-level model MODEL_DUV (HIGH) (usually on-chip in DUV in actual SOC design). The number of design objects connected via the bus will be at least 10 and as high as 100), and the validation performed during the full specification process is that all or most of the design objects in MODEL_DUV (LOW) exist at the low level of abstraction. The execution speed of verification targeting MODEL_DUV (LOW) is higher than the abstraction. Larger drops than the verify execution rate within the scope of the model MODEL_DUV (HIGH) of the semi by being presented is a major obstacle to effective verification element proceeds. As a concrete example, the verification execution speed of the RTL model that embodies this is slower than the ESL model by 10 to 10,000 times slower than that of the ESL model, and the verification execution speed of the GL model that embodies it compared to the RSL model is RTL. As it is slowed by at least 100 times and up to 300 times compared to the verification execution speed of the model, it becomes a big problem that the total verification time is greatly increased in the verification through such progressive specification.

Accordingly, an object of the present invention is to provide a systematic verification method that can effectively proceed the verification process applied to the process of progressing from the system level to the gate level through a gradual specification through a gradual specification like the design process.

It is still another object of the present invention to provide a systematic verification method that solves a problem that the verification speed gradually decreases or decreases significantly as the verification progressed in the design progressing through the gradual specification process proceeds to the lower level of abstraction through the gradual specification process. .

It is yet another object of the present invention to allow the entire process of design and verification from a higher level of abstraction to a lower level of abstraction in a gradual materialization manner in a systematic and automated manner.

It is still another object of the present invention to provide a systematic verification method that effectively maintains model consistency between two or more models present at various levels of abstraction.

Another object of the present invention is to provide a method of effectively verifying a low level abstraction model through a gradual materialization process by using a model at a high level of abstraction as a reference model based on systematically maintained model consistency.

It is another object of the present invention to provide a method for speeding up distributed parallel simulation by effectively reducing synchronization overhead and communication overhead in distributed parallel simulation.

Still another object of the present invention is to provide a method of correcting a design error through rapid debugging by systematically performing a debugging process for removing design errors found in a design process through a gradual specification process.

In order to achieve the above objects, the design verification apparatus necessary for applying the design verification method according to the present invention may be composed of one or two or more computers in which verification software and one or two or more simulators are installed. Another design verification apparatus to which the design verification method of the present invention can be applied includes one or more computers including verification software and one or more simulators, and one or two simulation accelerators connected to the one or more computers. It consists of an FPGA board. The verification software runs on a computer, and if there are two or more computers in the design verification device, these two or more computers are connected by a network (e.g. Ethernet or Gigabit Ethernet) to transfer the files or data between the computers. Enable it through 1 or 2 or more simulators for design verification use only consist of event-driven simulators. (Parallel Discrete Event Simulation (PDES) is a parallel simulation by configuring distributed parallel simulations only of event-driven simulators.) It can be a combination of an event-driven simulator and a cycle-based simulator, or it can consist only of a cycle-based simulator, or a cycle-based and transaction-based simulator. It can be configured as a transaction-based simulator, or as a transaction simulator only, or as an event-driven and transaction-based simulator, or an event-driven simulator and a cycle-based simulator. And together with a transaction-based simulator It may be such that the configuration of the simulator according to the present patent can be configured in a wide variety of ways. Therefore, when the two or more simulators are composed of an event-driven simulator and a cycle-based simulator, the distributed parallel simulation using the same is partially performed in the event-driven simulation and the other part is performed in the cycle-based simulation. Proceed to co-simulation mode. Alternatively, when the two or more simulators are composed of an event-driven simulator, a cycle-based simulator, and a transaction-based simulator, distributed parallel simulation using the same is partially performed as an event-driven simulation method, and the other part is a cycle-based simulation method. The other part can also be run in the co-simulation mode, which proceeds in a transaction-based simulation.

For example, on-chip including bus arbitrators and address decoders in the case of a conventional distributed parallel simulation of a particular abstraction-level SOC model based on the AMBA platform, or the distributed processing parallel simulations (as defined later) of this patent. The bus design object is a block modeled at the ca-transaction level. The local simulation, which is responsible for the simulation of this block, is performed in a cycle-based simulation. All other design objects (ARM core, DSP, memory controller, DAM controller, Other peripheral devices) are blocks modeled in RTL, and local simulations of each of these blocks can be run in an event-based simulation manner.

The HDL (Haraware Description Language) simulators (specifically, Cadence NC-sim, Synopsys VCS, Mentor Graphic ModelSim, Aldec Active-HDL / Riviera, etc.) used in chip design at the current register transfer level are all event-specific. Drive simulators. One cycle-based simulator is Synopsys' Scirocco.

The Systematically Progressive Refinement Verification Method, which is applied in the design through the gradual materialization process proposed in this patent, is abbreviated as SPR verification method in the future.The ESL is used to execute RTL verification on RTL models that can be implemented in RTL. Mixed validation of one or more ESL / RTL targets for MODEL_DUV (MIXED) _i, one or more abstract intermediate models constructed during the process of performing system-level validation on the model or in the process of gradual materialization from ESL to RTL. By using the results of the execution to run the RTL verification run in parallel or only partially (in part, you can use the incremental simulation technique, which will be described later). It is possible to perform RTL verification quickly. . In addition, the SPR verification method is an intermediate level of abstraction that is composed of the result of RTL verification execution targeting RTL model to GL implementation that can be implemented in GL or the process of gradual materialization from RTL to GL. Utilize the results of one or more RTL / GL hybrid verification runs on one or more MODEL_DUV (MIXED) _i models of the GL verification run in parallel or only partially (increment in part The mental simulation technique can be used, which can be performed quickly by performing GL verification. In addition, the high abstraction that is formed in the process of gradual refinement or the result of the system level verification that targets the transaction model that is highly abstract in the ESL verification execution that targets various transaction level ESL models in ESL. A particular design object in one or more transaction mixture validation runs (e.g., MODEL_DUV (MIXED_AT_TLM)) that targets one or more models MODEL_DUV (MIXED_AT_TLM) _i that mixes a transaction model with a low abstraction Object and the rest of the design are composed of timed-transaction level design objects that utilize the results of the mixed verification run to run the ESL verification run in parallel or only partially (in part, only incrementally). We can use mental simulation techniques, It is possible to quickly perform ESL verification.

Such verification is basically performed in a simulation method using one or two or more simulators, but not only one or two or more simulators, one or two or more simulation accelerators, or one or two or more hardware emulators, or one or two or more simulators. It is also possible to use hardware-based verification platforms, such as FPGA boards, to accelerate the simulation using a simulator. Since the simulation acceleration method of increasing the speed of simulation by using one or two or more simulation accelerators, one or two or more hardware emulators, or one or two or more FPGA boards together with one or two or more simulators, the present invention is a simulation in a broad sense. Unless otherwise stated, the term verification and simulation can be used interchangeably (i.e., in this patent, formal verification will not be considered, so verification is a dynamic verification technique). From now on, instead of using the term verification, we will replace it with simulation, and this simulation is not only a simulation using a simulator but also an accelerator or a simulation accelerator. It also includes simulation acceleration using a hardware emulator or FPGA board with a simulator.

As already mentioned above, in the SPR verification scheme in this patent, the parallel execution of the simulation at the lower level of abstraction or the execution of the simulation at the lower level of abstraction is performed previously in the process of gradual specification for partial execution only. Prior to the same level of abstraction in the gradual refinement process, to take advantage of simulation results at higher levels of abstraction or at least one simulation result at intermediate levels of abstraction, or for parallel or partial execution of simulations at the same level of abstraction. Take advantage of the simulation results performed. In addition, in rare cases, in the SPR verification scheme in this patent, the abstraction is performed at a lower level of abstraction previously performed in the gradual specification process (usually in the design process) for parallel or partial execution of the simulation at a particular level of abstraction. Iteration is necessary, and in this repetition process, the simulation may be performed after the abstraction low level simulation. As mentioned above, one of the key points in this patent is to make it possible to quickly perform a simulation that is performed later by utilizing the results of the simulation that was performed earlier. Although it is generally performed at a high level or the same level of abstraction, in some cases, the level of abstraction of the simulation performed earlier may be lower than that of the simulation performed later. In addition, modifications may be made to one or more design objects existing in one or more models to be simulated between the simulations performed earlier and later.

In more detail, the case in which the simulation performed earlier is relatively higher than the simulation performed later is described in more detail. In the above simulation, the state information (explained later) of the abstraction high-level model collected at a specific point in time or a specific section is used (hereinafter referred to as method-1), or at the intermediate level of abstraction using the abstract / high / low mixed level model. In the two or more simulations performed, the design state information of the abstract mid-level model collected at one or more simulation specific points or intervals during the execution of the two or more simulations (design state information will be abbreviated as state information in the future). Abstraction using a higher level model, or an abstraction higher level model collected during the entire simulation interval or a specific simulation interval during execution of this simulation. Two or more simulations in two or more simulations that utilize the input and output information (described later) of one or more design objects in the object (as described in Method 3), or an intermediate level of abstraction using an abstract upper / lower mixed-level model During execution, the input and output information of the design objects of the abstraction lower level existing in two or more abstract upper / lower mixed level models collected in the entire simulation section or a specific simulation section is used (called method-4).

In addition, in the parallel distributed parallel simulation in this patent, each local simulation does not perform only a local design object that must be performed by the local simulator (that is, in the conventional distributed parallel simulation, each local simulation is Only the local design objects will be performed.)

The higher level of abstraction of the model (ie, the higher level of abstraction than the overall model of DUV and TB, which consists of all local design objects that must be performed in each local simulation), or the simulation can be performed quickly. DUT and TB full models optimized to be able to be optimized (There are many known ways to optimize the simulation so that it can be performed quickly, but one of them is the simulation of the cycle-based method rather than the event-driven method. -Based simulations are about 10 times faster than event-driven simulations, and descriptions of event-driven and cycle-based simulations are omitted due to space constraints. To work with design objects And the expected information for simulating the local design object and the dynamic information obtained dynamically from the DUT and TB models that are optimized to perform the simulation quickly. It can be used as an expected output of the simulation of a local design object to enable distributed parallel simulation (more on this later), while minimizing the synchronization overhead and communication overhead with other local simulations. Will increase.

The state information of a model is a flip-flop output, latch output, or memory that exists in a model at a specific simulation time point (eg, simulation time 29,100,511 nanoseconds) or a constant simulation time interval (eg, 100 nanoseconds from 29,100,200 nanoseconds to 29,100,300 nanoseconds). Or dynamic information including the values of all variables or signals that describe a combinatorial feedback loop constituting the feedback loop (dynamic information of the model or dynamic information of the design object means a specific time point or a specific simulation interval during the simulation process) One or more signals or signal lines present in the design object, or values or constants on one or more variables present in the model or design object). These dynamic information can be obtained during the simulation run. For example, the dynamic way to obtain dynamic information during the simulation run is $ dumpvars, $ dumpports, $ dumpall, $ readmemb, $ readmemh, etc. in Verilog simulator. It can be obtained by using a system task or a user-defined system task (more specific methods are the contents of Korean patents 10-2005-95803, 10-2005-116706, 10-2006-19738, which are separately filed). The obtained dynamic information can be stored in VCD, SHM, VCD +, FSDB, or any binary or text format defined by the user. The state information of a design object is a dynamic data that includes the values of all variables or signals that describe the combinatorial path of the flip-flop output, latch output, memory, or feedback loop that exist in the design object at a specific simulation time point or a certain simulation time interval. Say information.

In addition, the input information of the design object refers to all input and input values of the design object in a specific simulation time interval (this specific simulation time interval may be the entire simulation time interval). The output information of the designation object refers to all outputs and values of the design object in a specific simulation time period (which can be the entire simulation time period), and the input / output information of the design object is a specific simulation time period (simulation total time). Values on all input, output, and input and output of the design object.

As already mentioned above, the simulation method proposed in this patent uses parallel simulations to perform later simulations using the same abstraction level model using temporal simulation results using the same abstraction level model during the process of progressive refinement. By performing partial simulations to speed up the simulation, or by performing parallel or partial executions of later simulations using the abstraction higher-level models, using the simulation results previously performed using the abstraction lower-level models during the process of progressive refinement. It is also possible to perform the simulation quickly, but the simulation method presented in this patent in a more general situation is a high level of abstraction in the process of gradual materialization. The simulation results using Dell can be used to perform the simulation using the abstraction low-level model in parallel or partially, or the abstraction high-level model in conjunction with the abstraction low-level model in the local simulation targeting the abstraction low-level model. By using the expected input and expected output in the local simulation targeting the abstraction low-level model, the local simulation targeting the abstraction low-level model is performed quickly. In other words. In this patent, the simulation results using the abstraction high-level model M (HIGH) or the combination with the abstraction high-level model M (HIGH) can be used more quickly to perform the simulation using the abstraction low-level model M (LOW). The focus is on. Therefore, the method of quickly performing the simulation using the abstraction high-level model M (HIGH) is a model M (HIGHER) (higher level of abstraction than the abstraction high-level model M (HIGH) by applying the method of the present invention continuously. In this case, it is possible to use a simulation result using M (HIGHER) is a high abstraction level model and M (HIGH) is a low abstraction level model), or to use a conventional distributed parallel simulation. It is also possible to use a general single simulation. In this patent, parallel execution of a simulation using a specific abstraction level model includes distributed-processing-based parallel execution (hereinafter abbreviated as DPE) and timed-sliced parallel execution. (Abbreviated as TPE in the future) (explained in detail later), that is, parallel simulation of distributed parallel execution and parallel execution of time division parallel execution are new simulations proposed by this patent. Term referring to bay). For detailed explanation, first, Temporal Design Check Point (t-DCP) and Spatial Design Check Point (s-DCP) are defined.

t-DCP is dynamic information about one or more design objects in the DUV or DUV required to allow a simulation of one or more design objects in the DUV or DUV to be started at any time Ta other than the simulation time zero. (Dynamic information of a design object is a logic value on one or more signals or signal lines present in the design object at a specific simulation point or a specific simulation section (which may be the entire section of the simulation) during the simulation process. , Or values on one or more variables that exist in the design object or constants). Therefore, the state information of the design object is a specific example of t-DCP. However, a model that can be simulated must contain both DUV and TB. Therefore, in order for the simulation to start at any time Ta other than simulation time 0, the DUV must be able to be performed from Ta as well as the TB must be considered. There are roughly three ways to do this. The first method is to run TB from simulation time 0 and DUV from Ta. To do this, if TB is a reactive TB, the output information of the DUV (so it is necessary to obtain this output information in the previous simulation) is used to advance only TB from simulation time 0 to Ta and then from Ta. Can be performed while the TB and the DUV are interlocked together, or if the TB is a non-reactive TB, the TB and the DUV from Ta are first processed after only the TB is progressed from simulation time 0 to Ta. This can be done by interlocking together. The second method is to save and restart the TB so that the TB can also start from the simulation time Ta. In other words, TB can be retried similarly to DUV by resetting it by storing the state of the simulation or by resetting it by storing the state of TB (the state of TB is the value of all variables and constants declared in TB at a specific point in time or for a certain period). It is done. However, unlike DUV modeling hardware, TB is a modeling of test environment. In order to re-execute TB state at any point in time, TB's oral form should be suggested (eg, TB can also be synthesized) or additional manual work. You need to go through the process. Third, the input generation subcomponent, which is one of the main elements of TB, is replaced with the pattern generation input component instead of the algorithmic input generation component. The input generation subcomponent is responsible for supplying the input stimulus to the DUV.In the algorithmic input generation, it is difficult to start the input supply to the DUV from a random point of time Ta rather than starting from the simulation point of time zero. Generation is very easy to start from any point Ta by simulating the input supply to the DUV by using a pattern pointer or the like. Therefore, in order to use the pattern-based input generation subcomponent, the input information generated in the original TB and applied to the DUV in the previous simulation process is probed over the simulation simulation period and stored as one or more files, and then performed. It is possible to operate the TB from any time Ta by utilizing in the simulation, which is a pattern method TB is widely used in the regression test (regression test). In order to apply one of the above methods, it is necessary to add additional code, which is an additional code, to the model or simulation environment to be simulated, and such additional code can be automatically added through the verification software of the present patent ( Specific examples of additional codes are shown in FIGS. 16 and 17 and 18).

Using t-DCP, such as the status information of one or more design objects in a DUV or DUV, a simulation of one or more design objects in the DUV or DUV can be started from any time Ta other than the simulation time zero. The detailed method is already described in detail in a separate domestic patent (10-2005-116706), and this will be referred to, and the detailed description thereof will be omitted in this patent.

By utilizing such t-DCP, the arbitrary simulation of the DUV is divided into a plurality of time intervals (slices) in the simulation time, and the simulation can be performed independently according to the simulation time intervals. It becomes possible. However, as already described in a separate domestic patent 10-2005-116706, in the case where the simulation, which is a method in which most HDL simulators are operated at present, is an event driven simulation in which an event is generated, DUV or DUV is performed. Even if a simulation of a DUV or one or more design objects in the DUV is restarted from any specific time Ta other than the simulation time 0 using t-DCP as the state information of one or more design objects in the Although no loss occurs at any given time Ta, even if the simulation proceeds after Ta, the simulation starts from simulation time 0, proceeds to Ta, continues until Ta, and starts from the Ta After that, you get the same simulation result. It is very important to make sure. The separate patent 10-2005-116706 describes in detail the specific ways in which such a thing is possible. In this patent, the detailed description of the page is omitted without limitation (see 10-2005-116706 for details). I will mention it. In other words, in order for the re-simulation to be corrected from the specific time Ta, the previous simulation does not store only the state information at the time Ta, but a certain time interval Ta-d (d is triggered by another event by one event in the model) D value depends on the model being simulated, which can be received from the user or calculated in an automated fashion, and stores state information from to Ta (for example, when Ta is 10,000,000 nanoseconds). Saving state information is not performed at one point at 10,000,000 nanoseconds, but proceeds over 10 nanosecond time intervals from 9,999,990 nanoseconds to 10,000,000 nanoseconds, in which case d = 10 nanoseconds). Re-start also proceeds in the same time interval ( Examples of standing hayeoseo re-use the saved state information from 9,999,990 to 10,000,000 ns ns - proceeds from the start, from 9,999,990 to 10,000,000 nanoseconds nanoseconds). When one or more local simulations are performed in event-driven simulation in the distributed parallelism simulation in this patent, re-start without such event loss is very important for proper rollback. If so, correct rollback is possible.

s-DCP refers to a distributed parallel simulation of two or more design objects in a DUV or DUV divided into two or more simulators. Dynamic information about the same abstract model of the DUV or TB and the different abstract level of the same model required to minimize the communication and synchronization for the correct delivery of the required signal values or for the correct delivery of the transaction values. Dynamic information about one or more design objects in the, or dynamic information about the DUV or TB, or dynamic information about one or more design objects in the DUV or TB, or an abstraction high-level model of the DUV and TB, or simulation Optimal to be performed (E.g., optimized with the two-state simulation option of the VCS, or in the same way as the Radiant Technology of the VCS, or a combination of these two methods, as well as similar to the VCS in the case of NC-sim or ModelSim). It is defined as the entire DUT and TB models that have been optimized using optimization techniques. Such s-DCP is simulated together in a process of simulating a specific local design object performed by a specific local simulator in distributed parallel simulation, while the estimated input and the expected input of performing the local simulation S_l (k) of the specific local design object are simulated. Expected output (in this patent, "expected input and expected output of local simulation execution" is a term that defines expected input and expected output before actual execution or during actual execution. Means that it is predicted during actual execution, or is predicted before the start of the simulation execution, or before the specific simulation time for applying the input during the execution of the simulation, or dynamically predicted at this specific simulation time and the corresponding output is outputted. Another specific S-DCP means that both the DUT and TB at the higher abstraction level are either dynamically predicted at the time of the simulation, or dynamically predicted at another specific simulation point, or both. It can be the model itself, the DUT and the entire TB model optimized for rapid simulation, or it can be the input / output information for one or more design objects collected from a simulation performed earlier in time, or a combination thereof.) Is used to obtain the first input of the expected input to the specific local design object and executes the actual local simulation S_l (k) if the actual output value of the specific local design object obtained matches the expected output. Other local design objects in the model to be simulated Omit the communication and synchronization with each other and to advance the simulation time of this particular local simulation S_l (k) independently. Providing the s-DCP information which is used as the predicted input and predicted output of performing the local simulation of the specific local design object and controlling the simulation progress accordingly (expected I / O run, real I / O run, rollback, etc.) Each of which is included in a model dictated as HDL or dictated as HDL, such as Verilog, SystemVerilog, or VHDL, or in C / C ++ / SystemC. It is dictated and interfaced to HDL dictated models through PLI / VPI / FLI, or intermixed with HDL and C / C ++ / SystemC, included in models dictated by HDL through PLI / VPI / FLI, etc. Simultaneously interfaced design code (usually HDL code, SystemC code, C / C ++ code, SDL code, or HVL code) Sum) or simulation environment (for example, simulation scripts for simulation compilation, execution, or execution), typically added to the TB portion of the model (ie outside the DUV) and also as C / C ++ code. (In this patent, the entire code to be added is referred to collectively as "additional code") It is common, but in some cases, a part is also added to the DUV, such a process that the verification software in this patent is subject to simulation One or more design source files or simulation environment files that dictate the model can be read and generated in an automated manner (for specific examples, see FIGS. 16, 17, 18, and 19. Internal Structure and Internals of Additional Code) See FIG. 8, FIG. 27 for the function). This additional code first applies the expected input to the local design object to be subjected to the local simulation, and compares the actual output output from the local design object with the expected output while the local design object is simulated, and if the comparison is identical, It is possible to perform this function because it is very similar to the function of normal test bench (the function of applying input and checking whether the output is expected is the basic function of general test bench). It is not difficult to generate additional code in an automated manner. In addition, if roll-forward is required (when roll-forward is required, there is a discrepancy between the actual output and the expected output performed in another local simulation, and this mismatch simulation point in time t_d is the current simulation point in this local simulation). Since this local simulation exists in time later than t_c, it is necessary to proceed this local simulation to the time of simulation t_d, but during the simulation between t_c and t_d, the local simulation is run through the expected I / O-run method from t_c to t_d. At point t_b, if there is a discrepancy between the actual output and the expected output in this local simulation, this local simulation should pause the progress at t_b and inform other local simulations of this new rollback point in time t_b and the possibility of rollback. The forward is to this local simulation Is to continue the simulation in the expected I / O-run method, so no rollforward needs to be treated specially), continue with the I / O-run and perform a rollback if a rollback is needed and when it is rolled back. From the actual I / O-run (in this patent, the actual I / O-run method is the data between each local simulation in a distributed parallel simulation-the input from other local simulations in each local simulation or the output to other local simulations). It refers to the method that actually performs the transmission and synchronizes with the conventional conservative synchronization or the optimistic synchronization for synchronization required in this process.The interval between performing data transmission (communication) and synchronization is the simulation minimum precision. Can be units, simulation A typical distributed parallel simulation by the minimum time unit, cycle unit, transaction unit, etc., and thus a conservative distributed parallel simulation in the actual I / O process. In addition, the control method may be controlled to perform a general optimistic distributed parallel simulation, and the rollback methods used in the conventional optimistic distributed parallel simulation may be used for a rollback. Since the simulation must support rollback, various methods for rollback are already described in detail in many literatures related to optimistic distributed parallel simulation, and a detailed description thereof is omitted in the present patent due to the limitation of the paper. Reference may be made to the old reference) or a separate save and re-start method described in a separate patent (10-2005-116706). In the Verilog, a specific method of storing the file as a file in the simulation schedule section and restarting at a specific simulation point or section among one or more simulation points or sections in which the design state information is stored at the time of rollback is described in the case of the force / release command syntax or PLI / VPI. By using the acc_set_value () function, the stored state information is rewritten to variables of the corresponding local design object constituting the design state information at the specific simulation point or interval. In particular, the method of resetting the design state information to the variables of the local design object without performing a separate simulation compilation at every rollback is performed by using the acc_set_value () of VPI / PLI from the file. The design state information values to be reset at the specific simulation time point or section are read and set in the variables of the corresponding local design objects, and the contents of the file having the design state information values become the simulation restart time point or section. This is possible by dynamically changing before performing each rollback to have the values of the variables of the corresponding local design objects at the specific simulation time point or interval) .A typical parallel input / output distributed parallel simulation is already well known. This also adds It is not difficult to generate the additional code in an automated manner so as to perform the function (for specific examples, see FIGS. 16, 17, 18, and 19, and the structural configuration of the additional code for performing such a function is shown in FIG. 8, the mock code is illustrated in FIG. 27). In other words, each of the local design objects executed in different local simulators in a distributed parallel simulation environment is first used in s-DCP due to the additional code added for the distributed processing parallel execution method (defined later) of the present patent. Using the expected inputs, the local design objects are independently simulated with each of the local simulators to obtain the output values of each of the local design objects, and each of these actual outputs is the expected outputs obtained from s-DCP. If these comparisons match, the comparison and synchronization between the local simulators can be completely or completely omitted, and each local simulation time proceeded forward (this approach is called Expected I / O-Run and is further described below. Greatly speeding up the simulation by This will be possible. If these comparisons do not match when compared to the expected outputs of the s-DCP (this is called the expected output / actual output discrepancy point), then only in this case can the distributed parallel simulation be performed while communicating and synchronizing between the local simulators. do. Also, it switches to the actual I / O-run method that performs communication and synchronization process between local simulators once. (This transition point is referred to as the actual I / O-run application point in the future. The point in time is generally the point that is later in time than the expected output / actual output mismatch of each of the local simulations running the distributed parallel simulation, i.e., the point in time that is in the past in time-t_lock or later in time than this t_lock. It can be t_advance_lock at any point in time, but to optimize simulation performance, setting the actual I / O application time point to t_lock can optimize the performance of the simulation, so each local simulation is a predicted I / O-run simulation. In case of expected output / actual output mismatch in progress Stops running the predicted I / O-run simulation and sends all the other local simulations their own predicted output / actual output inconsistency so that all other local simulations know their expected output / actual output mismatch. In addition, each local simulation can be rolled back to the t_lock time or t_advance_lock time, and the state information of one or more local design objects performed by local simulation or local simulation is periodically or non-periodized at the time t_lock or more than one t_advance_lock. Actual inputs that occur during the actual simulation process (even though it is necessary to save them periodically, so that the storage occurs when certain conditions are set before execution) (these inputs are used by distributed parallel simulation -Run room Compares the expected inputs from s-DCP with the expected outputs from s-DCP or the expected outputs from s-DCP. (For the sake of efficiency, it is also possible to compare the expected value-the expected output or the expected input-with the same abstraction level between the actual value-the actual output or the actual input-generated in the actual simulation process. Modules that perform the function of matching the abstraction level of actual values are called adapters or transactors. For example, in distributed parallel simulation in RTL, the comparison between expected values and actual values is possible not only by comparing the abstraction level of the actual value to the ca-transaction, which is the same level of abstraction as the expected value, but also the expected value of the RTL abstraction level. Fields and ca-transaction levels can be compared to the same timed-transaction abstraction level), a certain number of times (which can be set as input prior to running the simulation, or can be changed adaptively during the simulation process). From this point forward, this comparison (hereafter referred to as the actual I / O release point) releases the local simulators again in the I / O method to reduce communication overhead and synchronization overhead. Remove it again and run the simulation (in this case the distributed parallel simulation Each of the local simulations in this series proceeds very quickly, allowing communication and synchronization with other local simulations to be performed independently, in contrast to the actual I / O method described above. Each of the local simulations can be referred to as a predictive I / O-run method by completely skipping communication and synchronization with other local simulations and proceeding independently. The performance of distributed parallel simulation can be greatly improved by repeating the process of real-time I / O-run simulation. Input / output information for one or more design objects in the DUV and TB, or a simulation model including all of the DUVs and TBs having a higher level of abstraction than the DUVs and TBs, or the entire DUT and TBs optimized to be performed quickly. The model is specific examples of s-DCP. In addition, in distributed parallel simulations, the design objects that are part of the design (part of the design performed by the local simulator, ie the local design object), which are divided to be performed in each local simulation, exist in the DUV (for example, in the case of Verilog designs). Objects are modules, each of which is designed to run on each of the local simulations if they do not match the boundary of the design objects, in the case of VHDL designs, and the sc_modules, in the case of SystemC designs. The input and output information of each part of (i.e., parts of the overall design that exist in each local simulator for distributed parallel simulation) becomes s-DCP.

One more thing to consider in the distributed parallel simulation process that minimizes the communication overhead and synchronization overhead using s-DCP described above is that the expected output / actual output mismatches are different for each local design object performed in each local simulator. Can be. In such a case, all local simulators should be performed in the actual I / O method through the communication and synchronization process from the time t_e, which is the past point in the simulation time, among at least two expected output / actual output mismatch points. To this end, all simulations that are advanced more than the most recent point in time t_e need to be rolled back to the point in time t_e (specifically, four design objects are run without synchronization under communication). If t_e is 1,000,000ns when the simulation time is design object 1 = 1,000,000ns, design object 2 = 1,000,010ns, design object 3 = 1,000,020ns, and design object 4 = 1,000,030ns, respectively, design object 2, design object 3, design object 4 Roll back to 1,000,000 ns, and then perform parallel and distributed simulations on all design objects, starting at 1,000,000 ns, at the point of real I / O-run, at least in real I / O-run. Proceed to the actual I / O use-run release). To save such a rollback, a simulation save and restart function is used. The simulation save and restart method stores a simulation state at a specific time point or at one or more points in a simulation process and reloads it. There is a method of re-execution, and a design state (design state refers to state information of the corresponding design object) is periodically stored in the simulation process or at one or more specific time points or sections, and reloaded and reexecuted. Detailed methods for this may also be applied to methods used to obtain visibility or to quickly perform simulations in separate domestic patents (10-2005-116706 and 10-2006-19738). Detailed descriptions will be omitted due to space limitations. However, in order to allow the simulation to be stored and restarted, it is necessary to store the simulation state or the design state periodically or at one or more specific time points or intervals as mentioned above during the simulation (this process is called a checkpoint process). In this case, a checkpoint is generated through this process), and the state or design state of the simulation is stored at the one or more specific simulation viewpoints or sections, and later re-simulated from the one or more specific simulation viewpoints or sections. Each of the one or more specific simulation viewpoints or intervals that allow the simulation to be performed is called a checkpoint. Therefore, when the rollback described above is to be performed, the actual rollback time is not the inconsistent time t_est, which is the past in time, among the time points at which the discrepancy between the expected output and the actual output has occurred, and is equal to or in time in the past. The specific checkpoint closest to t_est is the rollback target.

In this patent, the expected input / expected output used for minimizing the communication overhead and the synchronization overhead of the distributed parallel processing method may be expressed in a signal unit of bit / bitvector type, or a higher abstraction data structure ( For example, it may be expressed in a transaction unit of a type). In the case of a transaction unit, it may be a transaction of every cycle or a transaction of several cycles. Therefore, the comparison between the predicted input and the actual input or the comparison between the predicted output and the actual output is performed in the signal unit, in the transaction unit of every cycle, or in the transaction unit of several cycles according to the level of abstraction of the model. Can be performed at multiple levels of abstraction. Therefore, in the present patent, when the comparison between the expected output and the actual output or the comparison between the expected input and the actual input, the above comparisons are performed in the signal unit according to the abstraction level of the model, or in the transaction unit of each cycle. It includes all that is performed, or performed in a transaction unit of several cycles, or performed in an un-timed transaction unit.

In this patent, the distributed parallel simulation method described in this patent is distributed distributed execution method using s-DCP or reduced distributed parallel execution method or distributed processing parallel simulation (ie distributed processing parallel execution). The distributed or parallel processing parallel simulation is not the conventional distributed parallel simulation method, but the distributed proposed in this patent that minimizes the communication overhead and the synchronization overhead of the distributed simulation by using the expected input and the expected output using s-DCP. Only parallel simulation method). In order to achieve the maximum performance of the distributed parallel execution method using the s-DCP, the total number of actual I / O releases and the total time from the actual I / O-run application to the time of the actual I / O-run release are required. It is very important to minimize (i.e., the total time the simulation is performed in a real-world I / O fashion). For this purpose, the accuracy of the s-DCP used to obtain the expected input and expected output of each local simulation is very important. In other words, the higher the accuracy of s-DCP, the smaller the interval that is performed by the actual I / O method in the entire section of the simulation, and most of the sections can be performed by the expected I / O-run method. Communication overhead and synchronization overhead, which are critical constraining factors, can be greatly reduced, which greatly improves the performance of distributed parallel simulation. However, not only the accuracy of the s-DCP but also the time required to acquire the s-DCP, that is, the s-DCP acquisition time, is also very important. Because the highest accuracy of s-DCP is simulated with the same level of abstraction model (i.e., the model to be distributed parallel simulation) to obtain the expected input and the expected output or the expected input or the expected output for the local design object. Although accurate, in this case the time it takes to acquire it is usually very long, and in most cases there are many problems. However, there are some cases where this method of obtaining s-DCP while simulating at least the same level of abstraction is very efficient, for example when performing a regression test or when the design has changed very locally, or in general, for a specific test. Since the simulation using the bench is not performed only once in the entire verification process, it is the case that the previously obtained s-DCP can be used in the one or more simulation processes performed earlier. In other words, in regression tests that investigate back-ward compatibility, most of the tests pass without error detection, and s obtained by simulating the regression test process using the same level of abstraction level design object. The accuracy of the obtained s-DCP is very high when the simulation is performed using a distributed parallel execution method using a s-DCP or a distributed parallel execution / single execution hybrid method (described later) using -DCP. In most tests, the regression test is dispersed by minimizing the total number of actual I / O releases and the total time from the actual I / O-run release to the time of applying the I / O run. The parallel simulation approach allows you to maximize the performance of your simulation and perform it very quickly. It is. Even if the design is only changed locally due to debugging or specification change, the distributed parallel execution method or the distributed parallel execution / single combination method (using s-DCP collected in the simulation process before the design change) If the simulation is carried out in a distributed processing parallel method (described later) using incremental simulation (explained later), the performance of the simulation can be maximized and performed very quickly.

In addition, it is not preferable to perform distributed parallel simulation by the actual I / O-run method from t_lockstep at the time of applying at least one actual I / O during the distributed parallel simulation by the distributed processing parallel execution method in the present patent. (For example, if you cannot assign many simulator licenses to a specific simulation task for a long time because there are not many licenses of the simulator, or if you are not expecting a significant improvement in simulation performance when performing distributed I / O-run distributed parallel simulation, Etc.) Instead of performing the distributed I / O distributed parallel simulation from the time t_lockstep where the distributed I / O distributed parallel simulation can be performed, a single simulation is performed for the DUV using a single simulator ( This In this case, the simulation for TB may be simulated with the single simulator or TB may be co-simulated with another simulator when the TB needs to be performed with a simulator that performs DUV and another simulator (for example, an HVL simulator). More detailed explanations are possible later).

In other words, in such a performance, a distributed parallel simulation using the distributed parallel processing method according to the present invention is performed for a certain period of the entire simulation time (for example, from the simulation time point 0 to the first expected output / actual output mismatch time point). DUV's t-DCP (DUV's t-DCP is a DUV that can be performed in local simulations that can be performed quickly and at the end of distributed parallel simulations while minimizing synchronization overhead and communication overhead between simulators. T-DCPs of design objects can be combined), and the generated DUV's t-DCP can be used to perform the simulation for the DUV as a single simulation from the point of application of the actual I / O. (I.e. from this point in time the actual I / O application run actually Does not proceed to distributed parallel simulation, but a single simulation). Such a scheme in the present patent will be referred to as a "distributed processing parallel / single mixed mode" from now on. In other words, both s-DCP and t-DCP are used in a distributed parallel processing / single performance hybrid method (a separate simulation compilation is required for a single simulation).

In addition, as another variation, it is also possible to perform distributed parallel processing as a configuration different from the above distributed parallel processing method from the actual I / O application-run point. For example, there are four design objects B0, B1, B2, and B3 in the DUV. In the initial distributed processing, B0, B1, B2, and B3 are assigned to each of four simulators running on four computers. Run up to the point of application, and from this point on, use only two simulators, assigning only B0 to the first simulator (for example, B0 is a TB design object), and assigning B1, B2, and B3 to the second simulator. It is also possible to perform I / O-run distributed parallel simulation and to allow the other two simulators to perform different simulation tasks (in this case, a new simulation compilation is required for a specific local simulation. Local simulation for continuous simulation without the need for new simulation compilation This process is possible, but local simulations for B1, B2, and B3 require new simulation compilation), and all of these methods are defined as being included in the distributed parallel processing method in this patent. In the general simulation process other than the cases, when s-DCP is not a simulation model but dynamic information, it is practically problematic to obtain a simulation at the same level of abstraction that requires a very long simulation time to obtain s-DCP. . In this case, instead, the s-DCP model can be used as the s-DCP, or the entire DUT and TB model optimized for fast simulation can be used as the s-DCP. It is efficient to obtain s-DCP using dynamic information obtained from the simulation using the model at the upper level of the abstraction or the above-mentioned method (Utilization Method 3 and Application Method 4 mentioned above). For example, for gate-level timing simulation, use an RTL model or an RTL / gate-level mixed model directly with s-DCP in each local simulation, or use a gate-level model optimized for fast simulation. S-DCP (e.g., one or more RTL / gate level mixed models) by using s-DCP directly, or using dynamic information obtained from the RTL simulation process as the s-DCP or RTL / gate level mixed simulation. Sum of the input and output information of the gate-level design object present in each model of each of the above 1 or more RTL / gate-level mixed models As a specific example, the example of the GL model previously described DUV (GL) = (B (1) _gl, B (2) _gl, B (3) _gl, B (4) _gl), and the RTL model consists of DUV (RTL) = (B (1) _rtl, B (2) _rtl, B (3) _rtl, 4 if B (4) _rtl) RTL / GL mixed models of DUV (MIXED) _4 = (B (1) _rtl, B (2) _rtl, B (3) _rtl, B (4) _gl), DUV (MIXED) _3 = (B (1) _rtl, B (2) _rtl, B (3) _gl, B (4) _rtl), MODEL_DUV (MIXED) _2 = (B (1) _rtl, B (2) _gl, B (3) _rtl, B (4) _rtl), MODEL_DUV (MIXED) _1 = (B (1) _gl, B (2) _rtl, B (3) _rtl, B (4) _rtl) and these four ESL / RTL mixed models Among them, I / O information of B (1) _gl in simulation using model DUV (MIXED) _1, I / O information of B (2) _gl in simulation using model DUV (MIXED) _2, B in simulation using DUV (MIXED) _3. In the simulation using the input / output information of (3) _gl and DUV (MIXED) _4, the input / output information of B (4) _gl is obtained and all four input / output information are combined as s-DCP), and the ESL model is used for the RTL simulation. ESL / RTL model as s-DCP, or RTL model optimized for fast simulation, s-DCP, or ESL simulation Input / output information of the RTL design object present in each model of the s-DCP (eg, one or more ESL / RTL mixed models) by using the dynamic information obtained in the migration process as the s-DCP or the dynamic information obtained in the ESL / RTL mixed simulation process. Sum for all of the one or more ESL / RTL mixed models. As an example, an example of the RTL model described above consists of DUV (RTL) = (B (1) _rtl, B (2) _rtl, B (3) _rtl, B (4) _rtl), and the ESL model is DUV (ESL). When four BSL models are composed of (B (1) _tlm, B (2) _tlm, B (3) _tlm, B (4) _tlm), the four ESL / RTL mixed models are DUV (MIXED) _4 = (B ( 1) _tlm, B (2) _tlm, B (3) _tlm, B (4) _rtl), DUV (MIXED) _3 = (B (1) _tlm, B (2) _tlm, B (3) _rtl, B ( 4) _tlm), MODEL_DUV (MIXED) _2 = (B (1) _tlm, B (2) _rtl, B (3) _tlm, B (4) _tlm), MODEL_DUV (MIXED) _1 = (B (1) _rtl, 4 models of B (2) _tlm, B (3) _tlm, and B (4) _tlm), and B (1) in the simulation using model DUV (MIXED) _1 of these four ESL / RTL mixed models. I / O information of _rtl, model DUV (MIXED) _2, I / O information of B (2) _rtl, simulation of DUV (MIXED) _3, I / O information of B (3) _rtl, simulation using DUV (MIXED) _4 In I / O information of B (4) _rtl and all four of these I / O information are summed to s-DCP) For the ESL simulation, use the s-DCP as the higher level transaction model than the current ESL level model, or use the s-DCP as the s-DCP which is optimized to perform the simulation quickly. S-DCP uses dynamic information obtained from the ESL simulation process using the higher-level transaction model than the current ESL level, or the transaction level (TLM model) higher than the current ESL level and the same transaction level as the current ESL level. Dynamic information obtained from a mixed simulation process using a mixed model (TLM model) is obtained from s-DCP (e.g., a ca-transaction level design object present in each model of one or more timed-transaction / ca-transaction mixed models. Sum the output information for the one or more timed-transaction / ca-transaction mixture models. As an example, an example of the ca-tlm-level ESL model described above. DUV (ca-tlm) = (B (1) _ca-tlm, B (2) _ca-tlm, B (3) _ca-tlm, B (4) ESL model DUV (timed-tlm) = (B (1) _timed-tlm, B (2) _timed-tlm, B (3) _timed-tlm, B (4) 4 timed-tlm / ca-tlm mixed models, DUV (MIXED) _4 = (B (1) _timed-tlm, B (2) _timed-tlm, B (3) ) _timed-tlm, B (4) _ca-tlm), DUV (MIXED) _3 = (B (1) _timed-tlm, B (2) _timed-tlm, B (3) _ca-tlm, B (4) _timed -tlm), MODEL_DUV (MIXED) _2 = (B (1) _timed-tlm, B (2) _ca-tlm, B (3) _timed-tlm, B (4) _timed-tlm), MODEL_DUV (MIXED) _1 = 4 models of (B (1) _ca-tlm, B (2) _timed-tlm, B (3) _timed-tlm, B (4) _timed-tlm), and these four timed-transactions / ca -The output information of B (1) _ca-tlm in the simulation using model DUV (MIXED) _1 among the mixed mixture models, the output information of B (2) _ca-tlm and DUV in simulation using model DUV (MIXED) _2. Simulation using (MIXED) _3 In B (3) _ca-tlm of the output information, DUV (MIXED) is s-DCP in the simulation using the output information of getting _4 B (4) _ca-tlm put together all of the four output information. As another example, the output information of RTL level design objects present in each model of one or more ca-transaction / RTL mixed models is summed for the one or more ca-transaction / RTL mixed models. As an example, an example of the ca-tlm-level ESL model described above. DUV (ca-tlm) = (B (1) _ca-tlm, B (2) _ca-tlm, B (3) _ca-tlm, B (4) 4 ca, consisting of) _ca-tlm) and RTL model DUV (rtl) = (B (1) _rtl, B (2) _rtl, B (3) _rtl, B (4) _rtl) -tlm / RTL mixed models with DUV (MIXED) _4 = (B (1) _ca-tlm, B (2) _ca-tlm, B (3) _ca-tlm, B (4) _rtl), DUV (MIXED) _3 = (B (1) _ca-tlm, B (2) _ca-tlm, B (3) _rtl, B (4) _ca-tlm), MODEL_DUV (MIXED) _2 = (B (1) _ca-tlm, B ( 2) _rtl, B (3) _ca-tlm, B (4) _ca-tlm), MODEL_DUV (MIXED) _1 = (B (1) _rtl, B (2) _ca-tlm, B (3) _ca-tlm, In the simulation using the model DUV (MIXED) _1 among the four ca-transaction / RTL mixed models composed of four models of B (4) _ca-tlm), the output information of B (1) _rtl, the model DUV Output information of B (2) _rtl in the simulation using (MIXED) _2, output information of B (3) _rtl in the simulation using DUV (MIXED) _3, and B (4) _rtl in the simulation using DUV (MIXED) _4. Get output information The sum of these four outputs is s-DCP. As another example, the output information of the GL-level design object existing in each model of one or more RTL / GL mixed models is summed for the one or more RTL / GL mixed models. As a specific example, the example of the RTL model described above consists of DUV (rtl) = (B (1) _rtl, B (2) _rtl, B (3) _rtl, B (4) _rtl) and GL model DUV (rtl) = In the case of (B (1) _gl, B (2) _gl, B (3) _gl, B (4) _gl), four RTL / GL mixed models are obtained using DUV (MIXED) _4 = (B (1 ) _rtl, B (2) _rtl, B (3) _rtl, B (4) _gl), DUV (MIXED) _3 = (B (1) _rtl, B (2) _rtl, B (3) _gl, B (4 ) _rtl), MODEL_DUV (MIXED) _2 = (B (1) _rtl, B (2) _gl, B (3) _rtl, B (4) _rtl), MODEL_DUV (MIXED) _1 = (B (1) _gl, B (2) _rtl, B (3) _rtl, B (4) _rtl), and B (1) _gl in the simulation using model DUV (MIXED) _1 of these four RTL / GL mixed models. Output information of B (2) _gl for simulation with model DUV (MIXED) _2, output information of B (3) _gl for simulation with DUV (MIXED) _3, and simulation with DUV (MIXED) _4 Obtaining the output information of B (4) _gl and combining all four output information is used as s-DCP). In this way, the model obtained at the higher abstraction level is used as s-DCP, or the same abstraction level model optimized at the same time as the s-DCP is optimized, or the dynamics obtained from the simulation using the model at the upper level of abstraction are used. When the information is used as s-DCP or the dynamic information obtained from the simulation using the model of the same abstraction level optimized to perform the simulation is used as the s-DCP, the simulation speed is very fast. The process of getting the expected output can be done very quickly. Therefore, the accuracy of the s-DCP obtained as described above is a problem, and the model coherence exists between the abstraction high-level model and the lower-level model that are logically specified through the gradual materialization process. The accuracy of the obtained s-DCP can be considered to be very high.

Ideally, if there is a complete coherence between the models that exist in these incremental refinements, the entire simulation can be performed without applying the actual I / O method once, and the higher the consistency between these models, the higher the actual I / O It is important to increase the consistency between models as it is possible to minimize the total number of run releases and the total time from each actual I / O-run to the actual I / O-run release. However, there is a very high model between models at the immediate abstraction levels (eg ca-transaction model and RTL model, or RTL model and gate-level model, etc.) at various levels of abstraction present in the design through the gradual materialization process. While it is possible to be consistent, this situation is naturally satisfied. If the accuracy of the s-DCP obtained by simulating the model of the abstraction is not satisfactory (the modeling of the abstraction higher-level model is wrong or due to the higher-level abstraction, If the accuracy of the dynamic information obtained by simulating the model of high accuracy or abstraction is low), the process of increasing the accuracy of s-DCP should be performed. Therefore, if you use a high-level abstraction model with high accuracy from the beginning, or if the modeling of the abstraction-high-level model is wrong, modify the model of the abstraction-high level model to obtain the correct abstraction-level model, and then obtain the correct higher-level model. To increase the accuracy of the s-DCP by obtaining the highly accurate dynamic information, or to correct the dynamic information obtained by simulating the high-level model of the wrong abstraction to obtain the high-precision s-DCP or the relatively accurate accuracy. Falling Abstraction High-precision s-DCP can be obtained by dynamically or statically modifying dynamic information obtained by simulating a higher-level model. An example of how to create a highly accurate abstraction high-level model with relatively little effort is to communicate a specific block in the model that is frequently used in the Transaction-Level Model (TLM) method with the external interface. The module is divided into a communication module and an internal calculation module, and the I / O timing accuracy of this specific module is left as it is (for example, the internal calculation module is dictated at an untimed-transaction level). By adding the timing annotation of the desired level to the communication module, from the input / output point of view, it is possible to achieve the required tie accuracy (e.g., accuracy in every cycle or accuracy in multiple cycles) at the module level. Speed can be achieved. It is possible to obtain a high s-DCP. It is also possible to add a transducer to a specific transaction-level communication module of such a model to convert the abstraction level of the module from the input / output point of view to a transaction level or register transfer level of another abstraction level. For example, if Forte Design's Cynthesizer's TLM synthesis is used, it is also possible to synthesize the TLM communication module into a communication module with cycle accuracy of signal unit that can be implemented in hardware. It is also possible to create models. In addition, if the s-DCP can be modified to obtain a high-precision s-DCP, such a transcript may be used when the model at the higher abstraction level is ca-transaction level or timed-transaction level. Since the projection must satisfy the on-chip bus protocol (for example AMBA bus protocol) protocol, the s-DCP can be modified by changing the s-DCP that violates this protocol to s-DCP conforming to this bus protocol protocol. You can increase the accuracy. Another specific example of a situation in which an accurate s-DCP can be obtained by modifying the s-DCP is distributed parallelism simulation for the GL model (distributed parallelism simulation in the present patent. This means that the parallel parallel simulation using the parallel processing method, the distributed parallel simulation using the distributed parallel processing, the distributed parallel simulation using the distributed parallel processing, and the distributed parallel simulation using the distributed parallel processing. In order to improve the accuracy of the s-DCP obtained from the RTL simulation or the RTL / GL mixed simulation, the SDF analysis or the delay time parameters of the library cells or the gate using the SDF are used. Level timing simulation with short simulation time intervals Or specific combinations of signal lines in the design object (e.g., clock signal lines, flip-flop output signal lines constituting the input information of each local simulation, etc.). For the correct delay time information (e.g., the clock skew delay of the flip-flop clock input in the case of flip-flops, and how much delay the positive-edge-sensitive flip-flop output changes after the rising edge of the clock input). clock-to-Q delay (clock-to-Q (high_to_low), clock-to-Q (low_to_high)), and clock of how long the negative-edge flip-flop output changes with the delay after the polling edge of the clock input occurs. -to-Q delay times (clock-to-Q (high_to_low), clock-to-Q (low_to_high)), and the flip-flop output at the asynchronous set enable edge of the flip-flop. The accuracy of s-DCP can be increased by obtaining the aset_to_Q delay to the point, the areset_to_Q delay from the flip-flop asynchronous reset enable edge to the point where the flip-flop output changes, etc.) In other words, the partitioning of the model for each local simulation to perform the gate-level timing simulation in a distributed parallel simulation is performed so that the outputs of the corresponding local design objects of each local simulation obtained through the partitioning are all the outputs of the flip-flop. Dividing). Another specific example of a situation in which an accurate s-DCP can be obtained by modifying the s-DCP is that in an ESL simulation or an ESL / RTL mixed simulation when distributed parallelism simulation of an RTL model is desired. In order to improve the accuracy of the obtained s-DCP, RTL functional simulation is performed only in a short simulation time interval, so that accurate timing information that does not exist in the ESL model (e.g., the time it takes for the output of the flip-flop to change after the clock rises, The accuracy of the s-DCP can be increased by obtaining the phase difference between the asynchronous clocks and reflecting the same in the s-DCP.

Not only can this modification of the s-DCP be carried out statically before the start of the distributed parallel simulation, but also dynamically (ie distributed parallel) during the execution of the distributed parallel simulation as necessary. As the simulation progresses, modification of the s-DCP is performed). For example, ca-transaction level can be used to modify the s-DCP dynamically (if s-DCP is already dynamic information) during the execution of distributed parallel simulation and use it as expected input or expected output. When the predicted input and the predicted output collected from the previous simulation performed in the simulation are used in distributed parallelism simulation using event driven simulation in the RTL, which is the latter simulation, the simulation is performed at the ca-transaction level at the beginning of the simulation. Performing distributed parallel simulation in RTL using expected input and expected output from s-DCP obtained from dynamic information with poor accuracy, dynamically reflecting the result of this distributed parallel simulation, and reducing the accuracy of s Increase the accuracy of DCP (specifically, ca-transaction This occurs when the RTL model is dictated so that the user clock in the model, a timing parameter that does not exist at the level, rises and changes one nanosecond (# 1 in Verilog syntax) from the time the output of the flip-flop in the model rises. The same situation (clock-to-Q latency event situation) is dynamically identified from the RTL simulation results early in the RTL simulation run and reflected in the s-DCP collected from the simulation at the ca-transaction level (ie ca- The s-DCP improves the accuracy of the s-DCP by reflecting the 1-nanosecond clock-to-Q delay that is not present in the s-DCP collected in the simulation at the transaction level, and the expected input from the increased s-DCP. And the expected output). This dynamic method estimates the expected inputs and outputs from the s-DCP with increased accuracy. When used as output and expected output, effective distributed parallel simulation using s-DCP, which has increased dynamic accuracy from the beginning of the simulation, becomes possible (i.e., this method has relatively low accuracy of s-DCP at the beginning of the simulation. As the execution of the actual I / O method progresses, the accuracy of the low accuracy s-DCP during the execution of the actual I / O method is on-the-run. fly) Using the collected dynamic information, this process can be thought of as a dynamic learning process, and thus the execution of the expected I / O-run method using s-DCP, which has increased accuracy, is performed. By doing so, since the initial simulation, the performance of the I / O method can be maximized. Is conducted). This technique can be applied not only to the distributed parallelism simulation in RTL described above, but also to distributed parallelism simulation considering timing in GL. That is, in the distributed parallel parallel simulation process considering the timing in GL, which is the latter simulation stage, which uses the s-DCP, which has relatively low accuracy collected in the RTL simulation, which is the previous simulation stage, the accuracy decreases at the same time as the simulation progresses. (original) s-DCP is the result of a simulation that is obtained dynamically during a timing simulation run in real I / O. (The results of this simulation are obtained in a distributed parallelism simulation run in real I / O. Dynamic information, resulting in a simulation that contains all of the accurate timing information in GL), and then transforms it into a more accurate s-DCP and uses the expected input and output in this highly accurate s-DCP. Expected value by executing parallel parallel simulation Using force - can maximize the proceeds of the run way.

Therefore, in the present patent, all of these processes for increasing the accuracy of s-DCP described above are collectively referred to as "s-DCP accuracy enhancement process". However, if the original s-DCP is not dynamic information collected in the previous simulation, and the model is a high level abstraction, the s-DCP accuracy enhancement process is performed by performing the original s-DCP, which is a high level abstraction model. The process of augmenting the accuracy of information in real time during the simulation time. In particular, by using the dynamic information collected dynamically at the beginning of the simulation of the trailing stage simulation just described above, the accuracy of s-DCP, which is less accurate in the leading edge simulation during the trailing stage simulation, is increased, or abstracted. The original s-DCP, which is a high-level model, is performed dynamically in real time during simulation time, or the original s-DCP, which is a model of the same level of abstraction that is optimized for fast simulation, is performed. All of the s-DCP accuracy enhancement processes in the present patent, which increase the accuracy of the dynamic information collected in real time during the simulation time, will be referred to as "s-DCP accuracy enhancement process using dynamic learning".

Another specific example of the process of increasing accuracy of s-DCP is as follows. First, by using the first order s-DCP or the first order t-DCP, which is obtained by simulating a high-level model of abstraction (the model of this high-level abstraction has a partial hierarchy correspondence with the model of the lower level of abstraction that is the original simulation target). Design objects that exist in the DUV, the abstraction lower-level model that is the original simulation object, each of these design objects exist in the upper-level model by partial layer correspondence, or in parallel to the DUV. By running the simulation more than once, a second order s-DCP with improved accuracy can be obtained. As a specific example, it is possible to use a first-order s-DCP to apply an expected input to each of the design objects, while simulating them (this simulation can be performed in parallel simulation completely independent of each design object). When the outputs of the design objects are collected, the second s-DCP is obtained. The second s-DCP is obtained by targeting the design objects that exist in the model to be the original simulation object, and thus it is possible to obtain very high accuracy. As another specific example, a simulation of DUV, which is a low-level abstraction model, is performed in parallel by dividing a plurality of simulation time intervals in time using a first-order t-DCP obtained by simulating the high-level abstraction model (TPE method). In this simulation process, the inputs and outputs of each design object in the DUV can be combined to obtain a second-order s-DCP with improved accuracy. Another specific example of s-DCP accuracy augmentation is to target two or more mixed abstraction level models consisting of a number of design objects dictated by a higher level of abstraction and a few design objects dictated by a lower level of abstraction. Time alignment of two or more dynamic information of all design objects dictated by the abstraction lower level collected in the above-described parallel simulation (all the design objects constitute the model of the lower abstraction level) in simulation time ( Time alignment refers to the matching of dynamic information in simulation time because the dynamic information for each of the design objects at the lower abstraction level may be different from each other in simulation time due to the inaccuracy of the model at the higher abstraction level. Alignment is easy when done at the transaction level For example, the dynamic information of one or more design objects in a model collected in one or more simulations of one or more models can be found and matched to the beginning of the same specific transaction. Enhanced s-DCP can be obtained. Another specific example of s-DCP accuracy enhancement is a simulation of a high level abstraction model or two or more composed of a number of design objects dictated by a high level of abstraction and a small number of design objects dictated by a low level of abstraction. Actual input using dynamic information about the design objects in the model collected in two or more parallel simulations for mixed abstraction level models as expected input and expected output of each local simulation in distributed parallelism. Or, the process of comparing with the actual output is carried out at the transaction level. In other words, even though these expected inputs and actual inputs or expected outputs and actual outputs are different at the pin level cycle unit, they may be the same in several cycle units at the transaction level. The accuracy of s-DCP can be improved if the comparison is not done at the pin level cycle but at the transaction level multiple cycles. In other words, increasing the pin-level s-DCP accuracy in cycles is relatively expensive, so instead of comparing the expected input with the actual output or comparing the expected output with the actual output, the transaction unit s-DCP accuracy Progression to level (A specific example of the method is to compare the expected value with the actual value first in the unit of transaction to find the expected transaction that matches the actual transaction, and in the matched project, the actual transaction and the unit of the cycle. Therefore, when comparing the expected value and the actual value in such a transaction unit, the expected transaction and the actual transaction are not compared based on the absolute simulation time. Compare the expected transaction with the actual transaction in terms of, for example, the start time of a specific expected transaction is 1,080ns and the end time 1,160 ns, even if the start time of a specific real transaction is 1,000 ns and the end time is 1,080 ns, if the expected transaction and the actual transaction match the meaning in the unit of transaction, the expected transaction and the actual transaction match. The reason why the absolute simulation time of the matched and actual transactions can be changed can be found in the inaccuracy of the high-level abstraction model or the loss of information due to the abstraction. Value-to-actual matching must take this into account, and the order in which these transactions appear, as well as the simulation time they occur, between transactions at different levels of abstraction, or between transactions at specific levels of abstraction and the RTL's event sequences that specify them. Or the sequence in which transactions and event sequences appear For example, a transaction at the timed-transaction level T_timed = {T1, T2, T3, T4} and the transaction at the ca-transaction level that embodies it. T3 = {t31, t32}, T1 = {t11, t12, t13, t14}, T4 = {t41, t42}, T2 = {t21, t22, other than the order of T1, T2, T3, T4 t23} (tij is ca-transaction in cycles. For example, a timed-transaction T3 may consist of two ca-transactions t31 and t32), and thus, the absolute simulation time of the expected transaction and the actual transaction may be different in this case. Therefore, even in this case, the matching between the expected value and the actual value at the transaction level should be taken into account), and it is easy to determine whether the expected value (expected input or expected output) is in violation of the on-chip bus specification and, if necessary, It is possible to effectively increase the accuracy of the s-DCP through the modification process, and the s-DCP accuracy enhancement process in the present patent which enhances the accuracy of the s-DCP by using the transaction level s-DCP. It will be referred to as "s-DCP accuracy process through the transaction". In this case, the s-DCP accuracy enhancement process through the transactionalization is also performed when the s-DCP is a high level abstraction simulation model, and dynamic information obtained from the high level abstraction simulation model is performed during the local simulation. It is possible.

It should be mentioned that the simulation method using the predicted input and the predicted output described above can not only improve the performance of distributed parallel simulation using two or more processors, as described above, but also provide a single processor (herein, Inter-process communication overhead and processes between the two or more processes and threads, even if the simulation is to be performed in two or more processes or threads. Process synchronization synchronization overhead can also be greatly reduced.

Using t-DCP enables parallel simulation of TPE, and using s-DCP enables parallel simulation of DPE. Parallel simulation of the TEP method divides the entire simulation time interval into two or more simulation time intervals (called slices) to independently perform each of these two or more simulation intervals. DEP parallel simulation divides the entire design objects (DUV and TB) into two or more sub-design objects and executes each of these two or more sub-design objects in a distributed parallel method in a separate simulator. As mentioned earlier, the accuracy of t-DCP and s-DCP is very important, but it is also important that the time required to acquire them is not excessive. Therefore, when it is possible to obtain t-DCP and s-DCP by simulating the design object of the specific abstraction level to be simulated, regression test or design change is made locally. In other cases, acquiring t-DCP and s-DCP by simulating a model that is higher than the specific level of abstraction is an efficient way to increase their accuracy as well as a fast acquisition time. In the TPE parallel simulation, the three methods mentioned above will be explained in more detail. First, in the method 1, the state information of the abstraction high-level model is collected at one or more simulation specific points or intervals in the simulation process of the abstraction high-level model, and the state information of the abstraction high-level model is collected from the above-mentioned one or more. Convert to state information of abstraction low-level model at a specific point of time or in a specific section (for details of the conversion method, refer to that described in Korean Patent (10-2005-116706)) and state information of the converted abstraction low-level model. It is possible to quickly perform the simulation for the abstraction low-level model by performing the simulation of the abstraction low-level model in parallel for each slice or only a specific slice. In method-2, two or more abstract mid-level models (DUVs that have both abstract high-level design objects and abstract low-level design objects) are executed in parallel independently. The state information of the abstraction low-level model is obtained by adding the state information together, and the simulation of the abstraction low-level model can be performed quickly by executing the simulation of this abstraction low-level model in parallel for each slice or only performing a specific slice. It is possible to carry out (see Figure 6). By using t-DCP obtained by performing these abstraction high-level models or by executing two or more abstract intermediate models in parallel or sequentially, the abstraction low-level model is divided into slices that are two or more simulation time intervals in simulation time. A detailed method for quickly performing a simulation on an abstraction low-level model by sequentially performing only slices or divided slices is described in detail in Korean Patents (10-2005-116706) and Korean Patents (10-2006-19738). In this patent, detailed description thereof will be omitted. However, when t-DCP is acquired at a higher level of abstraction, such as when s-DCP is acquired at a higher level of abstraction, t-DCP can be obtained quickly, but the accuracy of t-DCP may be low. In addition, there is a need for a method of increasing accuracy such as s-DCP. To this end, in the previous simulation, the state information stored from the T_f time point to the T_r time point for the abstraction high-level model is re-absorbed from the T_f time point (or from the previous time point) to the high-level model and released at the T_r time point. The input information of the high-level model (this information is collected and stored in the previous simulation) remains intact even after the time T_r (however, all user clocks from TB are not supplied, and user clock sources exist inside the DUV, such as PLLs). In this case, the user clock signals also maintain the value at the time T_r after the time T_r, and wait until the state information at the time T_r does not change anymore and stabilizes (that is, no longer changes). The state information at the time point is the state information with increased accuracy. However, if there are two or more asynchronous user clocks (they are completely independent) and there is an event of the user clocks between T_r and the unchanging time T_s, the above-mentioned process should be repeated.

In addition, even in the TPE simulation of the abstraction lower-level model using the first-order t-DCP obtained in the simulation process of the abstraction higher-level model, the abstraction higher-level model due to the low accuracy of the abstraction-higher model Dynamic information collected from one or more design objects present within may deviate from the simulation time, thereby lowering the accuracy of the primary t-DCP. Therefore, even in this case, t-DCP accuracy may be increased by time alignment described in the s-DCP accuracy enhancement process. Therefore, all the processes for increasing the t-DCP accuracy is called t-DCP accuracy enhancement process in this patent. The parallel simulation method using t-DCP in the above-described patent includes a time parallel execution method using t-DCP or a time-division parallel execution method (ie, a time divisional parallel execution method using the t-DCP). Refers to only the parallel simulation method proposed by the present patent which divides the entire simulation section into two or more slices using t-DCP and performs parallel execution for each slice.

The simulation method in this patent that utilizes the simulation results using the abstraction high-level model or the abstraction mid-level model for the simulation using the abstraction low-level model can not only speed up the simulation using the abstraction low-level model, You can effectively investigate the consistency between the abstraction high-level model and the abstraction low-level model. That is, if the simulation results for the abstraction lower-level model using the simulation results using the abstraction high-level model or the abstraction mid-level model do not match the simulation results using the abstraction high-level model or the abstraction mid-level model. This illustrates a specific example of inconsistency between the abstraction high-level model and the abstraction low-level model. By analyzing and eliminating the cause, it is possible to effectively maintain the consistency among the models existing at different levels of abstraction.

In the two types of parallel simulations mentioned above, DPE and TPE, it is possible for the leading and trailing simulations to simulate the same design at the same level of abstraction, but in general, the leading and trailing simulations have the same design with the same level of abstraction. The simulation is not to be verified, but to design verification at a different level of abstraction. That is, the front end simulation for the purpose of quickly obtaining s-DCP or t-DCP is generally performed on a model modeled at a higher level with a relatively high level of abstraction. This is achieved by targeting models that are modeled at lower levels of abstraction than those used in earlier simulations (as described previously, s-DCP is abstraction in distributed parallelism simulation using s-DCP). Note that the higher-level simulation model itself or the simulation model itself can be the same abstraction level optimized to perform the simulation quickly, so the earlier simulation is not necessary). In addition, the present patent focuses on one of performing a simulation that is performed later in time by using a simulation result performed earlier in time. Therefore, a method of performing the simulation performed earlier in time is faster than this simulation. It is also possible to obtain s-DCP from the simulation results performed earlier in time and use the distributed parallelism simulation in the present patent using the same, or use various conventional distributed parallel simulations (general distributed parallel simulation).

In addition, it is possible to quickly perform simulations performed when one or more design objects are modified by reusing the results of the distributed parallelism simulation proposed in this patent and the previous simulations presented in a separate patent 10-2004-93310. Another efficient simulation is possible by using the incremental simulation that is performed together. In other words, by using dynamic information (status information, input information, output information, etc.) of one or more design objects collected in the previous simulation, the one or more design objects are modified due to debugging or specification change. In the case where the simulation performed later is performed by the distributed parallelism simulation in the present patent, instead of performing distributed parallel simulation using two or more local simulations from the beginning of the simulation (simulation time 0), it is proposed in Patent 10-2004-93310. Using incremental simulation techniques, from the simulation time 0 to a specific simulation time ts, one or more local design objects that have been modified and one or more local design objects that have not been modified or made use of their input information or modified. Part of the design objects (eg Design objects such as testbenches, etc., which are not easy to store information, and their input information, proceed to a single simulation S_s, and after ts the single simulation is converted to a local simulation S_l (i) of distributed parallel simulation. (It is also possible to switch to two or more local simulations) (switching a single simulation S_s to one local simulation S_l (i) allows the simulation to proceed without interruption from ts without additional compilation), and the distributed parallelism In one or more other local simulations of the simulation, design objects other than the design objects performed in S_l (i) (these design objects are unmodified design objects) before the modification is made. Ts collected from ts (for event-driven simulations, ts is If you want to run the simulation from ts with the state information at the point and not the point, there is an additional advantage to minimize the number of licenses of the simulator required to run the simulation from simulation time 0 to ts (where ts is important. In particular, ts is a specific check that satisfies the condition that the simulation results of design objects that are as far apart as possible from simulation time 0 at the same time and that are not modified in the simulation after the modification by modification until ts are the same as the simulation results before the modification. Must be a point. See patent 10-2004-93310 for a specific determination method. In the present patent, such a simulation method is referred to as "distributive parallel simulation using incremental simulation" or "simulation of distributed parallel processing using incremental simulation". For a detailed method, refer to the separate patent 10-2004-93310.

Other objects and advantages of the present invention in addition to the above object will be apparent from the detailed description of the embodiments with reference to the accompanying drawings.

1 is a diagram schematically showing an example of a design verification apparatus according to the present invention.

2 is a diagram schematically showing another example of the design verification apparatus according to the present invention;

Cotton.

3 is a diagram schematically illustrating an example of a hierarchical structure of an ESL model in comparison with an example of a hierarchical structure of a corresponding RTL model.

4 is a diagram schematically illustrating an example of the hierarchical structure of the RTL model in comparison with the example of the hierarchical structure of the GL model corresponding thereto. In this example, there is a design object 387 that represents an additional hierarchy with boundary scancells in the GL model.

5 is a diagram schematically showing an example of a situation in which the execution of distributed parallel simulation is performed in a situation where two or more computers are connected by a computer network.

FIG. 6 is a diagram schematically illustrating an example in which t-DCP is obtained in a front-end simulation using an abstraction high-level model and a time-division parallel execution of a back-end simulation using an abstraction low-level model is performed.

FIG. 7 is a diagram schematically illustrating an example in which s-DCP is obtained in a front-end simulation using an abstraction high-level model and a post-process simulation using the abstraction low-level model is performed by distributed parallelism.

FIG. 8 is a diagram schematically showing an example of configuration of components constituting the interior of a design code (additional code) added for distributed processing parallel parallel simulation proposed in the present patent. In other words, each local simulator or local hardware-based verification platform constituting a distributed parallel simulation environment (in this patent, hardware-based verification platform is collectively referred to as a hardware emulator, a simulation accelerator, or an FPGA board. Currently, an example of such hardware-based verification platform is Cadence Corporation. Palladium series / Extreme series, Mentor's Vstation series, Tharas's Hammer series, Fortelink's Gemini series, Aptix's SystemExplorer series, EVE's ZeBu series, Aldec's HES series, ProDesign's CHIPit series, HARDI's HAPS series, S2CInc's IP porter Part of the model to be verified 404 performed on the series (e.g., series), etc. (a combination of all parts of the model to be tested performed on these local simulators and local hardware-based verification platforms) becomes the model to be verified. Added to) Is a diagram schematically showing an example in which the behavior of the code 62 is composed of components. Therefore, the additional code 62 is added to the model so that the components shown in Fig. 8 (expected input / output use-run / actual input output-run control module 54, expected input / actual input selection module 56, expected) The output / actual output comparison module 58, the expected input / actual input comparison module 59, and the s-DCP generation / storage module 60) should be able to perform the functions. The behavior of each module is summarized as follows. The expected I / O use-run / actual input output-run control module 54 communicates with the expected output / actual output comparing module 58 and the expected input / actual input comparing module 59 and the synchronization and synchronization module 64 for distributed parallel simulation. Values from these inputs and the current state of whether the current local simulation proceeds in the expected I / O-run mode or in the actual I / O-run mode (thus the expected I / O-run / actual I / O-run) The control module 54 internally selects the predicted input / actual input according to the state variable for determining whether the current local simulation is performed in the expected input / output using-run method or the actual input / output using-run method). The output is generated by the module 56 so that the expected input / actual input selection module 56 selects the expected input, or selects the actual input, or the actual input. If a rollback is required before selecting the force, control rollback execution. That is, while the local simulation is currently in progress in the I / O-run manner (thus, the I / O-run / real-input-use-run control module 54) currently expects the input / actual input selection module 56 to input the expected input. Sending an output to select to the expected input / actual input selection module 56 and controlling it) At the same time, when it is determined that the expected output and the actual output are different from the expected output / actual output comparison module 58, the estimated input / output use-run The real input / output use-run control module 54 sends the output to the predicted input / actual input selection module 56 so that the predictive input / actual input selection module 56 selects the actual input and sends the current state variable inside the predicted input / output. When a specific rollback time for a rollback is entered from the communication-synchronization module 64 for distributed parallel simulation and at the same time switching from the use-run to the actual I / O-run, the specific rollback It also controls to perform a rollback between the two. Also, while the local simulation is currently being performed in the actual I / O-run manner (the estimated I / O-run / actual I / O-run control module 54) is executed. Output is sent to the expected input / actual input selection module 56 to allow the actual input selection module 56 to select the actual input.At the same time, the expected input and the actual input are constant from the expected input / actual input comparison module 59. When it is determined that the number of times is equal to or greater than the input, the expected input / output use-run / actual input output using-run control module 54 selects the output from the expected input / actual input so that the expected input / actual input selection module 56 selects the expected input. It sends to module 56 and at the same time switches the internal current state variable from the actual I / O run to the expected I / O run. In addition, the expected I / O-run / actual I / O-run control module 54 has two outputs for informing other local simulations via the communication and synchronization module 64 for distributed parallel simulation. S-DCP generation / storage by sending the actual I / O-run, expected I / O-run possible) to the communication and synchronization module 64 for distributed parallel simulation, and controlling the s-DCP generation / storage module 60. The module 60 causes the corrected input or the expected output to be output at the correct timing. The predicted output / actual output comparison module 58 actually comes out of the local simulation execution process from the part 404 of the design verification target model performed in the local simulator and the predicted output stored in the s-DCP generation / storage module 60. Compares the actual output and if the comparison matches, the output is expected to match the expected I / O-run / actual input-output-run control module 54 and if this comparison is inconsistent, the expected I / O-run / actual-use output-run Sends the current simulation time for rollback to the communication and synchronization module 64 for distributed parallel simulations as well as outputs a mismatch to the control module 54 to the other local simulations for this information (the current simulation time for rollback). To send).

The predicted input / actual input comparison module 59 receives the actual input from the predicted input stored in the s-DCP generation / storage module 60 and other one or more local simulations from the communication and synchronization module 64 for distributed parallel simulation. By comparison, if the comparison is matched a predetermined number of times, it is sent as an output to the expected I / O use-run / actual input output use-run control module 54. The predicted input / actual input comparison module 59 and the predicted output / actual output comparing module 58 do not compare the actual value with the expected value based only on the bit signal unit and the simulation absolute time. Note that it is determined that the difference between the actual value and the expected value is different through the "fit" and the "s-DCP accuracy process through the transaction". Finally, the expected input / actual input selection module 56 is the output of the expected input / output use-run / actual input output-run control module 54 to generate the actual input from the communication and synchronization module 64 and the s-DCP. One of the expected inputs stored in the / storage module 56 is selected and applied as input to the portion 404 of the design verification target model performed in this local simulator. If the part 404 of the verification target model M is executed in the simulation acceleration mode on the local hardware-based verification platform, the additional code 62 to be added must exist in a synthesizable form. When the portion 404 is executed on the local simulator, the additional code 62 to be added only needs to be present in a simulated form. SystemVerilog, etc.) code, or C / C + + code or a combination thereof may be present in various forms. In addition, such additional code 62 is automatically generated by the verification software of the present patent. In the example illustrated in FIG. 8, the entire additional code 62 is present in the form of C / C ++ or SystemC code outside the HDL simulator, and interfaces with a part 404 of the verification target model M expressed in HDL through VPI / PLI / FLI. As described above, a part of the additional code 62 may be represented as HDL, and the rest may be expressed as C / C ++ or SystemC code. Also shown in FIG. 8 is a typical communication and synchronization module required for a conventional distributed parallel simulation as a communication and synchronization module 64 for distributed parallel simulation. As mentioned above, in FIG. 8, the s-DCP stored in the s-DCP generation / storage module 60 obtains the input / output information of the local design object performed in the local simulation from the dynamic information obtained in the previous simulation process, and predicts it. Since the input 50 and the expected output 52 are used as the input 50 and the expected output 52, the expected input 50 and the expected output 52 are stored in a file format so that the HDL code (for example, $ readmemb or $ readmemh in Verilog) is stored. ) Or VPI / PLI / FLI so that it can be read by C / C ++ code (by including an abstraction high-level model in s-DCP, so that this abstraction high-level model is a local An example of dynamically generating expected input and expected output from the model of the upper level of abstraction while simulating with a design object and using it for simulation of the local design object. See FIG. 32).

In particular, if the additional code for each local simulation in the distributed parallelism simulation is configured in the configuration as shown in Figs. 8 to 32, the prediction I / O execution is performed to all the local simulations with the same prediction I / O execution. In addition to being able to proceed (i.e., if an I / O run is performed, all local simulations are performed together in an I / O run method), and each local simulation can also run an I / O run (e.g., The local simulations can be run in an actual I / O run and the rest of the local simulations can be run in an expected I / O run. In this case, when the I / O run is performed for each local simulation, the communication overhead or the synchronization overhead of the distributed parallel simulation cannot be completely eliminated. Similarly, there is no communication overhead and no synchronous overhead in a situation where the expected I / O-run method is performed, but in this case certain local simulations are run in real I / O and other local simulations are expected in I / O. It is possible to considerably reduce the communication overhead or the synchronization overhead.

FIG. 9 is a diagram schematically showing an example of cycle accurate bus operation in signal units at the register transfer level and cycle accurate bus operation in transaction units at the transaction level.

FIG. 10 is a diagram schematically showing design objects in the ESL model illustrated in FIG. 3 and corresponding design objects in the RTL model.

FIG. 11 is a diagram schematically showing an example of generating mixed design objects DO_t_mixed (i) having an intermediate level of abstraction by replacing each of the design objects in the ESL model illustrated in FIG. 10 with the design objects in the corresponding RTL model. to be. When the ESL / RTL abstraction mixed level model (for example, DO_t_mixed (2)) generated from the ESL model by the gradual refinement process is generated as shown in FIG. Even if it is considerably lower than the simulation speed of the high-level abstraction ESL model, the distributed processing parallel execution method in this patent can increase the simulation speed for the model of the mixed ESL / RTL abstraction level.

As a specific example, in the case of DO_t_mixed (2) in FIG. 11, a distributed parallel simulation of a distributed processing parallel execution method is composed of two local simulations. If you run the project and configure the other local simulation to run all other transaction-level design objects, you can set the simulation speed of the model DO_t_mixed (2) at the ESL / RTL abstraction mixed level to the entire model DO_t_mixed (2). It can be effectively increased as compared with the simulation. Of course, it is also generally possible to speed up the simulation of the model of the abstraction mixed level by using distributed parallel simulation of a parallel processing simulation method composed of three or more local simulations.

12 shows independent parallel execution of six mixed simulations using the six mixed design objects DO_t_mixed (1), DO_t_mixed (2), .., DO_t_mixed (6) illustrated in FIG. FIG. 1 is a diagram schematically illustrating an example of performing a time-partitioned parallel simulation of the RTL model, which is a post-simulation step, using state information collected at time points.

FIG. 13 schematically illustrates an example of a design and verification process that proceeds from an initial level of abstraction to a final level of abstraction through a gradual refinement process.

14 is a diagram schematically showing an example of a process of generating from a transaction level model through a RTL model to a gate level model through a gradual specification process.

15 is an abstraction using s-DCP or t-DCP in the process of progressing from a cycle accurate transaction level model through a gradual specification process to a verification using a RTL model and a gate level model. A diagram schematically illustrating an example of a situation in which a simulation of a low-level model is performed in a distributed processing parallel execution or a time division parallel processing. In the figure, DCP refers to s-DCP or t-DCP.

Fig. 16 is a diagram schematically showing a part of an example model for carrying out the simulation method in the present patent.

17 and 18 and 19 schematically illustrate an example of a situation in which an additional code is added by using the verification software of the present patent to perform the distributed parallelism simulation of the example model illustrated in FIG. Figures shown.

20 is a diagram schematically showing an example of a performance situation of a distributed processing parallel execution / single performance mixed method.

FIG. 21 is a diagram schematically illustrating an example of a situation in which synchronization overhead and communication overhead between the simulator and the hardware-based verification platform are reduced by proceeding the simulation through simulation acceleration to distributed parallel execution. That is, a typical simulation acceleration technique implements a design object (typically a DUV) that can be synthesized in a model on one or more FPGAs or one or more Boolean processors in a hardware-based verification platform and a non-synthesizable design object (typically a TB) on a simulator. It is implemented by physically connecting them (for example, through PCI) to connect the hardware-based verification platform and the simulator in parallel, which is the same as distributed parallel execution through two local simulations. Therefore, the distributed processing parallel execution method proposed in this patent can be applied without any change in the conventional simulation acceleration, thereby minimizing the communication overhead and the synchronization overhead between the hardware-based verification platform and the simulator existing in the conventional simulation acceleration. It is also possible.

In this simulation acceleration, the predicted input and the predicted output used in SA_run (j) are collected during the simulation of SIM_run (i). Obtained from dynamic information (partial changes to one or more design objects in the model may occur through a specification change or debugging process between SIM_run (i) and SA_run (j)). Further, the preceding simulation execution SIM_run (i) can be performed using the same hardware-based verification platform on which SA_run (j) is performed, as well as the same hardware-based verification platform on which SA_run (j) is performed. It is also possible to simulate by using only one or two or more simulators (in this case, the entire model is simulated using only one or more simulators). In this case, only one or more simulators are used. The abstraction level of the model to be simulated may be the same level of abstraction as the design object performed by the hardware-based verification platform, but may be higher than the design object performed by the hardware-based verification platform to speed up the simulation. For example, if the design object DUV performed with the hardware-based verification platform is RTL, the level of abstraction of the simulated model (which contains the DUV) is the ca-transaction level model, or the design object DUV performed with the hardware-based verification platform. Is GL, the level of abstraction of the model being simulated (this model contains a DUV) can be an RTL model. In other words, even in the case of normal simulation acceleration, the distributed processing parallel execution method of the present patent is adopted, so that the entire process of simulation acceleration is performed at least once in the I / O process and at least one actual I / O process is required. This process can be performed by alternating the run process. By using the high accuracy predicted input and predicted output obtained from the dynamic information collected in the previous simulation process, most of the time of the acceleration process is estimated. It is possible to significantly increase the speed of simulation acceleration by greatly reducing communication overhead and synchronization overhead.

However, if there is enough memory in the hardware-based verification platform to store these expected inputs and expected outputs, all the expected inputs and expected outputs are stored in the memory existing in the hardware-based verification platform at once. If the amount of memory in the hardware-based verification platform is not large, all expected inputs and expected outputs are first stored in a large amount of memory (hard disk or main memory) on the computer connected to the hardware-based verification platform. The base verification platform has a buffer of a certain size that can store only a part of the expected input and expected output, and dynamically processes only the parts needed during the simulation acceleration process from the mass storage on the computer to the buffer. We adopt way to May.

And if you need to roll back to a design object running on a hardware-based verification platform, commercially available hardware-based verification platforms (e.g., Cadence's Palladium series / Extreme series, Mentor's Vstation series, EVE's ZeBu series, Fortelink's Gemini series, Tharas' Hammer) Shadow registers for flip-flops or latches present in the design object using the rollback function provided in the series, etc., or using the output probe / input probe function proposed in a separate patent (US 6,701,491). By using), rollback function can be easily implemented.

In the distributed parallel simulation environment referred to in this patent, one or more specific local simulations are performed by a simulator or when a part of the model to be verified in the local simulation is compositable, a hardware-based verification platform (simulation accelerator or hardware emulator or FPGA board). Commonly used, and in the case of a simulator, an event-driven Verilog simulator, a SystemVerilog simulator, a VHDL simulator, a SystemC simulator, a cycle-based SystemC simulator, a VHDL simulator, a Verilog simulator, or a SystemVerilog simulator may be used. In addition to this, any other semiconductor design simulator such as Vera simulator or e simulator can be used. Thus, in one or more local simulations that perform distributed parallel simulation, certain local simulations are run in an event-driven manner, while other local simulations that interact with them in a distributed parallel simulation run in a cycle-based fashion (eg, in FIG. 5). The on-chip bus design object 420 may be cycle-based and the remaining design objects 380, 381, 382, 383, 384, 385 may be operated in an event-driven manner. Of course, all local simulations that perform distributed parallel simulations can be run in an event-driven fashion (such event-driven distributed parallel simulations are called Parallel Distributed Event-driven Simulations (PDESs)). All local simulations performed may be run in a cycle-based manner.

FIG. 22 is a diagram illustrating some examples of logical connection structure schemes of two or more local computers installed in two or more computers for simulation of a distributed processing parallel execution scheme in the present patent. In addition to the logical connection structure schemes of the local computers shown in FIG. 22, there may be various logical connection structure schemes of the local computers, and the simulation of the distributed processing parallel execution scheme mentioned in the present patent includes various logical connection structure schemes of the local computers. Can be applied to

23 is a diagram schematically illustrating an example of a distributed parallel simulation environment in which distributed parallel simulation is performed using two or more computers and two or more HDL simulators installed on these computers. Distributed parallel simulations can also be applied to these environments.

Fig. 24 is a diagram schematically showing an example of an overall flow chart of a typical distributed parallel simulation. Thus, there can be any number of other progress flow diagrams for the overall progress of distributed parallel simulation.

FIG. 25 is a diagram schematically showing an example of an entire flow chart of distributed processing parallel simulation in the present patent. FIG. Therefore, there can be any number of other progress flow diagrams for the overall progress of distributed parallel simulation. In addition, the order of execution of each subblock in the overall flow chart (e.g., S200 to S202 to S204 to S206 to S208 to S210 to S212 in FIG. 25) may be changed so long as it does not prevent proper performance of the entire process. Alternatively, two or more subblocks may be executed at the same time as long as they do not interfere with the correct performance of the entire process.

Referring to the entire flow chart of the distributed parallelism simulation illustrated in FIG. 25, there are a total of eight subblocks except start and end. In step S200, the model to be distributed-parallel parallel simulation is read and the process proceeds to step S202. In step S202, the distributed processing is performed on the parallel simulation target model to generate a design object for each local simulation, and the design object or simulation environment for each local simulation of the distributed parallel simulation is a separate logical connection structure. In step S204 to generate an additional code for the SW server module existing in the central computer. In step S204 to read the leading simulation target model for s-DCP acquisition and proceeds to step S206. In step S206, the simulation compilation for the preceding simulation target model is performed, and the flow proceeds to step S208. In step S208, while performing the preceding simulation, the s-DCP is obtained and proceeds to step S210. In step S210, simulation compilation for each local simulation target design object for distributed processing parallel simulation is performed, and the flow proceeds to step S212. The additional codes added in the step S202 are also compiled when the simulation compilation for each local simulation target design object is performed for such distributed parallel processing. In step S212, distributed parallelism simulation is performed and the whole process is terminated.

FIG. 26 is a diagram schematically showing an example of a flowchart of local simulation execution executed by each local simulator for distributed processing parallel simulation simulation (subblock S212 in FIG. 25) in the present patent. Thus, there can be any number of other flow diagrams for performing distributed parallel simulation. In addition, the execution order of each subblock in the progress flowchart for performing this distributed parallel simulation can be changed as long as it does not interfere with the correct performance of the entire process, or two or more subblocks also perform the correct performance of the entire process. May be performed at the same time as long as they do not interfere with each other. Fig. 33 is a diagram schematically showing another example of the entire flow chart of the distributed parallelism simulation in the present patent. Therefore, there can be any number of other progress flow diagrams for the overall progress of distributed parallel simulation. In addition, the order of execution of each subblock in the overall flow chart (e.g., S201 to S203 to S211 to S213 in FIG. 33) may be changed as long as it does not prevent the correct performance of the entire process, or two or more subblocks. May also be performed at the same time as long as it does not interfere with the correct performance of the overall progress.

Referring to the entire flow chart of the distributed parallelism simulation illustrated in FIG. 33, there are a total of four subblocks except start and end. In step S201, the model to be distributed-parallel parallel simulation is read, and the flow proceeds to step S203. In step S203, the distributed processing is performed on the parallel simulation target model to generate a design object for each local simulation, and the design object or simulation environment for each local simulation of the distributed parallel simulation is a separate logical connection structure. In step S211 generates an additional code for the SW server module existing in the central computer. The additional code generated in step S203 includes the DUV and TB in the s-DCP which are at a higher level of abstraction than the design object to be simulated locally. In step S211, simulation compilation for each local simulation target design object for distributed processing parallel simulation is performed, and the flow proceeds to step S213. The additional codes added in step S203 are also compiled when the simulation compilation for each local simulation target design object is performed for such distributed parallel processing. In step S213, distributed parallelism simulation is performed and the whole process is terminated.

FIG. 26 is a diagram schematically showing an example of a flowchart of local simulation execution executed by each local simulator for distributed processing parallel simulation simulation (subblock S212 in FIG. 25) in the present patent. Thus, there can be any number of other flow diagrams for performing distributed parallel simulation. In addition, the execution order of each subblock in the progress flowchart for performing this distributed parallel simulation can be changed as long as it does not interfere with the correct performance of the entire progression, or two or more subblocks also perform the correct execution of the entire progression. It may be performed at the same time as long as it does not interfere.

Referring to the overall flow of the distributed parallel processing simulation illustrated in Figure 26, a total of 15 subblocks except for the start and end. In step S398 to set the current simulation time to 0, and proceeds to step S402. If the current simulation time of the local simulation is to create a checkpoint in step S402, and if the checkpoint has not been created at this point in advance, it is possible to roll back from another local simulation only if the checkpoint is generated now and the checkpoint is generated now. If the possibility of rollback occurs, go to step S410. If the possibility of rollback does not occur, proceed to step S418 if the current simulation time of the local simulation is equal to the actual roll forward time. If larger, go to step S422; otherwise, proceed with the simulation using the expected input to obtain the actual output, compare the actual output with the expected output, and proceed to step S406. In step S406, the actual output obtained from the simulation in step S402 compares with the expected output, and if it matches, the process proceeds to step S404. If the comparison does not match, the process proceeds to step S408. In step S404, the event time (time of occurrence of change) of the actual output is set to the current simulation time of the local simulation, and the flow proceeds to step S402. In step S408, the simulation is temporarily stopped, and a rollback possibility occurrence is transmitted to other local simulations, and the current simulation time (rollback possible time point) is also transmitted to other local simulations, and the flow proceeds to step S410. In step S410, the current simulation times (rollback possible points in time) of all local simulations in which a rollback possibility has occurred are determined, and from these, the necessity of rollback / rollforward of local simulation is determined, and at the same time, actual rollback-time / actual rollforward-time is determined. Proceed to step S412. That is, each local simulation time T_rb = (t_rb (1), t_rb (2), .., t_rb (N-1), t_rb (N)) for each local simulation in which rollback possibility has occurred, and t_rb (i) Rollback points of local simulation i where rollback possibility has occurred), and the rollback points are t_rb (1), t_rb (2), .., t_rb (N-1), t_rb (N ), T_rb (FINAL) = min (t_rb (1), t_rb (2), .., t_rb (N-1), t_rb (N)) If the current simulation time t_c (k) of the specific local simulation LP (k) performing FIG. 26 is greater than or equal to T_rb (FINAL), the specific local simulation LP (k) should perform rollback, and t_c (k) is If less than T_rb (FINAL), the specific local simulation LP (k) should perform roll forward. In step S412, if rollback is required, the process proceeds to step S414, and if rollback is not necessary, the flow proceeds to step S416. In step S416, if roll forward is required, the flow proceeds to step S402, and if roll forward is not required, the flow proceeds to step S418. In step S414, rollback of local simulation is executed, and the flow proceeds to step S418. In step S418, the simulation is performed using the actual input and the obtained actual output is transferred to another local simulation using the input, and at the same time, the actual input is compared with the expected input, and when the current simulation time of the local simulation is equal to the simulation end time, If not, proceed to step S420. In the step S420 by comparing the actual input and the expected input in the step S418 determines whether the number of times matched more than a predetermined predetermined number of times (for example, three times), if the predetermined number of times matched to proceed to step S421, otherwise to step S418 Proceed. In step S422, if all other local simulations are finished, the local simulation is also terminated. Otherwise, the process proceeds to step S424. In step S424, it is examined whether there is a need for rollback of this local simulation, and if not necessary, the flow goes to step S422, and if there is a need for rollback, the flow proceeds to step S426. In step S426, rollback is performed after the actual rollback-time determination, and the flow proceeds to step S418.

FIG. 27 is a diagram schematically showing another example of a flowchart of local simulation performed by each local simulator for distributed processing parallel simulation (subblock S212 in FIG. 25) in the present patent. Therefore, there can be any number of other flow diagrams for performing distributed processing parallel simulation. In addition, the execution order of each subblock in the progress flowchart for performing this distributed parallel simulation can be changed as long as it does not interfere with the correct performance of the entire progression, or two or more subblocks also perform the correct execution of the entire progression. It may be performed at the same time as long as it does not interfere.

Referring to the overall flow of the distributed parallel processing simulation illustrated in Figure 27, a total of 16 subblocks except for the start and end. In step S298 to set the current simulation time to 0, and proceeds to step S300. If the rollback possibility generation is transmitted from another local simulation in step S300, the flow proceeds to step S310, and if not, the flow proceeds to step S302. In step S302, if the current simulation point of local simulation is a point at which a checkpoint should be generated, and if a checkpoint has not already been generated in advance, a checkpoint is generated. If it is equal to or greater than the simulation end time, the process proceeds to step S318. Otherwise, the simulation proceeds using the predicted input to obtain the actual output, and compares the actual output with the expected output and proceeds to the step S306. In step S306, if the actual output obtained from the simulation in step S302 compares with the expected output, the process proceeds to step S304. If the comparison does not match, the process proceeds to step S308. In step S304, the event time (time of occurrence of change) of the actual output is set to the current simulation time of the local simulation, and the flow proceeds to step S300. In step S308, the simulation is temporarily stopped, a rollback possibility occurrence is transmitted to other local simulations, and a current simulation time (rollback possible time point) is also transmitted to other local simulations, and the flow proceeds to step S310. In step S310, the current simulation times (rollback possible points in time) of all local simulations that have rollback possibilities are obtained, and from these, the necessity of rollback / rollforward of local simulation is determined, and at the same time, actual rollback-time / actual rollforward-time is determined. Proceed to step S312. That is, each local simulation time T_rb = (t_rb (1), t_rb (2), .., t_rb (N-1), t_rb (N)) for each local simulation in which rollback possibility has occurred (t_rb (i) Rollback points of local simulation i where rollback possibility has occurred), and the rollback points are t_rb (1), t_rb (2), .., t_rb (N-1), t_rb (N ), T_rb (FINAL) = min (t_rb (1), t_rb (2), .., t_rb (N-1), t_rb (N)) If the current simulation time t_c (k) of the specific local simulation LP (k) performing FIG. 27 is greater than or equal to T_rb (FINAL), the specific local simulation LP (k) should perform rollback, and t_c (k) is T_rb If less than (FINAL), the specific local simulation LP (k) must perform a roll forward. In step S312, if rollback is required, the process proceeds to step S314. If rollback is not necessary, the flow proceeds to step S316. In step S316, if roll forward is required, the flow proceeds to step S302, and if roll forward is not required, the flow proceeds to step S318. In step S314, the rollback of the local simulation is executed, and the flow proceeds to step S318. In step S318, the real input is simulated and the obtained actual output is transferred to another local simulation using the input, and the actual input is compared with the expected input. When the current simulation time of the local simulation is equal to the simulation end time, the process ends. If not the same, proceed to step S320. In step S320 by comparing the actual input and the expected input in the step S318 determines whether the number of times matched more than a predetermined number of times (for example, three times) to match a predetermined number of times and proceeds to step S321 otherwise the step S318 Proceed. In step S322, if all other local simulations are finished, the local simulation is also terminated. Otherwise, the process proceeds to step S324. In step S324, it is examined whether there is a need for rollback of this local simulation, and if not necessary, the flow proceeds to step S322, and if there is a need for rollback, the flow proceeds to step S326. In step S326, rollback is performed after the actual rollback-time determination, and the flow proceeds to step S318.

Figures 26 and 27 show the control of local simulations in a distributed parallel simulation as the distributed server simulation does not use the SW server module existing in the central computer that performs the control of local simulations and the connection of local simulations (see Figure 22). The flow becomes relatively complicated by having to link the local simulations with the local simulations to be distributed to the local simulation run-time modules of each distributed parallel simulation. In the case of using a SW server module that exists in a central computer that performs local control and local simulation connection when performing distributed parallel simulation in a star-based logical interconnection architecture (see FIG. 22). Another example of distributed processing parallel simulation (subblock S212 in FIG. 25) is illustrated in FIGS. 28 and 29. 28 is a diagram schematically showing an example of a flowchart of a local simulation performed by a local simulator, and FIG. 29 is a diagram schematically showing an example of a flowchart performed by a SW server module existing in the central computer. Drawing.

As can be seen in the various examples above, there can be various various flow diagrams for performing distributed processing parallel simulations. In addition, the execution order of each subblock in the progress flowchart for performing this distributed parallel simulation can be changed as long as it does not interfere with the correct performance of the entire progression, or two or more subblocks also perform the correct execution of the entire progression. It may be performed at the same time as long as it does not interfere.

Referring to the entire flow chart of the local simulation for the distributed parallel processing simulation illustrated in FIG. 28, there are a total of 15 subblocks except for the start and end. In step S498 to set the current simulation time to 0, and proceeds to step S502. In step S502, the current simulation time information of the local simulation is generated, and if the current simulation time of the local simulation is to generate a checkpoint and if the checkpoint has not already been generated in advance, the checkpoint is generated, and the current simulation of the local simulation. If the time point is equal to the actual roll forward time, proceed to step S518. If the time point is equal to or greater than the simulation end time, proceed to step S522. Otherwise, proceed to the simulation using the predicted input to compare the actual output with the expected output. Proceed to step. In step S506, if the actual output obtained from the simulation of step S502 compares with the expected output, the process proceeds to step S504. If the comparison does not match, the process proceeds to step S508. In step S504, the event time (time of occurrence of change) of the actual output is set as the current simulation time of the local simulation, and the flow proceeds to step S502. In step S508, the simulation is temporarily stopped, and a rollback possibility generation is transmitted to the SW server module, and the current simulation time (rollback possible time point) is also transmitted to the SW server module, and the flow proceeds to step S510. In step S510, the actual rollback time / actual roll-forward time is obtained from the SW server module, and the process proceeds to step S512. In step S512, if rollback is required, the process proceeds to step S514. If rollback is not required, the flow proceeds to step S516. In step S516, if roll forward is required, the flow proceeds to step S502, and if roll forward is not required, the flow proceeds to step S518. In step S514 it performs a rollback of the local simulation and proceeds to step S518. In step S518, a simulation is performed using the actual input transmitted through the SW server module from another local simulation, and the actual output obtained is transferred to another local simulation using this as an input through the SW server module, and the actual input and the expected input are transmitted. In comparison, if the current simulation time of the local simulation is equal to the simulation end time, the process ends. If not, the process proceeds to step S520. In step S520 compares the actual input and the expected input in step S518 determines whether the number of times matched more than a predetermined number of times (for example, three times), and if the predetermined number of times matched, proceeds to step S521 otherwise it goes to step S518 Proceed. In step S522, if all other local simulations are finished, the execution of this local simulation is also terminated. Otherwise, the process proceeds to step S524. In step S524, if there is a need for rollback of the local simulation, the process proceeds to step S522 if it is not necessary, and if it is necessary to go back to step S526. In step S526, rollback is performed after the actual rollback-time determination, and the flow proceeds to step S518.

Referring to the overall flow of the local simulation of the SW server module for performing distributed processing parallel simulation illustrated in Figure 29, a total of 10 subblocks except for the start and end. In step S598, the current simulation time is set to 0, and the flow proceeds to step S602. In step S602, all local simulations are controlled in a predicted I / O-run manner, and the current simulation times of the respective local simulations are examined, and the flow proceeds to step S606. In step S606, it is examined whether rollback possibility has occurred in one or more local simulations that are currently performed in the predicted I / O use-run method, and if not, proceeds to step S604 and, if so, proceeds to step S608. In step S604, the current simulation times of all local simulations are terminated when the simulation end time, otherwise, the flow proceeds to step S602. In step S608, the actual rollback-time / actual roll-forward time is calculated by obtaining the rollback time points from all local simulations in which the rollback possibility has occurred, and performing the expected I / O-run method or the actual I / O-run method for each local simulation. Determine and rollback or rollforward each local simulation for each local simulation that is to be performed in an actual I / O method, and execute rollback for each local simulation that must be performed in an actual I / O method. Each control is performed so that roll forward is performed, and the flow proceeds to step S610. In step S610, by checking whether the switching condition from the actual input / output use-run method to the expected input / output use-run method is satisfied in one or more local simulations, proceeds to step S612 if it is satisfied and proceeds to step S614 if it is not satisfied. In step S612, the method of performing local simulation that can be switched to the expected I / O use-run method is switched to the expected I / O-run method, and the flow proceeds to step S614. In step S614, each of the local simulations can be performed using the estimated I / O-run method, and the local simulation performs the expected I / O-run method, while the remaining local simulations control the execution of the actual I / O method. Investigate the current simulation times of the simulations and proceed to step S616. In step S616, it is examined whether rollback possibility has occurred in one or more local simulations that are currently performed in the predicted I / O use-run method, and if so, proceeds to step S608 and, if not, proceeds to step S618. In step S618, the current simulation times of all local simulations are terminated when the simulation time reaches. Otherwise, the process proceeds to step S610.

In the overall flow chart of the local simulation performed by the SW server module for performing the distributed parallelism simulation illustrated in FIG. 29, the progress of the I / O method or the actual I / O method can be independently performed for each local simulation. The SW server module controls distributed processing parallel execution. However, as already explained above, in another configuration, the distributed processing of parallel processing of the SW server module for performing distributed processing parallel simulation is expected only if all local simulations are performed in the expected I / O-run manner. It is also possible to allow the use-run process to proceed, and in other situations, to control all local simulations to proceed in a real I / O use-run manner. In this case, there is a weak point in maximizing the performance of the simulation. There is an advantage in simplicity of control.

30 and 31 are examples of dictating their behavior in pseudo code form for each of the components constituting the additional code added to be distributed for distributed parallelism simulation presented in the present patent of FIG. Figure is a schematic diagram. If components of such additional code are added in a form that can be synthesized as much as possible, there may be an additional advantage that can be implemented on a hardware-based verification platform.

Therefore, it should be emphasized again that "simulation" in this patent includes not only pure simulation using only one or two or more simulators, but also simulation acceleration using one or more simulators and one or more hardware-based verification platforms. Therefore, each local simulation constituting the distributed processing parallel simulation environment in the present patent may not only be performed in the local simulator, but also may be performed in the accelerated manner in the local hardware-based verification platform, or locally. It is again emphasized that this can be done using a simulator and a local hardware-based verification platform.

In addition, the distributed process parallel simulation method proposed in this patent can be applied not only to the specification process from the transaction level to the gate level, but also in the specification process at other levels of abstraction.

32 is a diagram schematically showing another example of the configuration of components constituting the inside of an additional code added for distributed processing parallel simulation proposed in the present patent. 32 is very similar to FIG. 8, but FIG. 32 differs from FIG. 8 in that the s-DCP generation / storage module 60 has a higher level of abstraction than the level of abstraction of the local design object executed in the local simulation. A design object 53 containing both DUVs and TBs dictated at a high level of abstraction and a localized design object 53 containing both DUVs and TBs dictated at this high level of abstraction should be run in the local simulation. The execution of the design object 53 including both the DUV and the TB described at the upper level of abstraction is performed only by the simulation, or by the acceleration of the simulation using the hardware-based verification platform, or both. Mixed simulation) Local simulation of the local design object can be performed with minimum communication overhead and synchronization overhead. It is used to dynamically generate the hayeoseo expected input and expected output required. That is, the difference between the method illustrated in FIG. 32 and the method of using the s-DCP generation / storage module 60 of the method illustrated in FIG. 8 is golden, which is a method of automatically comparing the results of simulations in the conventional simulation method. Using the golden model (using the simulation results obtained dynamically from the golden model by allowing the DUV to be simulated with the golden model during the current simulation) and using the golden vector (already in the simulation). This method is similar to the method of using the simulation result obtained through To reiterate once again, the expected input, expected output, or expected input and expected output needed to enable the simulation to be performed while minimizing the communication overhead and the synchronization overhead in each local simulation of the distributed parallelism simulation in the present patent. It is obtained from the dynamic information collected and stored in the simulation, or dynamically obtained from the model having the high abstraction level while executing a model having a higher abstraction level than the local design object as the local design object in the local simulation. In addition, as already mentioned several times, instead of the design object 53 including both the DUV and TB dictated at the higher level of abstraction of FIG. 32, the DUV and the optimized level of abstraction are optimized to perform the simulation quickly. It is also possible to use a design object that contains all of the TBs.

And, through the distributed parallelism simulation proposed in this patent, a model of a specific abstraction level (for example, RTL model, RTL / GL mixed level model, TLM / RTL mixed level model, or TLM / RTL / GL mixed level model, etc.) If you want to perform only the simulation quickly, the process of increasing the abstraction level of the model or one or more design objects in the model through an automated method, or the optimization process for speeding up the simulation or a combination of the two processes (for example, Carbon Design Systems) One or more design objects in the model or model using the VSP of the company, or using the VTOC of the TenisonEDA company, or the methods in Korean Patent Nos. 10-2005-95803, 10-2005-116706, 10-2006-19738). A new model that transforms the model, use it as an s-DCP, or use this new model Hayeoseo utilizing the dynamic information obtained hayeoseo the simulation first to s-DCP may proceed to the parallel distributed processing ever simulation.

As described above, the effect of the present invention is that it is possible to quickly verify the abstraction low-level model by utilizing the results of the simulation using the abstraction high-level model when performing the super-scale design based on ESL. It is possible to significantly shorten the time for design verification and greatly increase the efficiency of verification.

In addition, another effect of the present invention provides a systematic verification method that can effectively proceed the verification process applied to the process of the design progress from the system level to the gate level through the gradual specification, such as the design process do.

Another effect of the present invention is to provide a systematic verification method that solves the problem that the verification speed decreases as the verification progressed in the design progressed through the gradual specification is progressed to the lower level of abstraction through the gradual specification process.

Another effect of the present invention is to allow the entire process of design and verification from a high level of abstraction to a low level of abstraction in a gradual materialization manner to be carried out in a systematic and automated manner.

Another effect of the present invention is to provide a systematic verification method that effectively maintains model consistency between two or more models present at different levels of abstraction.

Another effect of the present invention is to provide a method of effectively verifying a low level abstraction model through a gradual materialization process by using a model at a high level of abstraction as a reference model based on systematically maintained model consistency.

Another effect of the present invention is to provide a method of speeding up distributed parallel simulation by effectively reducing synchronization overhead and communication overhead in distributed parallel simulation.

Yet another effect of the present invention is to provide a method of correcting design errors through rapid debugging by systematically performing a debugging process for removing design errors found in a design process through a gradual specification process.

Those skilled in the art will appreciate that various changes and modifications can be made without departing from the technical spirit of the present invention. Therefore, the technical scope of the present invention should not be limited to the contents described in the embodiments, but should be defined by the claims.

Claims (70)

A design verification apparatus having verification software and one or more simulators, The verification software adds one or more models that can be simulated for design verification, or one or more models that can be simulated, and an additional additional code to the simulation environment, and performs advanced simulation using a specific model among the one or more models. The dynamics required to perform a post-end simulation targeting one or more design objects existing in the specific model or all other specific models among the one or more models in parallel or only in a simulation specific time period. It is possible to automatically collect information in the front end simulation process, and perform the front end simulation while collecting the dynamic information quickly, using the collected dynamic information 1 Design verification device to rapidly perform the rear-stage simulation that target one or more design objects present in the particular model naejineun another particular model from among the total naejineun model in the model. A design verification apparatus having verification software, one or more simulators, and one or more hardware-based verification platforms, The verification software adds one or more models that can be simulated for design verification, or one or more models that can be simulated, and an additional additional code to the simulation environment, and performs advanced simulation using a specific model among the one or more models. The dynamics required to perform a post-end simulation targeting one or more design objects existing in the specific model or all other specific models among the one or more models in parallel or only in a simulation specific time period. It is possible to automatically collect information in the front end simulation process, and perform the front end simulation while collecting the dynamic information quickly, using the collected dynamic information 1 A design verification apparatus for rapidly performing the post-simulation of one or more design objects existing in the specific model or all other specific models among the models. In simulations involving one or more models for design verification, The simulation is performed by dividing the front stage simulation stage and the rear stage simulation stage, and the rear stage simulation is performed in parallel over the entire time period of the simulation while the front stage simulation is performed on a specific model among the one or more models. Automatically collecting dynamic information necessary to be performed only in a section in the preceding simulation process, and using the collected dynamic information, one or more designs present in the same specific model or all other specific models or models within the one or more models. And performing the post-simulation on the object in parallel in the entire simulation time period or in a simulation specific time period. In simulations involving one or more models for design verification, The simulation is performed by dividing the front stage simulation stage and the rear stage simulation stage, and the rear stage simulation is performed in parallel over the entire time period of the simulation while the front stage simulation is performed on a specific model among the one or more models. Automatically collecting the dynamic information necessary to perform only in the interval during the preceding simulation process, and converting the dynamic information collected in the preceding simulation into dynamic information with improved accuracy through an s-DCP accuracy enhancement process or t-DCP. Converting the dynamic information with improved accuracy through an accuracy-enhancing process, and using the dynamic information with improved accuracy, all of the same specific model or one or more specific models in the one or more models, Simulation-based method to perform the subsequent stage of the simulation objects in the target throughout the simulation time interval in parallel or simulation comprising the step of rapidly performed in a specific time interval naejineun. The method according to claim 3 or 4, A simulation method having a different level of abstraction between the model used in the preceding simulation and the model used in the latter simulation. The method according to claim 3 or 4, The abstraction level of the model used in the preceding simulation is higher than the abstraction level of the model used in the latter simulation, and the abstraction level of the model used in the latter simulation is the same as the abstraction level of the model subject to the original design verification. Simulation method in which the model used is the original design verification target. The method according to claim 3 or 4, Simulation method of the same level of abstraction of the model used in the preceding simulation and the model used in the later simulation. The method according to claim 3 or 4, The simulation method, wherein the dynamic information collected in the preceding simulation is s-DCP or t-DCP. The method according to claim 3 or 4, And the dynamic information includes state information present in one or more design objects present in the entire model or the module at one or more simulation specific points of time, one or more simulation specific sections. The method according to claim 3 or 4, And the input / output information, input information, or output information of one or more design objects in which the dynamic information exists in the model. The method according to claim 3 or 4, And the input / output information, the input information, or the output information of the entire simulation period or one or more specific time intervals of one or more design objects in which the dynamic information exists in the model. The method according to claim 3 or 4, And all input / output information, input information, or output information of a simulation entire time period or one or more specific time periods of all design objects having a partial layer correspondence relationship in which the dynamic information exists in the abstraction higher level model. The method according to claim 3 or 4, And the post-simulation performed in parallel is distributed processing parallel execution. The method according to claim 3 or 4, The simulation method in which the post-simulation performed in parallel is time divisional parallel execution. The method according to claim 3 or 4 or 13, The back-end simulation that is performed in parallel is a verification method of distributed parallelism, and the back-end simulation that proceeds to distributed parallelism using s-DCP collected from the previous simulation or s-DCP with enhanced accuracy. Simulation method that maximizes the simulation time interval in the expected I / O using-run method. The method according to claim 3 or 4 or 13, The back-end simulation that is performed in parallel is a verification method of distributed parallelism, and the back-end simulation that proceeds to distributed parallelism using s-DCP collected from the previous simulation or s-DCP with enhanced accuracy. Simulation method to minimize the number of rollback executions in the. The method according to claim 3 or 4 or 13, The back-end simulation that is performed in parallel is a verification method of distributed parallelism, and the back-end simulation that proceeds to distributed parallelism using s-DCP collected from the previous simulation or s-DCP with enhanced accuracy. Simulation method to minimize the expected output / actual output discrepancy in. In gate-level timing simulation targeting a specific gate-level model for design verification, For the gate level timing simulation, a front end simulation step and a rear end simulation step are performed, and the rear end simulation is performed in a parallel parallel gate level timing simulation while the front end simulation is performed with different abstract level identical models having a higher abstraction level than the specific gate level model. Automatically collecting the dynamic information necessary to perform the process in the preceding simulation step and converting the dynamic information collected in the previous simulation into dynamic information with improved accuracy through the s-DCP accuracy enhancement process. Accurately execute two or more gate-level timing simulations independently by using the dynamic information collected in the previous simulation as input information for two or more design objects in the model. Obtaining an improved dynamic information and communicating over the rear end simulation of the entire gate-level model using the predicted input and the predicted output of each local simulation of the distributed parallel simulation obtained from the improved dynamic information. And performing a distributed parallel gate-level timing simulation with minimal head or synchronization overhead. In distributed parallel simulation targeting a model with a certain level of abstraction for design verification, in distributed parallel simulation using one or more local simulations of the distributed parallel simulation using the expected input and the expected output of the simulation, Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. Determining whether the output matches the expected output, determining the transition from the expected I / O run to the actual I / O run method, determining whether a rollback is necessary, and performing a rollback if necessary. And performing a step of determining the switching from the actual I / O-run method to the expected I / O-run method. In a distributed parallel simulation targeting a model of a specific abstraction level for design verification, at least one local simulation in the distributed parallel simulation may be performed on a model of the specific abstraction level or a different abstract level identical model before performing a distributed parallel simulation. In a distributed parallel simulation using the predicted input and the predicted output of the at least one local simulation, which are obtained from the dynamic information obtained in the at least one previous simulation performed, Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. Determining whether the output matches the expected output, determining the transition from performing the expected I / O to the actual I / O using method, determining whether a rollback is necessary, and performing a rollback if necessary. And performing a step of determining the switching from the actual I / O-run method to the expected I / O-run method. In the simulation of a model with a certain level of abstraction for design verification, The simulation is performed in a distributed parallel simulation, and in the process of performing the simulation in a distributed parallel simulation, one or more local simulations are performed on a model of the specific abstraction level or a different abstract level identical model before performing the simulation. Simulation method for increasing the performance of the distributed parallel simulation by using the dynamic information obtained in the previous simulation execution process. The method of claim 21 or 49, And a method for speeding up the execution of distributed parallel simulation by minimizing the synchronization overhead or the communication overhead of distributed parallel simulation by using the dynamic information obtained in the previous simulation. The method according to claim 21 or 22 to 49, The dynamic information obtained in the previous simulation is the input / output information, input information, or output information present in one or more design objects in the model. The synchronization of distributed parallel simulation is performed by using the input / output information, input information, or output information. Simulation method for increasing the speed of distributed parallel simulation by minimizing overhead or communication overhead. The method of claim 21, wherein 22, 23, or 49, The dynamic information obtained during the previous simulation is input / output information or input information or output information present in one or more design objects present in the model, and the input / output information or input information or output information is estimated in the one or more local simulations. A simulation method for speeding up the execution of distributed parallel simulation by minimizing the synchronization overhead or the communication overhead of distributed parallel simulation by using the input and the expected output or the expected input or the expected output. The method of claim 21, wherein 22, 23, or 49, Synchronous overhead of distributed parallel simulation by using predicted input and predicted output, or using predicted input, or using predicted output in one or more local simulations of the distributed parallel simulation obtained from the dynamic information obtained in the previous simulation execution process. Simulation method for increasing the speed of distributed parallel simulation by minimizing the communication overhead. Claims 21 to 22 to 23 to 24 to 25 to 25 53. The method of claim 48, wherein 49 is And wherein the previous simulation is a simulation using a model having a higher abstraction level than a specific abstraction level of a model that is a target of a simulation targeting a model having a specific abstraction level for the design verification. The higher level of abstraction by utilizing the s-DCP or t-DCP of the model or one or more design objects in the model, which is obtained from a model existing at a higher level of abstraction or one or more design objects in the model. Simultaneously perform one or more simulations of a model that exists at a lower level of abstraction or one or more design objects in this model in parallel, sequentially, or a mixture of parallel and sequential, Validation method that includes the process of speeding up simulations at the abstraction low level in the abstraction step-by-step verification process that proceeds gradually from the abstraction level to the abstraction level. The higher level of abstraction by utilizing the s-DCP or t-DCP of the model or one or more design objects in the model, which is obtained from a model existing at a higher level of abstraction or one or more design objects in the model. Leverage simulation results obtained from simulations that run at lower levels of abstraction or one or more simulations of one or more design objects in this model in parallel, sequentially, or a mixture of parallel and sequential Therefore, in the process of verifying the abstraction step by step from the upper level of abstraction to the lower level of abstraction, the upper model and the upper model existing at the upper level of abstraction are transformed through the specification process, and thus the lower level of abstraction. Present to verification methods, including the process of investigating the consistency naejineun equality and sub-models that stand. The method according to claim 27 or 28, A simulation method in which at least one parallel simulation of a model or at least one design object within the model comprises distributed parallelism or time divisional parallelism. Abstraction using high level model Abstraction using high level simulation result All or part of the lower level simulation is performed by distributed parallelism or time divisional parallelism. Obtain a simulation result of the level and compare the simulation result of the abstraction higher level and the simulation result of the abstraction lower level to determine that there is model consistency between the abstraction high-level model and the abstraction lower-level model, or Identifying the cause of model inconsistencies that exist between level models and removing the cause of this model inconsistency ensures model consistency between the high-level abstraction model and the low-level abstraction model under the input conditions used in the simulation. How to verify if. In gate-level timing simulation targeting a specific gate-level model for design verification, For the gate level timing simulation, a front end simulation step and a rear end simulation step are performed, and the rear end simulation is performed in a parallel parallel gate level timing simulation while the front end simulation is performed with different abstract level identical models having a higher abstraction level than the specific gate level model. Automatically gathering dynamic information necessary to perform the above-described simulation process, and obtaining predicted input and predicted output of each local simulation of distributed parallel simulation from the collected dynamic information, and calculating the predicted input and predicted output. Performing the post-end simulation of the entire specific gate-level model as a distributed parallel gate-level timing simulation to minimize communication overhead or synchronization overhead by using it for local simulation. Including verification method. In RTL simulation targeting a specific RTL model for design verification, For the RTL simulation, a front end simulation step and a rear end simulation step are performed, and the front end simulation is required to perform the rear end simulation as a distributed parallel RTL simulation while performing the front end simulation as the same abstract level having a higher level of abstraction than the specific RTL model. Automatically collecting dynamic information in the preceding simulation process and converting the dynamic information collected in the preceding simulation into dynamic information with improved accuracy through s-DCP accuracy enhancement process. Obtaining dynamic information with improved accuracy by independently performing each of two or more RTL simulations performed by using the dynamic information collected in the preceding simulation as input information for the above-described design objects, and from the collected dynamic information. Obtaining the predicted input and the predicted output of each local simulation of the co-parallel simulation; and using the predicted input and the predicted output for local simulation, the rear end simulation of the entire RTL model is performed for communication overhead or synchronous overhead. The verification method comprising the step of performing a distributed parallel RTL simulation to minimize. In RTL simulation targeting a specific RTL model for design verification, The front end simulation step and the rear end simulation step are performed for the RTL simulation, and the dynamics necessary to perform the rear end simulation as the distributed parallel RTL simulation are performed while performing the front end simulation with the same abstract level having higher abstraction level than the specific RTL model. Automatically collecting information in the preceding simulation process, obtaining predicted input and predicted output of each local simulation of distributed parallel simulation from the collected dynamic information, and using the predicted input and predicted output for local simulation. And performing the post-simulation of the entire RTL model as a distributed parallel RTL simulation with a minimum of communication overhead or synchronization overhead. In a specific transaction level simulation targeting a specific transaction model for design verification, The front end simulation step and the rear end simulation step are performed for the specific transaction level simulation, and the rear end simulation is performed in a distributed parallel transaction level while the front end simulation is performed with the same abstract model having different abstraction level higher than that of the specific transaction model. Automatically collecting the dynamic information required to perform the simulation in the preceding simulation process, and converting the dynamic information collected in the preceding simulation into dynamic information with improved accuracy through the s-DCP accuracy enhancement process The accuracy is improved by independently conducting each of two or more transaction level simulations using the dynamic information collected in the previous simulation as input information for two or more design objects in the projection model. Obtaining information, and using the predicted input and the predicted output of each local simulation of the distributed parallel simulation, which are obtained from the dynamic information with improved accuracy, to perform the communication overhead or synchronization of the rear end simulation of the entire transaction model. Validation method comprising the step of performing parallel parallel transaction level simulation with minimal overhead. In a specific transaction level simulation targeting a specific transaction model for design verification, The front end simulation step and the rear end simulation step are performed for the specific transaction level simulation, and the rear end simulation is performed in a distributed parallel transaction level while the front end simulation is performed with the same abstract model having different abstraction level higher than that of the specific transaction model. Automatically collecting the dynamic information necessary to perform the simulation in the preceding simulation process, and obtaining the predicted input and the predicted output of each local simulation of the distributed parallel simulation from the collected dynamic information, and the predicted input and the predicted output. Using the local simulation to perform the post-end simulation of the entire transaction model as a distributed parallel transaction level simulation which minimizes communication overhead or synchronization overhead. Way. The method according to claim 3 or 4, And the post-stage simulation is a distributed processing parallel execution / single performance hybrid method. The method according to claim 3 or 4 or 13, The post-simulation method is a simulation method in which distributed parallel processing / single performance is mixed. The distributed processing parallel processing in the distributed simulation is performed using the s-DCP collected in the preceding simulation. S-DCP is used to improve the accuracy of the distributed processing, while t-DCP is collected during the distributed parallel processing, and the collected t-DCP is used to improve the accuracy. A single method in a post-simulation of the distributed parallel processing / single performance hybrid method using t-DCP. In the simulation targeting a model of a certain level of abstraction for design verification, a distributed parallel simulation is performed on a specific simulation section in the entire time interval of the simulation, and at least one local simulation in the distributed parallel simulation is an expected input of performing the simulation. In simulations using Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. Determining whether an output matches the expected output, and determining a switch from performing a parallel parallel simulation to a single simulation. In the simulation targeting a model with a certain level of abstraction for design verification, a distributed parallel simulation is performed on a specific simulation section or an entire simulation time interval in the entire simulation time interval, and at least one local simulation in the distributed parallel simulation is performed. In the simulation using the expected input and the expected output of the simulation, Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. And determining whether an output matches the expected output. The method according to claim 19, 20, 38, 39, 42, 42, 43, 43, 47, 48, 54, or 55, A simulation method for obtaining the predicted input or predicted output from dynamic information collected in at least one separate simulation process made in advance of a simulation to be performed at present. The method according to claim 19, 20, 38, 39, 42, 42, 43, 43, 47, 48, 54, or 55, Simulation method for obtaining the predicted input or predicted output from input information and output information of one or more design objects in the model to be collected in one or more separate simulation processes performed in advance of the current simulation Expected input and predicted output of simulation execution in one or more local simulations in distributed parallel simulations for a specific simulation interval over the entire time interval of the simulation in a simulation targeting a model with a certain level of abstraction for design verification. In the simulation using Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. Determining whether an output matches the expected output, and determining a switch from performing a parallel parallel simulation to a single simulation. Prediction of simulation performance in one or more local simulations in distributed parallel simulations for a specific simulation interval or the entire simulation time interval in the simulation for the model of a specific abstraction level for design verification. In simulations using inputs and expected outputs, Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. And determining whether an output matches the expected output. 53. The method of claim 20, 21, 48, 49, or 52, Wherein said at least one previous simulation run is parallel simulation or comprises parallel simulation. The method according to claim 3 or 4, And the dynamic information includes input information of one or more design objects existing in the model. The method according to claim 3 or 4, And the dynamic information includes output information of one or more design objects existing in the model. In a distributed parallel simulation targeting a model of a certain level of abstraction for design verification, in a distributed parallel simulation using one or more local simulations of the distributed parallel simulation using the expected input and the expected output of the simulation, Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. Determining whether the output matches the expected output, determining the switching from the expected I / O using to the actual I / O using, and using the expected I / O in performing the actual I / O using. A distributed parallel simulation method comprising determining a switch to a run method. In a distributed parallel simulation targeting a model of a specific abstraction level for design verification, at least one local simulation in the distributed parallel simulation may be performed on a model of the specific abstraction level or a different abstract level identical model before performing a distributed parallel simulation. In a distributed parallel simulation using the predicted input and the predicted output of the at least one local simulation, which are obtained from the dynamic information obtained in the at least one previous simulation performed, Determining whether the distributed parallel simulation can be performed independently of the expected input by skipping the synchronization with the other local simulations and synchronizing with the other local simulations; and the actual obtained by performing the one or more local simulations. Determining whether the output matches the expected output, determining the transition from the expected I / O using to the actual I / O using the run, and using the expected I / O in performing the actual I / O using A distributed parallel simulation method comprising determining a switch to a run method. In the simulation of a model with a certain level of abstraction for design verification, The simulation performs the distributed parallel simulation with one or more specific simulation time intervals, including a distributed parallel simulation process, wherein, in the distributed parallel simulation, one or more local simulations are performed using a model or a different abstraction level before the simulation. Simulation method to speed up the distributed parallel simulation by using dynamic information obtained from one or more previous simulations performed on the same level model. A simulation method including time alignment in the process of increasing accuracy of dynamic information used in a distributed processing parallel execution simulation or a time division parallel execution simulation. 50. The method of claim 20, 21, 48, or 49, A simulation method or a verification method in which one or more design objects existing in a model of a specific abstraction level that are subject to design verification are modified between the previous simulation process and the current simulation process. In the simulation of a model with a certain level of abstraction for design verification, The entire simulation time interval or one or more specific simulation time intervals of the simulation are performed in a distributed parallel simulation method, wherein one or more local simulations in the distributed parallel simulation process are performed at a model of a specific abstraction level or a different abstract level before performing the simulation. Expected or predicted output using, or using, predicted input or predicted output of one or more local simulations in the distributed parallel simulation process obtained from dynamic information obtained from one or more previous simulations performed on the same model. And minimizing synchronization overhead or communication overhead in the distributed parallel simulation. 35. The method of claim 4, 18, 32, or 34, Simulation method including the s-DCP accuracy enhancement process through the transaction to the accuracy enhancement process. Expected input of the simulation performance in one or more local simulations in distributed parallel simulations for the simulation of the model at a specific abstraction level for design verification. In the simulation using And determining whether performing the distributed parallel simulation can independently perform the at least one local simulation by skipping communication and synchronization with other local simulations and independently performing the expected input. In a simulation targeting a model with a certain level of abstraction for design verification, the simulation is composed of two or more simulation processes or two or more simulation threads, and in the simulation using the predicted input of the simulation performance when the simulation process or the simulation thread is executed. , And determining whether performing a specific simulation process or performing a simulation thread can proceed independently of the predicted input by omitting interprocess communication and interprocess synchronization with another simulation process or a simulation thread. Claims 19 to 20 to 38 to 39 to 42 to 42 to The method of claim 43 to 47 to 48 to 54 to 55 In Simulation method using the dynamic information collected in one or more separate simulation process made in advance of the current simulation to be performed in order to obtain the expected input or expected output. The method according to claim 19, 20, 38, 39, 42, 42, 43, 43, 47, 48, 54, or 55, In order to obtain the predicted input or predicted output, the input information, the output information, or the input / output information of one or more design objects in the model to be the simulation target collected in one or more separate simulation processes performed in advance of the current simulation to be performed in time Simulation method The method according to claim 19, 20, 38, 39, 42, 42, 43, 43, 47, 48, 54, or 55, From the input information and output information of one or more design objects in the model to be collected in one or more separate simulation processes performed in advance of the simulation to be performed in time, or from different abstract levels of the model to be simulated. Simulation method for obtaining the expected input and expected output, expected input or expected output from input information and output information of one or more design objects The method according to claim 19, 20, 38, 39, 42, 42, 43, 43, 47, 48, 54, or 54, Input information, output information, or input / output information of one or more design objects in the model to be the simulation target collected in one or more separate simulation processes performed in time before the simulation to be performed to obtain the expected input or expected output. Different abstract level of a model to be simulated Simulation method using input information, output information or input / output information of one or more design objects in the same model. The method according to claim 19, 20, 21, 38, 39, 42, 42, 43, 47, 47, 48, 49, 52, 52, or 54. One or more particular local simulations of the one or more local simulations are performed on a hardware-based verification platform. In simulation for design verification, And the simulation comprises simulation of a distributed processing parallel execution method. The method of claim 19 to 20 to 38 to 39 to 42 to 43 to 43 to 47 to 48 to 54 to 55. And said determining is performed during the progress of local simulation. In the simulation method targeting a model of a specific abstraction level for design verification, The simulation method is a simulation method of a distributed parallel processing method, or a simulation method of a time division parallel processing method, or a simulation method comprising a distributed processing parallel processing or a time division parallel processing. In the simulation method targeting a model of a specific abstraction level for design verification, The simulation method is a distributed parallel processing using the incremental simulation, or a simulation method including a distributed parallel processing using the incremental simulation. A method for distributed parallelism simulation comprising s-DCP accuracy enhancement process using dynamic learning or s-DCP accuracy enhancement process through transactionalization. In one or more local simulations of distributed parallel simulations or distributed parallel simulations using dynamic information collected in a simulation performed earlier in time, a design object with a higher level of abstraction than the local design object targeted for the local simulation is desired. A distributed parallel processing simulation using DCP includes an s-DCP accuracy enhancement process using dynamic learning or an s-DCP accuracy enhancement process through transactionalization. The s-DCP, which is used in one or more local simulations in distributed parallel simulation, has a higher abstraction level than the local design object performed in the local simulation. Simulation method as a simulated model Expected input, predicted output, or predicted input and predicted output used in one or more local simulations in distributed parallel simulation have higher abstraction level than the local design object simulated with the local design object in the local simulation. Simulation method to obtain from simulation model that is optimized to perform simulation at the same level of abstraction as design object The method according to claim 19, 20, 38, 39, 42, 42, 43, 43, 47, 48, or 54, The local design in the process of simulating a simulation model having a higher abstraction level than the local design object to be performed by the local simulation, or a simulation model optimized to be performed quickly at the same abstraction level as the local design object as the local design object. A simulation method for obtaining the predicted input or predicted output from dynamic information collected from a simulation model having a higher abstraction level than an object or a simulation model that is optimized to perform a simulation at a same abstraction level as a local design object. 70. The method of claim 67 or 68 to 69 wherein Simulation method with a higher abstraction level than the local design object or a simulation object optimized for fast simulation at the same abstraction level as the local design object.

Images