KR20080009246A - Efficient debugging method in dynamic-based design verification - Google Patents

Abstract

A method for performing pure simulation effectively in dynamic-based design verification, a simulation acceleration method, or pure simulation/simulation acceleration hybrid method, and a debugging method thereof are provided to shorten whole design verification time largely by enabling a designer or a verifier to use various debugging-simulation methods capable of reducing debugging turn-around time. More than one design error is found by simulation. Causes of the design error are removed by correcting a design, and the simulation for determining whether design correction is correctly performed is performed. The simulation is performed by using more than two modes among a first assumption-based debugging and simulation mode, a second assumption-based debugging and simulation mode, and a third assumption-based debugging and simulation mode according to property of the design error.

Description

Effective Debugging Method in Dynamic-based Design Verification

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

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

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

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

FIG. 5 schematically illustrates an example of a scheme 1-home based post-debugging simulation or a scheme 2-home based post-debug simulation.

FIG. 6 is a diagram schematically illustrating another example of a scheme 1-home based post-debugging simulation or a scheme 2-home based post-debug simulation.

FIG. 7 is a schematic illustration of an example of a scheme-home based post-debugging simulation process. FIG.

FIG. 8 schematically illustrates another example of a scheme 1-home based post-debugging simulation or a scheme 2-home based post-debug simulation.

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

32: Verification Software

34: Verilog simulator or VHDL simulator or SystemC simulator

35: computer

37: accelerator or hardware emulator

The present invention refers to a dynamic system based on a digital system or a digital logic circuit (in this patent, a dynamic based method refers to a simulation or simulation acceleration using a test bench. Also, in this patent, a hybrid hybrid method of simulation acceleration and in-circuit emulation is also used. The simulation method is to reduce the turn-around time of debugging when verifying with a simulation speed. Specifically, debugging is the process of finding and eliminating one or more design errors in DUV (Design Under Verification) or TB (Test Bench). Debugging in dynamic-based verification should be done prior to debugging. Simulation Execution (In this patent, simulation execution is defined to include simulation acceleration using a simulation accelerator or a hardware emulator as well as simulation using a simulator. Current simulators used in the industry are Cadence's Incisive simulator or NC-sim or X-). sim, Synopsys' VCS, Mentor's ModelSim, Aldec's Riviera / Active-HDL, Fintronic's FimSim, Axiom's MP-sim and OSCI SystemC simulators. Cadence's Extreme series, Palladium series, Mentor VStation series of company, EVE company ZeBu series, Tharas Hammer series, Alatek HES series, ProDesign ChipIT series, Dynalith iPROVE series, Hardi HAPS series, S2C IP Porter series, Liga System Nitro-Sim, Fortelink Gemini series, etc.) It is necessary to determine whether there is a design error in the design to be verified (this simulation execution is defined as pre-debugging simulation in this patent). And when it is confirmed that a design error exists in the design in the pre-debugging simulation, the root cause of the design error is identified, and the design is found and corrected (this patent is defined as front-debugging). Leading-debugging is followed by one or more post-debugging simulations to determine whether one or more of the above design errors have been correctly removed from leading-debugging and that no new errors have been introduced by design modifications made in leading-debugging (i.e. After the front end debugging, to determine whether the front end debugging proceeds to the goal, the execution of the simulation is defined as post-debug simulation) to determine whether the front end debugging proceeds correctly. The present patent defines a particular leading-debugging and associated trailing-debugging (in this patent, a single "debugging process" is defined as including such a leading leading-debugging and associated trailing-debugging). Define one debugging turnaround and define the total time spent on one such debugging turnaround as debugging turn-around time, and the sum of all debugging turnaround times throughout the design verification is the total debugging turnaround time. It is defined as (debugging turn-aound total time).

However, during the entire design verification process, there is a very large number of debugging processes, which are very much time-delayed after each debugging process. This will take In particular, bugs that are hard to find and fix usually require a long time of pre-debugging, so post-debug-simulation in post-debugging requires a long time (specific example, 7 days of pre-debugging-simulation proceeds). Fixing certain bugs that are found only in the front end-debugging and post-debugging-simulation in the back-debugging will also require approximately seven days of simulation).

In addition, the dynamic-based verification for a particular DUV does not use only one TB, but uses a very large number of TBs (eg, relatively short 1000 TBs instead of one long TB). . Using multiple TBs instead of one TB allows you to run as many TB simulations as individual TBs on a large number of simulators (called simulation farms). Reduce the overall time of the simulation using all TBs. However, due to the recent design complexity, the simulation execution time using these individual TBs also becomes very long when using a simulator. In order to shorten the simulation time, a simulation accelerator or a hardware emulator is used. In order to shorten the overall time of the simulation using all TBs when there are a large number of test benches as described above, the simulation accelerator or the hardware emulator is used. In case of 1000 TB, 20 simulation accelerators or hardware emulators are allocated, and 50 TBs are assigned to each simulation accelerator or hardware emulator, and 20 simulation accelerators or hardware emulators are executed simultaneously. Shorten the overall time of the simulation).

