JP2003157182A - Logic verification method - Google Patents

Abstract

(57) [Summary] [PROBLEMS] To improve the design quality by easily generating a stricter condition than actually occurring on a test bench and performing bug detection on a circuit to be verified. SOLUTION: A plurality of master models and slave models different from an actual circuit are arranged on a test bench, and various data transfers are randomly generated.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to system LSI development, and particularly to a logic verification method.

[0002]

2. Description of the Related Art Conventionally, a system LSI having a built-in CPU
In the development, the logic was verified by using an actual logic circuit and performing simulation using software that operates on an actual machine.

[0003]

However, in an actual logic circuit, it is necessary to make detailed settings before the operation is generated, or it is impossible to generate a desired operation at an arbitrary timing. It was Therefore, it has been very difficult to sufficiently generate an external change given to the logic circuit to be designed, and it has been manufactured with a potential problem. In addition, there is a problem in that it takes a very long time to execute the simulation and the verification takes too long.

The present invention has been made by paying attention to the above points. By using a master model or a slave model in place of the actually connected logic circuit, the operation can be easily performed without complicated settings. It is possible to start it, and it is also possible to control the transfer start time, which can cause a complicated situation that the designer did not intend or can perform verification under more severe conditions than it actually is.

Further, by verifying a situation that the designer did not intend, a bug in the logic circuit can be found early. Also, latent bugs can be discovered by conducting verification under stricter conditions than they actually are.

Another object of the present invention is to provide a logic verification method which enables the development of a high quality system LSI without bugs by using the logic verification method of the present invention.

[0007]

According to the present invention, by using a bus function model instead of an actual CPU, a simulation can be executed without software for the CPU, and logic verification can be performed. . Also CP
By using the bus master model instead of the DMA controller circuit other than U, it is possible to omit the troublesome setting peculiar to the DMA controller and to generate the same operation, so that the operation verification can be easily performed. Further, the logic verification can be performed by executing the simulation even in the state where the logic circuit to be present outside the circuit to be verified is not completed yet.

Further, in the bus operation generated by an actual DMA controller or the like, a transfer having a specific pattern is likely to occur, and a complicated situation is unlikely to occur, but the active model according to the present invention is used. By doing so, it is possible to generate a random transfer that does not have a specific pattern, the probability of occurrence of a complicated situation not intended by the designer increases, and more accurate verification becomes possible.

Further, in an actual DMA controller or the like,
Although it is difficult to control in 1-cycle units, the active model can control the occurrence of transfers in 1-cycle units, and it is possible to perform a sweep test in which transfers from multiple active models are staggered in 1-cycle units. Become. Further, since it is possible to generate a transfer in an arbitrary cycle, it becomes possible to easily generate a concurrent transfer from a plurality of active models and verify a complicated situation. Further, by using the slave model, it is possible to verify a more complicated situation by generating a response from the slave arbitrarily or randomly.

Further, in more detail, the present invention can solve the above problems by the following constitution.

(1) A logic verification method characterized by using a model that does not actually exist in a test bench for logic verification in system LSI development.

(2) The logic verification method according to (1), wherein the model generates a stricter condition than an actual logic circuit.

(3) The logic verification method according to (1), wherein the model includes a master model and a slave model.

(4) The logic verification method according to (3), wherein the master model can start the operation more easily than an actual logic circuit.

(5) The logic verification method according to (3), wherein the slave model responds to the request from the master after a random time elapses.

[0016]

According to the present invention, first, by using the bus function model instead of the actual CPU, it is possible to generate an interesting operation for the logic circuit to be verified even without the actual software. , It is possible to generate random value data transfer with a random type that cannot be realized by actual software. This makes it possible to verify by simulation a situation that was not intended by the designer.

Further, according to the present invention, by making a plurality of instances of the master model and the slave model, it is possible to generate data transfer of a random value with a random type that cannot be realized by actual software. This allows
It is possible to verify by simulation the situation that the designer did not intend.

[0018]

BEST MODE FOR CARRYING OUT THE INVENTION (First Embodiment) A logic verification method according to the present invention will be described below with reference to FIGS.

