JP7112232B2 - Arithmetic unit verification device - Google Patents

Description

The present invention relates to a verification device for arithmetic units, and in particular, for arithmetic units that handle floating-point numbers, it is possible to ensure completeness of verification focusing on possible internal values and possible exceptions, and to perform highly reliable verification. The present invention relates to a device for verifying a computing unit suitable for performing

High safety is required for some of the instrumentation control devices for industrial equipment. For example, if a nuclear power plant fails, it will have a great impact on human society and the surrounding environment, so it is essential to reduce the risk of failure to an acceptable level. Therefore, it is required that the arithmetic applications executed on the instrumentation control device for these industrial equipments are error-free, that is, bug-free. Since the unit module that plays the core of the calculation of various numerical calculation functions used in arithmetic applications is a floating point arithmetic unit, it is necessary to go through the correct development process so that bugs do not occur in the floating point arithmetic unit. . For the purpose of preventing bugs, verification is the most important part of the floating-point arithmetic unit development process. Floating-point calculators are much more complex than fixed-point calculators, and there are many special calculation cases that tend to be overlooked in the calculation input patterns. If possible, the correctness of the design should be proved by inputting all input patterns to the floating-point arithmetic unit and checking the correctness of the output values during verification. However, for adders and multipliers with two inputs, when the precision is single precision (32 bits), the number of input patterns is 2 to the 64th power. is virtually impossible.

Therefore, since it is necessary to complete verification in a realistic number of man-hours, the concept of coverage is introduced to determine how much the current verification progress is sufficient for the overall verification parameters for verifying all input patterns. need to be measured quantitatively.

Regarding verification by coverage, for example, in Patent Document 1, in circuit verification on the premise of RTL (Register Transfer Level) description, line coverage that measures how many lines are executed in simulation among all descriptions of RTL description is described. (Paragraph No. 0002).

JP-A-2008-59032

The application range of the verification progress measurable by the line coverage of the circuit described by the circuit description language of the RTL description described in Patent Document 1 is general fixed-point arithmetic units and control circuits, and complex floating-point There are problems that are not applicable to special arithmetic cases of arithmetic units. This is because the operation of the floating-point calculator is complicated, and the combinations of input patterns of input values to be verified and the output patterns of their output values are enormous as described above.

Thus, in the conventional coverage measurement, the relationship between the values that can be taken inside the floating-point arithmetic unit and the coverage is focused only on the combination of the input pattern of the input values and the output pattern of the output values. is not considered. Even if the number of combinations of input patterns of input values and output patterns of output values is enormous, when there are few patterns of values that can be taken inside the floating-point arithmetic unit, verification is performed by focusing on the values. By doing so, the coverage value can be increased, and the reliability of verification can be improved. However, the measurement of circuit verification coverage in Patent Document 1 does not suggest how to do it.

In addition, various exceptions (for example, division by zero and overflow) are defined for floating-point arithmetic units. Verification of input value boundaries where such exceptions can occur is of great significance in improving the reliability of floating-point arithmetic units. However, in the coverage measurement of circuit verification in Patent Document 1, there is no suggestion as to how coverage should be measured at boundaries of input values where exceptions can occur.

SUMMARY OF THE INVENTION It is an object of the present invention to provide an arithmetic unit verification apparatus capable of quantitatively measuring the progress of verification of a special operation case of a floating-point arithmetic unit and performing highly reliable verification. .

The configuration of the arithmetic unit verification apparatus of the present invention is preferably an arithmetic unit verification apparatus for verifying an arithmetic unit whose function is described in a hardware description language based on RTL (Register Transfer Level) description, wherein the hardware description It has a logic simulator that interprets and executes a language and outputs an output value for an input value, and a high-reliability arithmetic unit that performs a specified operation on the input value and outputs an expected value, and the output of the logic simulator. A dynamic verification device for verifying a computing unit whose function is described in a hardware description language by comparing the output value of the high-reliability computing unit with the expected value output by the high-reliability computing unit. The device refers to an intermediate port used inside a module described in a hardware description language, calculates the coverage of verification for possible values of a certain intermediate port, and outputs it as intermediate value coverage. It is the one that was made.

Further, the configuration of the arithmetic unit verification apparatus of the present invention is preferably an arithmetic unit verification apparatus for verifying an arithmetic unit whose function is described in a hardware description language by RTL description, and interprets the hardware description language. A logic simulator that executes and outputs an output value for an input value, and a highly reliable computing unit that performs a specified operation on the input value and outputs an expected value, and the output value output by the logic simulator and an expected value output from the highly reliable computing unit to verify the computing unit whose function is described in a hardware description language, the dynamic verification unit verifying the computing unit, The coverage of verification with respect to boundary values where exceptions occur in input values of a module described in a hardware description language is calculated and output as exception generation boundary coverage.

According to the present invention, it is possible to provide an arithmetic unit verification apparatus capable of quantitatively measuring the progress of verification of a special operation case of a floating-point arithmetic unit and performing highly reliable verification. .

