WO2005078584A1

WO2005078584A1 - Performance improvement apparatus for hardware-assisted verification using massive memory and compilation avoidance and its verification method using the same

Info

Publication number: WO2005078584A1
Application number: PCT/KR2004/003296
Authority: WO
Inventors: Seiyang Yang
Original assignee: Logic Mill Technology, Llc
Priority date: 2003-12-16
Filing date: 2004-12-14
Publication date: 2005-08-25

Abstract

The present invention relates to a verification apparatus and a technique for verifying a digital system containing at least million gates. In the present invention, the design verification system software, executed in an arbitrary computer, makes the exchange of dynamic information among design objects in the design to be verified, whereby the modified part of the design to be verified is rapidly moved to the simulator from the hardware platform for speeding up the verification process. Also, the massive memory embedded in the design verification interface module in the present invention reduces the overhead incurred from testbench, which further contributes to speeding up the verification process.

Description

Performance Improvement Apparatus for Hardware- assisted Verification Using Massive Memory and Compilation Avoidance and Its Verification Method Using the Same

[Field of the Invention and Description of the Related Art]

The present invention relates to a technique for verifying a digital circuit or a digital system, and more particularly, to a verification apparatus which is capable of verifying a digital circuit or a digital system using hardware-assisted verification system, and a method using the same. Even more particularly, the present invention relates to a verification apparatus which can increase the verification performance and reduce the verification time by using a massive memory and hardware compilation avoidance, and a method using the same.

description of the Related Art>

The present invention relates to a technique for verifying a digital system having

at least several million gates, and more specifically to a verification apparatus which

rapidly removes at least one design bug in a digital system having at least several million gates by implementing it on programmable chips, ASIC chip, or SOC (System On a Chip),

and using emulation and simulation together, and a method using the same.

With the rapid development of integrated circuit design technology and

semiconductor fabrication, the architecture of digital circuit designs has become very

complex and the design complexity has grown to several million to several tens of millions

of gates. The design having over hundred million gates is expected in the near future. As

the competition in the market is getting more intense and the competitive products should

be developed rapidly, the need of efficient verification methods is growing.

Although the simulation, a software-based approach, has been used to verify

digital systems, the simulation as a verification method is limited by its low performance.

This is because the simulator must execute the software code consisting of instruction

sequence, which models the circuit to be verified, sequentially on a computer. Moreover,

the input stimuli, which constitute input to the circuit to be verified, need to be developed

for simulation. The size of input stimuli is growing with the size of the design to be

verified, and its development is done largely manually. This results in the increase of

development time and cost. As the testbench (abbreviated as TB thereafter), which

provides input stimuli, is in general not synthesizable it must be executed on a computer,

even though the synthesizable design under verification (abbreviated as DUV thereafter)

is executed on either a hardware emulator or on a simulation accelerator. In this

simulation acceleration environment, the TB overhead and the speed limitation of the

interface between the TB and DUV severely limit the overall verification performance. By contrast, when DUV is implemented as a prototype chip in hardware-assisted

verification environment, all elements in DUV are executed in parallel, and the verification

speed can be 1 ,000,000 times greater than that of simulation. Also, in hardware emulation

environment the verification speed can be maximized with in-circuit emulation (ICE) by

using hardware environment instead of the TB, as stimulus. In this situation, as the input

stimulus is supplied from the real hardware environment, the TB development time can be

completely eliminated. Recently, hybrid-based hardware-assisted verification system,

which combines both in-circuit hardware emulation and simulation acceleration using TB,

is becoming common. In the previous invention, "Input/output probing apparatus and input/output

probing method using the same, and mixed emulation/simulation method based on it

(Korea Patent Application Number: 10-2000-0034628)", an efficient verification method

using both emulation and simulation has been proposed by utilizing reusable field

programmable devices (abbreviated as RFPD thereafter), such as FPGA (Field

Programmable Gate Array), CPLD (Complex Programmable Logic Device), or application

specific IC devices, such as ASIC (Application Specific Integrated Circuit) or ASSP

(Application Specific Standard Product).

However, in all previous inventions, including the above mentioned invention,

efficient performance enhancement technique has not been proposed either in simulation

acceleration or in hybrid simulation acceleration and in-circuit emulation. Moreover, in

hardware-assisted verification, whenever a design error is discovered and corrected, the compilation of the hardware platform is always necessary for the entire DUV or of part of it.

That compilation process is known to take very long time.

Moreover, another problem is the total development time resulting from the

increased difficulty of design verification using a chip after fabrication, where no

correlation between test and design verification has been established.

[SUMMARY OF THE INVENTION]

