JP2007108995A - Test condition sufficiency measuring method in lsi logical function verification - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a test condition sufficiency measuring method in LSI logical function verification for efficiently measuring test condition sufficiency for confirming the positive generation of test conditions during execution of simulation, without being influenced by a bug correction and an internal implementation specification change in LSI logical function verification. <P>SOLUTION: When preparing a pattern 4, a test condition sign 5 describing test conditions which are test contents, without including design logic internal information 7 derived from a design logic 6 is prepared as verification data (checker) for verifying whether intended test conditions are established, and the design logic internal information 7 is derived from the design logic 6 and prepared. Simulation of the design logic internal information 7 is carried out by a simulation means 8 using the test condition symbol 5 to confirm the positive generation of the test contents to be carried out by the pattern 4, during the execution of simulation. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a test condition satisfaction measuring method in verification of logic function of LSI (Large Scale Integrated Circuit).

  Conventionally, functional verification of design logic at the logic design stage of an LSI has been performed using a simulation environment built on a computer. In other words, a test bench and pattern are prepared for verification in advance, and the design logic to be verified is simulated on the simulator using the test bench, and a pass / fail decision is made by confirming that the simulation result is correct. (For example, refer to Patent Document 1).

  By the way, in this functional verification, a verification item is defined based on a specification as a reference when designing, and the test bench and the pattern are used as means for realizing the verification contents written in the verification item. create.

  The test bench and pattern are basically created manually by the LSI designer. Therefore, the created test bench and pattern may be inappropriate. In this case, there is always a possibility that the test content intended by the verification item does not occur when the simulation is performed. Unfortunately, just because the intended test content has not occurred does not mean that the simulation results will not be as expected. In other words, because the test bench and pattern were inappropriate, even if the test content intended by the verification item did not occur at the time of the simulation, the simulation result worked as expected and the pass / fail judgment passed. It may be judged.

  As a solution to this problem, a method using a checker is employed. The checker is a code (verification data) written in HDL (Hardware Description Language) that checks whether a certain intended test condition is satisfied.

  In other words, when the verification items are defined and the verification contents are determined, it is determined what test conditions are desired to be generated. Therefore, a code written in HDL (checker) for checking whether or not the intended test conditions have occurred. ) Are created separately from the test bench and pattern and input to the simulation environment. The checker monitors the internal node of the logic to be verified during the simulation, and if it is observed that the intended test condition has occurred, the checker notifies the verification operator by a screen output or the like. .

  The verification operator checks whether the obtained result is consistent with the expected value and whether the intended test condition is generated by the checker as the pass / fail judgment of the simulation result. If the obtained result matches the expected value and it can be confirmed by the checker that the intended test condition has occurred, the test is judged to be acceptable.

  If the intended test conditions do not occur, it means that the test you want to perform is not possible due to inappropriate test bench or pattern. In this case, the comparison of the obtained result with the expected value is meaningless. Therefore, regardless of the result of comparison with the expected value, the test bench or pattern is corrected appropriately, and simulation is performed again. It is necessary to perform correction and simulation until it can be confirmed that the test condition is generated.

  In addition, if the intended test conditions have occurred but the simulation results do not match the expected values, the test bench and pattern have been properly tested, but failed due to a failure in the verification target logic. Means that. In this case, the logic to be verified is corrected and the simulation is performed again until it can be confirmed that the intended test condition by the checker has occurred, and the simulation result can be confirmed to match the expected value. This will be repeated.