1 is a functional configuration diagram of a verification device for a floating-point arithmetic unit; FIG. 1 is a diagram showing the circuit configuration of a floating-point arithmetic unit to be verified, and the contents of SVA, RTL, and LIB corresponding to the circuit configuration; FIG. 1 is a hardware/software configuration diagram of a verification device for a floating-point arithmetic unit; FIG. 3 is a functional configuration diagram of a dynamic verification device; FIG. It is a functional block diagram of the measuring side part of a dynamic verification apparatus. 4 is a functional configuration diagram of an input generation unit; FIG. 10 is a flowchart showing the overall processing of the verification device for floating-point arithmetic units; 4 is a flowchart showing formal verification processing; 4 is a flowchart showing dynamic verification processing by a dynamic verification device; FIG. 10 is a diagram showing an execution image of intermediate-value-oriented dynamic verification in a logic simulator; FIG. 11 is a flow chart showing the process of intermediate value-oriented dynamic verification; FIG. FIG. 11 is a flowchart showing processing for a port to be inspected; FIG. It is a flow chart which shows the processing of the test object shortage median value. FIG. 10 is a diagram showing an example of verification contents of exception occurrence boundary-oriented dynamic verification in an adder; FIG. 11 is a flow chart showing a process of exception occurrence boundary-oriented dynamic verification in an adder; FIG. FIG. 10 is a flow chart showing the process of boundary search and collation around (X1, X2); FIG. FIG. 10 is a diagram showing an example of verification contents of exception occurrence boundary-oriented dynamic verification in a multiplier; FIG. 11 is a flow chart showing a process of exception occurrence boundary-oriented dynamic verification in a multiplier; FIG. FIG. 10 is a diagram showing an example of verification contents of exception occurrence boundary-oriented dynamic verification in a divider; FIG. 11 is a flow chart showing a process of exception occurrence boundary-oriented dynamic verification in a divider; FIG. 10 is a flow chart showing processing of dynamic verification using perfect random numbers.

An embodiment according to the present invention will be described below with reference to FIGS. 1 to 21. FIG.

First, the configuration of a verification apparatus for a floating-point arithmetic unit according to an embodiment of the present invention will be described with reference to FIGS. 1 to 6. FIG.
The floating-point arithmetic unit verification apparatus described in this embodiment confirms that the function of the floating-point arithmetic unit to be verified is described in a hardware description language (for example, Verilog HDL) having an RTL description level. It is assumed.

First, the basic concept of the hardware description language related to the data input to the floating-point arithmetic unit verification device and the present embodiment will be described with reference to FIGS. 1 and 2. FIG.
As shown in FIG. 1, RTL 400, LIB 410, SVA 420, and inspection target port list 800 are input to verification apparatus 100 for floating-point arithmetic units.

The hardware description language defines the level of abstraction (level) of the description of the hardware description language. RTL is a level of abstraction that describes registers, arithmetic units, and wiring (connections) therebetween. The RTL 400 means source code of a hardware description language written in RTL.

Assertions in a hardware description language are statements that describe the behavior expected or prohibited in a designed circuit. The operation of the simulator can be verified. A representative language for writing assertions is SVA (System Verilog Assertion), and SVA 420 means source code written in SVA.

In a hardware description language such as Verilog HDL, a functional unit is regarded as a "module", and a virtualized input/output terminal is called a "port". These terms will also be used in this embodiment.

FIG. 2 shows a functional configuration in which the floating-point calculator is written in software. In FIG. 2, it has two input ports INPUT_1 and INPUT_2, an output port OUTPUT, and an exception output port EXCEPTION.

Here, the module that describes the function of the floating-point calculator is called the "top module". The top module has its internal configuration divided into lower modules module A, module B, module C, . . . , and module Z at the functional block level. Also, ports inside the top module (also lower-level input ports and output ports) will be referred to as "intermediate ports" or "internal ports." Further, the value that the intermediate port can take is called "intermediate value".

In the verification program SVA 420 for formal verification, assertions are described so as to correspond to each module on a one-to-one basis in order to verify the RTL 400 at the module level. That is, the floating-point arithmetic unit has required specifications defined for each of its submodules, and it is proved whether or not each of the modules A, B, C, . . . , and Z satisfies the required specifications. Assertion A, assertion B, assertion C, . . . , assertion Z are prepared. Also, regarding the required specifications of the top module of the floating-point arithmetic unit, the correctness of the behavioral description is proved by the top assertion. Since the operation contents of the floating-point arithmetic unit cannot be expressed by the assertion description for formal verification, the top assertion proves the functions required for connection with the upper layer such as the interface protocol.

LIB (arithmetic library) 410 is the source code of the function (details will be described later) used when obtaining the value of the input port from the value of the output port of the module when obtaining the missing intermediate value. The function is configured so that it is one-to-one with Each function is designed to have the same operation content as each module. That is, the top module corresponds to the top function, and the calculation contents of module A, module B, module C, . . . module Z and function A, function B, function C, . Peeping, respectively, are equivalent. Here, equivalence means returning the same output value for the same input value as the module.

The inspection target port list 800 is a list of ports for which intermediate value coverage is to be acquired (details will be described later).

Next, the configuration of the verification device for the floating-point arithmetic unit of this embodiment and the verification performed by inputting these data will be described.
A verification device 100 for a floating-point arithmetic unit consists of a control unit 110, a formal verification device 200, a dynamic verification device 300, and a verification result aggregation unit 120, as shown in FIG. The control unit 110 is a part that monitors and controls the overall operation of the verification device.

As described above, the verification apparatus 100 for floating-point arithmetic units aims at ensuring the reliability of floating-point arithmetic units. In order to achieve this purpose, the verification device verifies floating-point arithmetic units by two different verification methods. One is formal verification and the other is dynamic verification. In the floating-point arithmetic unit verification apparatus 100, the formal verification apparatus 200 formally verifies the RTL 400 of the floating-point arithmetic unit, and the dynamic verification apparatus 300 dynamically verifies the RTL 400 of the floating-point arithmetic unit.

