JPH10221410A - Automatic logic verification system for lsi - Google Patents

Abstract

PROBLEM TO BE SOLVED: To automate logical verification of an LSI or a system including it by providing a probability setting file storing access frequency information defining the event generation probability of an access object constituting an address space, and the like. SOLUTION: A probability setting file 11 stores access frequency information defining the event generation probability of an access object constituting an address space, and transaction frequency information defining the type and the frequency of transaction with respect to the access object. A pattern generator 12 generates a test pattern automatically based on a probability provided from the pattern generation probability setting file 11. Since a test pattern is generated based on the probability setting tile 11 defining the event generation probability in the address space, a high quality test pattern where the test coverage is sustained at a constant level can be generated while eliminating leakage. Furthermore, a test pattern reflecting the proceeding situation of verification can be generated efficiently.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to an automatic logic verification method for efficiently and automatically performing logic verification of an LSI or an LSI system including the LSI.

[0002]

2. Description of the Related Art A conventional general LSI verification method will be described with reference to FIGS. FIG.
(A) is the simplest simulation model for which only the LSI itself is to be verified. In this model,
The value of the input signal to the LSI and the input timing are given manually, and the validity of the operation is checked by comparing the output signal from the LSI with the expected value of the output pattern visually or manually created in advance. The bidirectional signal is treated as an input signal at the input timing and as an output signal at the output timing. FIG. 22B is a development of the model of FIG. 22A, and uses a model of a device connected to the LSI to be verified. In this way, only a part of the signal value in the operation to be verified is manually specified, and most of the input timing, the bus control signal, and the like are transferred between the LSI to be verified and the device connected thereto. Validated automatically based on protocol. Although not shown, when the device to be verified is an asynchronous circuit, the simulator checks the hazard margin in the same environment as in FIG.

Next, the operation will be described. FIG.
(A) is a diagram which actualized FIG.22 (a). For simplicity, the LSI to be verified has only the function of a 3-bit up / down counter. The input signal clk is LS
Clocks, up and do, which define the operation timing of I
wn is a control signal for instructing increment and decrement of the count value, respectively. When both the up signal and the down signal are "0", the count value does not change and both are "1".
In the case of, it is assumed that the count value is reset. When performing a simulation using the model to be verified, it is necessary to first provide a combination pattern (a set of time and signal value) for each input signal, but this pattern creation operation is performed manually. This situation is shown as “input signal” in FIG. At this time, it is necessary to visually confirm the state of the change of the output signal.
The output signal “count” is shown in FIG. Here, FIG.
When the configuration of FIG. 2B is applied to the example of the up-down counter, the operation is as follows. It is assumed that the simulation model includes only the verification model A in the figure and the LSI. First, the operation of the verification model A is manually specified as follows. reset 1 increment 5 hold 1 decrement 3 increment 1... Each line follows the format of “operation mode cycle number”. The verification model A interprets this instruction, creates the same input signal pattern as shown in FIG. 23B, and gives it to the LSI, thereby obtaining a simulation result similar to the previous example. Next, the hazard check is performed by the simulator in the same environment as described above (however, in this case, the object to be verified must not be a module in which the function is described). The simulator proceeds with the simulation by referring to a library dedicated to hazard check, and upon detecting a shortage of the hazard margin, shifts the attribute to the next element.

[0004]

Since the conventional LSI verification has been realized as described above, as the size of the LSI continues to increase or the complexity of the LSI continues to increase, a sufficient test can be performed with a manual test pattern. It has become impossible to cover the cases, and there is also a problem that there is a great risk that a bug is mixed in the test pattern itself.

In the case of manual creation, it is difficult to generate a test pattern focusing on a specific operation, and furthermore, it is difficult to grasp what kind of pattern should be prepared. There is a problem that it is difficult to maintain the level above a certain level.

Further, in the conventional method, the validity of the operation of the model to be verified is checked by comparing the output pattern with the expected value, so that the designer can determine the operation by checking the waveform or signal value log. An expected value for each time must be created one by one while taking into account the problem, and there is a problem that not only the work efficiency is poor but also a malfunction may be overlooked.

Further, there has been a method of automatically checking a bus protocol of a verification model (group) connected to a model to be verified. However, the conventional method has a problem that operation verification across buses cannot be sufficiently performed. Was.

In addition, the verification target is a large-scale and complicated LS
In the case of I, it is extremely difficult to determine the test coverage of how much has been verified in all the expected operation cases, and as a result, it is difficult to know what tests should be performed and how much later. There was a problem. Further, there is a problem that a dedicated tool is required to perform a hazard check.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-described problems. The present invention automates the logic verification of an LSI or a system including the same, and realizes a high-quality and efficient automatic LSI in consideration of test coverage. It is intended to provide a logic verification system.

[0010]

An LS according to the first invention is provided.
The automatic logic verification method of I specifies an event occurrence probability of an access target constituting an address space in an LSI logic verification system for verifying an internal circuit of an LSI connected via a verification model by an external control signal. A probability setting file storing access frequency information, transaction occurrence frequency information defining the type and appearance frequency of a transaction for the access target, and a test pattern generation for automatically automatically generating an input signal pattern based on the information in the probability setting file With the provision of the means, the output result of the test pattern generation means is supplied to the verification model and simulation is performed, thereby increasing the efficiency of test pattern creation.

A second invention is directed to an LSI according to the first invention.
In the automatic logic verification method, the test pattern generation means dynamically changes the event occurrence probability of an access target constituting an address space in accordance with a predetermined rule based on an existing situation.

A third invention is directed to an LSI according to the first invention.
In the automatic logic verification method, the test pattern generation means generates a test pattern by dividing the parameters required for test pattern generation into several groups and independently changing the parameters belonging to the groups at certain time intervals. It is like that.

