JP5799589B2 - Verification method and verification program - Google Patents

Description

  The present invention relates to a verification method and a verification program used for circuit verification.

  In the development of an integrated circuit such as LSI (Large Scale Integration), the logic of a circuit is expressed using a logical expression called a register transfer level (RTL) based on a design specification. In order to verify the function and operation of the circuit designed by the RTL, a simulation using a computer is performed.

  At the time of verification, a scenario describing the instruction procedure for the circuit to be verified is incorporated in the test bench, and the verification target is simulated using the test bench. Then, the output from the circuit to be verified is checked for an error such as a specification violation or a standard violation. Scenarios and test benches used for circuit verification are developed prior to circuit verification or in parallel with circuit verification.

  There is also known a technique for designing firmware for controlling a circuit, operating the circuit using the firmware, and confirming whether the firmware correctly controls the circuit.

  In addition, a method for confirming verification items actually tested by simulation when a circuit is verified by a random test using a scenario including randomly arranged test sequences is also known.

JP 2004-86838 A

  By the way, when the verification target is verified using the test bench incorporating the scenario, the detected error is caused by the verification target, and the test bench, for example, is included in the test bench development stage. There can be a scenario. When the scenario is the cause, for example, the command location of the scenario causing the error is specified using the waveform data at the time of simulation. However, because there is a time difference between the timing of the error and the instruction timing of the scenario that caused the error, the task of identifying the cause of the scenario that caused the error is complicated, and it takes a long time to analyze the cause of the error. May end up.

  On the other hand, at the development stage of the scenario used for verification as described above, based on the design specifications to be verified, a scenario is created in consideration of restrictions that restrict instruction execution under certain conditions, and a test that incorporates it Simulation is performed using a bench. The scenario operation is verified by visually checking the waveform data during the simulation. However, visual confirmation of such waveform data may take a long time. Furthermore, when the number of input commands to be verified based on the scenario becomes enormous, it is difficult to verify all of them by visual confirmation of the waveform data. Instructions that have not been verified in this way, and instructions that do not properly consider the restrictions, also contribute to the error caused by the above scenario.

  Here, a scenario is taken as an example, but in the development stage of the firmware that controls the circuit as well, at the development stage, the circuit (verification target) is operated using the created firmware, and if an error is detected, the waveform data Visual confirmation is performed. At this time, it takes time to determine whether the error is caused by the circuit to be verified or by the firmware that controls the error. This is because there is a time difference between the occurrence timing of the error and the instruction timing of the firmware that caused the error, and the analysis using the waveform data becomes complicated.

According to an aspect of the present invention, there is provided a verification method executed by a computer, wherein a list including restriction information for restricting instruction execution of a predetermined description portion of a program in which an instruction for a circuit to be verified is described is used. Generating a checker indicating the contents , incorporating the generated checker into the program so that the checker is called when the instruction of the predetermined description portion is executed, and using the program in which the checker is embedded, the verification target When the instruction of the predetermined description portion is executed, the checker is called to check whether or not the instruction of the predetermined description portion includes the restriction information, and result information indicating the result of the check is generated. A verification method is provided.

  In addition, according to one aspect of the present invention, a verification program for causing a computer to execute processing for realizing such a verification method is provided.

  According to the disclosed technology, it is possible to check a program such as a scenario or firmware using a checker when the program is executed, and verify the result of the check. This makes it possible to eliminate the need for waveform data acquisition and visual confirmation of the acquired waveform data when verifying the program or verifying the program. Programs such as appropriate scenarios and firmware can be efficiently developed, and verification work using the programs can be efficiently performed.

It is a figure which shows an example of a logic simulation environment. It is a figure which shows an example of a verification work flow. It is FIG. (1) which shows an example of a test bench development work flow. It is FIG. (1) which shows the structural example of the test bench in a test bench development stage. It is a figure which shows the example of an error occurrence of a scenario factor. It is FIG. (1) which shows an example of a scenario development work flow. It is FIG. (1) which shows the structural example of the test bench in a scenario development stage. It is FIG. (2) which shows an example of a scenario development work flow. It is FIG. (2) which shows the example of a structure of the test bench in a scenario development stage. It is FIG. (2) which shows an example of a test bench development work flow. It is FIG. (2) which shows the structural example of the test bench in a test bench development stage. It is a figure which shows an example of the format of a setting restriction | limiting list | wrist. It is a figure which shows the relationship between the verification object and scenario which concern on 1st Example. It is a figure which shows an example of the setting limitation matter which concerns on 1st Example. It is a figure which shows an example of the description part of the scenario which concerns on 1st Example. FIG. 6 is a diagram (part 1) illustrating a method for creating a setting restriction list. FIG. 6 is a diagram (part 2) illustrating a method of creating a setting restriction list. FIG. 11 is a third diagram illustrating a method for creating a setting restriction list. FIG. 6 is a diagram (part 4) illustrating a method of creating a setting restriction list. It is a figure which shows the conversion format from the setting restriction | limiting list | wrist by a scenario checker production | generation script to a scenario checker. It is a figure which shows the example of conversion from the setting restriction | limiting list | wrist by the scenario checker production | generation script which concerns on 1st Example to a scenario checker. It is a figure which shows the example of incorporating the scenario checker into the scenario by the scenario checker incorporation script according to the first embodiment. It is an output example of the log file which concerns on 1st Example. It is a figure which shows an example of the setting limitation matter which concerns on 2nd Example. It is a figure which shows an example of the description part of the scenario which concerns on 2nd Example. It is a figure which shows an example of the setting restriction | limiting list | wrist which concerns on 2nd Example. It is a figure which shows an example of the scenario checker concerning 2nd Example.