Formal verification is a verification method that logically proves that the behavioral description of the RTL 400 satisfies the required specifications, and the proof is described in the SVA 420, which is a formal verification program. The proof is executed by the formal verification tool reading the RTL 400 and the set of SVA 420 in which the proof for the RTL 400 is described, and when the proof is completed, proof result 630 and line coverage 520 can be obtained as execution result data. The proof result 630 describes whether the proof was completed or not, and if the proof was not completed, a counterexample is described. The line coverage 520 is a metric that reflects the percentage of lines of RTL referenced by the SVA in the formal verification proof. For the purpose of reducing potential bugs in the floating-point arithmetic unit as a whole, we have completed proof that all lines of all RTL that make up the floating-point arithmetic unit operate correctly according to the required specifications. must be By measuring the line coverage with the formal verification device and confirming that it achieves 100%, it is possible to confirm that the floating-point arithmetic unit is correctly designed according to the required specifications.

However, in formal verification, it is very difficult to comprehensively verify the output pattern data for the input pattern data of the floating-point calculator. This is because the input pattern of the floating-point arithmetic unit has an extremely large number of special operation cases, so all these special operation cases must be defined as required specifications and comprehensively expressed in the formulas described in the SVA. is unrealistic. Therefore, in order to verify whether or not the input/output data that cannot be covered by the formal verification is correct, the verification device 100 for the floating-point arithmetic unit introduces a dynamic verification device 300 . The dynamic verification device 300 is internally provided with the same type of arithmetic unit that has been used as the floating-point arithmetic unit that is input to the verification device.

In this specification, the calculator with a track record of use is hereinafter referred to as a "highly reliable model" and a "highly reliable calculator". The dynamic verification device 300 applies the same input data to the RTL 400 and the high-reliability model, and checks whether the results match. This is performed a sufficient number of times as determined by the verification standard, and the input data of each trial, the output data of the high-reliability model and the RTL 400 , and the results of matching or non-matching of them are saved in the matching result 620 . If there are no design errors or bugs in the floating-point arithmetic unit to be verified, it is expected that the calculation result of the RTL 400 will match the calculation result of the highly reliable model for all input patterns.

Both the exception occurrence boundary coverage 510 and the intermediate value coverage 500 are indices that indicate the completeness of the verification of special data input patterns that the dynamic verification device 300 should particularly focus on.

Floating-point arithmetic units output exceptions such as overflow exceptions and division-by-zero exceptions when the operation result deviates from the value that can be represented by the bit field, or when an illegal operation such as division by 0 is executed. do. Systems that require high security are required to correctly output exceptions from arithmetic units in data patterns that cause exceptions. Therefore, it is necessary to verify that exceptions do not occur for input data that does not cause exceptions, and that exceptions occur correctly for input data that causes exceptions. In order to achieve this purpose, it is necessary to perform dynamic verification on all boundaries between input data where exceptions occur and input data where exceptions do not occur, and the matching results are also correct. In order to confirm the completeness of the verification of boundary values where exceptions occur, the number of match results of collation against parameters is output as exception occurrence boundary coverage 510 when all boundaries of exceptions to be verified are used as parameters.

Further, the intermediate value coverage 500, which will be described in detail later, is an index indicating the coverage of verification of possible values for each internal port of the floating-point arithmetic unit. By referring to the intermediate value coverage 500, it is possible to know the completeness of verification for various special operation cases of the floating-point arithmetic unit. Here, the inspection target port list 800 is a list of information on internal ports for which the intermediate value coverage 500 should be acquired.

The inspection target port list 800 sequentially inspects ports in the verification process for obtaining the intermediate value coverage 500 . The LIB 410 is data consisting of a function for calculating the value of the input port from the value of the output port for the module when calculating the intermediate value coverage 500 (details will be described later). When various verification results of the proof result 630, the matching result 620, the line coverage 520, the exception occurrence boundary coverage 510, and the intermediate value coverage 500 are collected, the verification result aggregating unit 120 summarizes the information and outputs the verification result in a form that is easy for people to understand. Output. A comprehensive coverage 610 in the verification result 600 is for numerically indicating the status of various coverages. Detailed information 611 in the verification result 600 indicates the content of each proof result, counterexample, and matching result of formal verification, and specific conditions that occur.

Next, with reference to FIG. 3, the hardware/software configuration of the floating-point arithmetic unit verification device will be described.
As for the hardware configuration of the floating-point calculator verification device 100, for example, it is realized by a general information processing device such as a personal computer as shown in FIG.
The floating-point arithmetic unit verification device 100 includes a CPU (Central Processing Unit) 902, a main memory device 904, a network I/F 906, a display I/F 908, an input/output I/F 910, and an auxiliary memory I/F 912, which are coupled via a bus. It is in the form of

The CPU 900 controls each part of the floating-point arithmetic unit verification apparatus 100, loads necessary programs into the main memory 904, and executes them. The CPU 900 also incorporates an FPU 902 (Floating Point Unit) as a coprocessor, and when an instruction word for floating point arithmetic is touched, the FPU 902 is requested to execute processing. The FPU 902 corresponds to a highly reliable model realized by hardware. In this embodiment, the FPU 902 is implemented as a coprocessor of the CPU 900. However, an I/O port is connected to exchange data via the I/O port in the same manner as a normal peripheral device. , I/O processor type. The main memory device 904 is normally composed of a volatile memory such as a RAM, and stores programs executed by the CPU 900 and data to be referred to.