According to a fourth aspect of the present invention, there is provided an automatic logic verification system for an LSI, wherein a logic verification system for an LSI verifies an internal circuit of the LSI connected via a verification model by an external control signal. A plurality of sets of command files storing test patterns to be provided to the verification LSI, a monitor for monitoring transactions on a bus to which the LSI to be verified and the verification model are connected, and the plurality of sets of commands based on a monitoring result by the monitor; By providing a command file switching means for selecting a file, simulation is performed while selecting a test pattern according to a verification situation.

According to a fifth aspect of the present invention, there is provided an automatic logic verification method for an LSI, which is applied to an LSI to be verified in an LSI logic verification system for verifying an internal circuit of the LSI connected via a verification model by an external control signal. A command file storing a test pattern, monitoring means for monitoring a transaction on a bus to which the LSI to be verified and the verification model are connected, and a conflict list file storing a pattern for generating a race condition of operation for the LSI to be verified And a command register in which a race condition occurrence command in the race list file is set based on the monitoring result by the monitor means, and a command file switching means for selecting one of the command file and the command register. While generating race conditions according to the situation, It is obtained to perform the configuration.

An automatic logic verification method for an LSI according to a sixth aspect of the present invention provides an LSI logic verification system for verifying an internal circuit of an LSI connected via a verification model by a control signal from the outside. A command file storing a test pattern; and a monitor for monitoring a transaction on a bus to which the LSI to be verified and the verification model are connected. When the monitor detects a transaction to the memory space,
The application timing of the test pattern given to I is variably controlled.

An automatic logic verification method for an LSI according to a seventh aspect of the present invention provides an LSI logic verification system for verifying an internal circuit of an LSI connected via a verification model by a control signal from the outside. A command file storing a test pattern, a log file storing a bus simulation result for each bus to which the LSI to be verified and the verification model are connected, and a transaction crossing between buses is analyzed and traced based on the contents of the log file. By providing an inter-bus verification tool, the legitimacy of the processing across buses is checked.

An automatic logic verification method for an LSI according to the eighth invention is a logic verification system for an LSI which verifies an internal circuit of an LSI connected via a verification model by a control signal from the outside. A command file storing a test pattern, a log file storing a bus simulation result for each bus to which the LSI to be verified and the verification model are connected, and a transaction crossing between buses is analyzed and traced based on the contents of the log file. By providing an inter-bus verification tool and a coverage aggregation tool that aggregates coverage of transactions between buses, coverage evaluation is performed based on a transaction competition state between buses.

An automatic logic verification method for an LSI according to a ninth aspect of the present invention provides an LSI logic verification system for verifying an internal circuit of an LSI connected via a verification model by a control signal from the outside. A command file storing a test pattern; an operation state monitor connected to a bus connecting the LSI to be verified and verification models located at both ends of the LSI to be monitored to monitor an internal state of the LSI to be verified; And a log file for storing a monitoring result by the above method, thereby performing coverage evaluation based on the simulation result.

A tenth aspect of the present invention is the automatic logic verification method for an LSI according to any one of the first to ninth aspects, wherein the logic verification method is such that a hazard occurrence condition is satisfied for an input signal of a combinational circuit element. And a hazard detection tool for generating a narrow pulse in the output signal of the circuit element.

An eleventh invention is directed to the automatic logic verification method for an LSI according to any one of the first invention to the tenth invention,
A verification model, an input / output unit that interfaces with an external bus, a reception storage unit that stores input information from the input / output unit based on a response condition input as an external command, and an input information from the reception storage unit A transmission operation unit that transfers the input / output unit to the input / output unit based on a start condition input as an external command, and the input / output unit, the reception storage unit, and the transmission operation unit are connected by a simple communication protocol. Is to unify the internal structure.

[0021]

DESCRIPTION OF THE PREFERRED EMBODIMENTS First, an environment configuration of a logic verification by automatic test pattern generation according to the present invention will be described with reference to FIG. In the figure, reference numeral 13 denotes a simulation target composed of an LSI to be verified and a verification model connected thereto, which corresponds to FIG. 22B. In the present invention, the pattern generator 12 automatically generates a pattern. Here, the pattern generator 12 generates a pattern based on the probability given in the pattern generation probability setting file 11. Embodiments 1, 2, and 3 relate to automatic generation of this pattern. The fourth, fifth, sixth, and eleventh embodiments relate to a method of configuring the simulation target 13. Simulation target 13
Is input to the simulator and simulated (14). Embodiment 10 relates to a simulator used for simulation. The result of the simulation is checked for validity of the operation (15), and is subjected to coverage counting means 16 for determining what kind of verification has been performed. The seventh embodiment is related to the operation validity check, and the eighth and ninth embodiments are related to coverage totalization.

Embodiment 1 A first embodiment of the present invention will be described with reference to FIGS. The module to be verified is a bridge LSI connected to two buses.
Is assumed. FIG. 1 is a diagram illustrating an environment in which a test pattern is automatically generated and a logic simulation is performed as described above. In the figure, the module to be verified is connected via two different buses to a bus verification model that simulates the behavior of each bus. The verification model of each bus outputs a test pattern given from the outside to the bus according to the protocol of each bus, and performs processing of a signal output by the module to be verified. The operation when accessing the device on the bus B from the bus A is as follows. 1) Arbitration is performed between the bus A verification model and the bridge LSI, and the verification model acquires the right to use the bus A. 2) The bus A verification model extracts a set of patterns (for example, a command and an address in the case of reading, and a write data group in the case of writing) taken out of the test pattern (A), and outputs them to the bus A. 3) Arbitration is performed between the bridge LSI and the bus B verification model, and the bridge LSI acquires the right to use the bus B. 4) The bridge LSI converts the processing requested from the bus A into a format for the bus B and outputs the format to the bus B. (This ends in the case of writing, and continues in the case of reading.) 5) The bus B verification model outputs the contents of the specified address to the bus B. 6) The bridge LSI outputs the data received from the bus B to the bus A. 7) The bus A verification model compares the expected value data indicated by the test pattern (A) with the data returned from the bus A, and displays an error message if they are different. This embodiment is characterized in that a pattern generator 12 and a pattern occurrence probability setting file 11 indicated by oblique lines in the figure are prepared, and pattern creation which has conventionally been very troublesome is automated. If the probability is fixed, a probability setting file is not particularly required, and it is sufficient to embed a fixed value in the pattern generator.