Japanese Patent Laid-Open No. 3-62172 (logic verification sufficiency evaluation method)

  However, in the conventional method, the creation of a checker for checking that the intended test condition has occurred is described using the internal node information of the verification target logic as it is, and therefore has the following problems. .

  First, since the checker can be created at the stage after the coding of the logic to be verified is completed, the test conditions to be checked by the checker are determined at the stage where the verification items are defined. The checker cannot be created because the verification target logic has not been coded. In other words, conventionally, there is a possibility that a time lag occurs until the checker is created, which is not efficient.

  Second, as verification progresses, logic correction occurs due to bug discovery of the verification target logic. In this case, conventionally, since the checker directly describes the internal node information of the logic to be verified, there is a possibility that many checkers need to be corrected by this logic correction, which is not efficient. Also, the checker is not portable.

  Thirdly, there is a case where the design of the internal node is changed without changing the external specification for the logic that has already been developed in the past. For example, a development that improves performance while having the same function. In such a case, since the logic is redesigned, the verification is performed again. However, the function is functionally equivalent to the already developed logic, so the test used in the functional verification of the developed logic. It is expected that benches, patterns, and checkers can be used as they are, but many of the checkers are likely to require modification. Similarly, the checker is not portable.

  The present invention has been made in view of the above. In the logic function verification of an LSI, measurement of test condition satisfaction for confirming that the test condition is surely generated during simulation execution is performed by bug correction or internal implementation. It is an object of the present invention to obtain a test condition satisfaction measurement method in LSI logical function verification that can be performed efficiently without being affected by the change in the specification of the input.

  In order to achieve the above-mentioned object, the test condition satisfaction measurement method for LSI logic function verification according to the present invention uses a pattern created for LSI logic function verification in a simulation environment constructed on a computer. As verification data for verifying whether or not the intended test conditions are met in the LSI logic function verification, which performs a pass / fail judgment by executing a simulation of the design logic to be verified and confirming whether the operation result is correct , Creating a test condition symbol that describes the test conditions that are the test contents without including the design logic internal information derived from the design logic at the time of creating the pattern, and the design logic internal information from the design logic. Deriving and preparing, inputting the test condition symbol and the design logic internal information into the simulation environment Performing a simulation of the design logic internal information using a test condition symbol, and performing a test condition satisfaction measurement to confirm that the test content desired to be performed by the pattern is surely generated during the execution of the simulation. It is characterized by.

  According to the present invention, the verification data (checker) for confirming that the test condition is generated during the execution of the simulation is not described directly in the internal node of the logic to be verified, but is used when creating the pattern. Describe and prepare the internal node information of the verification target logic as design logic internal information separately during logic design, and perform logic simulation using the checker described in this alias and the design logic internal information when performing logic simulation Then, measure the satisfaction of the test conditions. According to this, since the checker can be created before the logical design is completed, even if the internal node information is changed due to bug correction or internal implementation specification change, it is necessary to change the checker. It is only design logic internal information, and it is not necessary to modify the checker. That is, the portability of the checker is improved.

  According to the present invention, since the portability of verification data (checker) is improved, measurement of satisfaction of test conditions can be performed in parallel with LSI logical function verification without being affected by bug correction or internal implementation specification change. The effect that it can perform efficiently is produced.

  Exemplary embodiments of a test condition satisfaction measurement method in logic function verification of an LSI according to the present invention will be described below in detail with reference to the drawings.

  FIG. 1 is a flowchart for explaining logic function verification of an LSI in which a test condition satisfaction measuring method according to an embodiment of the present invention is implemented. As shown in FIG. 1, in the logic function verification of an LSI, a verification item 2 is first defined and a design logic 6 is designed based on a specification 1 which is a reference for designing.

  From this verification item 2, a test bench 3 and a pattern 4 for realizing the test contents intended by the verification item 2 are created, and in this embodiment, a test condition symbol 5 is created. . The test condition symbol 5 is a checker that describes the test contents intended by the verification item 2, that is, the check contents for checking that the test conditions are generated during the execution of the simulation. Also, design logic internal information 7 is defined from the design logic 6. The test bench 3, the pattern 4, the test condition symbol 5, the design logic 6 and the design logic internal information 7 thus created or defined are input to the simulation means 8.

  The simulation means 8 executes the simulation of the design logic 6 using the test bench 3 and the pattern 4, confirms whether or not the operation result is correct, and outputs a simulation result value 9 used to make a pass / fail judgment. In parallel, the simulation means 8 executes the simulation of the design logic internal information 7 using the test condition symbol 5, and the test condition described in the test condition symbol 5, that is, the test content to be performed according to the pattern is being simulated. The test condition generation result 10 used to perform the test condition satisfaction measurement for confirming that it has occurred is output.

  Here, the description of the test condition symbol 5 does not include the internal code information of the verification target logic (see FIG. 4). Therefore, the test condition symbol 5 can be described without waiting for completion of coding of the verification target logic, and is efficient. Further, the test condition symbol 5 does not need to be corrected in conjunction with the correction of the verification target logic, is efficient, and improves portability.

  Next, description examples of actual test condition symbols and design logic internal information will be described with reference to FIGS. FIG. 2 is a diagram showing an example of the specification 1 specification. FIG. 3 is a diagram illustrating an example of the verification item 2. FIG. 4 is a diagram illustrating an example of the test condition symbol 5. FIG. 5 is a diagram illustrating an example of the design logic 6. FIG. 6 is a diagram illustrating an example of the design logic internal information 7.

  As shown in FIG. 2, in the “specification”, the design logic is defined as having a so-called state machine. In FIG. 2, the design logic internally has two states S0 and S1, and the output value 0 from the design logic and the next internal state are determined by the current internal state and the externally input values l0 and l1. An example is shown.

  In FIG. 3, as an example of one verification item defined from the specification example shown in FIG. 2, “input l0 = and l1 = 1 is given in state S1, and the result is output 0 = 0 and state S0. Confirm things. ”Is shown.

  FIG. 4 is an example of test condition symbols described based on the specification example shown in FIG. 2 and the verification item example shown in FIG. In the test condition symbol, the state machine transition condition defined in the specification example and the test condition intended in the verification item example are specified as symbols. Importantly, as shown in FIG. 4, the test condition symbol is described using only the temporary name “State” of “State, I0, I1”, and the internal node name “ This means that “Status” is not described directly.

  FIG. 5 is a design logic example based on the specification example shown in FIG. FIG. 6 is an example of design logic internal information derived from the design logic example shown in FIG. In FIG. 6, the node name “Status” inside the design logic corresponding to the temporary name “State” described in the test condition symbol example is described. The node name “Status” inside the design logic is described when coding of the verification target logic is completed, or when correction is made after it is once completed.

  Next, FIGS. 7 and 8 are flowcharts for explaining a test condition satisfaction measuring method according to an embodiment of the present invention, which is performed in the logic function verification of the LSI shown in FIG. As shown in FIG. 7 and FIG. 8, in the test condition satisfaction measurement method according to this embodiment, it is checked that the intended test condition is generated during the simulation based on the test condition symbol and the design logic internal information. To be done.

  FIG. 7 shows a case where the simulation is performed after the test condition symbols are converted into HDL codes that can be input to the simulation means. In FIG. 7, the HDL code generation means 23 generates an HDL code 24 based on the test condition symbol 21 and the design logic internal information 22. The generated HDL code 24 is input to the simulation unit 27 together with the test bench 25 and the pattern 26. The HDL code 24 is a code having a function of checking that the test condition described in the test condition symbol 21 has occurred during the simulation. As a result, the simulation unit 27 checks whether or not the intended test condition has occurred during the execution of the simulation, and the test condition generation result 10 shown in FIG.

  FIG. 8 shows a case where the test condition symbols are directly input to the simulation means. In FIG. 8, the test condition symbol 31 and the design logic internal information 32, the test bench 25 and the pattern 26 are all input to the simulation means 27. Among them, the test condition symbol 31 and the design logic internal information 32 are input to the test condition symbol decoding means 36 which is an engine for decoding the meaning of the test condition symbol provided in the simulation means 27.

  The test condition symbol decoding means 36 acquires the node name inside the verification target to be observed during the simulation execution from the design logic internal information 32 and acquires the condition to be checked from the test condition symbol 31, thereby executing the simulation The nodes inside the verification target to be observed are observed, and it is checked whether or not those values satisfy the condition written in the test condition symbol 31. As a result, the simulation means 35 checks whether or not the intended test condition has occurred during the execution of the simulation, and the test condition generation result 10 shown in FIG.

  As described above, according to this embodiment, as a checker for checking that a test condition is generated during simulation execution, the test condition symbol having no internal node information of the verification target logic is described. Because the internal node information of the verification target logic is separately prepared as the design logic internal information at the time of logic design, it is possible to describe the test condition symbols when the verification items are defined regardless of when the design logic is coded It is. Even if the verification target logic is modified due to bug modifications or internal implementation specification changes, only the design logic internal information must be modified accordingly, and the test condition symbols need to be modified. In addition, the portability of the checker is improved. Therefore, it is possible to efficiently measure the satisfaction of the test condition in parallel with the logic function verification of the LSI without being affected by bug correction or internal implementation specification change.

  As described above, the test condition satisfaction measuring method in the logic function verification of the LSI according to the present invention satisfies the test condition for confirming that the test condition is surely generated during the simulation execution in the logic function verification of the LSI. This measurement is useful as a method for efficiently performing measurement without being affected by bug fixes or changes in internal implementation specifications.