A network I/F 906 is an interface for connecting with a network. A display I/F 908 is an interface for connecting a display device 920 such as an LCD (Liquid Crystal Display). The input/output I/F 910 is an interface for connecting input/output devices. In the example of FIG. 3, a keyboard 930 and a mouse 932 as a pointing device are connected.

Auxiliary storage I/F 912 is an interface for connecting auxiliary storage devices such as HDD (Hard Disk Drive) 950 and DVD drive (Digital Versatile Disk).

The HDD 950 has a large storage capacity and stores programs for executing this embodiment. A logic simulator program 1000, a formal verification program 1010, an expected value/comparison value comparison program 1020, an insufficient intermediate value generation program 1030, a boundary value search program 1040, and a random number generation program 1050 are installed in the verification device 100 for a floating-point arithmetic unit. It is

A logic simulator program 1000 is a program for executing a logic simulator (described later) in the dynamic verification device 300 . The formal verification program 1010 is a program that performs formal verification in the formal verification device 200 . The expected value/output value comparison program 1020 is a program for collating and comparing with the expected value output by the highly reliable model. The missing intermediate value generation program 1030 is a program for generating missing intermediate values (details will be described later) in intermediate value-oriented dynamic verification. The boundary value search program 1040 is a program that searches for boundary values to be verified in exception generation-oriented dynamic verification. The random number generation program 1050 is a program that generates random numbers that serve as original data for obtaining verification targets.

Next, the functional configuration of the dynamic verification device will be described with reference to FIG.
The dynamic verification device 300 compares the RTL 400 of the floating-point calculator and the high-reliability model 220 that performs the same type of calculation. For comparison, the same input data is input to each of them, and it is confirmed whether or not the output value of the RTL 400 and the expected value of the high reliability model 220 match. The logic simulator 230 is a functional unit that receives the RTL 400 and provides behavior equivalent to an actual logic circuit according to the behavioral description of the RTL 400 . The RTL 400 operates on the logic simulator 230 and outputs an output value 720 as an operation result and an intermediate port intermediate value 730 .

The input generation unit 210 is a functional unit that generates input values mainly based on random numbers. The verification method of the dynamic verification device 300 of this embodiment consists of three types of dynamic verification. The three types of dynamic verification are intermediate value-oriented dynamic verification, exception boundary value-oriented dynamic verification, and completely random number dynamic verification (details will be described later).

In intermediate-value-oriented dynamic verification, the input generator 210 outputs an input value 700 and inputs it to the logic simulator 230 . In intermediate value-oriented dynamic verification, input values may be generated using the LIB 410 and the missing intermediate value list 740 (details will be described later).

The measurement unit 240 receives the expected value 710 from the high-reliability model 220, the output value 720 and the intermediate value 730 from the logic simulator 230, the input value 700 from the input generation unit 210, and the port information 810 of the inspection target port list 800, and performs dynamic verification. The collation result 620, the exception occurrence boundary coverage 510, and the intermediate value coverage 500, which are the output data of the device 300, are output. Here, the port information 810 is information relating to the intermediate ports listed in the inspection target port list 800 and to be measured for intermediate value coverage.
The functions and actions of various sub-devices that exist inside the dynamic verification device 300 will be explained in detail later with reference to flowcharts shown in FIGS.

Next, the functional configuration of the measurement unit in the dynamic verification device will be described with reference to FIG.
The measurement unit 240 includes a comparison unit 241, a verification result totalization unit 242, and an intermediate value totalization unit 243, as shown in FIG.

The comparison unit 241 compares the expected value 710 that is the calculation result of the high-reliability model 220 and the output value 720 that is the calculation result on the logic simulator 230 of the RTL 400 . Then, the input value 700, the output value 720, and the expected value 710 used for one comparison, the comparison result thereof, the port information 810, and the intermediate value 730 are associated and stored as a verification sample 770. FIG. Validation samples 770 are stored in validation log 780 and intermediate values 730 are stored in intermediate value log 760 .

The verification result aggregating unit 242 outputs the matching result 620 and the intermediate value coverage 500 from the verification log 780 in the intermediate value oriented dynamic verification, and outputs the matching result 620 and the exception occurrence boundary coverage from the verification log 780 in the exception occurrence boundary oriented dynamic verification. 510, and only the matching result 620 is output in the fully random dynamic verification. In the intermediate-value-oriented dynamic verification, the intermediate-value aggregating unit 243 calculates missing intermediate values (details will be described later) from the intermediate-value log 760 and the bit width of the inspection target port, and outputs the missing intermediate-value list 740 .

Next, the functional configuration of the input generator in the dynamic verification device will be described with reference to FIG.
The input generation unit 210 includes a library selection unit 211 , a random number generation unit 212 , a missing intermediate value generation unit 213 and an input value calculation unit 214 .

In the complete random number dynamic verification, the input value calculator 214 outputs the input value 700 from the random number output by the random number generator 212 . In the intermediate value-oriented dynamic verification, first, an input value 700 is generated from random numbers generated by the random number generation unit 212. If a missing intermediate value list 740 is generated during the intermediate value-oriented dynamic verification, the missing intermediate value selection unit 213 selects one missing intermediate value 750, the library selection unit 211 calls any function from the LIB 410, and the input value calculation unit 214 calculates an input value (details will be described later).