In LSI development, the function and operation of a logic circuit designed in RTL based on design specifications are verified by performing a logic simulation using a computer.
FIG. 1 shows an example of a logic simulation environment.

  The logic simulation environment is constructed using the computer 100. The entire computer 100 is controlled by a CPU (Central Processing Unit) 101. A ROM (Read Only Memory) 102 and a RAM (Random Access Memory) 103 are connected to the CPU 101 via a bus 110. The ROM 102 stores a program such as firmware for controlling a logic circuit that performs simulation. The RAM 103 temporarily stores at least part of an OS (Operating System) program and application programs to be executed by the CPU 101. The RAM 103 stores various data necessary for processing by the CPU 101.

  A plurality of peripheral devices are connected to the bus 110. Peripheral devices connected to the bus 110 include a hard disk drive (HDD) 104, a communication interface 105, a keyboard 106, a mouse 107, and the like.

  The HDD 104 magnetically writes and reads data to and from a hard disk (HD) 104a. The HDD 104 stores an OS program, application programs, and various data. The communication interface 105 is connected to a network, and transmits / receives data to / from other computers or communication devices via the network. Signals sent from the keyboard 106 and mouse 107 are sent to the CPU 101 via the bus 110. The mouse 107 is an example of a pointing device, and other pointing devices such as a touch panel, a tablet, a touch pad, and a trackball can be used.

  Other peripheral devices 108 may be further connected to the bus 110. Examples of other peripheral devices 108 include a graphic processing device and an optical drive device. In this case, a monitor (such as a display device using a CRT (Cathode Ray Tube) or a liquid crystal display device) is connected to the graphic processing device, and the graphic processing device displays an image on the screen of the monitor according to a command from the CPU 101. Let Further, the optical drive device uses an optical disk (DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc Read Only Memory), CD-R (Recordable) / RW (ReWritable)) using a laser beam or the like. Etc.) is recorded.

  For example, the HD 104a of the computer 100 having such a configuration stores the design data 120 of the RTL logic circuit (verification target), the logic simulator 130, the test bench 140 in which the scenario describing the instruction for the RTL logic circuit is incorporated, and the like. Is done. The computer 100 drives the HDD 104 and executes logic simulation of the logic circuit to be verified using these pieces of information stored in the HD 104a. Based on the result of this logic simulation, it is verified whether the function and operation of the logic circuit are appropriate.

Next, an example of verification work using logic simulation will be described.
FIG. 2 is a diagram illustrating an example of a verification work flow.
In the verification operation for performing the logic simulation, a verification specification is first created based on the specification (design specification) (S10) of the logic circuit to be verified (S11, S12). Then, the configuration of the test bench is examined from the created verification specification, and the test bench specification is created (S13, S14). Based on this test bench specification, the test bench is developed (S15, S16). Logic simulation (verification work) is performed using the developed test bench, and the result (verification result) is acquired (S17, S18). From the verification result obtained by the logic simulation, the developer or the computer 100 determines whether or not the logic circuit to be verified operates properly.

Further, the test bench development (S15, S16) will be described.
FIG. 3 is a diagram showing an example of a test bench development work flow.
In the test bench development work flow of FIG. 3, the developer further sets specifications for each part (model), which is a component of the test bench, from the test bench specification (S20), and performs development for each part (S21 to S21). S23). In the example of FIG. 3, checker development (S21), transactor development (S22), and scenario development (S23) are performed. Then, a unit test is performed on each component, and it is confirmed that there is no problem, and each component is acquired (S24). By assembling the parts thus obtained together with the logic circuit to be verified (S25), a test bench (the entire simulation environment including the logic circuit) is obtained (S26).

FIG. 4 shows a configuration example of the test bench at the test bench development stage.
The test bench 200 of FIG. 4 includes a model 210 including a scenario 211 and a transactor 212, a protocol checker 220, and an expected value comparison checker 230 as test parts (test bench development environment).

  The scenario 211 describes a procedure of instructions for the logic circuit of the verification target 300 designed by RTL. The scenario 211 gives a command for controlling (operating) the verification target 300 to the transactor 212 in accordance with the specification of the transactor 212.

  The transactor 212 controls a signal according to the interface specification with the verification target 300 in accordance with the command from the scenario 211, and transmits information on the command from the scenario 211 to the verification target 300. The verification target 300 receives information from the transactor 212 and executes the operation of the command indicated by the information. Further, the transactor 212 receives information transmitted from the verification target 300 and notifies the scenario 211 of the received information.

  The protocol checker 220 refers to a related input / output terminal for an interface in which the protocol exists, and performs a check specialized for the protocol. If the protocol checker 220 detects a protocol violation, it reports an error.

  The expected value comparison checker 230 refers to the input / output terminals of the verification target 300 and checks whether the output terminals (data value, signal control, etc.) of the verification target 300 are operating according to the design specifications. The expected value comparison checker 230 reports an error when a design specification violation is detected.

  In the test bench development work flow of FIG. 3, after obtaining the test bench having such a configuration (S26), the logic circuit to be verified is operated on the test bench using a computer, and the final operation check test ( (Whole simulation) is performed (S27). The result of this entire simulation (check result by the checker incorporated in the test bench) is output as a log file (S28). From this log file information, the developer determines whether an error has occurred (S29). If an error has occurred, waveform data is required to identify the cause of the error. In order to acquire this waveform data, re-simulation using a computer is performed (S30, S31). The developer visually confirms the acquired waveform data, and identifies the cause of the error (S32). Error factors are first divided into two cases: the case of being on the logic circuit side to be verified and the case of being on the test bench side (S33).

  When the error factor is on the logic circuit to be verified (S33), the developer corrects the logic circuit designed in the RTL (S34), and creates a corrected logic circuit (S35). A test bench is acquired again together with the corrected logic circuit (S25, S26). Then, the work after the entire simulation (S27) is performed using the re-acquired test bench.

  On the other hand, when the error factor is on the test bench side (S33), the error factor is present in at least one of the parts such as a scenario, a transactor, and a checker in the test bench (S36). For example, in the case of the test bench 200 in FIG. 4, an error factor exists in any of the scenario 211, the transactor 212, the protocol checker 220, and the expected value comparison checker 230.

  If there is an error factor (scenario error) in the scenario (S36), the process returns to scenario development (S23) to correct the error factor of the scenario. If there is an error factor (transactor miss) in the transactor (S36), the process returns to transactor development (S22) to correct the error factor of the transactor. If there is an error factor (checker miss) in the checker (S36), the process returns to the checker development (S21) to correct the checker error factor. Then, as described above, the unit test is performed to acquire each component (S24), the test bench is acquired (S25, S26), and the work after the entire simulation (S27) is performed.

  If no error is detected in the overall simulation (S29) and the overall simulation (test) is performed under different conditions (S37), the simulation conditions are changed and the test is performed (S27). If all tests are completed without error (S37), the test bench development work is completed. The logic simulation (verification work) shown in FIG. 2 is performed using the developed test bench (S17, S18).

The test bench can be developed with the work flow as shown in FIG. 3, for example, but has the following problems.
For example, in the work flow of FIG. 3 described above, if an error is detected by the checker (S27, S28) and the checker detects an error (S29), waveform data is acquired by re-simulation (S30, S31), and the visual check is performed. Performed (S32).

  When a proper developed test bench is used, if the checker detects an error, it can be determined that there is a problem in the logic circuit to be verified. However, at the test bench development stage, it is not determined whether the checker itself is appropriate, and there remains a problem with its quality, so the detected error may be due to a mistake in the checker itself. There is. Furthermore, in the test bench development stage, even if there is a problem in the scenario, it is detected as an error by the checker. Thus, when the cause of the error is in the scenario, it takes time to specify the cause. The reason will be described with reference to FIG.

FIG. 5 is a diagram showing an example of scenario factor error occurrence. In FIG. 5, (A) is an example of a test bench, and (B) and (C) are examples of waveform data.
First, the checker detects an error in response to an operation in which the output terminal to be verified violates the specification or the standard, and the output operation to be verified is determined by the input pattern. That is, if there is an error in the input pattern (scenario command) to the verification target, the checker detects an error.

  Now, according to the scenario 211a of one model 210a in the test bench 200 of FIG. 5A, an input pattern (output signals 1 and 2) as shown in FIG. 5B is output to the verification target 300 via the transactor 212a. Shall be. Based on the input pattern, an output (output signals 1 and 2) as shown in FIG. 5C is obtained from the verification target 300, and the output is sent to the other model 210b (scenario 211b, transactor 212b). Shall be sent. It is assumed that the B protocol checker 220b detects an error in the X section with respect to the output from the verification target 300. That is, in this example, the B protocol checker 220b detects an error in which both the output signals 1 and 2 become high (H) level at the rising edge of the clock in the X portion of the output. The error detected by the B protocol checker 220b is caused by an input pattern error in the Y part in the input pattern from the scenario 211a.

  In this way, when the error factor detected by the B protocol checker 220b for the output of the verification target 300 is in the input pattern for the verification target 300, the error detection point (X portion) and the input pattern (Y Part)), a time difference T occurs. If there is an error factor in the scenario 211a and it is attempted to identify the factor from the waveform data, the analysis may be complicated due to the time difference T, and the analysis may take a long time.

  It is also conceivable to develop a checker that checks for violations of input pattern constraints on the verification target 300 for such a problem. For example, by implementing an assertion for checking the input pattern to the verification target 300 in the A protocol checker 220a, the problem can be improved. However, the checker development man-hours increase and the check cannot be performed unless the checker development is completed.