The purpose of present invention is to reduce the testbench (TB) overhead and

the communication overhead between the TB and the DUV in either simulation

acceleration or in in-circuit emulation, where very large digital system is realized in

hardware by using at least one RFPD, a Boolean processor, or an ASIC/SOC chip. It is

also a purpose of this invention to minimize the compilation overhead in design

modification to enhance the verification performance and establish correlation between

the manufacturing test and the design verification.

The foregoing and other objects, features, aspects and advantages of the present

invention will become more apparent from the following detailed description of the present

invention when taken in conjunction with the accompanying drawings.

[BRIEF DESCRIPTION OF THE DRAWINGS] The accompanying drawings, which are included to provide a further

understanding of the invention and which constitute a part of this specification, illustrate

embodiments of the invention and together with the description serve to explain the

principles of the invention.

In the drawings:

FIG. 1 is a schematic view of a design verification apparatus and a hardware

platform in accordance with the present invention;

FIG. 2 is a schematic view of one example of the internal structure of a design

verification interface module;

FIG. 3 (a) is a schematic view explaining the TB cache writing and reading

processes through the primary TB caching using massive memory;

FIG. 3 (b) is a schematic view explaining the TB cache writing and reading

processes through the primary TB caching using massive memory and data

compression/decompression hardware module;

FIG. 3 (c) is a schematic view explaining the TB cache writing and reading

processes through the secondary TB caching using hard disk attached to a computer;

FIG. 3 (d) is a schematic view explaining the TB cache writing and reading

processes through the secondary TB caching using hard disk attached to a computer and

DMA; FIG. 4 is a schematic view showing the transformation process of TB throughout

TB caching;

FIG. 5 is a schematic view showing the verification process in which the design

object that exists in the hardware platform is transferred to the simulator after a bug is

fixed;

FIG. 6 is a schematic view showing a process of recursive caching;

FIG. 7 is a schematic view of one example of one part of the instrumentation logic

added to the design object for exchanging the dynamic information;

FIG. 8 is a schematic view of one example of the remaining part of the

instrumentation logic added to the design object for exchanging the dynamic information;

FIG. 9 is a schematic view showing a verification process, in which the

instrumentation logic enables the exchange of dynamic information between the modified

design object that is transferred to the simulator, and the remaining design objects

implemented in the hardware platform; FIG. 10 is a schematic view of one example of a generic architecture of a

simulation acceleration system providing TB caching and compilation avoidance;

FIG. 11 is a schematic view of one example of a hardware platform and a

simulation acceleration controller in FIG.10;

FIG. 12 is a schematic view of one example of PBS (Proprietary Boundary Scan); FIG. 13 is a schematic view of one example of BSC (Boundary Scan Cell), which

is a basic element of PBS; FIG. 14 is a schematic view of one example of a specific implementation for

reading and writing by dynamically accessing the input/output ports of DUV through s-

PBS;

FIG. 15 is a schematic view of one example of a specific implementation for

reading and writing by dynamically accessing the input/output ports of a particular design

block through d-PBS;

FIG. 16 (a) is a schematic view of one example showing the execution of the

entire DUV, or the part of DUV, at least once with the TB cached data using a hierarchical

d-PBS structure on a hardware platform; FIG. 16 (b) is a schematic view of one example of a hierarchical d-PBS added to

a hierarchical DUV, such as in FIG. 16 (a);

FIG. 16 (c) is a schematic view of one example showing the hierarchical structure

of d-PBS in FIG. 16 (b) in detail;

Explanation of symbols in figures>

10 : Boolean processor 11 : ASIC/SOC

12 : RFPD 20 : computer

26 : design verification interface module 27 : interface module 28 : massive memory

29 : date compression/decompression module

30 : memory read/write module

31 : main controller in interface module controller chip 32 : design verification system software

33 : interface module controller chip 34 : arbitrary simulator

35 : Interface part in the interface module controller chip for connecting the interface module and the system bus in a computer which executes a testbench

36 : DMA controller 37 : testbench

44 : arbitrary hardware platform

45 : DUV

64 : cached TB 65 : Part of DUV, in which the design is modified, cached

66 : Part of DUV, in which the design needs to be modified

67 : The rest of DUV, excluding the part of DUV in which the design needs to be modified

68 : Part of DUV in which the design is modified and moved to simulator

69 : Part of computer main memory as a buffer 70 : hard disk attached to a computer

71 : control module for multiplexer selection input

72 : multiplexer implemented in software

73 : PBS

74 : multiplexer implemented in hardware 75 : PBS controller

76 : Testbench caching controller