Next, automatic generation of a pattern will be described. FIG. 2 is an example of the probability setting file.
In the first line (21), the access target is SRAM, DRA
M and IO indicate that the ratio of the frequency of accessing each is 1: 7: 2. In the second line (22), the type of transaction is 1
Write word (WRITE1), write two words (WRITE2), read one word (READ
1) There are four types of two-word reading (READ2), and the appearance frequency ratios are all the same (1: 1: 1: 1). The interpretation of the contents of the probability setting file depends on the agreement with the pattern generator described below.

FIG. 3 shows a processing flow of the pattern generator 12. Hereinafter, the operation of the pattern generator 12 will be described with reference to the drawings. In the initial setting phase, a pseudo-random number sequence to be used in subsequent programs is set based on the seed of the random number (seed) specified when the tool is started. Also, the count value (the number of patterns to be generated) passed at the time of startup is
Set to t. The parameter table is a table in which the contents (character strings) of the probability setting file shown in FIG. 2 are converted into numerical values so as to be easily used by the pattern generator and expanded. The memory table is a table that holds the contents of addresses at the time when a certain test pattern is executed. The contents are updated in a write transaction, and are referred to as expected values in a read transaction.
The memory table is, for example, a table including a set of an address and data. After these settings, the output file is opened and the process proceeds to the pattern generation phase (step 3.1). In the generation phase, every time one pattern is generated, c
“out” is decremented (step 3.15), and a loop is performed until the value becomes 0 (step 3.2). The procedure of pattern generation is as follows. First, according to the setting of the first row (21) in FIG. That is, address-based) is selected, and an address is generated by concatenating the offset with a randomly generated offset (step 3.3). Next, a command (transaction) type is randomly generated according to the setting of the second line (22) in FIG. 2 (step 3.4).
If the generated command is a write transaction (step 3.5, step 3.8), random write data is generated (step 3.6, step 3.9), and the contents of the memory table are newly updated. Update to the data to be written (step 3.7, step 3.1
0). If the command is a read transaction (step 3.11), the contents of the address generated from the memory table are read and set as the expected value (step 3.11).
12, step 3.13). For both writing and reading,
The difference between one word and two words is the difference between whether to generate one write data or two read expected values. When these processes are completed, the generated pattern is output to an output file (step 3.14), and the process enters the next loop (or ends (step 3.16)).

FIG. 4 shows an example of the generated test pattern. Each row has a format of “command address data 1 data 2”, and data 1 and data 2 are write data in the case of writing, and expected values in the case of reading. The contents of FIG. 4 will be further described with reference to FIGS. 2 and 3 described above. As can be seen from the generation of four patterns, the initial value of count is 4 (step 3.1). ), (Step 3.
From (2) to (Step 3.3), “adr = FF000000” is obtained based on FIG. 2 (21), and then “cmd” is calculated based on FIG. 2 (22) in (Step 3.4).
= WRITE1 ". The command is WRITE
Since it is E1, (step 3.9) is executed, and "data
1 = 1234678 "and" data2 = 0 ".
Also, as a result of executing FIG. 4 (41) in the simulation, the content of the number “FF000000” is “123456”.
78 ", and when reading the same address thereafter, the updated value must be used as the expected value.
In 0), the contents of the memory table corresponding to the value of “FF000000” are changed to “12345678”.
The parameters generated as described above (step 3.1)
What is output to the file by 4) is the pattern (41) on the first line in FIG. (Step 3.15) c
"out = 3", and generation of the next pattern is started via (step 3.2). When the fourth pattern in FIG. 4 is output, the count becomes 0 and the pattern generation ends (step 3.16).

Embodiment 2 FIG. Before describing the second embodiment of the present invention, consider how the contents of the probability setting file of FIG. 2 are used in the flow of FIG. 3 in the first embodiment. A method of generating a pseudo-random number in a program is not particularly described. For example, a function provided by a computer system to be used may be called. In the following, for simplicity, it is assumed that a function that returns an integer between 1 and 100 at all is already defined and will be used. First line of FIG. 2 (21)
Is related to the address space, and the access frequency to the three types of spaces is 1: 7: 2. The corresponding pattern table has three entries, and the contents of each entry are 10, 80, and 100. This value is 100 * (1 / (1 + 7 + 2)), 100 * ((1
+7) / (1 + 7 + 2)), 100 * ((1 + 7 + 2)
/ (1 + 7 + 2)). Therefore, in the pattern generation phase of the pattern generator, when the value of the random number obtained from the function at the time of address generation is 10 or less, the SRAM space is used.
If it is 1 or more, the address for 10 spaces is returned (Fig. 5
(A)). Similarly, the parameter table corresponding to the second line (22) in FIG. 2 is composed of four entries, and their contents are 25, 50, 75, and 100, respectively. In addition, (2
The contents of 1) and (22) are set completely independently. Also,
If the occurrence probability is fixed, the address space and the command may be determined by the remainder when the obtained random number value is divided by an appropriate numerical value without performing such a procedure (see FIG. 5B).

When the occurrence probabilities of the parameters are determined as described above, the pattern generator generates a pattern based on a certain probability from the beginning to the end. When a simulation is performed using such a pattern, there may be a problem that there is a conflict case that is difficult to appear, or that a case that appears once is sufficient many times, and the verification efficiency is not improved. The second embodiment is to solve this problem, and dynamically changes the occurrence probability of each parameter according to the progress of the pattern generation. Specifically, for example, “DR
When three patterns of writing to the AM space are generated in succession, thereafter, the frequency of access to the DRAM space is reduced by one, and the frequency of access to the SRAM space is increased by one instead. Each time the pattern generator checks the conditions, the rules such as `` reduce the writing ratio every time '', `` return to the initial setting when the occurrence probability of a certain parameter is less than half of the initial value '' Will be updated. As an example, if the first rule is satisfied in the state where the content of the parameter table corresponding to the first line (21) in FIG. 2 is (10, 70, 20), the content becomes (11, 69, 20). To change. Since the above contents can be easily incorporated into the flow chart of the pattern generator of FIG. 3, they are not particularly shown.