In FIG. 1 showing the first embodiment of the present invention, 1 is a Bus Function model for generating only the bus operation of a CPU controlling the entire circuit, and 2 is a connection between various buses in the circuit, and a bus between the buses. Bus Bridge that controls data transfer, 3
Is a memory device which is a memory device, 4 is a memory controller which controls reading and writing to the memory device, 5 is an IO-Bus which is a data path for data transfer between various input / output devices and devices in the circuit, and 6 is this IO1 Interface that controls the data transfer with the IO device connected to the circuit, 7 is the IO2 Interfac that controls the data transfer with the IO device connected to this circuit
e, 8 is an IO3 Interface that controls data transfer with an IO device connected to this circuit, 9 is a data transfer instead of the actual circuit IO-Bus master model1, 10 is data instead of the actual circuit IO-Bus master generating transfer
model2 and 11 are Device / Bus that is a data path when data is transferred between internal logic circuits, 12 is a Device1 having a logical function such as compression / expansion and 13 is a Device2 having a logical function such as compression / expansion. , 14 is a Device-Bus master model that generates data transfer instead of the actual circuit
1 and 15 are D that generate data transfer instead of actual circuit
evice / Bus master model 2, 16 is an IO-Bus slave that responds to data transfer requests from the master instead of the actual circuit.
model1, 17 responds to the data transfer request from the master instead of the actual circuit IO-Bus slave model2, 18 responds to the data transfer request from the master instead of the actual circuit Device-Bus slave model1, 19 Device that responds to the data transfer request from the master instead of the actual circuit
-Bus slave model 2.

FIG. 4 shows a conventional example, 20 is a CPU for controlling the entire circuit, 21 is a ROM (Read only Memory) for storing programs and the like, 2 to 8 and 11 to 13 are the same as in FIG. Is.

In the conventional example shown in FIG. 4, it is configured only by the functions used in the actual circuit, and the CPU 20 can read the program from the ROM 21 and execute it, or after transferring the contents to the Memory 3, the memory 3 Read and execute instructions. In this case, what is to be executed next by the CPU 20 is determined by the instruction to be read, and therefore, even when transferring some data, instruction reading (Instruction Fetch) always occurs. However, CP
This does not apply while the instruction is hit in the cache inside U20.

As described above, when verifying the logic circuit, it is necessary to describe the actual software, create the ROM image, and execute the simulation. However, it is not easy to describe the sturmulus for verifying the desired functional block in actual software, and it is also necessary to initialize various parts such as the CPU, so it is difficult to verify easily. is there. Furthermore,
If a real CPU is used in the simulation, it takes a very long time to execute. Even if it is completed in about 10 seconds on the actual machine, it may take 24 hours in the simulation.

Bus Function model 1 in FIG.
Of the actual functions of the CPU, only the change of the signal appearing on the bus can be generated by the command. In this case, it is not necessary to read the instruction as the CPU 20 does. Therefore, it is possible to easily realize generation of desired data transfer without extra transfer. For example, when writing data to an address such as Memory3, write (address,
data); such as Bus Function model 1 may be issued.

Next, in the conventional example of FIG. 4, in order to start data transfer from other than the CPU 20, the IO1 Interface 1
DMA (Direct Memory Access)
Need to start. In this case, the setting method differs for each IO, and the transfer rate also depends on the type of IO.

Therefore, the setting itself is complicated, and the type of transfer generated there is also limited. When that happens,
Transfers cannot be generated one after another, and complicated situations where various things overlap cannot be generated. Therefore,
It is difficult to perform sufficient verification.

IO-Bus master model 1 9 and I in FIG.
O-Bus master model2 10 can generate various data transfers on IO-Bus 5 without the need for complicated settings. Also in this case, it is only necessary to issue a command such as io_write (address, data) ;. Device-Bus master
The same applies to model1 14 and Device-Bus master model2 15. IO-Bus slave model1 16 and IO-Bus slave model
217 is Bus Function model 1 and IO-Bus master mod
It is a slave model that responds to a transfer request from a master model such as el19, and it is possible to respond not only in a fixed cycle but also in a random cycle. Random data is also generated when sending data from these slave models. In addition, there are often bugs in the logic circuit during operations other than normal operations such as bus errors and retries, and it is possible to respond to these slaves with bus errors and retries, which is useful for finding bugs in the logic circuit. Device-Bus slave model1 18 and
The same applies to the Device-Bus slave model 219.

As described above, by using the master model and the slave model that do not exist in the actual circuit, it is possible to verify the situation that the designer does not intend or the complex operation of complicated events.