However, in general, simulation accelerators or hardware emulators are very expensive compared to simulators, so the number of simulator licenses or hardware emulators is relatively small (all companies have 1000 simulator licenses). At least 1-2 cars, at most 3-4 cars). In such a situation, the only way to effectively perform dynamic-based verification using a large number of TBs is to share a very small number of simulation accelerators or hardware emulators, such as the method proposed in US Pat. No. 5,937,179 (eg 1000 TB Assuming that there is one simulation accelerator, the simulation accelerators are used sequentially at a given time for 1000 simulations by 1000 TB, and at the same time, several simulators are used simultaneously).

However, a simple sharing through such a simple time division of very few simulation accelerators or hardware emulators is not efficient because it does not take into account the dynamic-based verification process consisting of leading-simulation, debugging, and trailing-simulation. In addition, it is not possible to support TB that generally cannot save the state information of design object (ie, it is impossible to save state information of TB design object and restart using it. There is a problem that can only be used in a very limited situation (i.e., TB is an input vector form so that it can be used in acceleration and simulation) due to the fact that it cannot be switched to simulation using the simulator. When using a number of simulation accelerators or hardware emulators, the number of simulations performed per unit time is higher than that of using a number of simulation accelerators or hardware emulators. Or hardware emulators cannot be increased closely).

Accordingly, an object of the present invention is to enable a designer or a verification engineer to use various post-debug simulation methods that can reduce debugging turnaround time, thereby greatly reducing overall design verification time. Specifically, two or more post-debug simulation methods that can be traded off in terms of accuracy and execution time can be selectively executed to reduce debugging turnaround time.

It is still another object of the present invention to execute a simulation using a simulator for a design verification object including a design object (eg, a test bench) that cannot save state information of a design object and later restore it. Or by using state information on one or more design objects obtained at a specific simulation point of a simulation run using a simulation accelerator or a hardware emulator in conjunction with a simulator, or at a specific simulation point or a specific simulation section of a simulation run advanced at an abstraction level. By using the status information of one or more design objects, it is possible to reduce the debugging turnaround time, or the debugging turnaround time, and the time required for the pre-debugging simulation to identify the existence of a bug. to be.

Another object of the present invention is to use the total time of a simulation using all TBs when performing verification using a large number of TBs by using a very small number of simulation accelerators or hardware emulators as efficiently as a number of simulators. To shorten (i.e. increase the number of simulations performed in unit time when verification is performed using a large number of TBs).

In order to achieve the above objects, the design verification apparatus required for applying the design verification method according to the present invention includes verification software and one or more simulators (Verilog simulator, VHDL simulator, SystemVerilog simulator, SystemC simulator, Verilog / VHDL / SystemVerilog /). SystemC simulator) may be configured with one or more computers 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 a hardware emulator, which includes one or more FPGA boards with simulation acceleration. 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 It should be emphasized once again that simulation execution (or simulation for short) in the present patent refers to both a simulation run and a simulation accelerator or a hardware emulator.

A typical method for post-debugging simulations performed in post-debugging when design modifications have been made in front-debugging is a conventional simulation of the modified DUV and TB as a whole. However, as already mentioned above, this conventional simulation method has the problem of requiring a very long post-debug simulation time. In order to solve this problem, the simulation method proposed in Patent 10-2004-93310 (this patent defines such a simulation method as incremental simulation) effectively reduces the simulation time of the post-debug simulation. It is possible. However, such incremental simulations have limitations in shortening the debugging turnaround time since the simulation of some design objects existing in the DUV and the TB must be performed from the simulation time zero. DUV and TB generally have a hierarchical structure and have various one or more submodules. Each of these submodules is a design block, and there are design modules inside the design block, and submodules inside the design module. exist. Such design blocks, or design modules, or submodules or DUVs, and TBs, respectively, to some or some of their combinations or some of their combinations, are all referred to herein as design objects (specific examples, In case of Verilog, module, VHDL entity, and SystemC sc_module are all examples of design objects). Thus, a DUV can be regarded as one of the design objects, and a part of the DUV, one or more design blocks in the DUV, a part of the design blocks, design modules within the block, sub-modules, or sub-modules within the design module are included. 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).

In general, the pre-debug simulation proceeds correctly as expected from simulation time 0 to simulation time T_o (hence the presence of bugs) and progresses from T_o to T_e so that the simulation does not proceed as expected. You will find out. If the design has been partially modified in front-debugging to eliminate this particular bug, then the inputs and outputs of the design object containing such design modifications will be generated from simulation time 0 before and after the design modification. It may be equal to the simulation time T_e, may be the same from simulation time 0 to simulation time T_o, but may be different from after simulation time T_o, or may be different from before simulation time T_o. In addition, the state information of the design object including the portion of the design modification (the design object state information is a flip-flop output value, latch output value, memory that exists in the design object at a specific simulation time point or a specific simulation section during the simulation process) The content value, and the value that includes all of the signal values on the combined closed loop, if there is a combined closed loop), may or may not be the same from simulation time 0 to T_o before and after the design modification. It may be. The difficulty is that it is difficult to know these T_o times correctly before running the post-simulation simulation.