Embodiment 3 A third embodiment of the present invention will be described with reference to FIG. This embodiment also aims at efficiently improving test coverage by using a random pattern, and determines the address (step 3.3) and the command (step 3.4) in FIG. And other implementation methods. In the second embodiment, it is assumed that test patterns are collectively generated and stored in a file in advance, and the patterns are extracted and executed one by one during the simulation. The parameters generated at random are divided into several groups while the simulation is performed in parallel with each other, and the cycle of changing the parameters is changed for each group, so that a slightly different pattern is efficiently generated.

Hereinafter, the present embodiment will be described with reference to FIG. FIG. 6 is a flowchart showing the operation of this embodiment. In the figure, 601 is a parameter number determining mechanism, 602 is a parameter extracting mechanism, 603 is a parameter determining mechanism, and 604 is a simulation mechanism.

Next, the operation will be described. In the simulation, types of parameters that can be randomly changed include, for example, an address, a command, a bus access start time, and a data response time. Since it depends on the model to be verified, there are X types here. First, the number-of-parameters determining mechanism 601 determines how many types of parameters are varied from the X types of parameters by 1 to 1.
The value is randomly determined within the range of X, and the value A is passed to the parameter extracting mechanism 602. The parameter extraction mechanism 602 randomly extracts A parameters from the X types of parameters and passes them to the parameter determination mechanism 603. The parameter determining mechanism 603 randomly determines a value within a range determined by each of the selected A parameters. Note that the parameters not extracted by the parameter extraction mechanism 602 retain the values determined before. As described above, all the parameter values are set, and the simulation execution mechanism 604 executes one bus access operation on the simulation.
After the execution is completed, the process returns to the parameter determining mechanism 603 again, and the above operation is repeated the number of times set in the loop 607.
In this way, instead of changing all the parameters for each test pattern separately, by providing regularity in the random pattern, the appearance of a periodic test pattern that is unlikely to occur when the test is performed completely at random Can be accelerated.

Embodiment 4 FIG. A fourth embodiment of the present invention will be described with reference to FIGS. The present embodiment relates to logic verification after a test pattern is generated, and the test pattern itself may be either automatically generated or manually generated. In FIG. 7, 701,
702, a command file storing a group of transactions executed by the bus model A; 703, a selector for switching the command file according to the value of the flag 704;
Reference numeral 4 denotes a flag for instructing command file switching. A monitor module 705 monitors a transaction on the bus B and sets / resets a flag. The same reference numerals in FIG. 1 denote the same or corresponding parts. Although FIG. 7 shows an example in which two command files are switched, the same applies to a case in which three or more command files are switched.

Next, the operation will be described with reference to FIG. Here, a case where an interrupt occurs during normal processing will be described as an operation example. Command file A1
The normal processing and the interrupt processing shown in FIG. 8A are stored in (701) and A2 (702), respectively. The bus model A first executes a transaction according to the command file A1 (701). The monitor module 705 monitors an interrupt signal (not shown) on the bus B, and sets the flag 704 when the interrupt signal becomes significant (FIG. 8).
(Time T1 in (b)). The selector 703 sets the flag 704
Is set, the file applied to bus model A is
From the previous command file A1 (701) to A2
Switch to (704). The monitor module 705 is
The interrupt signal on the bus B is monitored, and when it becomes "insignificant", the flag 704 is reset (time T2 in FIG. 8B). When the flag 704 is reset, the selector 703 sends a file to be applied to the bus model A to the command file A2.
Switching from (702) to the original A1 (701). still,
In the present embodiment, an interrupt signal has been described as an example, but the command file may be switched by using an error signal or the number of transactions on the bus as a trigger. As described above, since the command file can be dynamically changed according to the operation on the bus, the verification can be performed efficiently.

Embodiment 5 FIG. (Designation of Input Pattern by Inter-Model Communication) A fifth embodiment of the present invention will be described with reference to FIGS. In FIG. 9, reference numeral 801 denotes a command file storing a group of transactions executed by the bus model A; 802, a command register storing a transaction executed by the bus model A; 803, a transaction on the bus B; Reference numeral 704 denotes a monitor module for setting / resetting the command register 802, and reference numeral 804 denotes a conflict file storing a conflict pattern to be verified by the module under test. still,
1 and 7 represent the same or corresponding parts.

Next, the operation will be described. Here, as an operation example, a case will be described in which the conflict pattern shown in FIG. 10 is verified. The monitor module 803 monitors the transaction on the bus B, and
If a transaction (write transaction to the memory space in this example) that matches 4 is detected, a transaction to collide with the command register 802 (write transaction to the register space in this example) is set, and at the same time, a flag (704) is set. . At the same time, the monitor module 803 deletes the verified conflict pattern from the conflict file 804 and monitors the bus B.
When the flag 704 is set, the selector 703 stores the file to be applied to the bus model A in the command file A (8
01) to the command register 802. As described above, since the transaction to be executed can be dynamically changed according to the operation on the bus, the verification can be performed efficiently.

Embodiment 6 FIG. A sixth embodiment of the present invention will be described with reference to FIG. In FIG.
A monitor module 901 monitors a transaction on the bus B and changes the timing at which a command is applied to the bus model A. 1 and 7 represent the same or corresponding parts.

Next, the operation will be described. Here, as an operation example, a case where the timing of applying a command file to the bus model A is changed every time a write transaction to the memory space is executed on the bus B will be described. The monitor module 901 has a command file A
Transactions are sequentially taken out from (801) and the transaction is immediately activated by the bus model A. on the other hand,
The monitor module 901 monitors a transaction on the bus B, and when detecting a write transaction to the memory space, changes the application timing of the transaction to be activated by the bus model A (for example, adds a delay of one to several tens of clocks). As described above, the timing of the transaction to be executed can be dynamically changed according to the operation on the bus, so that the verification can be performed efficiently.

