JP2013069174A - Cooperation verification method and cooperation verification device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To determine whether or not a design circuit satisfies performance requirements.SOLUTION: A cooperation verification method by software and hardware of a design circuit to be executed by a computer includes: setting a countable specified value based on performance requirements in a specified value register when cooperation verification of the design circuit is started; counting the operation of the design circuit according to the performance requirements under the execution of the cooperation verification; and comparing the counted count value with the specified value set in the specified value register to execute performance measurement.

Description

  The present invention relates to a collaborative verification method and a collaborative verification apparatus that perform collaborative verification using software and hardware of a design circuit.

  In software development, software and hardware are collaboratively verified using a hardware model on which the software operates. Many programs (software) executed by LSI (Large Scale Integration) for multimedia use require real-time performance, and the processing units that are repeatedly executed by these programs are always executed within a specified time. In many cases, a strong constraint is required.

  When performing verification, it is conceivable to monitor the processing time related to the processing unit when the program is executed. From the viewpoint of monitoring processing time, the processing time for a given process is monitored, and when the specified time elapses, a time-out is notified, and software / hardware co-verification verifies the processing time of the software model. A technique for monitoring the simulation time at a preset timer interval based on the timer value calculated from the verification time in the mobile platform has been proposed.

Japanese Patent Laid-Open No. 04-239341 Japanese Patent Laid-Open No. 04-279940 JP 2010-009113 A

  However, since the above conventional technique is a technique for monitoring a state in which the process does not end at a predetermined time for some reason or the process loops and does not end, the program to be verified functions normally. Therefore, it is not possible to accurately evaluate such a program having no functional problem based on the performance defined by the constraints.

  Even if the program for multimedia is satisfied with the restrictions on the function, for example, if the execution of a certain processing unit exceeds the specified time in graphic processing, audio processing, etc., quality becomes a problem due to noise mixing etc. There is a case.

  When performing software / hardware collaborative verification with a simulator and emulator in LSI design, not only is it verified that it is logically correct, but it also measures the overall processing time, and with regard to the processing of individual parts of the program, It cannot be verified at the same time that it is executed within the specified time. For this reason, in audio processing, it is difficult to detect a case in which noise occurs because sampling cannot be performed in time for sampling at a certain moment, that is, there is no problem in function, but it is difficult to detect processing that has a problem in performance. .

  Therefore, an object of the present invention is to enable not only software and hardware functions but also performance restrictions to be verified in software / hardware cooperative verification before LSI manufacturing.

  The disclosed technology is a method for collaborative verification by software and hardware of a design circuit executed by a computer, and sets a count value that can be counted based on performance requirements in a specified value register at the start of the collaborative verification of the design circuit. During the collaborative verification, the operation of the design circuit according to the performance requirement is counted, and the performance measurement is performed by comparing the counted value with the prescribed value set in the prescribed value register.

  Further, as means for solving the above-described problems, a collaborative verification apparatus, a program for causing a computer to perform the collaborative verification method, and a recording medium on which the program is recorded can be used.

  In the disclosed technology, it is possible to determine whether or not the design circuit satisfies the performance requirement by measuring the performance using a countable specified value based on the performance requirement.