Next, the processing of the verification device for the floating-point arithmetic unit will be described with reference to FIGS. 7 to 21. FIG.
First, referring to FIG. 7, the overall processing of the verification device for floating-point arithmetic units will be described.
In the overall processing of the floating-point arithmetic unit verification device, first, formal verification processing is performed by the formal verification device 200 (S200).

Next, dynamic verification is performed by the dynamic verification device 300 (S300).
Then, the verification result 600 is output (S110).
As an output of the verification result 600, the number of proof completions and line coverage 520 with respect to the total number of proofs in formal verification, the matching number with respect to the total number of verifications in dynamic verification, exception occurrence boundary coverage 510, and intermediate value coverage 500 are output as total coverage 610. . The detailed information 611 includes lines that were not subject to proof in the formal verification, modules and assertion information that contained counterexamples, input/output patterns that did not match in the matching of the dynamic verification, and missing intermediate values. Output the information of the median coverage 500 .

Next, the formal verification processing by the formal verification device will be described with reference to FIG.
This is the process of S200 in FIG.
First, the top module is formally verified and certified by the top assertion (S201). Record the result of the proof, the number of lines of the top module that is the object of proof, and the number of lines of the entire top module.

Next, as an initial process, the module A is set as the verification target module MOD, and the assertion A is set as the formal verification program ASE (S202).
Next, the verification target module MOD is formally verified and certified by the formal verification program ASE. Then, the result of the proof, the number of lines of the top module to be proofed, and the number of lines of the entire top module are recorded (S203).
Next, it is determined whether or not all modules of the RTL 400 have been verified by formal verification (S204). (S204: NO), the process proceeds to S205.

When there is a module that has not been verified by formal verification, a module that has not been verified by formal verification is searched in the RTL 400, the module is set as a verification object module, and the assertion corresponding to that module is set as a formal verification program ASE. (S205). Note that NEXT_MOD( ) in FIG. 7 is a function that returns the module next to the module of the argument, and NEXT_ASE( ) is a function that returns the assertion next to the assertion of the argument.

When all modules are verified by formal verification, the result of proof of formal verification for each RTL 400 is output as proof result 630 . It also outputs the number of lines proven with respect to the total number of lines in each RTL 400 as line coverage 520 . Accompanying information of the certification result 630 is output including information on uncertified rows.

Next, dynamic verification processing by the dynamic verification device will be described with reference to FIG.
This is the process of S300 in FIG.
In order to operate the RTL 400 of the floating point arithmetic unit, the RTL 400 is set in the logic simulator 230 (S301). Logic synthesis is performed as necessary.

Next, intermediate value-oriented dynamic verification is performed (S400). In intermediate-value-oriented dynamic verification, matching result 620 and intermediate-value coverage 500 are output. Details will be described later.

Next, exception generation boundary-oriented dynamic verification is performed (S500). Exception boundary-oriented dynamic verification outputs matching results 620 and exception boundary coverage. Note that the type of boundary to be checked differs depending on whether the content of the operation executed by the floating-point calculator is addition, multiplication, or division. Details will be described later.
Next, dynamic verification using complete random numbers is performed (S900). Only the collation result 620 is output in dynamic verification using perfect random numbers. Details will be described later.

Next, FIG. 10 is a diagram showing an execution image of intermediate-value-oriented dynamic verification.
Intermediate-value-oriented dynamic verification is dynamic verification focused on intermediate values of intermediate ports in a module when the logic simulator 230 is executed by the RTL 400 of the floating-point arithmetic unit to be verified. A floating-point adder as shown in 10 will be described as an example. In this case, dynamic verification is performed by designating the intermediate port of NUM_LEADING_ZERO for the purpose of focusing on verifying special cases of operations in which digit loss occurs in the floating-point adder.

Precision loss is a special case of floating-point adders that occurs when two inputs are very close in value and are effectively subtracted. For example, when the input value is the following value.
INPUT_1=(-1)^0*2^9*1.01110010101110110111000 ₂
INPUT_2=(-1)^1*2^9*1.01110001111011001011010 ₂

Here, âb represents a raised to the b-th power, and the index 2 indicates a binary number. In this case, the subtraction of values of approximately the same magnitude cancels each other out, resulting in a very small value being output. At this time, special processing is required because the position of the floating point changes greatly. The module that performs special processing is the module X in the figure, and the intermediate port that is activated when this cancellation occurs is the NUM_LEADING_ZERO port. For example, when INPUT_1 and INPUT_2 are the above values, the input values of the module X are obtained by directly subtracting the mantissas " _{1.011100101011101101110002} " and " _{1.011100011110110010110102} ".
SUMMATION=000000000110011101011110 ₂

Count the number of 0s lined up in the upper bits and output that number from the NUM_LEADING_ZERO port.
NUM_LEADING_ZERO=01001 ₂
This is 9 in decimal. FRAC is a value obtained by left-shifting SUMMATION by NUM_LEADING_ZERO. In this example,
FRAC=110011101011110000000000 ₂
and the final OUTPUT value is
OUTPUT=(-1)^0*2^0*1.10011101011110000000000 ₂
is.

The port that fires characteristically in a floating point adder when this loss occurs is NUM_LEADING_ZERO. For this reason, if you want to focus on verifying the special case of the cancellation of significant digits, check whether the input value is well generated so that NUM_LEADING_ZERO is exhaustive, and whether the value of NUM_LEADING_ZERO is actually obtained as an intermediate value and is exhaustive. The basic idea of intermediate-value-oriented dynamic verification is to improve the reliability of floating-point adder operations by verifying the