77 : SA main controller

86 : Signals for output probing

87 : Flipflops consisting of a shift register in an output-probing instrumentation circuit 88 : Flipflops consisting of a shift register in an input-probing instrumentation circuit

90 : Part of DUV implemented on a RFPD, a Boolean processor, or an ASIC/SOC

92 : Remaining part of DUV implemented on a RFPD, a Boolean processor, or an ASIC/SOC, which needs to be executed continuously in the hardware platform

94 : Part of DUV implemented on a RFPD, a Boolean processor, or an ASIC/SOC, which needs to be transferred to the simulator, and simulated after the design is modified.

[DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT]

To achieve the above mentioned objectives, the design verification apparatus of

the present invention provides a design verification system software and a design

verification interface module (26). The design verification interface module (26) consists of

an interface module (27) and a massive memory (28). The design verification system

software is executed on an arbitrary computer, which has an arbitrary simulator (for

example, an HDL simulator, logic simulator, event-driven simulator, or a cycle-based

simulator). The design verification interface module connects a computer, which has the

design verification system software with at least one arbitrary emulation hardware board,

an arbitrary simulation acceleration hardware platform, or an arbitrary emulation hardware

platform (abbreviated as hardware platform thereafter), which contains at least one RFPD,

one Boolean processor, one ASIC/SOC chip manufactured through a fabrication process,

or at least two different kinds of these devices. For this purpose, the interface module has

at least one interface module controller chip, which is another FPGA, CPLD,

microprocessor, microcontroller, or a dedicated ASIC/ASSP. FIG. 1 is a schematic view of

a design verification apparatus, which consists of a design verification interface module and a design verification system software. In more detail, the design verification interface

module (26) can be mounted onto a PCI (Peripheral Computer Interface) to access a PCI

bus, connected to a secondary system bus (for example, S-bus in SUN workstations), or

even connected to a main system bus for high speed interface or to a USB (Universal

Serial Bus)/parallel port/serial port for low speed interface. This results in the connection

of an arbitrary hardware platform to an arbitrary computer mentioned above.

The design verification system software controls the computer and the hardware

platform in such a way that some dynamic information related to the execution result of a

multi-million gate DUV, implemented on the hardware platform, should be read from the

platform or written with a particular value transferred from the computer at a specific

verification time or condition. The dynamic information is divided into the state information

and the logic information. The state information represents a set of values of storage

elements (flip-flops or latches) and memories (RAMs or ROMs) in a digital circuit.

Complete state information represents the values of all storage elements and memories,

and partial state information represents the values of some storage elements and (or)

memories. We define the storage element as either a flip-flop or a latch, and the memory

as any kind of RAM or ROM memory such as SRAM, DRAM, SDRAM, Rambus DRAM,

PROM, EPROM, EEPROM, and Flash Memory. In contrast, logic information represents

the values at the outputs of some combinational logic gates or values of inputs in a digital

circuit. If the DUV is implemented and executed on a hardware platform, and at least one

read is needed from the DUV to the simulator or to the design verification system software

in a computer, or one write is needed from the simulator or from the design verification

system software in a computer to DUV, the exchange of dynamic information is required.

Such a situation can be found in simulation acceleration (abbreviated as SA thereafter). In

simulation acceleration, where the testbench is executed by the simulator on a computer

and the DUV is executed in the hardware platform, the exchange of dynamic information

between the simulator and the hardware platform is required on an event by event, cycle

by cycle, or transaction by transaction basis. In this case, the dynamic information

consists of the input stimuli generated in TB and supplied to DUV, and the response

generated from DUV and sent back to TB. The performance of SA largely depends on the

speed of the exchange of this dynamic information, and, in general, to connect the input

and output ports between DUV in the hardware platform and TB in the simulator the

instrumentation logic is needed to provide the exchange of dynamic information. (We shall

call the instrumentation logic to achieve this objective an s-PBS.) Alternatively, the test

infra-structure (such as IEEE 1149.1 or IEEE P1500 standards, proposed by IEEE),

originally developed for DFT (Design For Testability), could be used for providing the

same features s-PBS does in ASIC/SOC chips, without adding an instrumentation logic,.

The main factors limiting the performance of SA are the low speed in the

exchange of dynamic information between the TB and DUV and the low execution speed

of TB on a computer. In this invention, a new method is proposed to resolve these problems. That is, mounting a massive memory at the design verification interface module

or at the hardware platform, the dynamic information in form of stimuli generated from TB

in the computer is simultaneously stored in a massive memory during the first SA

execution run. In addition, if necessary, these input stimuli from TB are stored with at least