FIG. 2 shows an example of the description of a test in which the various models described above are operated and verified. Where fork and jo
In the part surrounded by in, the tasks described in each line operate concurrently. For example, cpu_master_kick and io1_ma
ster_kick is started at the same time.

For example, in FIG. 2, cpu_master_kic
k is Bus Functional model1 to Memory3 and IO-Bus sl
The description is such that the transfer to ave model1 16 etc. is generated in a random sequence with a random address. Similarly, io1_master_kick has IO-Bus master model1 9
From IO-Bu to io2_master_kick
s master model2 Transfer sequence from 10 is io1_sl
ave_kick is the transfer sequence to IO-Bus slave model1 16 and io2_slave_kick is the IO-Bus slavemodel2 1
The transfer sequence to 7 is devi for dev1_master_kick
Transfer sequence from ce-Bus master model1 14 to d
ev2_master_kick has Device-Bus master model2 15
Transfer sequence from dev, Dev1_slave_kick to Devic
The transfer sequence to e-Busslave model1 18 is dev2_
In slave_kick, describe the transfer sequence to Device / Bus slave model219.

In this way, if a sequence for transferring data from each master model and a transfer sequence from the CPU to the slave model are described in each task,
An operation from each master model to each memory or slave model occurs, and the logic circuit to be verified performs processing according to the designed logic.

In the example of FIG. 2, since the for part is outside the fork-join part, each operation is started at the same time each time the for loop is executed, and when each sequence ends, the next for is executed. loop is performed. In other words, the task that completed the operation first waits for the start of the next operation until all other tasks have completed the operation.

In the example of FIG. 3, inside the fork-join portion, the for portion is arranged for each task. In this case, each task starts the first operation at the same time, but each task repeats the loop a predetermined number of times. That is, the operation of each task is continuously executed one after another regardless of the operation of other tasks. In this case, Bus Bridge 2
Has to process transfers from all directions without any breaks, which makes it possible to apply more stress than it actually does.

Further, at the beginning of each task, a random value is first generated, and the operation is started after waiting for a cycle corresponding to the value, so that the operation can be prevented from forming a specific pattern. Furthermore, instead of waiting for a random cycle, it is easy to delay the operation start one cycle at a time by using for loop, and it is also easy to sweep the operation start of one task with respect to the operation start of another task. realizable.

As described above, various situations and complicated situations can be executed by simulation by slightly changing the calling method of each task without rewriting most of the test program.

[0035]

As described above, according to the present invention, first, the master model or the slave model is used instead of the actually connected logic circuit, so that the operation can be easily started without complicated setting. In addition, it is possible to control the transfer start time, and it is possible to generate a complicated situation that the designer did not intend or to perform verification under more severe conditions than it actually is.

By verifying a situation that the designer did not intend, a bug in the logic circuit can be found early. Also, latent bugs can be discovered by conducting verification under stricter conditions than they actually are.

By using the logic verification method of the present invention, it is possible to develop a high quality system LSI without bugs.

[Brief description of drawings]

FIG. 1 is a block diagram of a simulation target according to an embodiment of the present invention.

FIG. 2 is a description example of a test for executing a simulation according to the embodiment of the present invention.

FIG. 3 is a description example of a test for executing a simulation according to the embodiment of the present invention.

FIG. 4 is a block diagram of a conventional example.

[Explanation of symbols]

1 Bus Function model 2 Bus Bridge 3 Memory 4 Memory Controller 5 IO-Bus 6 IO1 Interface 7 IO2 Interface 8 IO3 Interface 9 IO-Bus master model1 10 IO-Bus master model2 11 Device-Bus 12 Device1 13 Device2 14 Device-Bus master model1 15 Device-Bus master model2 16 IO-Bus slave model1 17 IO-Bus slave model2 18 Device-Bus slave model1 19 Device-Bus slave model2 20 CPU 21 ROM

Claims (5)

[Claims] 1. A logic verification method characterized by using a model that does not actually exist in a test bench for logic verification in system LSI development. 2. The logic verification method according to claim 1, wherein the model generates a stricter condition than an actual logic circuit. 3. The logic verification method according to claim 1, wherein the model includes a master model and a slave model. 4. The logic verification method according to claim 3, wherein the master model can start operation more easily than an actual logic circuit. 5. The logic verification method according to claim 3, wherein the slave model responds to a request from the master at random times.