Embodiment 7 A seventh embodiment of the present invention will be described with reference to FIGS. Conventionally,
The validity of the simulation result was checked by visual confirmation or by comparing the output value created in advance with an expected value pattern. In the simulation target (13) as shown in the upper frame of FIG. 12, a bus model (or a dedicated monitor module) monitors each bus, and outputs an error message when detecting an operation contrary to the protocol. In this way, the simulation results were automatically checked. However, this method is extremely effective in terms of efficiency in terms of operation check, but is insufficient in checking operation across buses. In other words, the write transaction from the bus A to the bus B is completed when it reaches the bus bridge LSI from the viewpoint of the module monitoring the bus A, and it is checked whether the transaction is correctly transmitted to the bus B. Not. Similarly, the module monitoring the bus B does not check whether the transaction output to the bus B by the bus bridge LSI correctly reflects the transaction from the bus A. To check whether a write to a certain address has been performed correctly, it seems sufficient to issue a transaction that reads the contents of the same address and compare the returned data with the written data. In general, there is no guarantee that the contents of the same address as the write address will be read in a test pattern.
In order to guarantee this, the pattern appearing on the bus is restricted, and furthermore, a bug such that the address is fixedly changed in the LSI is not detected.

The seventh embodiment of the present invention addresses the above problem, and is used together with a protocol check for each bus. The outline is as follows. First, as shown in FIG. 12, a logic simulation 14 is performed in a conventional environment. At this time, the signal value of each bus at each time is output to a log file (12.1, 12.2). After completion of the simulation, the legitimacy of the transaction processing across the buses is checked by mutually referring to these log files (12.3). Prepare a tool for checking the validity based on the log file separately.

Next, the operation of the validity check (12.3) of a transaction across buses will be described below. For simplicity, the bus connected to the LSI to be verified is 2
Assume type. FIG. 13 shows an example of the logs of the buses A and B. It is assumed that the bus A supports the transfer of a plurality of words and the bus B supports the transfer of only one word. WriteN and readN represent writing and reading of N words, respectively, and the number at the beginning of the line indicates the time when the signal appears on the bus. (13.1)-(1
Steps up to 3.7) show the steps (in numerical order) in which one transaction appearing on the bus A is executed. Although appearing as a two-word write on the bus A, it appears on the bus B as being broken down into two one-word writes. (13.8) to (13.11) correspond to bus B
This shows the process in which the one-word read transaction appearing above is processed, and it is impossible to perform these processes manually for all enormous simulation patterns, and this process is automated in this embodiment. FIG.
14 is an example of an output file as a result of performing a validity check on the bus log of FIG. 13. The validity check tool traces the transaction issued to each bus to the target bus and outputs a trace result to a file. At the time of tracing, we perform data comparison checks, etc.
The contents of the detected error are reported to the same file.
In the figure, the row indicating the signal of the target bus shows the position of the first column shifted to the right. FIG. 15 shows a schematic flow of a tool for tracing a transaction and checking the validity. FIG. 16 is a detailed flow chart of the processing contents in (Step 15.2) and (Step 15.3) in FIG. The variable trans-num in FIG. 16 indicates the order in which the transaction of interest appears on the bus, and the variable M
ax is the total number of transactions appearing on the bus, and is obtained in the phase of (step 15.1) in FIG.

The operation will be further described below with reference to FIGS. (1) Preprocessing (Step 15.1) (a) When the tool is started, first, a transaction table for each bus is created based on the log file shown in FIG. This table is a structure that holds the transaction start time, transaction type, transaction address, and the like. One element of the structure holds information about one transaction on the bus.
(B) Mark that the contents of all logs have not been traced yet. (C) Open the output file of the tool. (2) Trace the transaction from bus A to bus B (step 15.2) (3) Trace the transaction from bus B to bus A (step 15.3) In this phase, (step 15.1) While referring to the created transaction table, the transaction crossing the buses is traced according to the flow of FIG. This will be described in more detail with reference to FIG. Bus A
The operation when tracing a transaction addressed to bus B is as follows. “trans-num” is a number assigned to the transaction appearing on the bus A in the order of appearance. (Step 16.1), (Step 1
By the scanning of 6.2) and (step 16.7), the processing is performed in order from the transaction which first appears on the bus A to the last transaction. (Step 16.
In 3), the transaction table of bus A
By looking at the address of the ns-num-th transaction, it is determined whether the transaction is addressed to the LSI to be verified (that is, addressed to the bus B). If the transaction is not addressed to the LSI to be verified, this transaction is a part of the transaction addressed to the bus A from the bus B, and therefore, is not traced at this time. If it is addressed to the LSI to be verified, in step (16.4), the logs of the bus B are searched for those having the same transaction address and type from among the untraced logs, and the result is obtained (step 16.5). )
To output to a file. For a newly traced log, the traced flag is turned off (step 16.6), and if a later transaction happens to access the same address, the same log is erroneously duplicated and traced. Avoid getting lost. (4) Post-processing (Step 15.4) When the tracing of the transaction is completed for all the buses, the log that has not been traced last is reported, and the processing is completed. As described above, according to the present embodiment, it is possible to automatically check the validity of transaction processing across buses. It is also possible to check that the operation is performed as specified by referring to the input pattern file of each bus model.