one file on a hard disk attached to the computer or in a main memory of the computer.

These input stimuli stored in a massive memory mounted on the design verification

interface module during the first SA execution will be read from the massive memory and

directly applied to DUV under the control of the interface module during the second and all

the subsequent SA executions. Throughout this process, the second and the subsequent

SA execution runs can completely eliminate the speed limitation of physical interface

between the TB and DUV, and the TB overhead run by a computer. Through the

application of this process, the verification performance can be increased by several

hundred to tens of thousand times. We will refer to this new method as testbench caching

(abbreviated as TB caching thereafter). We will call it a primary TB caching, if a massive

memory is used in the design verification interface module, and a secondary TB caching,

if the main memory or a hard disk of the computer is used.

Also, in hardware-assisted verification a very long time is spent when the modified

DUV is re-implemented on the hardware platform once the design bug is corrected. This

comes from the fact that re-compilation process for re-implementing a modified DUV on a

hardware platform requires a complete hardware re-compilation onto RFPD or Boolean

processors in the hardware platform, which takes a couple of times to a couple of hundred times longer than a software compilation for the simulator. In particular, if RFPD is used in

the platform, much longer compilation time is required. Moreover, if ASIC/SOC chip is

used in the platform, the re-compilation actually means re-manufacturing, or re-spin, of a

new chip, which takes the longest time (typically a few weeks to a few months) and is very

expensive. (For simplicity of explanation, we will also refer to re-spin for ASIC/SOC

debugging as re-compilation). This long re-compilation time significantly degrades the

verification performance and efficiency. Particularly, in the early phases of the design

process, characterized by a large number of design bugs in DUV, the long compilation

time of hardware-assisted verification systems is a major hurdle for deploying such

systems.

In the present invention, to solve the problem of long compilation time after fixing

a design error, the part of DUV, in which the design errors are found and fixed, is

transferred from the hardware platform to the simulator, compiled, and executed in the

simulator, thereby providing uninterrupted design verification without a hardware re-

compilation. We refer to this feature as compilation avoidance. To accomplish this, the

DUV must be partitioned into two parts: (1) a part, say DUV(B), in which some design

errors are fixed (this part should be executed by the simulator on the computer); and (2)

the remaining part, say DUV(PO), that should be operated with DUV(B) in the hardware

platform in an event by event, cycle by cycle, or transaction by transaction mode (this is

called lock-step mode). Unfortunately, the division onto DUV(B) and DUV(PO) parts is not

known in advance. Therefore, it is necessary to partition DUV into a set of design objects in advance (the number of such objects can be decided by a designer or verification

engineer, or can be determined by the design verification system software automatically).

In general, as the design has hierarchical structure and each block in the hierarchy or

each module in the block is assigned to an individual designer or verification engineer,

there may be a number of different partitions.

The overhead of the instrumentation logic for compilation avoidance can be

minimized by minimizing the number of the partitioned design objects. However, the

performance of simulation may be degraded due to the increased size of the portion of

DUV that is transferred to the simulator from the hardware platform after design bug

correction. In contrast, increasing the number of design objects, resulting from partitioning

of the DUV, will keep the performance degradation at minimum by minimizing the portion

of DUV transferred to the simulator from the hardware platform. In this case, however, the

overhead of the instrumentation logic may increase. Also, it is important to partition the

design into evenly balanced objects (in terms of their complexity) because it is not known

in advance which object will need to be transferred to the simulator. Basically, the partition

should be performed based on the hierarchical structure of the DUV; this can be done

either automatically or manually by a designer or verification engineer. The role of

instrumentation logic in compilation avoidance is to allow the exchange of dynamic

information between the boundary of those design objects where no design bugs were

found and which need to remain in a hardware platform, and the boundary of the design

objects where some design bugs were found and which needs to be transferred to the simulator and simulated in an event by event, cycle by cycle, or transaction by transaction

mode, in a so called lock-step fashion. The boundary represents all of the input, output,

and input/output ports in the design objects. Such dynamic information exchange is

different from the dynamic information exchange between the TB and the DUV in the

sense that this exchange can occur at the boundary of DUV(PO), which resides inside the

hardware platform. The specific examples of instrumentation logic for supporting this kind

of dynamic information exchange include the proprietary logic added at the boundary of

each design object (to be explained later) or a JTAG-based boundary scan structure,

proposed by IEEE. Alternatively, one can use the test infrastructure, such as IEEE 1149.1

or IEEE P1500, which is already provided in ASIC/SOC chips to support DFT (Design For

Testability). We will refer to the proprietary instrumentation logic, added at the boundary of