The scenario is developed by the following work flow, for example.
FIG. 6 is a diagram illustrating an example of a scenario development work flow.
In the scenario development work flow of FIG. 6, the developer examines the specification of the scenario based on the specification (S40) used for the design to be verified (S41), the setting procedure (S42) for setting the scenario, the scenario The restriction item (setting restriction item) (S43) is extracted. Based on the extracted information, the developer creates a scenario (S44, S45), and acquires a test bench incorporating the scenario (S46, S47). Then, in order to confirm the operation of the acquired test bench, a simulation is performed using a computer (S48), and the result (waveform data) is acquired (S49).

FIG. 7 shows a configuration example of the test bench at the scenario development stage.
The test bench 200A used for the scenario development stage simulation (S48) includes a verification target 300 and a model 210 including a scenario 211 and a transactor 212 for operating the verification target 300 (scenario development environment).

  The scenario development environment does not have a function for checking input / output to be verified. Therefore, during simulation (S48), waveform data is acquired (S49), and the waveform data is visually confirmed (S50) to confirm the scenario operation. As a result of the operation check, if a problem is found in the scenario, a corrected scenario is created (S44, S45), a test bench incorporating the same is acquired (S46, S47), and simulation is performed again (S48, S47). S49), the waveform data is confirmed (S50). When there is no problem in the scenario in the operation check (S50) and simulation (test) is performed under different conditions (S51), the simulation conditions are changed and the test is performed (S48). If all tests are completed without error (S51), the scenario development work is completed.

The scenario can be developed with the work flow as shown in FIG. 6, for example, but has the following problems.
For example, in the work flow of FIG. 6, the scenario operation is confirmed by visual confirmation of the waveform data (S49) acquired during the simulation (S48) (S50).

  In the scenario, the input pattern to be generated varies depending on the state to be verified and the reception state thereof. Therefore, there are a large number of input patterns in consideration of combinations. For all these combinations, it is difficult to visually check the waveform data and check the operation of the scenario. Therefore, there is a case where only the operation check for each function is performed without considering the combination.

  Even if you confirm the operation of the scenario in this way and complete its development work, the operation check of all input patterns is not completed, so the scenario generates an input pattern that violates the setting restrictions. In some cases, it may affect subsequent processes. For example, in the case of the overall simulation (S27, S28) described in the test bench development work flow of FIG. 3 and the re-simulation (S29 to S31) based on the result, the above scenario factor problem occurs. There is.

  As described above, in the development of a scenario used for verification of a logic circuit to be verified (and development of a test bench incorporating a scenario), an appropriate and stable quality scenario can be acquired at an early stage of verification. difficult. In order to acquire an appropriate scenario, it is necessary to acquire the scenario data under development and the waveform data when the test bench is actually operated, and the developer must visually check it. I need it.

  In the above description, the scenario (and the test bench incorporating the scenario) is taken as an example. However, the same may occur in the development of firmware that controls a logic circuit.

  That is, at the firmware development stage, the logic circuit is operated using the created firmware, and when an error is detected, the waveform data is visually confirmed. At this time, it takes time to determine whether the error factor is on the logic circuit side or the firmware side. This is because, as described with reference to FIG. 5, there is a time difference between the error occurrence timing and the firmware instruction timing that caused the error, which complicates the analysis using the waveform data. Even in the case of firmware for controlling a logic circuit, it takes time to check its operation, and it is difficult to obtain firmware with appropriate and stable quality at an early stage of logic circuit verification.

  In both scenarios and firmware, visual confirmation of the waveform data acquired when they are actually operated reduces their development efficiency and further verifies the logic circuit to be verified. This contributes to a reduction in work efficiency.

  Therefore, in the following, a method for efficiently acquiring an appropriate scenario and firmware without using such visual confirmation of waveform data will be described in detail. Here, a scenario will be mainly described as an example.