However, even after a design is modified in a particular debugging, the inputs of a design object containing such a design modification are not only the same from simulation time 0 to simulation time T_e before and after the design modification, but also the simulation time. If the state information of the design object including the modified part of the design from 0 to the simulation time T_o is the same before and after the design modification (case 1-1), or the design including the modified part of the design The inputs of an object (this design object may be a DUV) are the same from simulation time 0 to simulation time T_e before and after the design modification, or if the design object containing the modified portion of the design is a DUV. This is a situation where non-reactive TB is used. The pre-debug simulation simulation is executed by the simulator before the modification, and after the design modification, the design object including the modified part is executed from simulation time 0 to simulation time T_o by using the accelerator or hardware emulator. When the state information of the design object including the modified part of the design obtained can be used for simulation execution using a simulator for the design object including the modified part of the design (in such a case, the debugging as necessary The state information obtained in the pre-simulation execution is referred to as "stabilized state information" ("stable state information" in this patent), even if the simulation time proceeds, there is no change in the state information value unless additional input events are input from the outside. Status information The specific method for obtaining such stabilized state information is described in the separate patent 10-2006-92574, "How to obtain state information with increased accuracy in t-DCP accuracy enhancement process". (Case 1-2), or pre-debugging simulations performed before design modification at a specific abstraction level (eg gate level), and design objects containing modifications to the design after design modification. By using a simulator to perform simulation time 0 to simulation time T_o at an abstraction level (e.g., register transfer level) higher than the specific level of abstraction (for a detailed description of the abstraction level, see separate patent 10-2006-92574). The design object including the modified part of the state information of the design object including the modified part of the design obtained in T_o If it can be used to run the simulation at the original specific abstraction level (eg gate level) using the simulator for the case (cases 1-3), then each post-debug simulation of the design object contains the modified part of the design. Restore the information to the same state information as before the modification at simulation time T_o (1-1), or run the simulation from simulation time 0 to simulation time T_o using simulation accelerator or hardware emulator. The state information collected at the simulation time point T_o is used as the state information of the design object including the modified part of the design to execute the simulation from T_o using the simulator (eg, timing simulation at the gate level) (case 1-2). ), Or post-debugging-simulation abstraction In the execution of the simulation at the level, the state information collected at the simulation time point T_o or the stabilized state information of the state information from the T_o using the simulator as the state information of the original low abstraction level design object including the modified part of the design. Originally used to run simulations at low abstraction levels (even in this case, it is necessary to make the state information obtained from the simulation execution at the higher level of abstraction as "stabilized state information" as necessary. For a specific method of obtaining the state information, refer to "How to obtain the state information with increased accuracy in the t-DCP accuracy augmentation process" described in a separate patent 10-2006-92574) and the design from T_o to T_e is modified. Run simulations very quickly on design objects containing embedded sections (cases 1-3 This greatly reduces the debugging turnaround time (this post-simulation simulation is referred to in this patent as "post-simulation based simulation"). In addition, when a simulation accelerator or a hardware emulator is used to obtain state information in the T_o, or when the simulation is performed at a higher abstraction level than in the pre-debugging simulation, the general simulation of the DUV is performed from T_o to T_e. As the input values of the DUV required for the simulation or the simulation from T_o to T_e and after T_e, the simulation accelerator or the hardware emulator continuously executes the simulation or the simulation at the high abstraction level is continuously performed. A typical simulation of the DUV is performed from T_o to T_e to T_ using the inputs of the DUV obtained by executing (the inputs of these DUVs are applied as inputs of the TB to the DUV). It is also possible to continue from o to T_e and beyond T_e. This way, the post-debug simulation to determine whether one or more specific bugs have been correctly removed through front-end debugging continues naturally after t_e, while another pre-debug simulation to find one or more additional bugs. This method is very effective by allowing the process to be linked to (ie, the simulation after t_e becomes a new pre-simulation to find one or more new bugs). -Simulation and Pre-Development-Simulation based debugging method. In the above cases, in case 1-2, the simulation accelerator or the input stimulus in the post-debug simulation using the hardware emulator is collected in the simulation process before the debugging and stored in a file form (in this case, the simulation accelerator). The hardware emulator operates in vector mode or stored in the built-in memory format (in this case, the simulation accelerator or hardware emulator operates in a synthesized testbench mode, ie both TB and DUV are synthesized to simulate accelerator or hardware). It can be operated at the highest execution speed by operating on the hardware verification platform of the emulator.) By using the input vector, the simulation speed can be greatly increased.

However, the assumption for applying this method is that even after the design has been modified as previously mentioned, the inputs of the design object containing such a modified portion of the design object have been changed from simulation time 0 before and after the design modification. The state information of the design object which is not only identical to the simulation time T_e but also includes the modified part of the design at the simulation time T_o is the same before or after the design modification, or proceeds using a simulation accelerator or a hardware emulator. The state information collected at the simulation time T_o of a simulation is correct, or the state information collected at the simulation time T_o of the simulation performed at a high level of abstraction must be correct. The first method to check whether the assumptions are correct is to ensure that the designer or verification engineer who has a good understanding of the design, or secondly, to post-debug-simulate after the execution of the assumptions based on the assumptions. This is verified by execution (in this patent, such a separate post-debug simulation is referred to as "post-debug simulation for home verification"). This post-debug simulation for assumptions can also be run at the same level of abstraction using the same simulator as for post-debug simulations based on assumptions, but a separate method (described later) can be used for faster execution. It is also possible. Post-Debugging-Simulation for Assumption Verification is performed in parallel with hypothesis-based debugging and Post-Debug-simulation for Assumption verification even when running at the same level of abstraction using the same simulator as Assumption-based Debug-Simulation. Not only is it possible to run it, but it is also possible to use a simulation farm to perform total simulation throughput, even when executing post-debug simulation simulations based on assumptions and post-debug simulation simulations for assumptions. It is advantageous to increase.