each design object for compilation avoidance, as d-PBS. It will be called PBS when

referring to both s-PBS and d-PBS together. For ASIC/SOC, where adding the

instrumentation logic is impractical, it is possible to have the same functionality as PBS by

using the test infrastructure (such as IEEE 1149.1 or IEEE P1500) integrated with the chip.

Referring to the compilation avoidance already explained above, the 100%

visibility of DUV(B), which resides in the simulator, is also provided, except for the

advantage of the continuous execution of SA with incremental simulation compilation, but

without the need for hardware re-compilation. Therefore, compilation avoidance is very

efficient even for the debugging of DUV. In this case, a potentially buggy design block can

be transferred to the simulator using compilation avoidance even before the corresponding design code is modified and still provide 100% visibility for debugging. This

makes it possible to confirm the existence of design errors and to correct them. In this

process, if it is found that there are no design errors in a potentially buggy design block,

the design block in question can be re-executed in the hardware platform. Such a

verification process is very efficient because of the high execution speed of hardware

platform and 100% visibility, similar to that of a simulator.

If compilation avoidance is used for the purpose of efficient debugging, instead

of minimizing the hardware re-compilation time, it is very important to simulate at least one

design block in the simulator fast. To achieve this, two techniques can be used. The first is

to relax the requirement of lock-step co-execution with the remaining design blocks in the

hardware platform. The second is to minimize the size of design blocks executed in the

simulator, and run the simulation fast. Therefore, it is necessary to use the primary TB

caching and the secondary TB caching together in that order. By applying either a) the

input stimulus, stored as the primary TB cached during the execution of the first simulation

run, to all design blocks in the hardware platform at least once at hardware speed; or b)

the input stimuli, stored as the secondary TB, to all design blocks in the hardware platform

at least once, the input stimuli l(B(potentially_buggy)) for the block B(potentially_buggy),

which only needs to be executed in the simulator through compilation avoidance, are

obtained first. By using input stimuli l(B(potentially_buggy)) as the TB, it is possible to

execute the simulation for B(potentially_buggy) at high speed without lock-step interaction

with other design blocks in the hardware platform. To obtain such input stimuli, l(B(potentially_buggy)) in the hardware platform, it is necessary to probe all inputs and

inputs/outputs with the instrumentation logic to achieve compilation avoidance. To do so,

the instrumentation logic or instrumentation codes (d-PBS) for compilation avoidance,

added to the set of design objects for verification, must have a hierarchy structure

compatible with the hierarchy of the DUV.

In this process, it is even possible to read or write the dynamic state information of

DUV (the dynamic state information represents a set of values of all storage devices) by

using the input/output probing technique proposed in the previous invention "Input/output

probing apparatus and input/output probing method using the same, and mixed

emulation/simulation method based on it" (Korea Patent Application Number: 10-2000-

0034628) ^**. Therefore, as it is possible to set up the state of the entire DUV or part of DUV

in the hardware platform or of the simulator with a specific state, the SA re-execution on

the hardware platform or in the simulator can begin at the arbitrary simulation time other

than simulation time 0. This can additionally reduce the times of the repeated simulation in

SA.

Moreover, by combining the two techniques explained above it is possible to

significantly reduce the design verification time. That is, during the first SA execution TB

caching is carried out. This step needs to be performed for every TB used in the

simulation, and in this process a number of different TB caching writes is performed

(writes are procedures of storing input stimulus of DUV into either a massive memory or a

massive hard disk attached to the computer, while the first SA is running by the co- execution of the TB and DUV). In the case of primary TB caching, the application of input

stimulus, stored in a massive memory and present in the design verification interface

module, to a DUV is controlled by the interface module. In the case of the secondary TB

caching, the application of input stimulus, stored in a massive hard disk attached to the

computer, to the DUV is controlled by the interface module and the computer. The

execution speed of the primary TB caching is very high, but its capacity may be smaller

than that of a massive hard disk. To compensate for this, the data compression can be

done during TB caching write process and the data decompression can be done during

TB caching read process (the process that applies input stimulus stored in a massive hard

disk attached to a computer into a DUV). To do this, the interface module can have a data

compression/decompression hardware module. As the secondary TB caching needs to

access a massive hard disk attached to a computer, the fast access scheme by buffering

and DMA (Direct Memory Access) techniques can be used, and, if necessary, high speed

interconnection scheme (for example, infini-band) may connect a hard disk to a main bus

system of the computer. The input stimuli cached in the TB cache during this process can

be applied by TB cache read process to the DUV at the second and the subsequent SA

executions at very high speed, thus maximizing the overall SA execution speed. If at least