FIG. 8 is a diagram showing an example of a scenario development work flow.
In the scenario development work flow of FIG. 8, like the work flow described in FIG. 6 above, the developer first reviews the specifications of the scenario based on the specifications (S60) used for the design to be verified (S61), Scenario setting procedure (S62) and scenario setting restrictions (S63) are extracted. The developer creates a scenario based on the extracted information (S64, S65).

  After the scenario is created, in the scenario development work flow of FIG. 8, the developer creates a setting restriction list based on the setting restriction items (S63) extracted at the time of reviewing the scenario specifications and the created scenario (S65). (S66, S67). In the setting restriction list, for example, information (restriction information) corresponding to the contents of the above-mentioned setting restriction items restricting the command execution of the predetermined description part of the created scenario, information such as a predetermined line number corresponding to the description part Is included. Details of the setting restriction list will be described later.

  Then, a scenario checker for checking the operation of the scenario is automatically generated (S68, S69) using such a setting restriction list (S67) as input. For example, the computer rewrites the contents of the setting restriction list (S67) into a scenario checker with a predetermined description using the same language as the scenario. The scenario checker, for example, when an instruction of a predetermined description part of the scenario described above is executed, whether or not the instruction includes the restriction information, that is, the instruction (input pattern) does not violate a setting restriction item. To check. Details of this point will be described later.

  The setting restriction list (S67) is used for generating a scenario checker (S68, S69) and for incorporating a scenario checker into a scenario (S70, S71). The computer, for example, calls the generated scenario checker (S69) at the position of the scenario line number based on the line number corresponding to the predetermined description portion of the scenario shown in the setting restriction list (S67). Is inserted (S70). As a result, a scenario in which the generated scenario checker (S69) can be called at the time of executing the instruction of the predetermined description portion is acquired (S71). Details of this point will be described later.

  The developer acquires a test bench incorporating the scenario checker (S69) acquired in this way and a scenario (S71) that can call the scenario checker (S69) in a predetermined description part (S72, S73). .

A configuration example of the test bench at the scenario development stage is shown in FIG.
The test bench 200A in the scenario development stage includes a verification target 300, a scenario 211 that is a model 210 that drives the verification target 300, and a transactor 212 (scenario development environment). In this scenario 211, a scenario checker 213 is incorporated so as to be called in a predetermined description part.

  When the verification target 300 is operated according to the scenario 211, the scenario checker 213 is called at the predetermined description portion of the scenario 211. The called scenario checker 213 checks whether or not the restriction information is included in the command (input pattern) from the scenario 211, that is, whether or not an input pattern that violates the setting restriction items is generated. Such a check is performed by a subsequent computer simulation (S74).

  That is, in order to confirm the operation of the acquired test bench, a simulation using a computer is performed (S74), and the computer generates information (log file) of the simulation result (S75). The simulation result information generated here is a log file indicating whether an error is detected by the scenario checker because the scenario checker is incorporated in the test bench. As in the work flow described in FIG. 6, it is not always necessary to acquire waveform data as a simulation result.

  The developer can determine whether or not an appropriate command (input pattern) that does not violate the setting restrictions is input from the scenario to the verification target based on the log file information of the simulation result. The operation of the scenario can be confirmed (S76). Therefore, it is not necessary to visually check the waveform data as described above for the scenario operation confirmation, and the scenario operation confirmation can be performed efficiently.

  If an error is detected as a result of checking the operation of the created scenario, a corrected scenario is created (S64, S65). Then, as described above, the setting restriction list is created (S66, S67), the scenario checker is generated (S68, S69) and incorporated (S70, S71), the test bench is acquired (S72, S73), and the simulation is performed again. Perform (S74, S75). From the log file information, the operation of the corrected scenario is confirmed (S76).

  If no error is detected in the operation check (S76) and simulation (test) is performed under different conditions (S77), the simulation conditions are changed and the test is performed (S74). If all tests are completed without error (S77), the scenario development work is completed.

Furthermore, the process after scenario development is demonstrated.
FIG. 10 is a diagram showing an example of a test bench development work flow.
In the test bench development work flow of FIG. 10, as in the work flow described in FIG. 3, the developer develops a checker for each component of the test bench based on the test bench specification (S80) (S81). ), Transactor development (S82) and scenario development (S83, S60 to S77). Then, each tested part is acquired (S84), and a test bench incorporating them is acquired (S85, S86).