It is a flowchart explaining the logic function verification of LSI with which the test condition satisfaction measuring method by one embodiment of this invention is implemented. It is a figure which shows the example of 1 specification of the specification shown in FIG. It is a figure which shows an example of the verification item shown in FIG. It is a figure which shows an example of the test condition symbol shown in FIG. It is a figure which shows an example of the design logic shown in FIG. It is a figure which shows an example of the design logic internal information shown in FIG. 6 is a flowchart for explaining a test condition satisfaction measuring method (part 1) according to an embodiment of the present invention, which is performed in the logic function verification of the LSI shown in FIG. 6 is a flowchart for explaining a test condition satisfaction measurement method (part 2) according to an embodiment of the present invention, which is performed in the logic function verification of the LSI shown in FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Specification document 2 Verification item 3, 25, 33 Test bench 4, 26, 34 Pattern 5, 21, 31 Test condition symbol 6 Design logic 7, 22, 32 Design logic internal information 8, 27, 35 Simulation means 9 Simulation result value 10 Test condition generation result 23 HDL code generation means 24 HDL code

Claims (3)

In the simulation environment built on the computer, the design logic that is the verification target is simulated using the pattern created for verifying the logic function of the LSI, and it is confirmed whether the operation result is correct or not. In the logic function verification of the LSI that performs the determination,
As verification data for verifying whether or not the intended test condition is satisfied, a test condition symbol describing the test condition that is the test content without including the design logic internal information derived from the design logic is created at the time of creating the pattern Process,
Deriving and preparing the design logic internal information from the design logic;
The test condition symbol and the design logic internal information are input to the simulation environment, and the design logic internal information is simulated using the test condition symbol, and the test content desired to be performed according to the pattern is ensured during the simulation. A test condition satisfaction measurement method in the logic function verification of LSI, comprising the step of performing a test condition satisfaction measurement for confirming occurrence of the test condition. The process of performing test condition satisfaction measurement is as follows:
Converting the test condition symbol into an HDL description that can be input to a simulator based on the design logic internal information;
Inputting the obtained code according to the HDL description into the simulation environment and performing the confirmation;
The test condition satisfaction measuring method in the logical function verification of the LSI according to claim 1, wherein The process of performing test condition satisfaction measurement is as follows:
Providing an engine for decoding the meaning of the test condition symbol in the simulation environment;
The engine receives the test condition symbol and the design logic internal information, observes a node to be observed inside the design logic to be verified during simulation, and collates it with the test condition symbol And performing the confirmation,
The test condition satisfaction measuring method in the logical function verification of the LSI according to claim 1, wherein

Images