Also, the missing intermediate value in this embodiment means an unverified intermediate value at the inspection target port (here, it is NUM_LEADING_ZERO, and its possible values are 2̂6).

Next, intermediate value-oriented dynamic verification processing will be described with reference to FIG.
This is the process of S400 in FIG.
First, one uninspected port is selected from the inspection target port list 800 and set as the inspection target port (S401).

Next, a process of exhaustively verifying the intermediate value of the port to be inspected is executed (S600).
It is determined whether or not coverage rate inspection has been completed for all ports to be inspected (S402). If completed (S402: YES), proceed to S403. ) and proceed to S401.

If coverage rate inspection has been completed for all ports to be inspected, a collation result 620 is output, and the coverage rate of inspection ports for which inspection has been completed is output as an intermediate value coverage 500 (S403).

Next, the process of comprehensively verifying the intermediate values of the ports to be inspected will be described with reference to FIG. 12 .
This is the process of S600 in FIG.
First, a variable i is initialized to 0 (S601).
Next, input values X1 and X2 are generated as random numbers and input to the high-reliability model 220 and logic simulator 230, respectively, to obtain an expected value 710 and an output value 720, respectively. The expected value YE obtained from the high-reliability model 220, the output value YO obtained from the logic simulator 230, and the intermediate value IV of the inspection target port are input to the measurement unit 240 and stored in the internal verification log 780 and intermediate value log 760 ( S602).

Next, the predetermined number of verification samples N times is compared with the variable i (S603), and if i is smaller, the process proceeds to S604;

When i is smaller than N, 1 is added to the variable i and stored in the variable i (S604), and the process proceeds to S602.
When i becomes equal to N, the range of possible values of the port to be inspected is calculated. Among them, unrecorded intermediate values that do not exist in the intermediate value log 760 are found, and all of them are registered as missing intermediate values in the missing intermediate value list 740 (S605).

Next, one unchecked missing intermediate value is selected from the missing intermediate value list 740 and registered as the missing intermediate value to be inspected (S606).
Next, verification processing is executed for the missing intermediate value to be inspected (S700).
Next, it is determined whether or not verification has been completed for all the missing intermediate values registered in the missing intermediate value list (S607), and if the verification has been completed (S607: YES), the process is terminated. However, if the verification is not completed (S607: NO), the process proceeds to S606.

Next, verification processing for the missing intermediate value to be inspected will be described with reference to FIG. 13 .
First, a data structure of a list of data (port information, value list) having a pair of a list of port information and port value is defined, and {(tested port, {missing intermediate value })} is substituted (S701).

Next, in S702 and S703, a search is made for a value that can reach the deficient intermediate value of the inspection target port in the LIST of S701.
First, one element is taken out from LIST and set to CUR. Remove CUR from LIST. Set PO to the port of CUR and set VOLIST to the value list of CUR. A function corresponding to a module with PO as an output port is loaded from LIB 410, and the input port of that function is referenced. If there are N input ports, N port information PIx (0≤x<N) and N empty data input value lists VILISTx={} are prepared (S702).

Next, we input all possible values of the input ports of these functions into the function. If the value of the output port PO of the function matches the value existing in VLIST, the value VIx of PIx at that time is recorded in VILISTx (S703). The expression regarding append in FIG. 13 means that the value of the second argument VIx is added to the end of the list of the first argument VILISTx to make it a new VILISTx.

Next, it is determined whether or not VLISTx is empty for all input ports PIx (S704). YES), proceed to S705; otherwise (S704: NO), proceed to S706.

When no value is recorded in VLISTx and VLISTx remains empty, it is determined that the missing intermediate value to be inspected is not within the range of possible values (S705).
When values are recorded in VLISTx, {PIx, VILISTx} is added to LIST for all input ports PIx (S706).

Next, it is determined whether or not both the input ports INPUT_1 and INPUT_2 of the arithmetic unit exist in the LIST (S707). : YES), proceed to S708; otherwise (S707: NO), proceed to S702.

Then, one or more pairs of possible values of INPUT_1 and INPUT_2 stored in the LIST are selected and input to the high-reliability model 220 and the logic simulator 230, respectively, to obtain a collation result 620 (S708). .

Next, exception occurrence boundary-oriented dynamic verification processing will be described with reference to FIGS. 14 to 20. FIG.
Exception occurrence boundary-oriented dynamic verification is a method of performing verification by paying attention to the boundary of whether an exception occurs or not for an input value. In the following description, the floating-point arithmetic unit to be verified is an adder, a multiplier, and a divider. This is the process of S500 in FIG.

14 to 16, the exception generation boundary-oriented dynamic verification processing when the floating-point arithmetic unit to be verified is an adder will be described.
FIG. 14 shows the boundaries at which the adder overflows. MAX in the figure indicates the maximum absolute value that can be represented by a floating-point number that can be handled by the floating-point arithmetic unit to be verified. EPS indicates the smallest number that (1+EPS) exceeds one. Values that can be represented by floating-point numbers handled by the floating-point arithmetic units are represented as discrete values on a grid. The grid spacing is not constant, and when expressed as a ratio, it gradually increases as the value increases, such as 1, (1+EPS), and (1+EPS)^2. The region of X1 and X2 where the adder does not overflow is -MAX≤X1+X2≤MAX, and the grid points (X1, X2) in this region are indicated by ◯. Conversely, the areas where the adder overflows are X1+X2<-MAX and X1+X2>MAX, and the points (X1, X2) on the lattice existing in these areas are indicated by x. The exception-occurring boundary-oriented dynamic verification of this embodiment targets points on the grid adjacent to such a boundary.