FIG. 11 shows a configuration example of the test bench at the test bench development stage.
The test bench 200 of FIG. 11 includes a model 210 including a scenario 211 and a transactor 212, a protocol checker 220, and an expected value comparison checker 230 (test bench development environment). In this scenario 211, a scenario checker 213 is incorporated.

  The scenario checker used in scenario development (FIG. 9) has a configuration incorporated in the scenario (a configuration that can be called), and can be used as it is in a test bench for test bench development. By using such a test bench (S86), an overall simulation for operating the logic circuit to be verified is performed (S87) as in the work flow described in FIG. The result of this overall simulation is output as a log file of the check results by checkers (protocol checker, expected value comparison checker, scenario checker) incorporated in the test bench (S88). From the information in the log file, the developer determines whether an error has occurred (S89).

  If an error is detected by the scenario checker (S89), the process returns to scenario development (S83) to correct the scenario error factor. Since the scenario checker is provided here, it is possible to detect a scenario error (scenario error) at the result confirmation stage of the log file of the entire simulation (S87). Therefore, it is possible to correct the scenario at a relatively early stage of verification and create an appropriate scenario. Further, if there is no scenario checker error at this time and other checker errors are detected, it can be determined that the cause of the error is a verification target or a part other than the test bench scenario.

  If an error other than the scenario is detected (S89), re-simulation using a computer is performed to acquire waveform data (S90, S91). The developer visually confirms the acquired waveform data, and identifies the cause of the error (S92).

  When the error factor is on the logic circuit to be verified (S93), the developer corrects the logic circuit (S94), creates a corrected logic circuit (S95), and corrects the logic circuit. At the same time, the test bench is acquired again (S85, S86). And the operation | movement after the whole simulation (S87) is implemented using the re-acquired test bench.

  When the error factor is on the test bench side, the error factor is divided into a transactor or a checker in the test bench (S96). If there is an error factor (transactor miss) in the transactor (S96), the process returns to transactor development (S82) to correct the transactor error factor. If there is an error factor (checker miss) in the checker (S96), the process returns to the checker development (S81) to correct the checker error factor. Then, as described above, the unit test is performed to acquire each part (S84), the test bench is acquired (S85, S86), and the work after the entire simulation (S87) is performed.

  If no error is detected in the entire simulation (S89) and the entire simulation (test) is performed under different conditions (S97), the simulation conditions are changed and the test is performed (S87). If all tests are completed without error (S97), the test bench development work is completed.

  As described above, by incorporating the scenario checker into the scenario, in scenario development and test bench development, acquisition of waveform data by simulation and visual confirmation of the acquired waveform data can be eliminated for scenario mistakes. Thereby, an appropriate scenario can be created relatively early, scenario development can be made more efficient, and further, test bench development and logic circuit verification can be made more efficient.

  In the scenario development work flow of FIG. 8, unlike the work flow of FIG. 6, the creation of a setting restriction list (S66, S67), generation of a scenario checker (S68, S69), and incorporation of a scenario checker (S70, S71) Log file confirmation (S75, S76). By including these steps, the efficiency of scenario development as described above is improved. Each of these steps is performed as follows.

First, the setting restriction list creation step (S66, S67) will be described.
The developer creates the setting restriction list (S67). The setting restriction list is created with the setting restriction item (S63) and the scenario (S65) as inputs.

  In the setting restriction item, the content of the restriction item that restricts the input operation (command) for the verification target is described in a natural language. Further, it is assumed that a corresponding number (No.) is assigned to each item that restricts the input operation. A scenario is source code that describes instructions to a transactor. The developer creates a setting restriction list using such setting restriction items and scenarios.

FIG. 12 shows an example of the format of the setting restriction list.
The setting restriction list format 400a of FIG. 12 includes columns 401a to 406a for entering (inputting) various information.

  In the column 401a, the name (checker name) of the scenario checker generated in the scenario checker generation step (S68, S69) from the setting restriction list is entered. In the checker name column 401a, an arbitrary character string representing the function of the scenario checker to be generated is entered. The checker name entered in this column 401a is used as part of the file name generated in the scenario checker generation step. This checker name is also used for a character string output in a message when a checker error occurs.

  In the column 402a, a file name (reference file name) of a part having a description for performing an input operation regarding the setting restriction item (S63) in the scenario (S65) is entered. In the column 403a, a line number (insertion line number) for inserting the scenario checker generated in the scenario checker generation step into the file having the above reference file name is entered.

  No. in the column 404a. (Numbers 1 to n) are assigned corresponding to each setting restriction item regarding the scenario input operation. In the input 1 to m column 405a, a variable name that determines the content of the input operation of each setting restriction item is entered. In the conditions 1_1 to n_m column 406a, specific variables corresponding to variable names (inputs 1 to m) for determining the contents of the input operation of each setting restriction item are entered. In the other conditions 1 to m in the column 406a, conditions other than the variables corresponding to the variable names of the inputs 1 to m are entered. The columns 405a and 406a are blank when there is no applicable condition.

  The developer uses the setting restriction items (S63) and the scenario (S65) to fill in the contents of the respective columns 401a to 406a of the format 400a, and creates the setting restriction list (S67). In creating the setting restriction list, the number of rows and the number of columns are appropriately adjusted according to the number of setting restriction items (number of numbers), the number of variable names, and the like.

Next, the scenario checker generation step (S68, S69) will be described.
The scenario checker (S69) is generated by a computer process when the developer activates a scenario checker generation script. The scenario checker is generated using the setting restriction list (S67) as an input.

  A scenario checker is a file that contains one or more checkers. By executing the scenario checker generation script with the setting restriction list as an input, a scenario checker describing the contents of the setting restriction list is generated and output to a file. The file name at this time is “[checker name]. [Extension]”. The extension depends on the language used in the test bench (S73).

  The description content of the generated scenario checker differs depending on the language used in the test bench. However, in any language, when a simulation is executed and a scenario checker becomes an error, it is possible to determine which setting restriction item is an error. Therefore, a scenario checker is generated that outputs a character string (label name) “[checker name] _ [number i]” (i = 1 to n) together with the error content to the log file.

Next, the scenario checker incorporation step (S70, S71) will be described.
The scenario checker (S69) is incorporated by a computer process when the developer starts a scenario checker incorporation script. The scenario checker is incorporated using the setting restriction list (S67), the scenario checker (S69), and the scenario (65) as inputs. By executing the scenario checker built-in script, the scenario checker (S69) has the line number corresponding to the insertion line number (column 403a) of the file corresponding to the reference file name (column 402a) described in the setting restriction list. A file include statement is added.

Next, the log file confirmation step (S75, S76) will be described.
The developer checks the log file. In the confirmation of the log file, the presence or absence of a scenario checker error output message is confirmed from the contents of the log file (S75) to which the result of the simulation is output, and the necessity of scenario correction is determined. If a scenario checker error occurs during simulation, the log file will output a character string with a label name that includes the name of the checker that detected the error and information indicating the content of the error (number of setting restrictions) . Based on the information included in such a log file, the necessity of scenario correction is determined.

Hereinafter, the above method will be described more specifically with reference to examples.
First, the first embodiment will be described.
FIG. 13 is a diagram illustrating the relationship between the verification target and the scenario according to the first embodiment.