It is a figure which shows a basic composition. It is a figure for demonstrating the 1st example of a regulation value calculation method. It is a figure for demonstrating the 2nd example of a regulation value calculation method. It is a figure which shows the function structural example of the additional circuit for a measurement. It is a figure which shows the hardware constitutions of a verification system. It is a figure for demonstrating the 1st Example which implements only a performance measurement process with a simulator. It is a figure for demonstrating the 2nd Example which implements only a performance measurement process using an emulator. It is a figure for demonstrating the 3rd Example which implements only a function verification process with a simulator. It is a figure for demonstrating the 4th Example which implements only a function verification process with an emulator. It is a figure for demonstrating the 5th Example which implements a performance measurement process and a function verification process. It is a figure for demonstrating the 6th Example which implements a performance measurement process and a function verification process. It is a figure for demonstrating the 1st search example which searches a frequency. FIG. 13 is a flowchart for explaining an outline of processing in the first search example of FIG. 12. It is a figure for demonstrating the 2nd search example which searches the combination of a function. FIG. 15 is a flowchart for explaining an outline of processing in the second search example of FIG. 14. It is a figure for demonstrating the 3rd search example which searches the conditions which satisfy | fill a performance requirement in the combination of the same function. It is a figure for demonstrating the performance measurement based on a bus occupation rate. It is a figure for demonstrating the modification of 5th Example. It is a figure for demonstrating the modification of 6th Example. It is a flowchart figure for demonstrating the process outline | summary in the modification of 6th Example of FIG. It is a figure which shows the example of the circuit model structure of LSI corresponding to a multimedia. FIG. 22 is a diagram illustrating a search example of performance limits of the multimedia-compatible LSI illustrated in FIG. 21. It is a figure which shows the example of a data flow. It is a flowchart figure for a bus monitor result display. It is a figure for demonstrating the example of a bottleneck analysis. It is a figure for demonstrating the verification example of the performance margin using a bus occupation rate.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. In this embodiment, in addition to verifying that each partial process executed by LSI is logically correct in software / hardware collaborative verification (hereinafter referred to as collaborative verification) using a simulator and an emulator. By monitoring the execution within the pre-specified performance requirements, it is possible to detect performance or / and functional processing violations and provide verification results for analysis.

  FIG. 1 is a diagram showing a basic configuration. In FIG. 1, only the components according to the present embodiment are shown, and other components are omitted. In the basic configuration illustrated in FIG. 1, the verification system 1000 mainly includes a specified value generation unit 2, a conversion unit 4, and a cooperative verification unit 50. Furthermore, performance requirement data 1, a program 3, a test program 5, design data 6, and a test bench 7 are stored in the storage unit.

  As will be described later, the specified value generation unit 2, the conversion unit 4, and the cooperative verification unit 50 are processing units realized by a CPU executing a corresponding program in a computer device such as a workstation. . Alternatively, the specified value generation unit 2 and the conversion unit 4 may be realized by one workstation, and the cooperative verification unit 50 may be realized by an emulator.

  The performance requirement data 1 indicates performance requirements defined by the constraints, and includes data such as processing time and bus occupancy required for the partial processing to be verified.

  The specified value generation unit 2 reads the performance requirement data 1 and generates a specified value for performance verification. It is a processing unit that calculates a specified value that can be counted in the process in the cooperative verification unit 50 from the value related to the performance requirement defined by the performance requirement data 1. The specified value generation unit 2 embeds a specified value setting program 39 for writing the calculated specified value in a predetermined register of the cooperative verification unit 50 in the verification target program 3 when the verification-target partial processing is started. .

  The conversion unit 4 is a processing unit that converts the program 3 into a test program 5 for testing the verification target LSI 90m. The program 3 is a program to be executed by the verification target LSI 90m in order to verify the performance or / and function of each partial process. The test program 5 is converted by the conversion unit 4 into a program code that can be executed by the verification target LSI 90m.

  The design data 6 is data that abstractly represents the operation of the hardware by a hardware description language such as RTL (Register Transfer Level).

  The test bench 7 includes a circuit model created in a hardware description language such as RTL (Register Transfer Level) for verifying the performance or / and function of the verification target LSI 90m operated by the test program 5. Implemented. In the present embodiment, the test bench 7 includes an additional circuit 51 for measurement which is a circuit model created in a hardware description language such as RTL (Register Transfer Level) added for measurement.

  The cooperative verification unit 50 is a processing unit that performs cooperative verification on a simulator or an emulator, and includes a verification target LSI 90 m and a measurement additional circuit 51.

  The verification target LSI 90m is a circuit model representing the operation of the designed LSI, which is mounted by loading the design data 6 into the cooperative verification unit 50, and includes at least a CPU 91m and a memory 93m. Both the CPU 91m and the memory 93m are mounted as a circuit model. When the test program 5 is loaded into the memory 93m and the CPU 91m executes the test program 5, the cooperative verification is started.

  At the start of the predetermined partial processing, the CPU 91m executes the predetermined partial processing by writing the predetermined value in the predetermined register of the measurement additional circuit 51 in accordance with the predetermined value setting program 39 embedded by the predetermined value generation unit 2. Then, the measurement additional circuit 51 acquires the result collected by measuring the performance or / and function of the verification target LSI 90m during execution of the predetermined partial process, and determines the test result.

  The measurement additional circuit 51 is a circuit model that is mounted by loading the test bench 7 into the cooperative verification unit 50, and includes a performance measurement unit 52, a function verification unit 54, and a result collection unit 54.

  The performance measurement unit 52 is a processing unit that is activated by the test program 5 and performs performance measurement based on the specified value set by the CPU 91m when the operation of the verification target LSI 90m is started. The results are collected by the result collection unit 54 and notified to the verification target LSI 90m.

  The function verification unit 56 is a processing unit that is activated by the test program 5 and performs functional measurement of the operation of the verification target LSI 90m. The results are collected by the result collection unit 54 and notified to the verification target LSI 90m.

  The result collection unit 54 collects the results from the performance measurement unit 52 or / and 56 and notifies the CPU 91m. The result is determined by the test program 5 being executed by the CPU 91m.

  Next, an example of the specified value calculation method performed by the specified value generation unit 2 will be described with reference to FIGS. FIG. 2 is a diagram for explaining a first example of the specified value calculation method. In FIG. 2, the performance requirement data 1 a in which the processing time “33 ms” for satisfying the performance is designated and the defined value calculation data 8 a used for calculating the defined value are read into the defined value generation unit 2. It is.

  In this first example, the clock frequency “100 MHz” obtained from the design data 6 is specified by the specified value calculation data 8a.

  The specified value generation unit 2 calculates the number of cycles for the design data 6 that is the specified value, based on the performance requirement specified by the read performance requirement data 1a and the clock frequency specified by the specified value calculation data 8a.

  The specified value generation unit 2 obtains one cycle “10 ns” of the design data 6 from the clock frequency “100 MHz”, and divides the processing time “33 ms” by one cycle “10 ns” of the design data 6, thereby processing time “33 ms”. "3,300,000" cycles that must be processed in the design data 6 to satisfy "

  The specified value generation unit 2 embeds in the program 3 a specified value setting program 39 for writing the number of cycles “3,300,000” of the calculation result into a predetermined register as a specified value at the time of performance measurement.

  FIG. 3 is a diagram for explaining a second example of the specified value calculation method. In FIG. 3, the performance requirement data 1b in which the bus occupation rate “50%” or less for satisfying the performance is specified, and the defined value calculation data 8b used to calculate the defined value are defined as a defined value generation unit. 2 is read.

  In this second example, the bus operation frequency “100 MHz” and the bus width “64 bits” obtained from the design data 6 by the specified value calculation data 8b, and the read command “64 bits” and the write command “64 bits” as the transfer amount of one command. The resolution “1 second” is designated.

  The specified value generation unit 2 calculates the number of cycles for the design data 6 that is the specified value, based on the performance requirement specified by the read performance requirement data 1b and the clock frequency specified by the specified value calculation data 8b.

  The specified value generation unit 2 uses the performance requirement specified by the read performance requirement data 1b, the bus operating frequency “100 MHz” and the bus width “64 bits” of the design data 6 specified by the specified value calculation data 8b, and one command. Based on the transfer amount, the maximum number of commands that can be issued that is a specified value is calculated.

  The specified value generation unit 2 obtains the maximum transfer amount (theoretical value) “6400 Mbps” by multiplying the bus operating frequency “100 MHz” by the bus width “64 bits”. Considering the transfer amount of one command of 64 bits for both read and write, in order to satisfy the performance requirement bus occupancy “50%” or less, the maximum transfer amount (theoretical value) “6400 Mbps” is divided by “64 bits” for one command. Further, by multiplying the performance requirement bus occupancy “50%”, the maximum number of commands that can be issued per second “50 M times” required as performance is acquired. In this case, since the resolution is “1 second”, the maximum number of commands that can be issued per second of resolution is “50 M times”. When the resolution is “2 seconds”, the maximum number of commands that can be issued per 2 seconds of resolution is “100 M times”.

  The specified value generation unit 2 embeds in the program 3 a specified value setting program 39 for writing the maximum number of command issuable times “50M times” of the calculation result into the predetermined register as a specified value at the time of performance measurement.

  FIG. 4 is a diagram illustrating a functional configuration example of the measurement additional circuit. In FIG. 4, a measurement additional circuit 51 that is a circuit model described in RTL includes a performance measurement unit 52, a result collection unit 54, and a function verification unit 56.

  The performance measurement unit 52 measures the performance of the verification target LSI 90m, and includes a control unit 521, a performance comparison unit 529, and a register unit 530.

  The control unit 521 monitors the start and end of performance measurement, and controls processing in the performance measurement unit 52.

  In the case of the first example of the prescribed value calculation method shown in FIG. When the count value exceeds the specified value, the control unit 521 notifies the result collection unit 54 and stores the performance measurement result in the memory 553 via the result storage unit 550.

  In the case of the second example of the specified value calculation method shown in FIG. 3, the control unit 521 incorporates a bus monitor into the verification target LSI 91m and counts each time a command is issued from the start of processing. The control unit 521 resets the counter when the number of cycles converted from the designated resolution has elapsed. When the count value exceeds the specified value, the control unit 521 notifies the result collection unit 54 and stores the performance measurement result in the memory 553 via the result storage unit 550.

  The performance comparison unit 529 performs performance measurement by comparing the specified value set by the verification target LSI 90m at the start of processing with the count value counted during the processing. The register unit 530 has a plurality of registers necessary for performance measurement.

  The result collection unit 54 collects the comparison results output from the performance measurement unit 52 and includes a control unit 541 and a result storage unit 550. The control unit 541 receives the results from the performance measurement unit 52 and the function verification unit 56 and stores them in the memory 553 of the result storage unit 550. The control unit 541 notifies the verification target LSI 90m of the results from the performance measurement unit 52 and the function verification unit 56. That is, the results from the performance measurement unit 52 and the function verification unit 56 are notified to the test program 5 being executed on the verification target LSI 90m. On the other hand, when there is a problem in performance or function, the control unit 541 stops the measurement additional circuit 51.

  The function verification unit 56 measures the function of the LSI 90m to be verified, and inputs the input unit 560, the control unit 561, the expected value generation unit 562, the expected value storage memory 563, the expected value comparison unit 564, and the register unit 570. Have The function measurement includes measurement related to whether or not the verification target LSI 90m is functioning correctly.

  The input unit 560 takes the input data to the internal memory or the external memory into the function verification unit 56. The control unit 561 determines the comparison start condition with the input data, and causes the expected value comparison unit 564 to compare with the expected value.

  The expected value generation unit 562 generates expected value data 58 and stores it in the expected value storage memory 563. The expected value comparison unit 564 compares the input data fetched from the input unit 560 with the expected value data 58. Data corresponding to the comparison result is provided to the result collection unit 54 by the control unit 561. When the result collection unit 54 is notified of the comparison mismatch with the expected value data 58 from the control unit 561 of the function verification unit 56, the result collection unit 54 stops the measurement additional circuit 51.