one design bug is discovered in this process and fixed, then the modified portion of the

DUV is re-compiled in the simulator and simulated on the computer. At this point, as TB

may already be cached into a massive memory in the design verification interface module

or in a massive hard disk attached to the computer, the simulator can execute the modified portion of the DUV. During this execution, the dynamic information at the output

from the modified part of DUV to the remaining portion of DUV can also be cached. We

will call this process a recursive caching. Recursive caching can further increase the

execution speed of SA since the entire DUV and the TB are in the hardware platform and

the memory, respectively, or in the hardware platform and a hard disk, or in the hardware

platform, the memory and a hard disk. Recursive caching can also be applied recursively.

Above method can be applied to a hybrid hardware assisted verification system,

which combines in-circuit hardware emulation and simulation acceleration using TB as

well as to the original SA. A preferred embodiment of the present invention will be described below, with

reference to the accompanying drawings.

FIG. 1 is a schematic view of the design verification apparatus for the present

invention, which consists of the design verification system software, a simulator and a

design verification interface module, together with an arbitrary hardware platform. FIG. 2 is a schematic view of one example of the internal structure of a design

verification interface module.

FIG. 3 (a) is a schematic view explaining the TB cache writing and reading

processes through the primary TB caching using massive memory.

FIG. 3 (b) is a schematic view explaining the TB cache writing and reading

processes through the primary TB caching using massive memory and data

compression/decompression hardware module. FIG. 3 (c) is a schematic view explaining the TB cache writing and reading

processes through the secondary TB caching using hard disk attached to a computer.

FIG. 3 (d) is a schematic view explaining the TB cache writing and reading

processes through the secondary TB caching, using hard disk attached to a computer and

DMA.

FIG. 4 is a schematic view showing the TB caching process.

FIG. 5 is a schematic view showing the verification process in which the design

object present in the hardware platform is transferred to the simulator after a bug is fixed.

FIG. 6 is a schematic view showing a process of recursive caching. FIG. 7 and FIG. 8 are schematic views of one example of the instrumentation

logic added to the design object for exchanging the dynamic information. For this dynamic

information exchange, the instrumentation logic added to design objects is automatically

synthesized, integrated and implemented with DUV in the hardware platform.

FIG. 9 is a schematic view showing a verification process in which the

instrumentation logic enables the exchange of dynamic information between a modified

design object, transferred to the simulator, and the remaining design objects, implemented

in the hardware platform for compilation avoidance.

FIG. 10 is a schematic view of one example of a generic architecture of a

simulation acceleration system, providing TB caching and compilation avoidance

mentioned in this present invention. FIG. 11 is a schematic view of one example of a hardware platform and a

simulation acceleration controller in FIG.10.

FIG. 12 is a schematic view of one example of PBS.

FIG. 13 is a schematic view of one example of BSC, a basic element of PBS. FIG. 14 is a schematic view of one example of a specific implementation for

PBS.

FIG. 15 is a schematic view of one example of a specific implementation for

block through d-PBS. The d-PBS is the basic element of compilation avoidance.

FIG. 16 (a) is a schematic view of one example showing the execution of the

entire DUV or the part of DUV at least once, with the TB cached data, using a hierarchical

d-PBS structure on a hardware platform. For the purpose of fast simulation, the goal is to

create at least one testbench module with the inputs and inputs/outputs of those design

blocks that may contain bugs, without interacting with other design blocks in the hardware

platform, by transferring those potentially buggy design blocks and the testbench

module(s) to the simulator. As shown in the drawing, the DUV is organized hierarchically,

consisting of design blocks M1 and M2. The design block M1 consists of lower design

blocks M11 and M12, and design block M2 consists of lower design blocks M21 and M22. FIG. 16 (b) is a schematic view of one example of a hierarchical d-PBS added to

a hierarchical DUV, such as in FIG. 16 (a), which makes it possible to read/write the input/output ports of some specific design blocks in the hierarchical DUV by accessing

these ports efficiently.

of d-PBS in FIG. 16 (b) in detail. As already explained, the purpose of the design verification apparatus for the

present invention and the design verification method using the same is to verify the design

rapidly by using hardware-assisted verification techniques even when the size of the

design exceeds the capacity of the simulator. More specifically, with the present invention,

the design bugs can be found more quickly, and subsequent verification process using

hardware verification platform can be carried out more quickly after fixing the design bugs.

As the present invention may be embodied in several forms without departing

from the spirit or essential characteristics thereof, it should also be understood that the

above-described embodiments are not limited by any of the details of the foregoing

description, unless otherwise specified, but rather should be construed broadly within its