The language used in the test bench of the first embodiment is SystemVerilog.
The verification target 300 in FIG. 13 is a memory model and has a register area 301 inside. As an input operation to the verification target 300, there is a write operation to the register area 301. A command for a write operation from the scenario 211 that specifies the address ADDR (32′h00000000 to 32′hFFFFFFFC) and data DATA is sent to the verification target 300 via the transactor 212. In the verification target 300, the designated data DATA is stored in the register area 301 indicated by the designated address ADDR.

  That is, first, in the scenario 211, the address ADDR of the write operation to the register area 301 and the contents of the data DATA are determined. Next, the scenario 211 instructs the transactor 212 by giving the information of the address ADDR and the data DATA so as to perform the write operation to the register area 301. The transactor 212 performs an input operation of a write operation to the register area 301 with respect to the verification target 300, and transmits the address ADDR and data DATA information to the verification target 300. The verification target 300 receives the information of the write operation to the register area 301 from the transactor 212 and stores the specified data DATA in the register area 301 of the specified address ADDR.

  In the first embodiment, it is assumed that there is a setting restriction item for setting the scenario 211 regarding such a write operation to the register area 301. FIG. 14 is a diagram illustrating an example of setting restriction items according to the first embodiment. In the setting restriction item 500 illustrated in FIG. 14, first, as the contents of the first (No. 0001) setting restriction item, write prohibition of 32′h00000001 is set for the address 32′h00000000. Furthermore, as the contents of the second (No. 0002) setting restriction item, top. When READYo == 0, write prohibition is set for the address 32'h00000004.

  FIG. 15 is a diagram illustrating an example of a description part of a scenario according to the first embodiment. FIG. 15 illustrates a description part (part) of performing a write operation to the register area 301 included in the scenario 211 of the first embodiment. The scenario 211 of the first embodiment includes a file 211fa named “scenario.sv”, and the file 211fa includes a description (write_access task) for performing a write operation to the register area 301. .

The creation of the setting restriction list using the setting restriction item 500 and the scenario 211 as described above is performed, for example, according to the flow shown in FIGS.
In creating the setting restriction list 400, first, as shown in FIG. 16, an arbitrary character string representing the function of the scenario checker to be generated, in this case, a character string “WRITE” is entered in the checker name column 401 (FIG. 12). In the column 401a) of the format 400a.

  Next, as shown in FIG. 17, the name “scenario.sv” of the file 211fa containing the description for performing the input operation regarding the setting restriction item 500 is entered in the reference file name column 402 (column 402a of the format 400a in FIG. 12). . Further, the line number for including the file generated in the later scenario checker generation step in “scenario.sv” is entered in the insertion line number column 403 (the column 403a of the format 400a in FIG. 12). In this first embodiment, the generated file is inserted into the 101st line, where the contents of the write operation (address ADDR, data DATA) to the register area 301 can be referenced. Enter 101 ".

  Next, as shown in FIG. 18, the variable name is entered in the input (variable name) column 405 (the column 400a (input 1 and input 2) of the format 400a in FIG. 12). In this first embodiment, since the variables that determine the content of the write operation to the register area 301 are the address ADDR and data DATA, “ADDR” and “DATA” are entered in the column 405.

  Next, the contents described in the setting restriction item 500 are interpreted, and specific conditions are entered in each condition column 406 (format 400a column 406a in FIG. 12) as shown in FIG. In the first embodiment, no. For the setting restriction item of 0001, “32′h00000000” is entered for “ADDR”, “32′h00000001” is entered for “DATA”, and other conditions are blank. No. For the setting items of 0002, “32′h00000004” is entered for “ADDR”, “DATA” is blank, and “top.READYo == 0” is entered for other conditions.

In this way, the setting restriction list 400 is created.
Next, generation of the scenario checker 213 using the created setting restriction list 400 will be described with reference to FIGS.

  Here, a case where SystemVerilog is used will be described as an example. The assertion of the SystemVerilog checker is in the format “[label name]: assert ([error condition])”. [Label name] is an arbitrary character string, and [Error condition] is a logical expression in the grammar of SystemVerilog. When this checker is executed during simulation, if the logical expression of [error condition] indicates true, the result (log file) is recorded as an error together with [label name].

  In the scenario checker generation in the case of SystemVerilog, the scenario checker generation script is executed to generate the character strings of the [label name] and [error condition] parts based on the created setting restriction list 400, and the scenario checker. 213 is generated. The scenario checker 213 is generated with a file name “[checker name] .svh”.

  FIG. 20 shows a conversion format from the setting restriction list to the scenario checker by the scenario checker generation script. FIG. 20 shows a correspondence between the description of the setting restriction list format 400a and the description of the scenario checker 213 generated therefrom.

  Each No. One checker is generated for each (number 1 to n). The [label name] of each checker is generated by a character string “checker name_number i” (i = 1 to n). [Error condition] is, for example, “No. In 0001, a character string “(input 1 == condition 1_1) && (input 2 == condition 1_2)... (Input m == condition 1_m) && (other conditions 1)” is generated. However, if the condition is blank, the logical expression for that part is not generated.

The first embodiment is as shown in FIG.
FIG. 21 is a diagram showing an example of conversion from the setting restriction list to the scenario checker by the scenario checker generation script according to the first embodiment.

  As shown in FIG. For 0001, a checker 213a having [label name] "WRITE_0001" and [error condition] "ADDR == 32'h00000000) && (DATA == 32'h00000001)" is generated. From the setting restriction list 400, No. For 0002, a checker 213b with [label name] "WRITE_0002" and [error condition] "ADDR == 32'h00000004) && (top.READYo = 0)" is generated.

The file name of the scenario checker 213 including such checkers 213a and 213b is “WRITE.svh”.
Next, incorporation of the generated scenario checker will be described with reference to FIG.