As a processing pattern in the collaborative verification based on the functional configuration described above,
Process pattern A: Performance measurement process only Process pattern B: Function verification process only Process pattern C: Performance measurement process and function verification process (process pattern A + B)
Thus, there are three types of processing patterns. For each of these processing patterns A, B, and C, an outline of processing will be described for each of the embodiment using only the simulator that does not use the emulator and the embodiment using the emulator.

  In describing the functional implementations A, B, and C described above, first, the hardware configuration of the verification system 1000 will be described. FIG. 5 is a diagram illustrating a hardware configuration of the verification system 1000. In FIG. 5, the verification system 1000 includes at least a WS (workstation) 100.

  The WS 100 is a device controlled by a computer so as to function as a simulator, and includes a CPU (Central Processing Unit) 11, a memory unit 12, a display unit 13, an output unit 14, an input unit 15, and a communication unit. 16, a storage device 17, and a drive 18, which are connected to the bus B.

  The CPU 11 controls the WS 100 according to a program stored in the memory unit 12. The memory unit 12 uses a RAM (Random Access Memory), a ROM (Read-Only Memory), or the like, and is obtained by a program executed by the CPU 11, data necessary for processing by the CPU 11, and processing by the CPU 11. Stored data. A part of the memory unit 12 is allocated as a work area used for processing by the CPU 11.

  The display unit 13 displays various information required under the control of the CPU 11. The output unit 14 has a printer or the like, and is used for outputting various types of information in accordance with instructions from the user. The input unit 15 includes a mouse, a keyboard, and the like, and is used by a user such as an LSI developer to input various information necessary for the WS 100 to perform processing. The communication unit 16 is a device that is connected to, for example, the Internet, a LAN (Local Area Network), and the like and controls communication with an external device.

  For example, a hard disk unit is used as the storage device 17, and a program for realizing processing in the specified value generation unit 2, the conversion unit 4, and the cooperative verification unit 50 that executes various processes, and the verification target LSI 90m. Data such as the program 3 for executing the verification target process to be executed, the test program 5 converted into the format of the memory 93m, the design data 6, the test bench 7, and the like are stored.

  The memory unit 12 or / and the storage device 17 or the like forms a storage unit that stores programs and data necessary in the present embodiment.

  A program that realizes processing performed by the WS 100 is provided to the WS 100 by a storage medium 19 such as a CD-ROM (Compact Disc Read-Only Memory). That is, when the storage medium 19 storing the program is set in the drive 18, the drive 18 reads the program from the storage medium 19, and the read program is installed in the storage device 17 via the bus B. When the program is activated, the CPU 11 starts its processing according to the program installed in the storage device 17. The medium for storing the program is not limited to a CD-ROM, and any medium that can be read by a computer may be used. As a computer-readable storage medium, in addition to a CD-ROM, a portable recording medium such as a DVD disk or a USB memory, or a semiconductor memory such as a flash memory may be used.

  In addition, a program that realizes processing performed by the WS 100 may be provided from an external device via the communication unit 16. Alternatively, the program may be provided to an external device, and each process described below may be realized by the external device. Communication by the communication unit 16 is not limited to wireless or wired.

  Further, the verification system 1000 can further perform cooperative verification using the emulator 200 by communicating with the emulator 200 by including the emulator I / F 20.

  In the following, the functional configuration and the processing procedure related to the processing pattern A for only the performance measurement processing will be described in a case where the functional configuration and a processing procedure are performed using the simulator (WS 100) and a case where the processing is performed using the emulator 200.

  A processing procedure according to the first embodiment in which the processing pattern A for only the performance measurement processing is performed by the simulator (WS100) will be described with reference to FIG. FIG. 6 is a diagram for explaining a first embodiment in which only performance measurement processing is performed by a simulator. In FIG. 6, the WS 100 has a write processing insertion unit 2a, and the register unit 530 of the performance measurement unit 52 of the measurement additional circuit 51 includes a start register A531, an end register A532, a specified value register A533, and a counter. A534.

  In the first embodiment shown in FIG. 6, the write processing insertion unit 2a writes data to the start register A531 at the start of performance measurement target processing (hereinafter referred to as processing A. For example, audio processing). Then, a program for performing a process of writing to the end register A532 at the end time is inserted into the program 3, and the specified value generation unit 2 performs a process of setting the specified value in the specified value register A533 based on the performance requirement data 1. The specified value setting program 39 is inserted into the program 3 (step S11).

  Next, the conversion unit 4 generates the test program 5 by converting the program 3 into a memory format for simulation (step S12).

  The CPU 11 executes the design data 6 and the test bench 7 loaded in the memory unit 12, thereby functioning as a cooperative verification unit 50a-1 that is a simulator, and the test program 5 is loaded into the memory 93m. Thus, the simulation is started (step S13).

  When the simulation is started, the CPU 91m of the verification target LSI 90m starts the performance measurement unit 51 according to the test program 5 loaded in the memory 93m, and at the time of starting the performance measurement process for the process A, the specified value (cycle) related to the process A Number) is set in the specified value register A533 (step S14).

  At the start of processing A by the verification target LSI 91m, the control unit 521 writes to the start register A531 (step S15). In addition, the control unit 521 resets the counter A534 (step S16). Thereafter, the counter A534 is counted up every cycle.

  At the end of the process A by the verification target LSI 91m, the control unit 521 writes in the end register A532 (step S17).

  The performance comparison unit 529 compares the counter value of the counter A534 with the specified value set in the specified value register A533 (step S18). When the comparison result by the performance comparison unit 529 indicates that the counter value of the counter A 534 is larger than the specified value of the specified value register A 533, the control unit 521 determines that there is a problem in performance and notifies the result collecting unit 54. As a result, the error flag managed in the memory 553 of the result storage unit 550 of the result collection unit 54 is set to 1.

  When the error flag indicates “1”, it indicates that it is determined that there is a problem in performance, and when it indicates “0”, it indicates that it is determined that there is no problem because the performance is within the specification. When receiving the setting of the error flag “1”, the result collection unit 54 stores the simulation result in the memory 553 of the result storage unit 550, sets “1” in the error flag in the memory 553, and stops the simulation. . You can choose whether to stop the simulation.

  On the other hand, if the simulation is not stopped and the performance is within the specified range and there is no problem, steps S15 to S18 described above are repeated.

  A processing procedure according to the second embodiment in which the processing pattern A for only the performance measurement processing is performed using the emulator 200 will be described with reference to FIG. FIG. 7 is a diagram for explaining a second embodiment in which only performance measurement processing is performed using an emulator. The second embodiment shown in FIG. 7 differs from the first embodiment in that the WS 100 further includes a compiler 8 and a compile DB 9. The register unit 530 of the performance measuring unit 52 of the measurement additional circuit 51 is the same as that shown in FIG.

  In the second embodiment shown in FIG. 7, the writing process insertion unit 2a writes data to the start register A531 at the start of performance measurement target processing (hereinafter referred to as processing A. For example, audio processing). Then, a program for performing a process of writing to the end register A532 at the end time is inserted into the program 3, and the specified value generation unit 2 performs a process of setting the specified value in the specified value register A533 based on the performance requirement data 1. The specified value setting program 39 is inserted into the program 3 (step S21).

  Next, the conversion unit 4 generates the test program 5 by converting the program 3 into a memory format for simulation (step S22).

  The compiler 8 compiles the design data 6 and the test bench 7 for the collaborative verification unit 50a-2 that is an emulator, and stores it in the compile DB 9 in the storage unit (step S23). The process in step S23 may be performed before the process in step S21.

  Then, the compiled DB 9 including the compiled design data 6 and the test bench 7 is loaded into the collaborative verification unit 50a-2 and executed via the emulator I / F 20, whereby the verification target LSI 90m and the measurement additional circuit 51 are loaded. Are realized as a circuit model, and the test program 5 is loaded into the memory 93m and executed, whereby emulation is started (step S24).

  When the emulation is started, the CPU 91m of the LSI 90m to be verified activates the performance measurement unit 51 according to the test program 5 loaded in the memory 93m, and when the performance measurement process for the process A starts, the specified value (cycle) for the process A Number) is set in the specified value register A533 (step S25).

  The control unit 521 writes the start register A531 at the start of the process A by the verification target LSI 91m (step S26). Further, the control unit 521 resets the counter A534 (step S27). Thereafter, the counter A534 is counted up every cycle.

  At the end of the process A by the verification target LSI 91m, the control unit 521 writes in the end register A532 (step S28).

  The performance comparison unit 529 compares the counter value of the counter A534 with the specified value set in the specified value register A533 (step S29). When the comparison result by the performance comparison unit 529 indicates that the counter value of the counter A 534 is larger than the specified value of the specified value register A 533, the control unit 521 determines that there is a problem in performance and notifies the result collecting unit 54. As a result, the error flag managed in the memory 553 of the result storage unit 550 of the result collection unit 54 is set to 1.

  When the error flag indicates “1”, it indicates that it is determined that there is a problem in performance, and when it indicates “0”, it indicates that it is determined that there is no problem because the performance is within the specification. When receiving the setting of the error flag “1”, the result collection unit 54 stores the emulation result in the memory 553 of the result storage unit 550, sets “1” in the error flag in the memory 553, and stops the emulation. . You can choose whether to stop emulation.

  On the other hand, if the emulation is not stopped and the performance is within the specified range and there is no problem, the above steps S26 to S29 are repeated.

  In the following, the functional configuration and processing procedure related to the processing pattern B with only the function verification processing will be described in the case of being executed by the simulator (WS 100) and the case of being executed using the emulator 200, respectively.

  A processing procedure according to the third embodiment in which the processing pattern B of only the function verification processing is performed by the simulator (WS100) will be described with reference to FIG. FIG. 8 is a diagram for explaining a third embodiment in which only the function verification processing is performed by the simulator. In FIG. 8, the WS 100 further includes a description adding unit 10. The register unit 570 of the function verification unit 56 of the measurement additional circuit 51 includes an expected value generation data register 571, a comparison mode register B572, a comparison start register B573, and an expected value comparison error register B574.

  In the third embodiment shown in FIG. 8, the writing process insertion unit 2b has a comparison mode register B572 at the start of a function verification target process (hereinafter referred to as process B. For example, graphic process). A program for performing a process of writing to the comparison start register B573 and the expected value generation data register B571 is inserted into the program 3 (step S31).

  Next, the conversion unit 4 generates the test program 5 by converting the program 3 into a memory format for simulation (step S32).

  The description adding unit 10 adds a description of a process for importing input data to the internal memory or the external memory into the input unit 560 of the function verification unit 56 to the test bench 7 (step S33). The process in step S33 may be performed before the process in step S31.

  The CPU 11 executes the design data 6 and the test bench 7 loaded in the memory unit 12, thereby functioning as a cooperative verification unit 50b-1 that is a simulator, and the test program 5 is loaded into the memory 93m. Thus, the simulation is started (step S34).

  By starting the simulation, the CPU 91m of the LSI to be verified 90m activates the function verification unit 56 in accordance with the test program 5 loaded in the memory 93m, and starts the function verification process for the process B (step S35).

  The control unit 561 monitors the comparison start register B 573 and the input data fetched into the input unit 560, and when the comparison start condition is met, the expected value comparison unit 564 performs comparison with the expected value (step S36). Then, the control unit 561 writes the comparison result by the expected value comparison unit 564 in the expected value comparison error register B 574 (step S37).

  When the comparison result indicates a mismatch, the control unit 561 stores the mismatched address and input data in the memory 553 of the result storage unit 550 of the result collection unit 54 by notifying the result collection unit 54, and The result collection unit 54 is caused to set the error flag managed by the result storage unit 550 to 1 (step S38).

  When the error flag indicates “1”, it indicates that it is determined that there is a problem with the function, and when it indicates “0”, it indicates that it is determined that there is no problem with the function. When receiving the setting of the error flag “1”, the result collection unit 54 stores the simulation result in the memory 553 of the result storage unit 550, sets “1” in the error flag in the memory 553, and stops the simulation. . You can choose whether to stop the simulation.

  On the other hand, if the simulation is not stopped and there is no problem in function, the above-described steps S35 to S38 are repeated.

  A processing procedure according to the fourth embodiment in which the processing pattern B of only the function verification processing is performed using the emulator 200 will be described with reference to FIG. FIG. 9 is a diagram for explaining a fourth embodiment in which only function verification processing is performed by an emulator. The fourth embodiment shown in FIG. 9 is different from the third embodiment in that the WS 100 further includes a compiler 8 and a compile DB 9. The register unit 530 of the performance measurement unit 52 of the measurement additional circuit 51 is the same as that in FIG.

  In the fourth embodiment shown in FIG. 9, the writing process insertion unit 2b has a comparison mode register B572 at the start of a function verification target process (hereinafter referred to as process B. For example, graphic process). A program for performing a process of writing to the comparison start register B573 and the expected value generation data register B571 is inserted into the program 3 (step S41).

  Next, the conversion unit 4 generates the test program 5 by converting the program 3 into a memory format for simulation (step S42).

  The description adding unit 10 adds a description of a process for fetching input data to the internal memory or the external memory into the input unit 560 of the function verification unit 56 to the test bench 7 (step S43). The process in step S43 may be performed before the process in step S41.

  The compiler 8 compiles the design data 6 and the test bench 7 for the collaborative verification unit 50a-2 that is an emulator, and stores it in the compile DB 9 in the storage unit (step S44). The process in step S44 may be performed before the process in step S41.

  Then, the compiled DB 9 including the compiled design data 6 and the test bench 7 is loaded into the collaborative verification unit 50a-2 and executed via the emulator I / F 20, whereby the verification target LSI 90m and the measurement additional circuit 51 are loaded. Are realized as a circuit model, and the test program 5 is loaded into the memory 93m and executed, whereby emulation is started (step S45).

  With the start of emulation, the CPU 91m of the LSI to be verified 90m activates the function verification unit 56 in accordance with the test program 5 loaded in the memory 93m, and starts a function verification process for the process B (step S46).

  The control unit 561 monitors the comparison start register B 573 and the input data fetched into the input unit 560, and when the comparison start condition is met, the expected value comparison unit 564 compares the expected value (step S47). Then, the control unit 561 writes the comparison result by the expected value comparison unit 564 in the expected value comparison error register B 574 (step S48).

  When the comparison result indicates a mismatch, the control unit 561 stores the mismatched address and input data in the memory 553 of the result storage unit 550 of the result collection unit 54 by notifying the result collection unit 54, and The result collection unit 54 is caused to set the error flag managed by the result storage unit 550 to 1 (step S49).

  When the error flag indicates “1”, it indicates that it is determined that there is a problem with the function, and when it indicates “0”, it indicates that it is determined that there is no problem with the function. When receiving the setting of the error flag “1”, the result collection unit 54 stores the emulation result in the memory 553 of the result storage unit 550, sets “1” in the error flag in the memory 553, and stops the emulation. . You can choose whether to stop emulation.

  On the other hand, if the emulation is not stopped and there is no problem in function, the above-described steps S46 to S49 are repeated.

  The fifth and sixth embodiments relating to the processing pattern C by the performance measurement process and the function verification process will be described below. In the fifth and sixth embodiments, the configuration of each circuit model is as described in the first to fourth embodiments. Further, from the first to fourth embodiments, the processing pattern C by the performance measurement process and the function verification process can be executed by the simulator (WS100) or by using the emulator 200. is there.

  The simultaneous implementation of the performance measurement process and the function verification process includes the functional configuration of the first embodiment shown in FIG. 6 and the third embodiment shown in FIG. 8, that is, the LSI to be verified 90m and the additional circuit for measurement shown in FIG. 51 includes the functional configuration in the configuration A that realizes the entire 51 with the WS 100, or the second embodiment shown in FIG. 7 and the fourth embodiment shown in FIG. 9, that is, the LSI to be verified 90m and the additional circuit for measurement shown in FIG. 51 is any one of the configurations B in which the entire emulator 51 is realized by the emulator 200.

  In the following, regardless of the configuration A or the configuration B, the basic configuration 50C-1 that realizes a combination of the performance measurement process and the function verification process, and the configuration 50C- 2 will be described as a fifth embodiment and a sixth embodiment, respectively.

  In common with the fifth and sixth embodiments, the function verification unit 56 can be stopped when there is a problem in performance, and the performance measurement unit 52 can be stopped when there is a problem with function. If there is a problem in performance or function, the CPU 91m can be notified of the state via the result collection unit 54, and execution of simulation by the WS 100 or emulation by the emulator 200 can be stopped.

  In the sixth embodiment according to the configuration 50C-2 for searching for a condition for the current performance to satisfy the performance requirement, the clock frequency can be gradually lowered to search for a frequency that satisfies the performance requirement. When there is a problem in performance, it is possible to select a function and search for a combination of functions that satisfy the performance requirement. Furthermore, it is possible to search for a bus occupancy rate that satisfies the performance requirements.

  First, a fifth embodiment will be described with reference to FIG. FIG. 10 is a diagram for explaining a fifth embodiment for performing the performance measurement process and the function verification process. In FIG. 10, since the configuration of the circuit model is as illustrated in FIGS. 6 and 8, the cooperative verification unit 50c-1 shows the processing configuration and processes related to the combination of the performance measurement process and the function verification process. The procedure of the fifth embodiment will be described.

  In FIG. 10, when the test program 5 is loaded into the memory 93m of the verification target LSI 90m (step S71), the test process 98p is started by the CPU 91m of the verification target LSI 90m (step S72).

  By starting the test process 98p, the performance measurement unit 52 is activated (step S73), and the function verification unit 56 is activated (step S74). The order in which the performance measurement unit 52 and the function verification unit 56 are activated does not matter. Then, verification target processing related to processing A such as audio processing and processing B such as graphic processing is started. With respect to the verification target processing, performance measurement and functional verification are performed by the measurement additional circuit 51 in real time.

  By the activation of the performance measurement unit 52 in step S73 described above, steps S14, S15, and S16 in FIG. 6 or steps S25, S26, and S27 in FIG. 7 are performed, and the performance measurement process 52p is started. In the performance measurement process 52p, the value of the counter A534 counted up every cycle is compared with the specified value of the specified value register A533 (step S731). When the comparison result indicates that the value of the counter A 534 exceeds the specified value of the specified value register A 533 (NG), the result collection unit 54 is notified of the setting of the error flag “1”. The result collection unit 54 that has received the setting of the error flag “1” stops the simulation or emulation (step S76-2). You can choose whether to stop simulation or emulation.

  On the other hand, when the comparison result indicates that the value of the counter A 534 is equal to or less than the specified value of the specified value register A 533 (OK), it is determined whether or not the processing is completed (step S735). If the process has not ended (NO), the performance measurement process 52p returns to step S731, and performs the same comparison process described above in the next cycle. On the other hand, when the process is finished (YES), the result collecting unit 54 is notified that the process is finished.

  By the activation of the function verification unit 56 in step S74 described above, step S35 in FIG. 8 or step S46 in FIG. 9 is performed, and the function verification process 56p is started. In the function verification process 56p, the input data is compared with the expected value (step S741). If the comparison result indicates a mismatch (NG), step S37 in FIG. 8 or step S48 in FIG. 9 is executed, and the setting of the error flag “1” is notified to the result collection unit 54. The result collection unit 54 that has received the setting of the error flag “1” stops the simulation or emulation (step S76-2). You can choose whether to stop simulation or emulation.

  On the other hand, when the comparison result indicates coincidence (OK), it is determined whether or not the processing is completed (step S735). If the process has not ended (NO), the function verification process 56p returns to step S743, and performs the same comparison process described above with the next input data. On the other hand, when the process is finished (YES), the result collecting unit 54 is notified that the process is finished.

  The result collection unit 54 notifies the test process 98p of the comparison results collected by the notification from the performance measurement unit 52 and the function verification unit 56 (result collection in the test process 98p: step S76).

  In the test process 98p, referring to the comparison result collected from the result collection unit 54 of the measurement additional circuit 51, the comparison result is determined by the performance measurement unit 52 and the function verification unit 56 (comparison determination: step S77). When it is determined that there is a problem in performance or / and function by determining the comparison result (NG), a test result indicating that there is a problem in performance or / and function is displayed on the display unit 13 (step S78-1). ), The test process 98p ends (step S79).

  On the other hand, when it is determined that there is no problem in performance or / and function (OK), a test result indicating that there is no problem in performance or / and function is displayed on the display unit 13 (step S78-2). The process 98p ends (step S79).

  Next, a sixth embodiment according to the configuration 50C-2 for searching for a condition for the current performance to satisfy the performance requirement will be described with reference to FIG. FIG. 11 is a diagram for explaining a sixth embodiment for performing the performance measurement process and the function verification process. In FIG. 11, the same steps as those in FIG. 10 are denoted by the same reference numerals, and the description thereof is omitted. Since the configuration of the circuit model is as illustrated in FIGS. 7 and 9, the cooperative verification unit 50 c-2 shows the processing configuration, and the processing procedure related to the combination of the performance measurement process and the function verification process. A sixth embodiment will be described.

  In the sixth embodiment, in the test process 98p, a test is performed using a plurality of patterns corresponding to different performance requirements in order to search for a condition for the current performance to satisfy the performance requirements. Each pattern is started by activation of the performance measurement unit 52 in step S73 and activation of the function verification unit 56 in step S74.

  Then, for each pattern, the processing up to step S77 is executed as described in FIG. 10, and whether or not all the patterns have been implemented after the test results are displayed on the display unit 13 in step S78-1 or S78-2. Is determined (step S78-3). If there is a pattern that has not yet been implemented (NO), the process returns to step S73 to implement the next pattern, and the same processing as described above is repeated.

  On the other hand, when all the patterns have been implemented (YES), the test process 98p ends (step S79).

  In the search for a condition for the current performance to satisfy the performance requirement, the specified value generation unit 2 prepares a plurality of specified values in the test program 98p. During execution of cooperative verification by the simulator (WS 100) or using the emulator 200, the test process 98p automatically changes the specified value to search for a condition for the performance to satisfy the performance requirement. There is a frequency as a condition, and for each different frequency, a specified value indicating the performance requirement by the number of cycles is calculated by the first example of the specified value calculation method.

  A first search example for searching for a frequency satisfying the performance requirement will be described with reference to FIG. FIG. 12 is a diagram for explaining a first search example for searching for a frequency. In FIG. 12, when the determination 1 with the specified value 1 based on the first frequency “100 MHz” and the performance requirement “33 ms” indicates that the verification target process has not ended within the specified value 1 (NG in S733). The LSI developer will reconsider the frequency or performance requirements to be met.

  On the other hand, when the determination 1 based on the specified value 1 indicates that the verification target process is completed within the specified value 1 (OK in S735), the determination is performed using the pattern of the specified value 2. If the determination 2 based on the specified value 2 based on the second frequency “90 MHz” and the performance requirement “33 ms” indicates that the verification target processing has not ended within the specified value 2 (NG in S733), the LSI developer Determines that the condition of the first specified value 1 is the limit.

  On the other hand, when the determination 2 based on the specified value 2 indicates that the verification target process is completed within the specified value 2 (OK in S735), the determination is made with the pattern of the specified value 3. By repeating such processing for each specified value 1, 2,..., A condition that satisfies the performance requirement is searched.

  The specified value 1 indicates the number of cycles “3,300,000” calculated according to the first example of the specified value calculation method shown in FIG. The specified value 2 also indicates the cycle number “2,970,000” calculated in the same manner.

  FIG. 13 is a flowchart for explaining an outline of processing in the first search example of FIG. In FIG. 13, in a test process 98p performed by the test program 5, a pattern is selected from the program configuration DB 71 (step S81).

  The program of the selected pattern is executed by the CPU 91m (step S82). At the start of execution, a specified value corresponding to the pattern is set in the performance measurement unit 52. Specifically, it is set in the specified value register A 533 (FIG. 6 or FIG. 7) in the register unit 530 of the performance measuring unit 52.

  Then, the comparison result with the specified value by the performance measuring unit 52 is written in the result storage unit 550 of the result collection unit 54 (step S83).

  Thereafter, in the test process 98p, it is determined whether or not all patterns have been implemented (step S84). If the execution of all the patterns has not been completed, the process returns to step S81, the next pattern is selected in the test process 98p, and the same process as described above is repeated. On the other hand, when all the patterns are implemented, the test process 98p ends.

  The program configuration DB 71 includes a program corresponding to the search pattern included in the test program 5. This example shows that patterns 1, 2, 3,... Are included for searching. The selection of the pattern is performed under severe conditions. When the comparison result is NG, the simulation is immediately terminated. The comparison judgment for each pattern is displayed on the display unit 13 so that the LSI developer can know the frequency search result.

  When the pattern 1 is selected, in the performance measurement process 52p, a comparison with the specified value 1 calculated based on the frequency “100 MHz” and the performance requirement “33 ms” is performed. Next, when the pattern 2 is selected, in the performance measurement processing 52p, a comparison is made with the specified value 2 calculated based on the frequency “90 MHz” and the performance requirement “33 ms”. Further, when the pattern 3 is selected, in the performance measurement process 52p, a comparison is made with the specified value 3 calculated based on the frequency “80 MHz” and the performance requirement “33 ms”.

  Next, in the configuration 50C-2 shown in FIG. 11, a second search example in which a combination of a plurality of functions is prepared in the test program 5, the performance measurement process 52p is performed for each combination, and a combination satisfying the performance requirement is searched. Will be described.

  FIG. 14 is a diagram for explaining a second search example for searching for a combination of functions. In the second search example shown in FIG. 14, a combination of functions “A1, A2, and A3”, “A1 and A2”, and “A1 and A3” are prepared in the test program 5 and simulated (or emulated). ), A combination of functions is selected to search for a combination that satisfies the performance requirements.

  As an example of the combination of functions, function A1 shows image reduction, function A2 shows part of the image in black and white, and function A3 shows image enlargement.

  The combination of the function A1, the function A2, and the function A3 is performed for the first time under the restriction of the performance requirement “33 ms”. As a result, although it was OK in the function verification, in the performance measurement, the time required to complete the functions A1 to A3 was 40 ms, which was NG exceeding the processing time of the performance requirement 33 ms.

  Under the same constraint, the combination of the function A1 and the function A2 is performed for the second time. Unlike the first time, the function A3 is not executed. As a result, the function verification was OK and the required time was 33 ms in the performance measurement, and the OK determination was made without exceeding the processing time of the performance requirement of 33 ms. In this example, it can be seen that the performance requirement cannot be satisfied by the first combination of functions, but the performance requirement is satisfied by the second combination of functions. In this way, it is possible to search for which combination satisfies the performance requirement.

  FIG. 15 is a flowchart for explaining an outline of processing in the second search example of FIG. In FIG. 15, in the test processing 98p performed by the test program 5, a pattern is selected from the program configuration DB 72 (step S91).

  The program of the selected pattern is executed by the CPU 91m (step S92). The specified value is set in the performance measurement unit 52 at the start of execution. In the second search example based on this combination of functions, the specified value set in the performance measurement unit 52 does not change in frequency, so it is uniform regardless of which pattern is selected.

  Then, the comparison result with the specified value by the performance measuring unit 52 is written in the result storage unit 550 of the result collection unit 54 (step S93).

  Thereafter, in the test process 98p, it is determined whether or not all patterns have been implemented (step S94). If the execution of all patterns has not been completed, the process returns to step S91, the next pattern is selected in the test process 98p, and the same process as described above is repeated. On the other hand, when all the patterns are implemented, the test process 98p ends.

  The program configuration DB 72 includes a program corresponding to the search pattern included in the test program 5. This example shows that pattern 1 (serial), pattern 2 (serial), pattern 3 (parallel),... Are included for searching.

  Pattern 1 (serial) is a pattern performed in the order of function A1, function A2, and function A3. Pattern 2 (serial) is a pattern performed in the order of function A1 and function A2. Pattern 3 (parallel) is a pattern in which the function A1 and the function A3 are performed in parallel and the function A2 is performed.

  The required time required until the program of the selected pattern is completed is compared with the specified value, and the comparison result is notified to the test processing 98p via the result collection unit 54.

  As a third search example, a case will be described in which the combination of functions is the same, but the input image size is changed to search for a condition (input image size) that satisfies the performance requirements. FIG. 16 is a diagram for explaining a third search example for searching for a condition that satisfies the performance requirements in the same combination of functions.

  In the third search example shown in FIG. 16, input image data having a plurality of input image sizes is prepared in the test program 5, and the input image size is changed and combined during execution of simulation (or emulation). Search for a condition “input image size” that satisfies the performance requirements of the function.

  As an example of the combination of functions, functions A1, A2, and A3 are shown. The function A1 is image reduction, the function A2 is black and white of a part of the image, and the function A3 is image enlargement.

  Under the constraint of the performance requirement “33 ms”, the first operation is performed using the input image data of the input image size “1024 × 768” by the combination of the function A1, the function A2, and the function A3. As a result, although it was OK in the function verification, in the performance measurement, the time required to complete the functions A1 to A3 was 40 ms, which was NG exceeding the processing time of the performance requirement 33 ms.

  In the combination of the same performance requirement and the same function, the input image size is changed to “800 × 600” and the second time is performed. As a result, the function verification was OK and the required time was 33 ms in the performance measurement, and the OK determination was made without exceeding the processing time of the performance requirement of 33 ms. In this example, it can be seen that the first input image size “1024 × 768” cannot satisfy the performance requirement, but the second input image size “800 × 600” satisfies the performance requirement. In this way, in the combination of functions, it is possible to search for which condition satisfies the performance requirement.

  Next, a case where a bus occupancy rate is designated as a performance requirement instead of a required time will be described. The bus occupancy ratio, which is a performance requirement, is indicated by a specified value that can be counted by the specified value generation unit 2, as shown in the second example of the specified value calculation method in FIG. FIG. 17 is a diagram for explaining the performance measurement based on the bus occupancy rate. FIG. 17 shows a case in which a verification target LSI 95m having a CPU 96m, a Codec 97m, and a MEMC 98m and an SDRAM 99m controlled by the MEMC 98m are circuit models to be tested. The bus monitors 6a, 6b, 6c, and 6d are incorporated in order to monitor the amount of processing to be verified for each circuit model, and the bus occupancy is acquired every predetermined time.

  By incorporating such bus monitors 6a, 6b, 6c, and 6d, it is possible to verify the bus occupancy 17a in the verification target LSI 90m and the bus occupancy 17b outside the verification target LSI 90m, respectively. For example, when the bus occupancy “50%” is a specified value, the period 17t that exceeds the specified value is known, so that the design related to the performance of the verification target LSI can be reviewed effectively.

  A modified example of the fifth embodiment for performing the performance measurement process and the function verification process when the performance requirement is set to the bus occupation ratio “50%” or less will be described with reference to FIG. FIG. 18 is a diagram for explaining a modification of the fifth embodiment.

  In the modification shown in FIG. 18, the function combination “A1, A2, and A3” is executed by the test program 5, and the function verification processing 56p and the performance are performed in accordance with the specified performance requirement that the bus occupancy is “50%” or less. The case where the measurement process 52p is performed is shown.

  As an example of the combination of functions, function A1 shows image reduction, function A2 shows part of the image in black and white, and function A3 shows image enlargement.

  In this example, the function verification was OK under the constraint of the bus occupancy rate of 50% or less, but in the performance measurement, there is a period when the bus occupancy rate is “60%” at the maximum, and the bus occupancy rate 50% of the performance requirement. It was NG beyond. The performance measurement shows that there was a time when the bus occupancy rate of 50% of the performance requirement was exceeded during execution of the functions A1 to A3.

  The bus occupancy for every predetermined time is collected and accumulated by the result collection unit 54, and the test result after the program execution is displayed on the display unit 13, so that the maximum value of 60% of the bus occupancy at time 110ms is obtained. It can be seen that the results are shown. Thus, it can be known in which period the performance requirement could not be satisfied.

  Next, a modified example of the sixth embodiment for searching for a condition “input image size” satisfying a bus occupancy ratio of 50% or less as a performance requirement by combining the same functions will be described. FIG. 19 is a diagram for explaining a modification of the sixth embodiment.

  In the modified example of the sixth embodiment shown in FIG. 19, input image data of a plurality of input image sizes are prepared in the test program 5, and the input image size is changed during the execution of simulation (or emulation). The condition “input image size” satisfying the performance requirement of the combination function is searched. The difference from the third search example shown in FIG. 16 is that “50% bus occupancy” or less is specified as the performance requirement.

  As an example of the combination of functions, functions A1, A2, and A3 are shown. The function A1 is image reduction, the function A2 is black and white of a part of the image, and the function A3 is image enlargement.

  The first time is performed using the input image data of the input image size “1024 × 768” with the combination of the function A1, the function A2, and the function A3 under the constraint that the bus occupation ratio is 50% or less. As a result, the function verification was OK, but the performance measurement was NG because there was a period exceeding “50%” in the bus occupancy for every predetermined time from the end of functions A1 to A3.

  In the combination of the same performance requirement and the same function, the input image size is changed to “800 × 600” and the second time is performed. As a result, the function verification was OK, and in the performance measurement, the bus occupancy at every predetermined time was “50%” or less, so the determination was OK. In this example, it can be seen that the first input image size “1024 × 768” cannot satisfy the performance requirement, but the second input image size “800 × 600” satisfies the performance requirement. In this way, it is possible to search under which conditions the performance requirement is satisfied in the combination of functions.

  In addition, it is possible to know in which period the performance requirement is not satisfied, and it is possible to verify a place where the performance falls when the functions are combined. By referring to the first and second result examples, the function A2 satisfies the performance requirement when the input image size is “1024 × 768” in the serial processing of the function A1-> function A2-> function A3. It is easy to verify that there is no period.

  FIG. 20 is a flowchart for explaining an outline of processing in a modification of the sixth embodiment of FIG. In FIG. 20, in the test process 98p performed by the test program 5, a pattern is selected from the input image size DB 73 (step S101).

  The predetermined program is executed by the CPU 91m (step S102). The specified value is set in the performance measurement unit 52 at the start of execution. In this modified example, the specified value set in the performance measuring unit 52 is not affected by the selection of the pattern, and therefore, no matter which pattern is selected, the bus occupancy is 50% or less and is uniform.

  Then, the comparison result with the specified value by the performance measuring unit 52 is written in the result storage unit 550 of the result collection unit 54 (step S103).

  Thereafter, in the test process 98p, it is determined whether or not all patterns have been implemented (step S104). If the execution of all patterns has not been completed, the process returns to step S101, the next pattern is selected in the test process 98p, and the same process as described above is repeated. On the other hand, when all the patterns are implemented, the test process 98p ends.

  The input image size DB 73 includes a pattern for searching for a condition that satisfies the performance requirements. The input image size DB 73 manages input image data having different input image sizes for each pattern. In this example, it is shown that the search condition includes a pattern 1 with an input image size “1024 × 768”, a pattern 2 with an input image size “800 × 600”,.

  Next, various usage examples of the performance measurement result by the configuration 50C-2 of the sixth embodiment shown in FIG. 11 in which the bus occupancy is a performance requirement will be described. A description will be given of a case where various multimedia-compatible LSIs capable of navigation, video reproduction, and music reproduction mounted on a vehicle or the like are verified using the configuration 50C-2 of the sixth embodiment.

  FIG. 21 is a diagram illustrating an example of a circuit model configuration of a multimedia-compatible LSI. FIG. 21 illustrates a circuit model to be verified. Various multimedia compatible LSI 300m includes CPU 301m, DMAC 302m, MEMC 303m, image processing circuit 305m, display controller 306m, CD / BD / DVD I / F 307m, HDD I / F 308m, and audio I / F 309m. And are connected to each other via a bus 330m.

  The SDRAM 313m is connected to the MEMC 303m. The displays 315m and 316m are connected to the display controller 306m. A CD / BD / DVD 317m is connected to the CD / BD / DVD I / F 307m. The HDD 318 is connected to the HDD I / F 308m. A speaker 319m is connected to the audio I / F 309m. In such a circuit model to be verified, the bus monitors 9a to 9k are incorporated in order to monitor the verification target processing amount, and the bus occupancy is acquired every predetermined time.

  FIG. 22 is a diagram showing a search example of performance limits of the multimedia-compatible LSI shown in FIG. FIG. 22 shows an example in which the performance limit is searched by performance measurement when the performance requirement is set to 50% or less of the bus occupation ratio. In the first pattern A, a combination of three functions including navigation, DVD video reproduction, and CD ripping including reproduction is performed. The total result 22a of all bus monitors is obtained by the performance measurement process 52p. Such a total result 22a indicates that there are periods exceeding 60% or less of the bus occupancy rate of the performance requirement between 60 ms and 90 ms, and 170 ms, and it becomes clear that the three functions cannot be operated simultaneously. .

  In the second pattern B, a combination of three functions different from the pattern A for navigation, DVD video reproduction, and HDD reproduction is performed. In this combination of functions, the HDD reproduction stores CD ripped data in the HDD 318m in advance, and reproduces music from the HDD 318m. The total result 22b of all bus monitors is obtained by the performance measurement process 52p. From such a total result 22b, it can be seen that the combination of functions for reproducing music from the HDD 318m can satisfy the bus occupancy of 50% or less of the performance requirement, and there is no problem in performance.

  For example, as illustrated in FIG. 23, the verification target processing related to music reproduction between the CPU 301m and the SDRAM 313m via the MEMC 303m in the pattern A and between the SDRAM 313m and the HDD 318m via the MEMC 303m is reduced in the pattern B. Thus, it is considered that the bus occupancy ratio of 50% or less as a performance requirement could be satisfied.

  FIG. 24 is a flowchart for displaying the results of the bus monitor. In FIG. 24, when the simulation is started (step S121), a predetermined program is executed (step S122). The performance measurement unit 52 notifies the measurement data 24a measured by the bus monitor to the result collection unit 54 every predetermined time, and writes it in the memory 553 of the result storage unit 550 (step S123).

  When the simulation ends (step S124), the data 24a written in the memory 553 of the result storage unit 550 is processed to obtain a csv file 24b (step S125). And the graph 24c which shows the measurement result produced using the csv file 24b is displayed on the display unit 13 (step S126).

  The measurement data 24a is recorded in a hexadecimal number in the memory 553 of the result storage unit 550, and includes read number data 25a and write number data 25b. The number-of-reads data 25a indicates the number of times of reading every predetermined time. Similarly, the number-of-writes data 25b indicates the number of times of writing every predetermined time.

  The measurement data 24a is processed into a csv file 24b expressed in decimal numbers. In the csv file 24b, the number of reads and the number of writes are recorded in association with each of numbers 0, 1, 2,... representing a predetermined time interval. The csv file 24b may be processed in S78-1 for performing test result display (NG) or S78-2 for performing test result display (OK) in the test process 98p shown in FIG.

  In the graph 24c showing the measurement results, the vertical axis represents the SDRAM bus occupancy, and the horizontal axis represents the time axis. By displaying the graph 24c indicating the measurement result on the display unit 13, the developer can easily visually confirm the period when the bus occupancy rate of 50% of the constraint requirement is not satisfied.

  In the circuit model configuration example of FIG. 21, the developer can perform more detailed analysis by recording the measurement data 24a for each of the bus monitors 9a to 9k. By displaying the measurement results obtained from the bus monitors 9a to 9k as graphs, performance can be improved by bottleneck analysis.

  FIG. 25 is a diagram for explaining an example of bottleneck analysis. In FIG. 25, as a result of performing a bottleneck analysis from all the measurement results obtained from each of the bus monitors 9a to 9k in the circuit model configuration example of FIG. 21, the bus occupancy rate of the SDRAM 313m from the graph 25c showing the bus occupancy rate of the SDRAM 313m. An example of a problem found in is shown.

  Referring to the graph 25c, it can be seen that there is a period in which the bus occupancy rate of the SDRAM 313m exceeds the bus occupancy rate 50% of the performance requirement. Therefore, the developer can determine that it is necessary to improve performance such as improving MEMC 303m, changing the type of SDRAM 313m, and increasing the frequency of SDRAM 313m.

  It is also possible to determine whether there is a margin in the performance of the LSI 300m using the measurement result of the bus occupancy rate. By determining the margin of performance, LSI development with reduced power consumption can be considered. For example, when only the navigation function and the HDD playback function need be performed, the performance margin by this combination can be verified by setting the bus occupancy rate as a performance requirement.

  FIG. 26 is a diagram for explaining a verification example of the performance margin using the bus occupancy rate. Referring to the graph 26c showing the measurement result of the bus occupancy exemplified in FIG. 26, even at the time of 70 ms when the bus occupancy becomes the maximum, a margin of 20% or more can be obtained up to the bus occupancy of 50% of the performance requirement. I know that there is.

  Therefore, the designer can determine that the power consumption can be reduced by lowering the frequency. As a result, it is possible to make a design change related to a change in frequency so as to obtain an LSI 300m that supports energy saving.

  As described above, in the verification system according to the present embodiment, in the LSI design, in the implementation of the collaborative verification by software and hardware by the simulator or emulator, not only the verification that the LSI design is logically correct, Measure the processing time of the program, measure the processing of individual parts (functions) of the program, and verify whether the performance requirements are satisfied with respect to the processing of individual parts (functions) of the program it can.

  It is possible to search for a clock frequency, a combination of functions, an input image size, and the like that satisfy performance requirements, to obtain information for design improvement, and to improve performance before manufacturing an LSI.

  The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of the claims.