spirit and scope as defined in the appended claims, and therefore all changes and

modifications that fall within the meets and bounds of the claims, or equivalence of such

meets and bounds, are therefore intended to be embraced by the appended claims.

Claims

[Claims]

Claim 1: A design verification apparatus comprising:

a design verification interface module for simulation acceleration or hybrid hardware-

assisted verification with an arbitrary simulator and an arbitrary hardware platform,

wherein a massive memory exists either in said design verification interface module or in

the said hardware platform, and the said design verification apparatus increasing the

performance of repeated simulation acceleration through testbench caching using the said

massive memory.

Claim 2: A design verification apparatus comprising:

assisted verification with an arbitrary simulator and an arbitrary hardware platform wherein

massive memory exists either in the said design verification interface module or in the

said hardware platform, or a hard disk exists in the computer, where the arbitrary

simulator is installed; and the design verification apparatus increasing the performance of

repeated simulation acceleration through testbench caching using the said hard disk.

Claim 3: A design verification apparatus comprising:

assisted verification with an arbitrary simulator and an arbitrary hardware platform wherein massive memory exists either in the said design verification interface module or in the

said hardware platform, wherein main memory exists in the computer, where the arbitrary

repeated simulation acceleration through testbench caching using the said main memory.

Claim 4: A design verification method, in which the input stimulus, generated by executing

the testbench, is simultaneously stored into a massive memory or a hard disk where it

serves as a TB cache in the first simulation session, and the subsequent simulation

sessions that use same testbench are executed rapidly by using the said TB cached

stimulus.

Claim 5: A hardware-assisted design verification method, in which, if the design is partly

modified, the modified part of the design is re-compiled for simulation and loaded into a

simulator, and the dynamic information is exchanged between the modified part of the

design in the simulator and the unchanged part of the design in the hardware platform so

that the simulation for the modified part of the design and the hardware-based execution

for the remaining, unchanged part of the design can be co-operated.

Claim 6: The method according to Claim 5, wherein, for the said dynamic information

exchange, a design verification system software instruments additional design codes or design logic circuits into the original hardware design codes or the design logic circuits to

be verified.

Claim 7: The method according to Claim 5, wherein, for the said dynamic information

exchange, the design verification system software instruments additional instruction

sequence for Boolean processors into the original hardware design codes or the design

logic circuits to be verified.

Claim 8: A design verification apparatus comprising:

a design verification system software, a design verification interface module, a simulator,

and a hardware platform for simulation acceleration or for hybrid hardware-assisted

verification, wherein a massive memory exists in the design verification apparatus; and

the design verification apparatus increasing the performance of repeated simulation

acceleration through testbench caching using the said massive memory.

Claim 9: A design verification apparatus comprising:

a design verification system software, a design verification interface module, and a

hardware platform for simulation acceleration or for hybrid hardware-assisted verification,

wherein a massive memory exists in the design verification apparatus; and the design

verification apparatus increasing the performance of repeated simulation acceleration

through testbench caching using the said massive memory. Claim 10: A design verification apparatus comprising:

a design verification interface module, a hardware platform, and a simulator for simulation

acceleration or for hybrid hardware-assisted verification, wherein a hard disk exists in the

computer where the simulator is installed; and the design verification apparatus increasing

the performance of repeated simulation acceleration through testbench caching using the

said hard disk.

Claim 11 : A design verification apparatus comprising:

acceleration or for hybrid hardware-assisted verification, wherein a main memory exists in

the computer where a simulator is installed; and the design verification apparatus

increasing the performance of repeated simulation acceleration through testbench caching

using the said main memory.

Claim 12: A design verification apparatus comprising:

a design verification interface module and a hardware platform for simulation acceleration

or for hybrid hardware-assisted verification, wherein a hard disk exists in the computer

executing the testbench; and the design verification apparatus increasing the performance

of repeated simulation acceleration through testbench caching using the said hard disk. Claim 13: A design verification apparatus comprising:

or for hybrid hardware-assisted verification, wherein a main memory exists in the

computer executing testbench; and the design verification apparatus increasing the

main memory.

Claim 14: A design verification apparatus comprising:

A design verification software, an arbitrary simulator, and an arbitrary hardware platform

for simulation acceleration or hybrid hardware-assisted verification, wherein by adding

either instrumentation codes or instrumentation logic to the design to be verified with the

said design verification software and accessing at least one design block in the design to

be verified through either the said instrumentation codes or the said instrumentation logic

during actual verification execution, the values of all inputs and input/output ports of at

least one design block in the design to be verified are probed at certain simulation cycles