Embodiment 8 FIG. An eighth embodiment of the present invention will be described with reference to FIG. The description of the embodiments up to this point has dealt with the creation of input patterns for logic simulation and the efficiency of verification work by automatically checking simulation results. By the way, in order to decide where to end the verification work, it is necessary to evaluate the coverage. To know coverage,
It is necessary to summarize what kind of case has appeared in the simulation process. Generally, the aggregation target for the coverage evaluation includes (1) the type and address of a transaction appearing on the bus connected to the module to be verified. As described above, what can be immediately understood if only the specific bus is monitored, and (2) those relating to the internal state of the verified module and the state of other buses when the specific transaction is input to the verified module are considered. Can be First,
Regarding (1), the total can be directly calculated from the log or test pattern of each bus, and it is sufficient to prepare a simple individual totaling tool. Of course, a bus verification model or the like may be totaled during the simulation.
Regarding (2), it is not as simple as (1), and necessary data cannot be totaled even if only a signal group of a specific bus is monitored. The present embodiment relates to automatic counting means, and based on logs of each bus connected to the module to be verified,
In addition to the counting of (1), the status (conflicting operation) inside the module to be verified is counted while mutually referring to the logs of the buses.

In the following, a group of a specific transaction input from a certain bus to a verified module and all transactions in process or waiting in the verified module at that time is considered as an object to be counted. The case will be described. Note that the description of (1) aggregation is omitted. In order to perform the above tally, it is essential to know the transaction inside the module to be verified at a certain time. This means that the start time and end time of all transactions appearing on each bus must be known, and therefore, it is necessary to trace transactions across buses. Regarding the tracing of transactions across buses, the method of realizing the tracing has been described in the seventh embodiment (FIGS. 15 and 16).
This is used in the present embodiment. Since the transaction table in FIG. 15 stores the transaction start time, transaction type, address, and the like as described above, in the present embodiment, an entry for storing the transaction end time is added to this table. The end time of the transaction traced in the transaction tracing phase is written in this entry (the default is the initial value = ∞). FIG. 17 shows an operation flow after the transaction table including the end times of all the transactions is completed in this way. As in the previous embodiment, it is assumed that only two buses (bus A and bus B) are connected for simplicity. First, one bus is selected and transactions are taken out one by one from the transaction table. If the fetched transaction is addressed to the module to be verified (step 17.1), information about the transaction is reported, and the start time of the transaction is remembered (this value is defined as "star").
t-time) (step 17.1). Next, search all transaction tables and start
Find and report all transactions destined for the verified module that started before time and ended after start-time. (Step 17.2) When this operation is performed for all bus transactions,
When a given transaction is given to the module to be verified, a list of transactions that have already been accepted and have not been completed is obtained. Based on this transaction list, the total of the race conditions can be easily performed.

Embodiment 9 Next, a ninth embodiment of the present invention will be described with reference to FIG. This embodiment also relates to a counting method for test coverage, as in the previous embodiment. FIG. 18A is a model diagram of the present embodiment, and FIG. 18B is a timing chart showing the operation. In FIG. 18A, reference numeral 1801 denotes a module to be verified, and here, a bus bridge LSI
Point to. Reference numeral 1802 denotes a bus A for requesting data transfer to the verified module 1801, and 1803 denotes a bus for requesting the
A bus B 801 transfers data to another module. Reference numeral 1804 denotes an operation state monitoring device for the present embodiment. In FIG. 18B, 18
11 is an operation state of the bus A 1802, 1812 is an internal state of the module to be verified 1801, 1813 is a bus B 180
3 shows the operation state of the third embodiment.

Next, the operation will be described. In this example, the module to be verified 1801 is connected from the bus A (1802).
Data to the bus B (1803) through When the bus A (1802) requests the transfer, the verified module 1801 and the bus B (1803) are not always in the same state. The module to be verified 1801 is executing transfer to the previous bus B (1803),
The bus B (1803) is performing transfer between other modules, or a data transfer request is coming from the bus B (1803) to the module to be verified 1801. The operation state monitoring device 1804 includes, for example, (1) an idle state,
(2) Receiving data from bus A (1802), (3)
Bus request to bus B (1803), (4) bus B (18
During the data transfer to the module 03, the bus A (1802) and the bus B (1803) are monitored as described above, and the internal state of the verified module 1801 that changes as described above is constantly checked. . Here, the moment when the bus A (1802) starts data transfer to the module to be verified (1801),
The condition affecting this operation, that is, the module 1 to be verified
The internal state 1812 of 801 is stored. Next, at the moment when the module to be verified 1801 receives data from the bus A (1802) and issues a bus request to the bus B (1803), the state to be affected, that is, the state 1813 of the bus B (1803) is stored. . Further, the module to be verified 1801
Ends the data transfer to bus B (1803),
Whether the transfer has been completed normally from the state of the bus B (1803),
It stores whether or not a retry request has occurred. As described above, when one data transfer is completed, the stored contents are output as a log file. As described above, a plurality of pieces of information are selectively collected at the time when a state change is caused, and a set of the pieces of information is used as one log, so that test coverage can be totaled for a detailed operation state.

Embodiment 10 FIG. Next, a tenth embodiment of the present invention will be described with reference to FIGS. The present embodiment is a simulator function that considers hazards, and relates to (14) in FIG. FIG. 19 shows the operation of the logical product (AND) of two inputs, and FIG. 20 shows the operation of the logical sum (OR). When there are three or more inputs, the other inputs can be handled in the same manner as described below by focusing on the two inputs and fixing the other inputs to logical values “1” or “0”. (1) 2
In the case of an input AND The operation in the case of a two-input AND will be described with reference to FIG. When it is detected that one of the two inputs has transitioned from the logical value "1" to "0" (step 1901), it is determined whether or not the other signal has transitioned from the logical value 0 to 1 during the time t1. Is determined (step 1902). During the time t1, the other signal has the logical value “0”.
If the state does not change from "1" to "1", the state is cleared. When the other signal transits from the logical value “0” to “1” during the time t1, the output of the two-input AND (signal Y) is changed to the time t2.
Is forcibly inverted only during the period (step 1903, 1
904). (2) In the case of 2-input OR based on FIG.
The operation in the case of a two-input OR will be described. When it is detected that one of the two input signals has transitioned from the logical value “0” to “1” (step 2005), the other signal transitions from the logical value “1” to “0” during time t1. It is determined whether or not the process has been performed (step 2006). If the other signal does not transition from the logical value “1” to “0” during the time t1,
Clear the state. If the other signal transitions from logical 1 to 0 during time t1, the output of two-input OR (signal Y) is forcibly inverted only at time t2 (step 200).
7, 2008). In the above embodiment, the times t1 and t2 are treated as fixed values.
You may make it programmable at the time of a hazard check. As described above, by adding a function on the designer side, a hazard can be detected without using a dedicated library.