FIG. 22 is a diagram illustrating an example of incorporation of a scenario checker into a scenario by a scenario checker incorporation script according to the first embodiment.
As shown in FIG. 22, by executing the scenario checker embedded script, the “WRITE.svh” inclusion is included in the 101st line of the “scenario.sv” file 211fa of the scenario 211 based on the information of the setting restriction list 400. A sentence 211c is inserted. As a result, a description in which the scenario checker 213 as shown in FIG. 21 is incorporated in the scenario 211 (a description that can call the scenario checker 213) is obtained.

  In the case of a simulation performed at the stage of scenario development or test bench development using such a scenario 211, the scenario checker 213 of “WRITE.svh” is executed at the time of executing an instruction in the description part of “scenario.sv” of the scenario. Called. Then, by the called scenario checker 213, whether or not the instruction executed by the scenario 211 includes restriction information (address ADDR, data DATA, other conditions) for restricting the execution (the logical expression of the error condition is true). Whether or not to show) is checked. If the restriction information for restricting the execution of the instruction of the scenario 211 is included, an error occurs. The result of checking whether there is an error is output as a log file.

Next, a log file obtained as a result of simulation using a scenario checker will be described with reference to FIG.
FIG. 23 shows an example of log file output according to the first embodiment.

  When the scenario checker 213 of the first embodiment detects an error in the simulation, a character string of [label name] of the checkers 213a and 213b is output to the log file 600 obtained as a result of the simulation. That is, in this example, label names 601 such as “WRITE_0001” and “WRITE_0002” are output to the log file 600.

  The developer checks the log file 600 obtained as a result of the simulation, and if the [label name] of the checkers 213a and 213b is output in this way, the scenario 211 is regarded as having an error, and the scenario 211 is corrected. Proceed to the process.

Next, a second embodiment will be described.
In the first embodiment, the case of the setting restriction item in the write operation to the register area 301 has been illustrated. However, in addition to the single operation as described above, the case of the setting restriction item for the entire series of processes of a certain function is also possible. Similarly, the above method can be applied. Such an example will be described as a second embodiment.

  The verification target of the second embodiment is assumed to have the following configuration. This verification target has a DMA (Direct Memory Access) function. The verification target includes a plurality of DMA function setting registers, and when the DMA function is activated by writing the setting of the operation to be performed in the DMA function setting register, the DMA function operation is performed according to the setting value written in the DMA function setting register. Do.

  It is assumed that the DMA function setting register includes setting items for transfer direction (OUT / IN), DMA mode (block / demand), and burst mode (SINGLE / INCR). The DMA mode block indicates a mode in which transfer is performed once in a block unit in response to a single transfer request, and the demand indicates a mode in which transfer is performed while the transfer request is active. SINGLE in the burst mode indicates a mode in which single transfer is performed with a single transfer request, and INCR indicates a mode in which incremental burst transfer is performed. In addition, the DMA function setting register further includes setting items for the total number of transfers (LENGTH) (16 bits), transfer source (SRC) address (32 bits), and transfer destination (DST) address (32 bits).

  Regarding the operation of the DMA function to be verified, it is assumed that there are setting restrictions for setting the scenario 211. FIG. 24 is a diagram illustrating an example of setting restriction items according to the second embodiment. In the setting restriction item 510 illustrated in FIG. As the content of the setting restriction item of 0001, DMA activation prohibition with a total transfer number of 0 is set. No. As the contents of the setting restrictions of 0002, DMA activation prohibition is set in which the transfer direction is IN and the DMA mode is demand. No. As the content of the setting restriction item 0003, prohibition of DMA activation when the DMA mode is block and the burst mode is INCR is set.

  FIG. 25 is a diagram illustrating an example of a description part of a scenario according to the second embodiment. FIG. 25 exemplifies a description part (a part) for performing the DMA function activation process included in the scenario 211 of the second embodiment. The scenario 211 of the second embodiment includes a file 211fb named “scenario.sv”, and this file 211fb includes a description (dma_process task) for performing DMA function activation processing. The dma_process task is a task for performing a series of DMA function activation processing by writing a register in accordance with the input setting item information of the DMA function setting register.

FIG. 26 shows an example of a setting restriction list according to the second embodiment created using the setting restriction items 510 and the scenario 211 as described above.
The setting restriction list 410 in FIG. 26 can be created in the same procedure as in the first embodiment. In the setting restriction list 410 of the second embodiment, the character string “DMA” is entered in the checker name column 411 (the column 401a of the format 400a in FIG. 12).

  In the reference file name column 412 (the column 402a of the format 400a in FIG. 12), the name “scenario.sv” of the file 211fb having a description for starting the DMA function is entered.

  In the insertion line number column 413 (the column 403a of the format 400a in FIG. 12), the line number for including the file generated in the scenario checker generation step is entered. In the second embodiment, “207”, which is a line that can refer to the contents of the DMA function activation processing (directory DIR, DMA mode DMA_MODE, burst mode BURST_MODE, LENGTH), is written in the column 413 for the generated file. .

  In the input (variable name) column 415 (the column 405a of the format 400a in FIG. 12), variable names of the directory DIR, DMA mode DMA_MODE, burst mode BURST_MODE, and LENGTH that determine the contents of the DMA function activation processing are entered. The

  In each condition column 416 (the column 406a of the format 400a in FIG. 12), the content of the setting restriction item 510 is interpreted and specific restriction information is entered. In the second embodiment, no. For the setting restriction item of 0001, “16′h0000” is entered for “LENGTH”, and the others are blank. No. For the setting items of 0002, “1′b1” is entered for “DIR” and “DMA_MODE”, and the others are blank. No. For setting items 0003, “1′b0” is entered for “DMA_MODE”, “1′b1” is entered for “BURST_MODE”, and the others are blank.