First, in exception generation boundary-oriented dynamic verification processing when the type of floating-point arithmetic unit to be verified is an adder, the X1 coordinate of the initial value of the boundary value to be investigated is set (S501). In the case of an adder, MAX*EPS is set as an initial value.

Next, in the calculation using the high-reliability model 220, from the value of X1, the boundary line of the first quadrant: X1 + X2 = MAX, the X2 value X2_P = MAX - X1, and the boundary line of the third quadrant: X1 + X2 = -MAX The value of X2 X2_M=(-1)*MAX+X1 is obtained (S502).

Next, boundary search and matching processing around the coordinates (X1, X2_P) are performed (S800a).
Next, a boundary search and matching process flow around the coordinates (X1, X2_M) is performed (S800b).

Then, it is determined whether X1 is smaller than MAX (S503), and if X1 is smaller than MAX (S503: YES), proceed to S504; otherwise (S503: YES), end the process.
If X1 is smaller than MAX, X1*(1+EPS) is substituted for X1 (S504). That is, the value of X1 is updated to the value of the point next to X1. Then, the process proceeds to S502.

Next, the boundary search and collation processing around (X1, X2) will be described with reference to FIG.
This is the processing corresponding to S800a and S800b in FIG. Further, S800c to S800f in FIG. 18 for the later processing of the multiplier and S800g to S800k of FIG. 20 for the later processing of the divider are also used as subroutines.

In the processing of this embodiment, grid points (X1, X2) existing on the boundary are determined in advance by the boundary formula. is used to confirm that the grid points to be investigated are in the vicinity of the boundary, and then matching is performed.

First, the points to be checked for boundary values are narrowed down to five points, and collation is performed (S801). Since the approximate position of the boundary is known in advance by a mathematical formula, it is sufficient to check about five points. Five adjacent points centered on X2 are set to X2_0 to X2_4. That is, in order, X2_0*(1+EPS)^2=X2, X2_1*(1+EPS)=X2, X2_2=X2, X2_3=X2*(1+EPS), X2_4=X2*(1+EPS)^2. Define ~X2_4.

Next, a loop variable i is initialized to 0 (S802).
Next, using the high reliability model 220, the expected values YE_A=X op X2_i and YE_B=X op X2_{i+1} are calculated (S803). Note that X2_i and X2_{i+1} are variable names depending on i. Also, op is a binary operator, and op=+ if the type of floating-point number operation to be verified is addition, op=* if multiplication, and op=/ if division.

Next, it is determined whether an exception occurs in either the operation for YE_A or the operation for YE_B, or whether the operation for YE_A does not cause an exception or the operation for YE_B causes an exception. (S804), and if an exception has occurred in any of the operations (S804: YES), proceed to S805; otherwise (S804: NO), proceed to S806.

If an exception occurs in either the operation for obtaining YE_A or the operation for obtaining YE_B, the logic simulator 230 is used to calculate the output values YO_A=X op X2_i and YO_B=X op X2_{i+1}. (S805).
If no exception occurs in either the operation for obtaining YE_A or the operation for obtaining YE_B, the loop variable i is updated to i+1 (S806). Then, the process proceeds to S803.
Finally, YE_A and YO_A and YE_B and YO_B are compared (S806).

Exception generation boundary-oriented dynamic verification processing when the floating-point arithmetic unit to be verified is a multiplier will now be described with reference to FIGS. 17 and 18. FIG.
FIG. 17 shows the boundaries at which the multiplier overflows. The region of X1 and X2 where the multiplier does not overflow is -MAX≤X1*X2≤MAX, and the grid points (X1, X2) in this region are indicated by ◯. Conversely, the area where the multiplier overflows is X1*X2<MAX, X1*X2>-MAX, and the point (X1, X2) on the lattice existing in this area is indicated by x.

First, in exception occurrence boundary-oriented dynamic verification processing when the type of floating-point arithmetic unit to be verified is a multiplier, the X1 coordinate of the initial value of the boundary value to be investigated is set (S510). For multipliers, 1 is set as the initial value.

Next, from the value of X1, the X2 value X2_P=MAX/X1 of the boundary line between the first and second quadrants and the X2 value X2_M=(-1)*MAX of the boundary line between the third and fourth quadrants /X1 is obtained (S511).

Next, boundary search and matching processing around the coordinates (X1, X2_P) are performed (S800c).
Next, boundary search and matching processing around the coordinates (X1, X2_M) are performed (S800d).
Next, boundary search and collation processing around the coordinates ((-1)*X1, X2_P) are performed (S800e).
Next, boundary search and matching processing around the coordinates ((-1)*X1, X2_M) are performed (S800f).

Next, it is determined whether or not X1 is smaller than MAX (S512). If X1 is smaller than MAX (S512: YES), proceed to S513; otherwise (S512: NO), end the process. do.

If X1 is smaller than MAX, X1*(1+EPS) is substituted for X1 (S513). That is, the value of X1 is updated to the value of the next point. Then, the process proceeds to S511.

Exception generation boundary-oriented dynamic verification processing when the floating-point arithmetic unit to be verified is a divider will now be described with reference to FIGS. 19 and 20. FIG.
FIG. 19 shows the boundaries at which the divider overflows. The region of X1 and X2 where the divider does not overflow is -MAX≤X1/X2≤MAX, and the grid points (X1, X2) in this region are indicated by ◯. Conversely, the area where the divider overflows is X1/X2<MAX, X1/X2>-MAX, and the points (X1, X2) on the grid that exist in this area are indicated by x.