The following additional notes are further disclosed with respect to the embodiments including the first to sixth examples.
(Appendix 1)
A collaborative verification method by software and hardware of a design circuit executed by a computer,
Set a countable specified value based on performance requirements in the specified value register at the start of the collaborative verification of the design circuit,
During the execution of the collaborative verification, the operation of the design circuit according to the performance requirement is counted,
A collaborative verification method characterized in that performance measurement is performed by comparing the counted value with the specified value set in the specified value register.
(Appendix 2)
The collaborative verification method according to claim 1, wherein the specified value is the number of cycles calculated based on a processing time specified by the performance requirement and a clock frequency indicated by design data of the design circuit. .
(Appendix 3)
The program loaded in the design circuit includes a plurality of specified values based on different clock frequencies, and the clock frequency satisfying the performance requirement is searched by changing the specified values during the execution of the cooperative verification. The cooperative verification method according to Supplementary Note 2, which is a feature.
(Appendix 4)
The specified value is a bus occupation rate specified by the performance requirement and a bus cycle number per unit time specified by a bus operating frequency and resolution indicated by design data of the design circuit. The cooperative verification method according to 1.
(Appendix 5)
A program loaded in the design circuit includes a combination of a plurality of functions, and the combination of the functions satisfying the performance requirement is searched by changing the combination of the functions during the execution of the cooperative verification. The cooperative verification method according to Supplementary Note 1.
(Appendix 6)
The input image that includes the combination of one function and a plurality of input image sizes in the program loaded in the design circuit, and satisfies the performance requirements by changing the input image size during the collaborative verification. The cooperative verification method according to supplementary note 1, wherein the size is searched.
(Appendix 7)
The cooperative verification method according to appendix 5 or 6, wherein the combination of functions includes a combination executed serially or in parallel.
(Appendix 8)
Every predetermined time, the number of reads and writes to the memory of the design circuit by the bus monitor in the design circuit is stored in the result storage unit,
Process the read count and write count indicated in hexadecimal into a data file indicated in decimal,
The cooperative verification method according to appendix 1 or 4, wherein a graph representing the bus occupation state in a time series is displayed on the display unit.
(Appendix 9)
A collaborative verification device that performs collaborative verification by software and hardware of a design circuit,
Having an additional circuit for measurement having at least a performance measuring unit and a result collecting unit;
The performance measurement unit
A prescribed value register in which a prescribed value that can be counted based on the performance requirement of the design circuit is set;
A counter register that counts the operation of the design circuit according to the performance requirements during the execution of the collaborative verification;
A performance comparison unit that compares the value of the counter register with the specified value set in the specified value register;
The result collection unit includes a result storage unit that stores a result of the performance comparison unit.
(Appendix 10)
The additional circuit for measurement further includes a function verification unit,
The function verification unit
An input unit for inputting data processed by the design circuit;
A function comparison unit that compares the data input by the input unit with expected value data;
The cooperative verification apparatus according to appendix 9, wherein the result collection unit stores the result of the function comparison unit in the result storage unit.
(Appendix 11)
The cooperative verification apparatus according to appendix 9 or 10, wherein the result collection unit stops the cooperative verification when an error is detected in the performance measurement unit or the function verification unit.
(Appendix 12)
12. The cooperative verification device according to appendices 9 to 11, wherein the measurement additional circuit is a circuit described in a hardware description language.
(Appendix 13)
13. The cooperative verification apparatus according to any one of supplementary notes 9 to 12, wherein the cooperative verification apparatus is a simulator or an emulator.
(Appendix 14)
Setting a countable specified value based on performance requirements in the specified value register at the start of the collaborative verification by the software and hardware of the design circuit,
During the execution of the collaborative verification, the operation of the design circuit according to the performance requirement is counted,
A program for causing a computer to execute a process of measuring performance by comparing the counted value with the specified value set in the specified value register.