Embodiment 11 FIG. An eleventh embodiment of the present invention will be described with reference to FIG. This embodiment shows a standard configuration method of a simulation model including an LSI to be verified and a verification model. In FIG. 21, reference numeral 2101 denotes a simulation model body;
2 is an input / output unit serving as an interface with the outside;
Is a reception / storage unit that processes a signal from the input / output unit 2102, and 2104 is a transmission operation unit that requests the input / output unit 2102 to perform processing. Reference numeral 2105 denotes a reception / storage unit 2103
Condition determination unit for determining the processing content of
Reference numeral 2107 denotes an activation condition determination unit for deciding the processing content of the transmission operation unit 2104, and 2107 denotes an instruction command unit for giving an external instruction to the response condition determination unit 2105 and the activation condition determination unit 2106.

Next, the operation will be described. The three elements of the simulation model 2101, that is, the input / output unit 2102, the reception / storage unit 2103, and the transmission operation unit 2104 are connected by a bus. Here, the input / output unit 210
2 and the reception / storage unit 2103, and the input / output unit 2102 and the transmission operation unit 2104 are connected by a simple and minimum necessary communication protocol. In the reception / storage unit 2103, the input / output unit 2
The information from the storage unit 102 is stored in a storage device, and the storage condition and the data conversion of the information can be controlled by the external command / command unit 2107 via the response condition determination unit 2105. The transmission operation unit 2104 includes the reception / storage unit 210
3 has a function of transferring the information from the input / output unit 3 to the input / output unit 2102, and performs the transfer request condition and the data conversion on the activation condition determination unit 210.
6, and can be controlled by an external command / command unit 2107. When a new simulation model is created, a mechanism for converting the input / output specifications of the model into the communication protocol defined above is created in the input / output unit 2102, and the response conditions necessary for reception and transmission are determined by the response condition determination unit 2105. It is given as an instruction code to the activation condition determination unit 2106. As described above, work efficiency can be improved as compared with the case where a simulation model is newly created.

[0048]

Since the present invention is constructed as described above, it has the following effects.

Since the test pattern is generated based on the probability setting file that defines the event occurrence probability in the address space, a high-quality test pattern is generated without any omission and maintaining test coverage at a constant level. be able to.

According to the progress of the test pattern generation,
Since the pattern occurrence frequency in the probability setting file is dynamically changed, there is an effect that a test pattern reflecting the progress of the verification can be efficiently generated.

Since the parameters necessary for generating the test pattern are divided into a plurality of groups and the parameters are changed independently for each group, an effect that a test pattern with a fine grain can be efficiently generated. is there.

Since a plurality of test pattern commands prepared in advance are selected based on the result of monitoring the simulation operation, efficient verification reflecting the operation result can be performed.

Since the verification is performed by forcibly generating a race condition based on the monitoring result of the simulation operation, efficient verification reflecting the intermittent operation can be performed.

When a specific transaction is detected, the application timing of the test pattern to be applied to the LSI to be verified is variably controlled, so that the verification can be performed on the basis of the timing without recreating the test pattern. Becomes

At the time of executing the simulation, the bus status is output to a log file for each of a plurality of buses connected to the module to be verified, and the validity of the process for crossing buses is checked based on the log contents by the inter-bus transaction analysis tool. As a result, there is an effect that accurate simulation can be realized even for a wide range of systems configured across the buses.

The state of the bus connected to the module to be verified is output to a log file during the execution of the simulation, and the coverage analysis tool counts the race conditions while referring to the log contents, so that the verification based on the coverage evaluation is performed. There is an effect that work can be performed.

Since the internal state of the module to be verified and the input / output state of the bus are monitored and stored in the log file by providing the operation state monitor, a detailed coverage evaluation can be performed for a detailed operation state. is there.

The input signal of the combination gate is monitored during the simulation in consideration of the delay time, and when the hazard generation condition is satisfied, a narrow pulse signal is generated in the output signal of the gate for a certain period of time. The presence or absence of a hazard can be confirmed without using a library.

Since the internal structure of the verification model connected to the module to be verified is unified, there is an effect that the creation of the simulation model is simplified.

[Brief description of the drawings]

FIG. 1 is a diagram showing an execution environment for logic verification according to the present invention.

FIG. 2 is a view showing contents of a probability setting file given to a pattern generator according to the first embodiment of the present invention.

FIG. 3 is a view showing a flow of generating a test pattern by a pattern generator according to the first embodiment of the present invention.

FIG. 4 is a view showing a test pattern generated by a pattern generator according to the first embodiment of the present invention.

FIG. 5 is an explanatory diagram showing how a pattern is generated based on a probability given in a second embodiment of the present invention.

FIG. 6 is a flowchart showing how a test pattern is generated by grouping parameters in the third embodiment of the present invention.

FIG. 7 is a diagram showing test pattern selection by communication between verification models according to a fourth embodiment of the present invention.

FIG. 8 is a diagram showing a command file given to a verification model and a timing of selecting a test pattern according to a fourth embodiment of the present invention.

FIG. 9 is a diagram showing designation of application of a specific pattern by communication between verification models according to the fifth embodiment of the present invention.

FIG. 10 is a diagram showing an example of a conflict list according to the fifth embodiment of the present invention.

FIG. 11 is a diagram illustrating adjustment of test pattern application timing by a monitor module according to a sixth embodiment of the present invention.

FIG. 12 is a diagram showing a flow of an automatic check of a simulation result in a seventh embodiment of the present invention.

FIG. 13 is a diagram showing an example of a simulation log for automatically checking a simulation result according to the seventh embodiment of the present invention.