and used as input stimulus to simulate the said design block(s) in the design to be verified

alone in the said arbitrary simulator for obtaining visibility of the said design block(s) in the

design to be verified. Claim 15: The design verification method using the apparatus according to Claim 14,

wherein either the said instrumentation codes or the said instrumentation logic for the

design to be verified has the functionality of d-PBS.

Claim 16: The design verification method according to Claim 15, wherein either the said

instrumentation codes or the said instrumentation logic for the design to be verified has

the functionality of hierarchical d-PBS.

Claim 17: The design verification method using the apparatus according to Claim 14,

wherein by adding either instrumentation codes or instrumentation logic to the design to

be verified with the said design verification software, accessing at least one design block

in the design to be verified through either the said instrumentation codes or the said

instrumentation logic during actual verification execution, and probing the values of all

inputs and input/output ports of at least one design block in the design to be verified, are

carried out by executing the said design block(s) implemented in the hardware platform at

least once.

Claim 18: The design verification method according to Claim 5, wherein the said

exchange of the dynamic information uses the test infra-structure already pre-fabricated in

ASIC/SOC. Claim 19: A design verification apparatus comprising:

instruction sequence of Boolean processor(s) to the design to be verified with the said

design verification software and accessing at least one design block in the design to be

verified through the said instruction sequence of Boolean processor during actual

verification execution, the values of all inputs and input/output ports of the said design

block(s) in the design to be verified are probed out at certain simulation cycles and used

as input stimulus to simulate the said design block(s) in the design to be verified alone in

the said arbitrary simulator for obtaining visibility to the said design block(s) in the design

to be verified.

Claim 20: A design verification apparatus comprising:

for simulation acceleration or hybrid hardware-assisted verification, wherein by using the

test infra-structure pre-fabricated in ASIC/SOC and accessing at least one design block in

the design to be verified through the said test infra-structure pre-fabricated in ASIC/SOC

during actual verification execution, the values of all inputs and input/output ports of the

said design block(s) in the design to be verified are probed at certain simulation cycles

and used as input stimulus to simulate the said design block(s) in the design to be verified alone in the said arbitrary simulator for obtaining visibility to the said design block(s) in the

design to be verified.

Claim 21 : The design verification method using the apparatus according to Claim 19,

wherein by adding instruction sequence for Boolean processor(s) to the design to be

verified with the said design verification software, accessing at least one design block in

the design to be verified through the said instruction sequence of Boolean processor(s)

during actual verification execution, and probing the values of all inputs and input/output

ports of the said design block(s) in the design to be verified, are carried out by executing

the said design block(s) implemented in the hardware platform at least once.

Claim 22: The design verification method using the apparatus according to Claim 20,

wherein by using the test infra-structure pre-fabricated in ASIC/SOC, accessing at least

one design block in the design to be verified through the said test infra-structure pre-

fabricated in ASIC/SOC during actual verification execution, and probing the values of all

inputs and input output ports of the said design block(s) in the design to be verified, are

least once.

Claim 23: The design verification method according to Claim 5, wherein the said

exchange of the dynamic information uses both the test infra-structure already pre- fabricated in ASIC/SOC, and the hardware description codes or hardware logic

instrumented to the original design codes or logic to be verified by the said design

verification system software.

Claim 24: A design verification apparatus comprising:

for simulation acceleration or hybrid hardware-assisted verification, wherein by using both

the test infra-structure pre-fabricated in ASIC/SOC and the instrumentation codes or

instrumentation logic to the design to be verified with the said design verification software

for accessing at least one design block in the design to be verified during actual

block(s) in the design to be verified are probed at certain simulation cycles and used as

input stimulus to simulate the said design block(s) in the design to be verified alone in the

said arbitrary simulator for obtaining visibility to the said design block(s) in the design to

be verified.

Claim 25: The design verification method using the apparatus according to Claim 24,

wherein by using the test infra-structure pre-fabricated in ASIC/SOC and the

instrumentation codes or instrumentation logic to the design to be verified with the said

design verification software, accessing at least one design block in the design to be

verified during actual verification execution, and probing the values of all inputs and input/output ports of the said design block(s) in the design to be verified are carried out by

executing the said design block(s) implemented in a hardware platform at least one time.

Claim 26: The design verification method according to Claim 18, Claim 20, Claim 22,

Claim 23, Claim 24, or Claim 25, wherein the said test infra-structure is IEEE 1149.1.

Claim 27: The design verification method according to Claim 18, Claim 20, Claim 22,

Claim 23, Claim 24, or Claim 25, wherein the said test infra-structure is IEEE P1500.