DESCRIPTION OF SYMBOLS 1 Performance requirement data 2 Specified value production | generation part 2a Write processing insertion part 3 Program 4 Conversion part 5 Test program 6 Design data (verification object LSI)
7 Test bench 8 Compiler 8a Specified value calculation data 8b Specified value calculation data 9 Compile DB
11 CPU
DESCRIPTION OF SYMBOLS 12 Memory unit 13 Display unit 14 Output unit 15 Input unit 16 Communication unit 17 Storage device 18 Driver 19 Storage medium 39 Regulation value setting program 50 Cooperative verification part 50a-1, 50b-1 Cooperative verification part (simulator)
50a-2, 50b-2 Cooperative verification unit (emulator)
50c-1, 50c-2 Cooperative verification unit (simulator or emulator)
51 Additional Circuit for Measurement 52 Performance Measurement Unit 54 Result Collection Unit 56 Function Verification Unit 58 Expected Value Data 90m Verification Target LSI
91m CPU
93m Memory 521 Control unit 529 Performance comparison unit 530 Register unit 531 Start register A
532 End register A
533 Default register A
534 Counter A
541 Control unit 550 Result storage unit 553 Memory 560 Input unit 561 Control unit 562 Expected value generation unit 563 Expected value storage memory 564 Expected value comparison unit 570 Register unit 571 Expected value generation data register B
572 Comparison mode register B
573 Comparison start register B
574 Expected value comparison error register B
1000 verification system