First, in exception occurrence boundary-oriented dynamic verification processing when the type of floating-point arithmetic unit to be verified is a divider, boundary search and matching processing around coordinates (0, 0) are performed (S800g).

Next, the X1 coordinate of the initial value of the boundary value to be investigated is set (S520). For dividers, MIN is the initial value. MIN is the minimum positive integer expressed in floating-point numbers in the floating-point arithmetic unit to be verified.

Next, from the value of X1, the X2 value X2_P=X1/MAX of the boundary between the first and second quadrants and the X2 value X2_M of the boundary between the third and fourth quadrants X2_M=(-1)* A value of X1/MAX is obtained (S521).

Next, boundary search and matching processing around the coordinates (X1, X2_P) are performed (S800h).
Next, boundary search and matching processing around the coordinates (X1, X2_M) are performed (S800i).
Next, boundary search and matching processing around the coordinates ((-1)*X1, X2_P) are performed (S800j).
Next, boundary search and collation processing around the coordinates ((-1)*X1, X2_M) are performed (S800k).

Next, it is determined whether or not X1 is smaller than MAX (S522). If X1 is smaller than MAX (S522: YES), proceed to S523; otherwise (S522: NO), end the process. do.
If X1 is smaller than MAX, X1*(1+EPS) is substituted for X1 (S523). That is, the value of X1 is updated with the value of the neighboring point. Then, the process proceeds to S521.

Next, dynamic verification processing using perfect random numbers will be described with reference to FIG.
This is the process of S900 in FIG.
Unlike the intermediate value-oriented dynamic verification and the exception generation boundary-oriented dynamic verification described above, the processing of dynamic verification using completely random numbers does not focus on specific values, and uses values generated completely by random numbers as a high-reliability model. 220 and the expected value 710 and the output value 720 respectively output as inputs to the logic simulator 230 are compared and verified.
In dynamic verification using perfect random numbers, first, a loop variable i is initialized to 0 (S901).

Next, input values X1 and X2 are generated using random numbers. X1 and X2 are input to the high-reliability model 220 and the logic simulator 230, respectively, and the expected value YE and the output value YO output from each are collated (S902).
Next, the loop variable i is compared with the prescribed number of times of verification N (S903). If i<N (S903: YES), proceed to S904. If not (S902: NO), end the process. do.
Next, if i<N, the loop variable i is updated to i+1 (S904), and the process proceeds to S902.

DESCRIPTION OF SYMBOLS 100... Verification apparatus of a floating-point arithmetic unit, 110... Control part, 200... Formal verification apparatus, 300... Dynamic verification apparatus, 120... Verification result aggregation part,
400...RTL, 410...LIB, 420...SVA,
500... intermediate value coverage, 510... exception occurrence boundary coverage, 520... line coverage,
600... Verification result, 610... Comprehensive coverage, 611... Detailed information, 620... Verification result, 630... Certification result,
700 Input value 710 Expected value 720 Output value 730 Intermediate value 740 Missing intermediate value list 750 Missing intermediate value 760 Intermediate value log 770 Verification sample 780 Verification log
800 … port list to be inspected, 810 port information

Claims (7)

A calculator verification device for verifying a calculator whose function is described in a hardware description language by RTL (Register Transfer Level) description,
a logic simulator that interprets and executes the hardware description language and outputs an input value as an output value;
a highly reliable calculator that performs a specified operation on an input value and outputs an expected value, and that compares the output value output by the logic simulator with the expected value output by the highly reliable calculator; has a dynamic verification device for verifying a computing unit whose function is described by the hardware description language,
The dynamic verification device refers to an intermediate port used inside the module described in the hardware description language,
A verification apparatus for a computing unit, which calculates coverage of verification for possible values of a certain intermediate port and outputs it as intermediate value coverage. 2. The arithmetic unit verification apparatus according to claim 1, wherein said arithmetic unit whose function is described in said hardware description language is a floating-point arithmetic unit. a function that outputs the same output value for the same input value as the input port value of the module corresponding to the module described in the hardware description language is input to the dynamic verification device;
The dynamic verification device obtains an unverified missing intermediate value for possible values of an intermediate port, and obtains a value of an input port corresponding to the missing intermediate value by a function corresponding to the module. 2. A verification device for a calculator according to claim 1. 4. The method according to claim 3, wherein the value of the input port corresponding to the missing intermediate value is inputted to the logic simulator and the high-reliability calculator, and the output value and the expected value are compared. Arithmetic unit verification device. A calculator verification device for verifying a calculator whose function is described in a hardware description language by RTL (Register Transfer Level) description,
a logic simulator that interprets and executes the hardware description language and outputs an input value as an output value;
a highly reliable calculator that performs a specified operation on an input value and outputs an expected value, and that compares the output value output by the logic simulator with the expected value output by the highly reliable calculator; has a dynamic verification device for verifying a computing unit whose function is described by the hardware description language,
The dynamic verification device is characterized in that it calculates verification coverage with respect to a boundary value at which an exception occurs in the input value of the module described in the hardware description language, and outputs it as exception occurrence boundary coverage. Verification device for computing units. 6. The arithmetic unit verification apparatus according to claim 5, wherein the arithmetic unit whose function is described by the hardware description language is a floating-point arithmetic unit. 6. The arithmetic unit verification device according to claim 5, wherein the exception is a division by zero exception or an overflow exception.

Images