However, as already mentioned above, for fast execution of post-debugging simulation for assumption verification, this post-debug simulation for assumption verification is performed by using a simulation accelerator or a hardware emulator, or post-debugging based on assumption. Compared to the simulation, it can be performed at a higher level of abstraction, or the time-divisional parallel simulation or distributed processing parallel simulation method mentioned in the separate patent 10-2006-92574 can be applied. See -92574. Such post-debugging simulations for assumption verification may be performed using a simulation accelerator or a hardware emulator, or performed at a higher level of abstraction than post-debugging simulations based on assumptions, or the time mentioned in separate patent 10-2006-92574. In order to perform fast execution by applying the partitioned parallel simulation or distributed parallel parallel simulation method, the simulation time is used to calculate the input values or input values and output values for one or more design objects in the DUV and TB during the pre-debugging simulation. At the same time, if necessary, the state information of one or more design objects in the DUV and TB can be saved at one or more specific simulation times or simulation intervals, and then all or part of them can be used in the post-simulation process. Should See patent 10-2005-116706 for related details).

According to the above-described method, the present patent describes a post-debug-simulation method consisting of "post-simulation based on home" or "post-simulation based on home" and "post-debug simulation for home verification". Home-based post-simulation.

In addition, "Post Debug Simulation with Incremental Simulation" or "Post Debug Simulation with Incremental Simulation" and simulation runs for the entire DUV and TB (This simulation run can be used only with the simulator, The post-debug simulation method, which consists of "post-debug simulation for home confirmation" (or may use a hardware emulator), will be referred to as "method two-home based post-debug simulation". In order to speed up the simulation in post-debugging simulation through incremental simulation, even if the pre-debug simulation is performed by using the simulator, the incremental simulation method is performed partially or entirely by using the simulation accelerator or the hardware emulator. It is also possible to proceed. The input stimulus in post-debugging simulation, which is performed by the incremental simulation method using partial or full simulation accelerator or hardware emulator, is collected during pre-simulation and stored in file form (in this case, The simulation accelerator or hardware emulator operates in vector mode or stored in the built-in memory format (in this case, the simulation accelerator or hardware emulator operates in the synthesized testbench mode, ie both the TB and DUV are synthesized. It is possible to operate at the highest execution speed by operating in the hardware verification platform of the hardware emulator.) By using the input vector, the simulation speed can be greatly increased. However, in this case, the pre-debugging simulation is performed with event accuracy using the event-driven simulator, and if the post-debugging simulation is performed with cycle accuracy using the cycle-based simulation accelerator or hardware emulator, it is incremental. It is necessary to equalize the accuracy of the two comparison targets in order to compare the pre-modification output values (these have event accuracy) and the post-modification output values (these have cycle accuracy) of the design objects that have undergone design modifications in the simulation. (See patent 10-2004-93310 for details of incremental simulation method). That is, abstract the corrected I / O values with event accuracy to have only cycle accuracy (e.g., the unmodified output values of the design modifications made by the design modification obtained in the simulation execution of the pre-debugging simulation using the simulator are adapted to the active edge of the driving clock. To change). In other words, the modified input / output values with cycle accuracy are specified to have event accuracy (for example, the post-modification output values of the design objects in which the design modification is obtained in the simulation execution of the post-debugging simulation using the accelerator or the hardware emulator are driven clocks. After the active edge of the program, it can be considered to change after a predetermined demonstration time (for example, after 1 ns). This process may be applied during the post-debugging-simulation process, or before the post-debugging-simulation process. Can be done. In addition, in this case-home-post-simulation-simulation case, the same nested post-simulation and pre-debug-simulation-based debugging method can be applied as in the case of scheme 1-home-based post-debugging-simulation.

This incremental simulation method is based on two-home-based post-debugging-simulation, which uses a small number of simulation accelerators or hardware emulators as efficiently as many simulators. Performing verification using a large number of TBs can shorten the overall time of the simulation using all TBs (or, in other words, a simulation that can be performed in unit time if the verification is performed using a large number of TBs). It is possible to increase the number of latencies as follows (in this patent, such a simulation, which will be described in detail below, may be performed using a simulation accelerator or a hardware emulator to determine the transition time Ts (i) and accelerate the simulation. Using the results of After simulation system debugging 2-home-based through the use of a simulator - will be referred to as a simulation "). For each TB, the input and output information of the DUV collected in the pre-debugging simulation (in this patent, the input and output information is not only the values at the DUV's input and output ports, but also the cross module reference (XMR). Considering read / write between the DUV design object and the TB design object in the same way as the above) For example, when the TB design object reads the DUV design object from the DUV to the TB by cross-module referencing the internal signal of the DUV design object, If the TB design object cross-references the internal signal of the DUV design object and writes it from TB to DUV as a signal from TB, the TB signal is also stored in the DUV input information. Later, in the context of making design changes in front-end debugging and running post-debug simulations to incremental simulation Using the shorthand or hardware emulator, the input information of the DUV collected in the pre-simulation is used as the input stimulus, and the output information of the DUV is used as the expected output. By combining both DUV and TB on the hardware verification platform), until the actual output is different from the expected output (this time associated with a specific testbench TB_i is denoted by the transition point Ts (i)). This is a high-speed process, which proceeds very quickly using one or more simulation accelerators or hardware emulators compared to the number of simulators that can be utilized for each of the entire TBs. It is done. During this post-debug simulation process, which proceeds to each individual TB of the entire TBs using a simulation accelerator or a hardware emulator, checkpoints (checkpoints are used to store the state information of the DUV at one or more specific simulation points or simulation intervals. The stored state information is reset to the DUV so that the simulation can be re-executed.) At the transition point Ts (i), the simulator is executed for the entire DUV and TB (i) from the transition point Ts (i). Checks closest to Ts (i) in the past than the transition point Ts (i) by generating one or more checkpoints periodically or non-periodically during the post-debug-simulation process. From the point, it simulates the entire DUV and TB (i) It should be able to proceed with simulation emitters. However, a simulation using a simulator that proceeds from the transition point Ts (i) to the DUV and TB (i) from the checkpoint closest to Ts (i) in the past than the transition point Ts (i) is performed by TB ( i) can only be performed from the transition point Ts (i), or from the checkpoint closest to Ts (i) in the past than the transition point Ts (i). However, unlike general DUV design objects that are made synthesizable, it is generally impossible to create checkpoints using the state information of TB design objects. In order to be possible, TB must be synthesizable like DUV, but there are many problems because it imposes a very large constraint on TB dictation. Thus, the only way for TB (i) to be carried out from the transition point Ts (i), or from the checkpoint closest to Ts (i), which is in the past than the transition point Ts (i), performs TB (i). It is to save the state of the simulation by the simulator and restart it (that is, to use the save / restart method of the simulation to save and restore the simulation state information rather than the state of the design object). And SystemC simulators provide implemented simulation commands that enable save / restart using these simulation states. Using this method, the simulation using the simulator for DUV and TB (i) in the post-debugging simulation using the incremental simulation method starts from the transition point Ts (i), or the transition point Ts (i). Although it is possible to start from the checkpoint closest to Ts (i) in the past, simulations using simulators such as DUV and TB (i) cannot be performed by a single simulation executable code. It must be performed by a simulation consisting of at least two independent processes and inter-process communication (IPC) between them. The disadvantages of this are that the simulation can be slowed down due to IPC overhead when performing the simulation. Each independent process must be run in a separate simulator Licenses from two simulators (one running DUV and another running TB (i)) or three or more simulators (in this case running DUV with two or more simulators), The advantage is that simulations using these simulators, as already mentioned, need to be run from simulation time 0 to the transition point Ts (i), or until the checkpoint closest to Ts (i), which is in the past than the transition point Ts (i). Without (from simulation time 0 to the transition point Ts (i), or to the checkpoint closest to Ts (i) in the past than the transition point Ts (i), after the debugging with the hardware accelerator or the hardware emulator-at the beginning of the simulation Was executed) Ts (i) and T from the transition point Ts (i) or earlier than the transition point Ts (i). (The simulation using the simulator is executed from simulation time 0 to the transition point Ts (i), or to the checkpoint closest to Ts (i) in the past than the transition point Ts (i). It is not necessary to proceed from the transition point Ts (i), or from the checkpoint closest to Ts (i) in the past than the transition point Ts (i), greatly reducing the debugging turnaround total time).

However, if the design requires foreign models, such as C models, or foreign codes, such as C / C ++ code, to be executed together using PLI / VPI / FLI, often state information of the simulation Storage and restarting can be very difficult or even impossible. As described above, when it is impossible to store the state of the simulation that performs the entire design object except the design object executed in the simulation accelerator or the hardware emulator, the following method is used. In other words, in the simulation acceleration performed by using input information (used as input stimulus) and output information (used as expected output) for the DUV modified by using the accelerator or hardware emulator and the DUV collected in the pre-debugging simulation TB design objects that have no state storage until the transition point Ts (i) found, or the checkpoint closest to Ts (i) in the past than the transition point Ts (i). Only external code is included), and the DUV design object is simulated using simulation accelerator or hardware emulator before the state storage is performed like the TB design object. In the "Enter the situation" (described below). DUVs that have been dormant from the transition point Ts (i) or from the checkpoint closest to Ts (i) from the transition point Ts (i) to this point "wake up from dormancy" (details below) Enabled to be simulated with TB design objects. When a DUV design object enters a dormant state, an event (event is a change in logic value) for all signals existing in and out of the DUV's I / O port. For example, 0 to 1 change, 0 to X change, From 0 to Z, from 1 to 0, from 1 to X, from 1 to Z, from X to 0, from X to 1, from X to Z , From Z to 0, from Z to 1, from Z to X, etc.) at all. An example of a specific way for such a DUV design object to enter a dormant state for a period of time T1 <t <T2 is to use a simulator force command to specify a specific value for each of the signals present in the DUV design object for each point in time. Is assigned to the desired time interval (for example, from simulation time 0 to the transition time Ts (i) or to the checkpoint closest to Ts (i) in the past than the transition time Ts (i)) T1 <t <T2 In the event that all the signals present in the DUV design object do not occur during the desired time period T1 <t <T2. For design objects in the model, the overall simulation speed is increased because no operation is required to run the simulation.), DUV An example of a specific method to awaken the system object in the sleep state is using at the time T2 the desired release command of the simulator. In this case, it is important to ensure that TB design objects that do not enter the dormant state operate correctly, from the point of time when the DUV enters the dormant state to the transition point Ts (i) or past the transition point Ts (i). Until the checkpoint closest to Ts (i), the TB design object uses the output information of the stored DUV as input input to the TB design object during the pre-debug simulation, so that the TB design object can be stored even when the DUV design object enters the dormant state. Ensures that the DUV design object operates correctly in the same manner as it normally does (that is, even if the DUV design object goes to sleep, the TB design object will be deceived as if the DUV design object was operating normally). .

From the simulation point 0 to the transition point Ts (i) or to the checkpoint closest to the transition point Ts (i) and closest to Ts (i), the DUV enters the dormant state. Since the simulation is performed using the output information of the stored DUV, the simulation can be performed relatively quickly. (For example, if the simulation overhead of TB is 10% and the simulation overhead of DUV is 90%, such a DUV is dormant. A simulation method that runs only TBs by entering into can speed up the simulation by nearly 10 times).

If it is impossible to save the state of the simulation that executes the entire design object except the design object executed in the simulation accelerator or the hardware emulator, another method may be used as follows. In other words, in the simulation acceleration performed by using input information (used as input stimulus) and output information (used as expected output) for the DUV modified by using the accelerator or hardware emulator and the DUV collected in the pre-debugging simulation Until the transition point Ts (i) found out or the checkpoint closest to Ts (i) in the past than the transition point Ts (i), the state of the design object is not stored (the part where the state of the design object is stored) The design object executed by the simulation accelerator or the hardware emulator stores the state information of the design object, and the state storage of the simulation (the part where the state storage of the simulation is performed is performed by the simulator with the simulation state storage function in the simulation acceleration). As a design object, this design object excludes stateless-impossible design objects. A stateless-impossible design object (eg, a stateless-capable design object) that is not a TB (for example, a stateless-capable design object) is a simulation accelerator, a hardware emulator, or a simulator with a simulation state storage function. As a design object excluding design objects, only C-model design objects that do not support save / restart function or C / C ++-code design objects that perform file-in / out, etc.) are executed. From Ts (i) or the checkpoint closest to Ts (i) in the past than the transition point Ts (i), the entire DUV and TB can be simulated together. In order to simulate the entire DUV and TB from the checkpoint Ts (i) or the checkpoint closest to Ts (i) in the past than the transition point Ts (i), the following method can be used. The method means that the state of the simulator that simulates the TB excluding the state storage-impossible design object through the state restoration of the simulation is in the past than the transition point Ts (i) or the transition point Ts (i) and is the first with Ts (i). Force / release command, PLI / VPI / FLI, etc. against the design object DO (h2s) in a separate simulator that restores from the nearest checkpoint and simulates the design object DO (h2s) performed by the simulation accelerator or hardware emulator. Simulate state information of DO (h2s) that was performed in the accelerator or hardware emulator using State initialization after restart, which is equal to the state information read by the accelerator or hardware emulator, is in the past than the transition point Ts (i) or the transition point Ts (i) and is the first to Ts (i). After performing at a close checkpoint, the simulators are interworked with IPC (the design objects executed in the simulator and the design accelerators performed in the simulator or the hardware emulator must be interlocked with the IPC while the simulation is accelerated). It refers to the method of performing the actual execution of the simulation (ie, state information of the design object performed by the simulation accelerator or the emulator in the entire design object through the post-restart-state initialization process is converted from the transition time Ts (i) to the transition time Ts (i Checkpoint closest to Ts (i) in the past In this simulation it will be time to move forward shortly after being set up properly, the actual simulation run).

This is because only stateful-impossible design objects are executed from simulation time 0 to transition time Ts (i) or to the checkpoint closest to Ts (i) in the past than transition time Ts (i). It is possible to proceed very quickly (for example, if the simulation overhead of TB is 10%, the DUV's simulation overhead is 90%, and the stateful-non-design object's overhead is 10% of TB overhead, it is not stateless. Running only design objects can increase execution speed by nearly 100 times).

Method 2-Home-based post-simulation-simulation allows debugging using the input and output information of the TB collected in the pre-simulation simulation when modifications are made to the TBs that cannot save the state information of TB design objects. In post-simulation, only TB can be simulated by the simulator from simulation time 0 to Ts (i) and state information can be stored. One example is already described above, and both Ts (i) and TB and DUV perform simulations (thus TB is applied to the input information of TB collected in pre-simulation from simulation time 0 to Ts (i)). The input is received by Ts (i) and the output is received by the output of the DUV. It can also be used as a simple statement (if statement or case statement). In order to simulate both the TB and the DUV from the Ts (i), an example of a specific method of setting the state information of the DUV in the Ts (i) to wake the DUV from the dormant state (the waking state from the dormant state) is also described above. To do this, checkpoint CP (Ts_i) closest to Ts (i), which is in the past than Ts (i) collected in pre-debugging simulation, is set to the initial state of DUV and Ts (i) to Ts. (i) A separate simulation using the input information of the DUV up to (i.e. such a separate simulation may use a simulator or a simulation accelerator or an emulator) to execute the process to obtain the DUV status information in Ts (i) The DUV state information in this Ts (i) may be restored.

In incremental simulation, a design object that has changed design is a design object that can save and restore state information, or a design object that cannot save and restore state information, and incremental simulation in one simulation ( Therefore, only one compilation is needed or two simulations (so two compilations are required. Two compilations may be two simulations using a simulator, one simulation using a simulator, an accelerator, or an emulator, and one simulation). Depending on whether you want to accelerate the simulation, or if you want to simulate simulation by linking two or more simulators using two or more processes and IPC, you can actually target the entire TB and DUV (actually the entire TB and DUV). TB and DUV full sim Will be run from Ts (i) or from the checkpoint closest to Ts (i) in the past than the transition point Ts (i). Is determined.

As described above in the incremental simulation, if the simulation accelerator or the hardware emulator is used instead of the simulator to determine the transition point Ts (i), it is the design object that the design change is made during the debugging process. Since it is possible without causing degradation, there is an important advantage of maximizing the simulation time interval that can be performed very quickly by the incremental simulation.

As described above, the method of "Two-home based post-simulation through simulation" using a simulator using a simulation accelerator or a hardware emulator to determine the transition point Ts (i) first and using the results of the simulation acceleration " This applies to not only one DUV and many TBs, but also two or more DUVs and multiple TBs for each DUV (i.e. more than one design to be validated). Maximize the utilization of hardware emulators (e.g. only one simulation accelerator) to maximize the number of simulations (one simulation with one DUV and one TB) that are run per unit time using multiple simulators. It is also possible. In other words, even if only a small number of simulation accelerators or hardware emulators can be used (e.g. only one simulation accelerator), pre-debug simulations performed using the testbench TB (i) of each of a large number of TBs. The DUV input information and output information collected from the DUV are operated at high speed in simulation acceleration input vector mode or embedded test bench mode, respectively. The simulation acceleration, which yields the transition point Ts (i), is also true for all transition point Ts (i) (e.g. TB) for a very large number of testbench TB (i) (i.e. i = 0 to 999 for 1000 TB). Note that it is possible to quickly find i) from 1000 to 999). In addition, since the transition time Ts (i) corresponding to the specific test bench TB (i) is obtained through the acceleration of the simulation, the simulation execution can be started using the simulator for the completion of the incremental simulation at any time. It is worth noting. Because of the above reasons, the method of using a simulation accelerator or a hardware emulator is based on two-home-based post-debugging-simulation even when a large number of simulator licenses and a very small number of simulation accelerators or hardware emulators are used. Similar to using, the number of simulations performed per unit time can be increased.

Finally, "Method 3-home based post-debugging-simulation" means the following post-debugging-simulation method. That is, the designer or verification engineer manually modifies the state information or input values and state information, or some or all of the input values and output values and state information for one or more design objects collected in the pre-debugging simulation. (You can delete one or more signals in the design object constituting the status information, add one or more signals, or add one or more signals while deleting one or more signals.) Post-Dimulation-Simulation, and if necessary, run "Post-Dimulation-Simulation for Assessing" simulations for the entire DUT and TB (either using only the simulator, or using the accelerator or hardware emulator). Going on with "method 3-home based debugging Post-simulation "(in this manner, if the state information obtained from the pre-debug simulation run is also used in the three-home-based post-debug simulation, the state information obtained from this pre-debug simulation run is" stable "as needed. It is necessary to make the "status information", the specific method of obtaining such stabilized status information is a method of obtaining the status information with enhanced accuracy in the "t-DCP accuracy enhancement process described in a separate patent 10-2006-92574 "). "Method 1-home based post-debugging-simulation", or "Method 2-home based post-debugging-simulation", or "Method 3-home based post-debugging-simulation" are "home-based post-debugging-simulation" And "Post-Dimulation-Simulation for Assumptions." In this case, "Post-Dimulation-Simulation-Based Simulations" is usually performed first, followed by "Post-Dimulation-Simulation for Assumptions." In general, in some cases, "post-simulation for home verification" may be performed first to confirm that the assumption is correct before proceeding to "post-simulation based on home". The verification engineer will do it.

Using these three methods, "Method 1-home based post-debugging-simulation", "Method 2-home based post-debugging-simulation", and "Method 3-home based post-debugging-simulation" Depending on the debugging situation, it is possible to effectively reduce the debugging turnaround time, thereby effectively reducing the overall debugging turnaround time during the entire verification process in which various various debugging situations are mixed. In other words, designers or verification engineers can choose one of the three methods that best suits the specific debugging situation without using one method to reduce the debugging turnaround time. It is possible to shorten the turnaround total time.

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 still another example of the design verification apparatus according to the present invention.

3 is a diagram schematically showing still another example of the design verification apparatus according to the present invention.

4 is a diagram schematically showing still another example of the design verification apparatus according to the present invention.

FIG. 5 is a diagram schematically showing an example of a scheme 1-home based post-debug-simulation process or a scheme 2-home based post-debug-simulation process.

FIG. 6 is a diagram schematically illustrating another example of a scheme 1-home based post-debugging simulation or a scheme 2-home based post-debug simulation. Specifically, the simulation execution using a simulation accelerator or a hardware emulator is a gate level simulation based on an incorrect latency model (eg, zero latency model), and the simulation execution using a simulator is an accurate latency model. Can be a gate-level simulation (eg, timing simulation using SDF reflecting placement & wiring results).

FIG. 7 is a diagram schematically showing an example of a scheme-home based post-debugging simulation process.

FIG. 8 is a diagram schematically illustrating another example of a scheme 1-home based post-debugging simulation or a scheme 2-home based post-debug simulation. Specifically, the simulation execution at the higher abstraction level is the simulation using the SystemC simulator at the transaction level with cycle accuracy and the register accuracy. It may be a simulation using an event-driven Verilog simulator or a VHDL simulator at a register transfer level.

As described above, the effect of the present invention is to provide an effective debugging method or simulation method for shortening the debugging turnaround time in dynamic-based design verification. Specifically, the effect of the present invention is to significantly reduce the debugging turnaround time by allowing a designer or a verification engineer to selectively use various post-debug simulation methods that can reduce the debugging turnaround time. Another effect of the present invention is to execute a simulation using a simulator, or a simulation accelerator or a hardware emulator, for a design verification target including a design object such as a test bench that cannot store state information of the design object and return it later. Using state information about one or more design objects acquired at a specific simulation point of a simulation run using a simulator or at least one design object obtained at a specific simulation time point or a specific simulation section of a simulation run performed at a higher level of abstraction. Use of state information to reduce debugging turnaround time to eliminate specific bugs, or to reduce debugging turnaround time to eliminate specific bugs, and to pre-debug to identify the presence of new bugs. It allows with the shortening of the time required for calibration.

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 (8)

In the design verification process, the existence of one or more design errors is determined by simulation execution (pre-simulation), and the design correction is performed to determine the cause of the one or more design errors and eliminate them (front-debugging). In the step of conducting a simulation (post-debugging-simulation) to determine whether this has proceeded correctly, A simulation is performed to determine whether the design modification has been performed correctly according to the characteristics of the one or more design errors in a method 1-home based post-debugging-simulation method or method 2-home based post-debugging-simulation method or method 3-home based debugging Debugging method using 1 or 2 or more methods selected from post-simulation methods In the design verification process, the existence of one or more design errors is determined by simulation execution (pre-simulation), and the design correction is performed to determine the cause of the one or more design errors and eliminate them (front-debugging). In the step of conducting a simulation (post-debugging-simulation) to determine whether this has proceeded correctly, In order to determine whether the design modification is correctly performed, the simulation is performed in a method 1-home based post-debugging-simulation method or method 2-home based post-debugging-simulation method or method 3-home-based post-debugging-simulation method. Debugging methods, including the above methods During the design verification process to eliminate design errors, the simulation run detects the presence or absence of one or more design errors (pre-debugging), and proceeds with the design modification to identify and eliminate the cause of the one or more design errors ( Fore-debugging Iteratively repeats the steps of conducting a simulation (post-debugging) to determine whether the design modification was successful, According to the characteristics of the one or more design errors, a designer or a verification engineer uses a scheme 1-home-based post-debugging-simulation method or scheme 2-to determine whether a design modification for correcting the one or more design errors has been correctly performed. Home-based post-simulation method or method 3-Debugging method that selectively uses 1 or 2 or more of the home-based post-simulation method. The method according to claim 1 or 2 to 3, The dynamic-based design verification method performed by the above method 1-home based post-simulation method or the method 2-home based post-simulation method includes nested post-simulation and pre-debug-simulation debugging methods. Dynamic based design verification method The method according to claim 1 or 2 to 3, Simulation in post-debug-simulation that examines whether one or more specific bugs are correctly removed in the dynamic-based design verification method performed by the method 1-home based post-debug-simulation method or the method 2-home-based post-debug-simulation method. Simulation run using an accelerator or a hardware emulator or abstraction In a simulation run at a higher level, the state information of the DUV collected at a specific simulation time point t_o1 or a specific simulation section t_o2 after the simulation time 0, and the DUV of the DUV in a certain simulation section from t_o1 to t_o2. By using the input values, the simulation accelerator or the hardware emulator can be used to execute the simulation, followed by the simulation using the simulator, or the simulation at the higher level of abstraction. Dynamic simulations, including nested post-simulation and pre-debug-simulation-based debugging methods, which examine whether a particular bug has been correctly removed by running the simulation at the lower level of the conversation, while at the same time examining the existence of one or more specific bugs. -Based design verification method The method according to claim 1 or 3, According to the characteristics of the at least one design error, at least two of the method 1-home-based post-debugging-simulation method or the method 2-home-based post-debugging-simulation method or the method 3-home-based post-debugging-simulation method are independent. Debugging methods, including the process of running concurrently The method according to claim 1 or 2 to 3, Debugging method of performing the post-debugging simulation based on the assumptions and the post-debugging-simulation for hypothesis confirmation in parallel in the method 1-home based post-debugging-simulation method or the method 2-home based post-debugging-simulation method. The method according to claim 1, 2, 3, 4, 5, 6, or 7, The method 2- assumption based post-debug simulation method is based on the method 2- assumption based on the simulation using a simulator using a simulation accelerator or a hardware emulator to determine the transition point Ts (i) first and using the simulation acceleration results. Debugging Methods with "Post-Dimulation"

Images