FIG. 27 is a diagram illustrating an example of a scenario checker according to the second embodiment.
By executing the scenario checker generation script based on the setting restriction list 410 as described above, No. A scenario checker 213 including checkers 213c, 213d, and 213e of 0001, 0002, and 0003 is generated. Each checker 213c, 213d, 213e is generated according to the format "[label name]: assert ([error condition])", as in the first embodiment. In the case of the second embodiment, the generated scenario checker 213 has a file name “DMA.svh”.

  Then, as in the first embodiment, a scenario checker embedded script is executed, and an include statement that calls the scenario checker 213 including these checkers 213c, 213d, and 213e on line 207 of the file 211fb is executed based on the setting restriction list 410. insert. Thereby, a scenario 211 in which the scenario checker 213 is incorporated so as to be called on the 207th line of the file 211fb can be obtained.

  In a simulation performed in scenario development or test bench development using such a scenario 211, [label names] of “DMA — 0001”, “DMA — 0002”, and “DMA — 0003” are output to the log file at the time of error detection. The developer checks the log file obtained as a result of the simulation, and if the [label name] of the checkers 213c, 213d, and 213e is output in this way, the scenario 211 is regarded as having an error, and the scenario 211 is corrected. Proceed to the process.

  According to the method described above, in the simulation performed in the scenario development stage and the test bench development stage, information indicating the presence / absence of a scenario error and the content of the error can be confirmed by checking the log file. Therefore, it is not necessary to dare to acquire waveform data when a scenario error is detected, and further, the developer confirms the acquired waveform data visually and analyzes it to identify the cause of the error. Is no longer necessary. Therefore, it is possible to shorten the analysis time of the scenario factor error. For example, if a scenario factor error and other errors occur at a rate of 50% in the test bench development stage, the error analysis time as a whole is reduced to about one half.

  Furthermore, with the method described above, scenario operation confirmation (verification) at the scenario development stage can be performed by confirming the log file. On the other hand, when confirming the operation of the scenario by visual confirmation of the waveform data, it takes time, and there are cases in which it is not possible to confirm a large number of operations. According to the above method, the operation of the scenario can be confirmed by confirming the log file, and the visual confirmation of the waveform data can be eliminated, so that the time required for the operation confirmation can be shortened. As a result, it is possible to confirm more operations, and it is possible to sufficiently confirm the operation of the scenario.

  In the above description, the scenario (and the test bench incorporating the scenario) is taken as an example. However, the same technique as described above can also be used in the development of firmware for controlling the logic circuit.

  That is, setting restrictions for setting the firmware control operation are obtained based on the specification to be verified, the firmware specification, and the like. Based on the setting restriction item, a setting restriction list including restriction information for restricting instruction execution of a predetermined description part of the firmware is created according to the example of the scenario. Then, a firmware checker in which the contents of the created setting restriction list are described is generated, and the generated checker is incorporated into the firmware so that it can be called at the time of execution of the instruction of the predetermined description part. The logic circuit is operated using this firmware, the checker is called at the predetermined description part, and whether the restriction information for restricting the execution is included in the instruction of the predetermined description part is checked by the called checker. An error occurs if the restriction information that restricts the instruction execution of the firmware is included. Information indicating the presence or absence of an error and the content of the error is output as a log file.

  According to such a method, it is possible to determine from the log file that the detected error is caused by firmware, and further, it is not necessary to analyze the waveform data for the error caused by the firmware. Therefore, the error analysis time can be shortened as compared with the case where the error caused by the firmware is performed by visual confirmation of the waveform data.

  The scenario, test bench, firmware, and verification of the target circuit using them can be realized using a computer. In this case, a program describing the contents of processing functions executed by the computer is provided. Is done. By executing the program on a computer, the above processing functions are realized on the computer. The program describing the processing contents can be recorded on a computer-readable recording medium. Examples of the computer-readable recording medium include a magnetic storage device, an optical disk, a magneto-optical recording medium, and a semiconductor memory. Magnetic storage devices include HD, flexible disk (FD), magnetic tape, and the like. Optical discs include DVD, DVD-RAM, CD-ROM / RW, and the like. Magneto-optical recording media include MO (Magneto-Optical disk).

  When distributing the program, for example, a portable recording medium such as a DVD or a CD-ROM in which the program is recorded is sold. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.

  The computer that executes the program stores, for example, the program recorded on the portable recording medium or the program transferred from the server computer in its own storage device. Then, the computer reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. In addition, each time a program is transferred from a server computer connected via a network, the computer can sequentially execute processing according to the received program.

  Further, at least a part of the above processing functions can be realized by an electronic circuit such as a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), or a PLD (Programmable Logic Device).

100 computer 101 CPU
102 ROM
103 RAM
104 HDD
104a HD
105 communication interface 106 keyboard 107 mouse 108 peripheral device 110 bus 120 design data 130 logic simulator 140, 200, 200A test bench 210, 210a, 210b model 211, 211a, 211b scenario 211c include statement 211fa, 211fb file 212, 212a, 212b transactor 213 Scenario checker 213a, 213b, 213c, 213d, 213e checker 220 protocol checker 220a A protocol checker 220b B protocol checker 230 expected value comparison checker 300 verification target 301 register area 400, 410 setting restriction list 400a format 401a, 402a, 403a, 404a , 405a, 406a, 401, 402, 403, 405, 406, 411, 412, 413, 415, 416 Column 500, 510 Setting restrictions 600 Log file 601 Label name

Claims (4)

Computer
Using a list including restriction information for restricting instruction execution of a predetermined description part of a program describing instructions for a circuit to be verified, and generating a checker indicating the contents of the list,
The generated checker is incorporated into the program so that the checker is called when an instruction of the predetermined description portion is executed,
The circuit to be verified is operated using the program in which the checker is incorporated, and the checker is called when executing the instruction of the predetermined description part, and whether or not the instruction of the predetermined description part includes the restriction information Check
Generating result information indicating the result of the check;
A verification method characterized by that. The list includes identification information for identifying the checker generated from the list, a line number in the program that calls the checker, and the restriction information.
The computer
Generating the checker including the identification information and the restriction information from the list;
After generating the checker, based on the list, insert a statement including the identification information for calling the checker into the line number of the program,
Calling the checker to the line number of the program based on the identification information and performing the check,
The verification method according to claim 1 . The restriction information verification method according to claim 1 or 2, characterized in that it comprises a variable that determines the contents of the instruction for the circuit of the verification target. On the computer,
Using a list including restriction information for restricting instruction execution of a predetermined description part of a program describing instructions for a circuit to be verified, and generating a checker indicating the contents of the list,
The generated checker is incorporated into the program so that the checker is called when an instruction of the predetermined description portion is executed,
The circuit to be verified is operated using the program in which the checker is incorporated, and the checker is called when executing the instruction of the predetermined description part, and whether or not the instruction of the predetermined description part includes the restriction information Check
Generating result information indicating the result of the check;
A verification program characterized by causing processing to be executed.

Images