FIG. 14 is a view showing an automatic check result of a simulation result in the seventh embodiment of the present invention.

FIG. 15 is a diagram showing a flow of operation of a validity check tool according to a seventh embodiment of the present invention.

FIG. 16 is a view showing a transaction trace flow of a validity check tool according to the seventh embodiment of the present invention.

FIG. 17 is a diagram illustrating a flow of counting race conditions from a simulation log according to the eighth embodiment of the present invention.

FIG. 18 is a view for explaining a log collecting method according to a simulation situation in the ninth embodiment of the present invention.

FIG. 19 is a diagram showing a pulse generation flow of a hazard checker for an AND gate according to the tenth embodiment of the present invention.

FIG. 20 is a diagram showing a pulse generation flow of a hazard checker for an OR gate according to the tenth embodiment of the present invention.

FIG. 21 is a diagram showing a shared verification model structure according to an eleventh embodiment of the present invention.

FIG. 22 is a diagram showing a simulation environment based on a conventional logic verification method.

FIG. 23 is a diagram illustrating a logic simulation using a conventional technique.

[Explanation of symbols]

11 probability setting file, 12 pattern generator, 701, 702 command file, 704 flag, 705, 803, 901 monitor module, 80
4 Competition list, 1802, 1803 bus, 1804
Operation state monitor, 2102 input / output unit, 2103 reception storage unit, 2104 transmission operation unit.

Claims (11)

[Claims] An LSI for verifying an internal circuit of an LSI connected via a verification model by a control signal from the outside
In the logic verification system, the access frequency information defining the event occurrence probability of the access target constituting the address space, the probability setting file storing the transaction occurrence frequency information defining the type and appearance frequency of the transaction for the access target, By providing a test pattern generating means for automatically randomly generating an input signal pattern based on the information of the probability setting file, by supplying an output result of the test pattern generating means to a verification model and performing a simulation, LS characterized by improving the efficiency of creation
Automatic logic verification method for I. 2. The test pattern generating means according to claim 1, wherein said test pattern generating means dynamically changes an event occurrence probability of an access target constituting an address space in accordance with a predetermined rule based on an occurrence situation. LSI automatic logic verification method. 3. The test pattern generating means divides parameters required for test pattern generation into several groups, and generates test patterns by independently changing parameters belonging to the groups at predetermined time intervals. The L according to claim 1, wherein
Automatic logic verification method for SI. 4. An LSI for verifying an internal circuit of an LSI connected via a verification model by an external control signal.
In the logic verification system of FIG.
Plural sets of command files storing test patterns to be given to the SI, monitoring means for monitoring transactions on a bus to which the LSI to be verified and the verification model are connected, and the plural sets of command files based on monitoring results by the monitoring means An automatic logic verification method for an LSI, comprising: a command file switching means for selecting a test pattern; thereby performing a simulation while selecting a test pattern according to a verification situation. 5. An LSI for verifying an internal circuit of an LSI connected via a verification model by an external control signal.
A command file storing a test pattern to be given to the LSI to be verified, monitoring means for monitoring a transaction on a bus connecting the LSI to be verified and the verification model, and a conflict of operations with the LSI to be verified. A conflict list file storing a pattern for generating a status, a command register in which a conflict status generation command in the conflict list file is set based on the result of monitoring by the monitor means, and a command for selecting one of the command file and the command register LS by performing a simulation while generating a race condition according to a verification situation by providing a file switching means.
Automatic logic verification method for I. 6. An LSI for verifying an internal circuit of an LSI connected via a verification model by an external control signal.
A logic verification system comprising: a command file storing a test pattern to be supplied to a verification target LSI; and a monitor for monitoring a transaction on a bus connected to the verification target LSI and the verification model. Wherein the application timing of a test pattern applied to a verification target LSI is variably controlled when the above transaction is detected. 7. An LSI for verifying an internal circuit of an LSI connected via a verification model by an external control signal.
In the logic verification system of (1), a command file storing a test pattern given to the LSI to be verified, a log file storing a bus simulation result for each bus to which the LSI to be verified and the verification model are connected, An automatic logic verification method for an LSI, characterized in that an inter-bus verification tool for analyzing and tracing transactions across buses is provided to check the validity of processing across buses. 8. An LSI for verifying an internal circuit of an LSI connected via a verification model by an external control signal.
In the logic verification system of (1), a command file storing a test pattern given to the LSI to be verified, a log file storing a bus simulation result for each bus to which the LSI to be verified and the verification model are connected, By providing a bus-to-bus verification tool that analyzes and traces transactions across buses, and a coverage tallying tool that totals coverage for bus-to-bus transactions, coverage evaluation is performed based on transaction competition between buses. An automatic logic verification method for an LSI characterized by the following. 9. An LSI for verifying an internal circuit of an LSI connected via a verification model by an external control signal.
In the logic verification system of the above, a command file storing a test pattern given to the LSI to be verified, and an internal state of the LSI to be verified connected to a bus connecting the LSI to be verified and the verification models located at both ends of the LSI to be verified. An automatic logic verification method for an LSI, comprising: an operation state monitor for monitoring; and a log file for storing a result of monitoring by the operation state monitor, wherein a coverage evaluation is performed based on a simulation result. 10. The logic verification method according to claim 1, further comprising a hazard detection tool that generates a narrow pulse in an output signal of the combinational circuit element when a hazard generation condition is satisfied in the input signal of the combinational circuit element. 10. The automatic logic verification method for an LSI according to claim 1, wherein 11. The verification model includes: an input / output unit that interfaces with an external bus; a reception storage unit that stores input information from the input / output unit based on a response condition input as an external command; A transmission operation unit that transfers input information from the reception storage unit to the input / output unit based on a start condition input as an external command, wherein the input / output unit, the reception storage unit, and the transmission operation unit use a simple communication protocol. An automatic logic verification method for an LSI, characterized in that the internal structure of the verification model is unified by connecting with each other.