Claims (5)

A collaborative verification method by software and hardware of a design circuit executed by a computer,
Set a countable specified value based on performance requirements in the specified value register at the start of the collaborative verification of the design circuit,
During the execution of the collaborative verification, the operation of the design circuit according to the performance requirement is counted,
A collaborative verification method characterized in that performance measurement is performed by comparing the counted value with the specified value set in the specified value register.   The collaborative verification according to claim 1, wherein the specified value is a cycle number calculated based on a processing time specified by the performance requirement and a clock frequency indicated by design data of the design circuit. Method.   The program loaded in the design circuit includes a plurality of specified values based on different clock frequencies, and the clock frequency satisfying the performance requirement is searched by changing the specified values during the execution of the cooperative verification. The cooperative verification method according to claim 2, wherein:   The specified value is a bus occupation rate specified by the performance requirement and a bus cycle number per unit time specified by a bus operating frequency and resolution indicated by design data of the design circuit. Item 4. The cooperative verification method according to Item 1. A collaborative verification device that performs collaborative verification by software and hardware of a design circuit,
Having an additional circuit for measurement having at least a performance measuring unit and a result collecting unit;
The performance measurement unit
A prescribed value register in which a prescribed value that can be counted based on the performance requirement of the design circuit is set;
A counter register that counts the operation of the design circuit according to the performance requirements during the execution of the collaborative verification;
A performance comparison unit that compares the value of the counter register with the specified value set in the specified value register;
The result collection unit includes a result storage unit that stores a result of the performance comparison unit.