WO2017013783A1 - 論理回路の検証方法 - Google Patents

論理回路の検証方法 Download PDF

Info

Publication number
WO2017013783A1
WO2017013783A1 PCT/JP2015/070945 JP2015070945W WO2017013783A1 WO 2017013783 A1 WO2017013783 A1 WO 2017013783A1 JP 2015070945 W JP2015070945 W JP 2015070945W WO 2017013783 A1 WO2017013783 A1 WO 2017013783A1
Authority
WO
WIPO (PCT)
Prior art keywords
register
logic circuit
name
assertion
test
Prior art date
Application number
PCT/JP2015/070945
Other languages
English (en)
French (fr)
Inventor
慶太 朝倉
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2015/070945 priority Critical patent/WO2017013783A1/ja
Publication of WO2017013783A1 publication Critical patent/WO2017013783A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]

Definitions

  • the present invention relates to a logic circuit verification technique.
  • Assertion-based verification is known as one of the techniques used in the verification process of semiconductor integrated circuits.
  • An assertion is a description of a state or operation expected or prohibited in a designed circuit using a verification language (assertion description language) or a hardware description language.
  • Assertion-based verification is a method for confirming the operation of a circuit to be verified by incorporating the assertion into a model of the circuit to be verified.
  • the design verification apparatus generates an assertion expectation value table that records the number of executions of an assertion that is expected to be executed when a request for a certain test pattern is executed. The consistency between the contents of the value table and the execution result of the logic simulation is determined.
  • the design verification device When the design verification device generates an assertion expectation value table, the operator determines whether to execute each assertion for each request of the test pattern, and information on the number of times of execution (assertion constraint information). Is given to the design verification device.
  • a logic circuit verification method provides a hardware description language for a logic circuit that outputs an error signal when an error occurs and has a plurality of functional blocks each having a register for storing the output error signal. Verification is performed using the logic circuit description described in.
  • the name of the error signal output from the functional block the name of the error register that is a register in the functional block that stores the output value of the error signal, the register of the error signal propagation destination, and the functional block having the register It is expected to be ignited when a test of the logic circuit using a test pattern is executed among the assertions incorporated in the logic circuit description based on one or more register specifications having the name of Generating a list of assertions to be made.
  • the verification cost of a large-scale logic circuit can be reduced.
  • the processing content may be described with an expression such as “the program does ...”. Since the program is executed by a processor (CPU (Central Processing Unit)) and causes a computer to perform a predetermined process, an expression in which the program is an operation subject is not necessarily an accurate expression. However, in order to prevent the description from becoming redundant, the contents of the process may be described with “program” as the subject.
  • Various programs may be provided to a user who uses the program by a program distribution server or a computer-readable storage medium, and may be installed in a computer that executes the program.
  • the computer-readable storage medium is a non-transitory computer-readable medium, such as a non-volatile storage medium such as an IC card, SD card, or DVD.
  • a part or all of the program may be realized by dedicated hardware.
  • the verification processing (logic verification processing) of the present embodiment does not perform verification work such as testing of an actual semiconductor integrated circuit (hereinafter referred to as “logic circuit”), but performs logic verification that operates on a computer such as a server.
  • the logic circuit is verified by simulating the operation of the logic circuit using a tool (simulator).
  • the verifier of the logic circuit gives the simulator information on the operation specifications (behavior) of the logic circuit described in the hardware description language, thereby causing the simulator to simulate the operation of the logic circuit.
  • the information on the operation specifications of the logic circuit described in the hardware description language is called “circuit data”.
  • the work and processing for simulating the operation of the logic circuit by giving circuit data to the simulator is expressed as “simulating the logic circuit”.
  • An “assertion” is a description of a state or operation expected or prohibited in a designed logic circuit using a verification language (assertion description language) or a hardware description language. is there. An assertion is sometimes called an “assertion description”.
  • assertion is sometimes called an “assertion description”.
  • a verifier incorporates an assertion into circuit data and performs a simulation using the circuit data in which the assertion is incorporated, for example, when a state prohibited by the logic circuit occurs, the computer executing the simulation Error information is output to the display device, or information indicating that an error has occurred in the log file.
  • Module means a circuit description of some functions included in the circuit data.
  • the designer divides the logic circuit into several functional blocks, and designs each functional block.
  • a logic circuit is configured by connecting a plurality of designed functional blocks. Further, hierarchical design may be performed.
  • the functional block is divided into several sub-functional blocks, and design for each sub-functional block is performed.
  • the circuit description for the functional block is referred to as a “module”.
  • the circuit description for the sub functional block is called a “sub module”.
  • the functional block and the sub functional block may be referred to as “functional block” without being distinguished from each other.
  • a module and a submodule may be referred to as a “module” without being distinguished from each other.
  • the module may be referred to as a “functional block”.
  • “Instance” means a sub-module that is called as a part from a higher-level module.
  • the circuit data has a configuration in which one or more submodules exist below the module (top module) located in the highest hierarchy. Calling a lower module (submodule) from a module located in a higher hierarchy is called “instantiating”, and an instantiated module is called “instance”.
  • FIG. 1 shows a configuration example of a computer system used in the verification process according to this embodiment.
  • the computer system includes a server 1, a terminal 2, and a storage device 3.
  • the server 1 and the terminal 2 are connected so as to be able to communicate with each other via a local area network (LAN) 4 configured using, for example, Ethernet.
  • the server 1 is connected to the storage apparatus 3 via a network 5 (or called SAN 5) configured by using, for example, a fiber channel (FibreChannel).
  • LAN local area network
  • SAN 5 or called SAN 5
  • FibreChannel fiber channel
  • the server 1 is a computer for performing logic circuit verification processing, and includes a CPU 11, a memory 12, a NIC (Network Interface Controller) 13 for connecting to the LAN 4, and an HBA (Host Bus Adapter) 14 for connecting to the SAN 5.
  • the memory 12 is a storage device such as a DRAM, for example, and is used to store the program or control information used when the program is executed when the CPU 11 executes the program.
  • the CPU 11 is a component that executes a program for executing the verification process according to the present embodiment.
  • the terminal 2 is a computer that is used by a logic circuit verifier to instruct the server 1 to execute a verification process or to refer to the result of the verification process.
  • the terminal 2 includes a CPU 21, a memory 22, a NIC 23 for connecting to the LAN 4, an HDD 24 used for storing programs and the like, and a human interface device (HID) 25 used by a verifier for input / output processing.
  • the HID 25 includes a display (output) device such as a display in addition to an input device such as a keyboard and a mouse.
  • the storage device 3 is a storage device for storing programs used by the server 1 and verification data.
  • the storage apparatus 3 includes a volume 31 that is a storage area composed of a nonvolatile storage device such as a magnetic disk, and a controller 30 (sometimes abbreviated as CTL 30) that processes I / O requests from the server 1. Have. There may be a plurality of volumes 31 and CTLs 30.
  • the volume 31 may be a storage area composed of a plurality of magnetic disks like a so-called disk array (or RAID). Further, any non-volatile storage device other than the magnetic disk may be used as the storage device constituting the volume 31. For example, a storage device (SSD) using a flash memory may be used.
  • SSD storage device
  • a logic circuit description circuit data described in a logic circuit description language (hardware description language) such as VHDL and a test pattern to be described later are given to the simulator.
  • the operation of the logic circuit designed by the circuit designer is simulated.
  • the circuit data that is, the designed logic circuit
  • the circuit data is verified by verifying whether the operation of the logic circuit executed by the simulator is valid (the operation expected by the designer or verifier). .
  • the circuit data of the logic circuit (verification target circuit) to be verified in the logic verification processing according to the present embodiment is referred to as “verification target circuit data”.
  • the circuit data to be verified may be created by a designer using a text editor or the like, or may be created using a known logic circuit design program (logic design tool).
  • the verification target circuit data may be created by a designer executing a logic design tool or the like on the server 1, or may be created by a computer other than the server 1.
  • the simulator 125 (also referred to as “logic verification tool 125”) is a program for simulating the verification target circuit.
  • the simulator 125 may be any program as long as it can simulate the operation of circuit data described in the hardware description language.
  • a known logic verification tool can be employed.
  • FIG. 1 shows a configuration example in which each program exists on the memory 12, but in actuality, each program is stored in a nonvolatile storage such as the volume 31 of the storage apparatus 3 when not being executed. Stored on media. Each program is read from the volume 31 onto the memory 12 when executed by the CPU 11.
  • the simulator 125 simulates the operation of the verification target circuit using the verification target circuit data in which the assertion is incorporated. If an assertion is incorporated, error information is displayed on the display of the computer (server 1) that is executing the simulation or a log file is displayed when a state that is not expected in the verification target circuit occurs during the simulation. Information indicating that an abnormality has occurred is output.
  • the assertion generation program 121 is a program for generating an assertion to be incorporated into the verification target circuit.
  • the test execution program 122 tests the verification target circuit data in which the assertion is incorporated. During the test, the test execution program 122 calls the simulator 125 and causes the simulator 125 to simulate the verification target circuit.
  • the determination program 123 is a program for checking the validity of circuit data to be verified after the execution of the test execution program 122.
  • the determination program 123 includes an expected value generation program 1231 and a result determination program 1232.
  • the expected value generation program 1231 and the result determination program 1232 are executed by being called from the determination program 123.
  • the configuration of the computer system shown in FIG. 1 is an example, and the verification processing according to the present embodiment can be performed even with other configurations.
  • the server 1 may be provided with a human interface device (HID).
  • the user who performs the verification may use the HID of the server 1 instead of the terminal 2 to refer to the verification processing execution instruction or the result.
  • HID human interface device
  • the server 1 and the storage device 3 may be connected to the LAN 4 instead of being connected to the SAN 4 different from the LAN 4.
  • the server 1 and the storage apparatus 3 communicate using the iSCSI protocol or a file access protocol such as NFS or CIFS.
  • a storage device such as an HDD may be provided in the server 1.
  • a nonvolatile storage device such as an HDD is provided in the server 1 in addition to the storage device 3, and an HDD or the like in which some programs or data among the programs and data used by the server 1 are provided in the server 1 It may be stored in the non-volatile storage device.
  • a plurality of servers 1 there may be a plurality of servers 1.
  • a plurality of servers 1 are provided, the assertion generation program 121 is executed by the first server 1, and the simulation of the verification target circuit data in which the assertion is incorporated is performed by the second server 1 (the simulator 125 in the second server 1). May be executed).
  • the second server 1 the simulator 125 in the second server 1). May be executed.
  • Various other configurations are possible.
  • the functional block of the logic circuit to be verified in this embodiment outputs a signal (referred to as an error signal) for notifying the outside that an error has occurred as an output signal when an error occurs.
  • a register for holding an error signal value (referred to as an error register).
  • error signals of the respective functional blocks are aggregated and the aggregated signals are input to an error signal register.
  • FIG. 2 is a circuit diagram describing a part of the verification target circuit. In the example of FIG. 2, the error signal of each functional block is mainly described, and the specific circuit diagram of each functional block is not shown.
  • FB0, FB1, and FB_ERR are functional blocks, respectively. Boxes in FB0 (B00-0, ... B00-30, B00-31, B01-0, ... B01-30, B01-31), and boxes in FB1 (B10-0, ... B10) ⁇ 30, B10-31) represents sub-function blocks in the function blocks FB0 and FB1.
  • a line (s_ERR0_31 etc.) coming out from each sub functional block (B00-31 etc.) represents an error output signal line (error signal line).
  • s_ERR0_0 to s_ERR0_31 and s_ERR1_0 to s_ERR1_31 exist as signal lines of the functional block FB0.
  • one (1 bit) error signal is output from each sub functional block.
  • the error signal output from each sub-function block in the function block FB0 is input to the register r00 via the signal lines s_ERR0_0 to s_ERR0_31 (that is, when an error signal is output, a value is stored in the register r00).
  • an error signal output from the sub functional blocks (B01-0 to B01-31) to which the signal lines s_ERR1_0 to s_ERR1_31 are connected is input to the register r01.
  • the sub function blocks (B10-0 to B10-31) to which the signal lines s_ERR0_0 to s_ERR0_31 in the function block FB1 are connected are input to the register r10.
  • the register r00 is a 32-bit register, and when an error signal is output to s_ERR0_n (n represents an integer value from 0 to 31), the output value (signal) is n bits of the register r00.
  • the registers r01 and r10 have the same relationship.
  • Each error signal is input to the registers in the functional block, and is aggregated and input to the registers r20 and r21 of the functional block FB_ERR. Specifically, for example, for the error signals output to the signal lines s_ERR0_0 to s_ERR0_31 in the functional block FB0, the logical sum (OR) of these error signals is calculated in the functional block FB0, and the calculation result is the register r20. It is input to a specific bit of r21.
  • the logical sum of the error signals output to s_ERR0_0 to s_ERR0_31 is input to specific bits of the registers r20 and r21. That is, when an error occurs in the sub-function block (when any error signal is output), the results are collected and stored in the registers r20 and r21 of the function block FB1.
  • FIG. 2 shows only an example in which the error signals of the function blocks FB0 and FB1 are aggregated in the registers r20 and r21 in the function block FB_ERR. However, the signal obtained by further integrating or processing the input error signals is shown in FB_ERR. There may be a circuit configuration in which the signal is generated in the memory and the signal is input to a register of another functional block.
  • the computer system stores the circuit data 300, the assertion description 310, the register specification table 320, the test pattern 330, the test parameter 340, the ignition expectation assertion list 350, the assertion result log 360, the test result log 370, the assertion in the volume 31.
  • a result list 380 is stored. These pieces of information are stored as one file or a plurality of files in the volume 31, respectively.
  • Circuit data 300 is circuit data of a verification target circuit created by a designer using a hardware description language.
  • verification simulation
  • a circuit description for adding an input signal to the circuit data 300 and a circuit description for observing an output signal are actually required.
  • the circuit description is called a “test bench”.
  • a test bench In the present embodiment, for simplicity of explanation, it is assumed that a test bench is included in the circuit data 300. However, as another embodiment, the test bench may be stored in the volume 31 as information different from the circuit data 300.
  • the test pattern 330 is input information (data pattern) to the verification target circuit used when the simulator 125 verifies the operation of the verification target circuit.
  • the test pattern 330 is created in advance (before the verification process) by the designer (or verifier) of the circuit to be verified. In the verification, many types of data patterns are given to the verification target circuit, and the validity of the operation of the verification target circuit is checked for each data pattern. Therefore, a plurality of data patterns are created. In the present embodiment, description will be made on the assumption that one data pattern is stored in one file. Unless otherwise specified, each file storing each data pattern is referred to as a “test pattern 330”. Each test pattern 330 is given a unique identifier (specifically, a file name).
  • This identifier (file name) is called a “test name”.
  • a plurality of data patterns may be stored in one file, and a certain identifier (test name) may be assigned to each of the plurality of data patterns stored in the file. .
  • the test parameter 340 includes information regarding each test pattern 330. An example of the contents of the test parameter 340 will be described with reference to FIG.
  • the test parameter 340 is management information including information of a test name 341, a test attribute 342, a function block name 343, and a signal name 344 for each test pattern.
  • the test name 341 is a test pattern identifier (for example, a file name) as described above.
  • the test pattern specified by the test name 341 is a test pattern of a normal system test (a test in which no error occurs in the verification target circuit) or a fault system test (in the verification target circuit). Information indicating whether the test pattern is a test pattern in which an error is expected to occur.
  • test pattern When “normal system” is stored in the test attribute 342, it means that the test pattern is a test pattern of a normal system test. Conversely, when “failure type” is stored in the test attribute 342, it means that the test pattern is a test pattern of the fault type test.
  • the test pattern of the fault test is a test in which a signal of a pattern that cannot actually occur is input to any one module in the verification target circuit, and an error signal is expected to be output from that module It is a pattern.
  • the function block name 343 and the signal name 344 are valid information only when the test attribute 342 is “faulty”.
  • each module in the verification target circuit outputs an error output signal.
  • the circuit is premised on having an (output signal of at least one bit) and an error output register for holding the contents of this signal.
  • the error output signal bit of that module is turned ON (1), and the information is also stored in the error output register.
  • the error output register is defined as a register variable in a hardware description language such as VHDL.
  • the register variable defined as the error output register is referred to as a failure register variable.
  • the character string “ERR” is included in the variable name of the failure register variable ( The character string “ERR” is not used in register variables other than the fault register variable). However, the character string does not have to be “ERR” in the name of the fault register variable. It is only necessary that the character string to be used for the name of the fault register variable is uniquely determined in the circuit data.
  • the function block name 343 stores the name of the module (functional block) that is expected to output an error signal when the test pattern specified by the test name 341 is input.
  • the name stored in the function block name 343 is exactly the instance name in which the function block (module) is instantiated. However, in order to prevent the description from becoming redundant, the function block name will be described below.
  • the signal name 344 is the name of the error signal that is expected to be turned ON at that time.
  • the test parameter 340 is created simultaneously with the test pattern 330 by the designer (or verifier) of the circuit to be verified.
  • the register specification table 320 is information indicating the specification of the error output register and the propagation destination of the error signal. Similarly to the test parameters 340 and the like, the register specification table 320 is information created in advance (before verification) by the designer (or verifier) of the circuit to be verified. An example of the contents of the register specification table 320 will be described with reference to FIG.
  • One register specification table 320 is created for each register that holds error signal states in a module (functional block).
  • the register specification table 320 includes a function block name 321, a register name 322, a (register) bit (320-0), a signal name 320-1, a connection destination block name 320-2, and a connection destination register name 320-3. It is.
  • the function block name 321 and the register name 322 store the name of the function block (module) that is the output source of the error signal and the name of the error output register (name of the fault register variable), respectively.
  • the signal name 320-1 is a name of a signal line (error signal line) used for propagating an error signal output from the functional block specified by the functional block name 321 to another functional block.
  • the value output to the signal line specified by the signal name 320-1 is also stored in the error output register specified by the register name 322. Referring to FIG. 4, bit (320-0) exists in front of signal name 320-1, but bit (320-0) is in the error output register (register specified by register name 322). It is information representing a specific bit among the bits.
  • the register name 322, bit (320-0), and signal name 320-1 have the following relationship.
  • the signal name 320-1 in the row where bit (320-0) is “30” is “s_ERR0_30”.
  • the 30th bit of the register STS_REG_ERR_0 indicates that the value of the signal line s_ERR0_30 is stored.
  • connection destination block name 320-2 and the connection destination register name 320-3 store the name of the module that is the propagation destination of the error signal and the name of the register, respectively.
  • the numerical value in parentheses represents the bit position of the register that is the storage destination of the error signal.
  • FIG. 4 shows the contents of the register specification table 320 storing the information on the propagation destinations of the error signals s_ERR0_0 to s_ERR0_31 in the module FB0 in the circuit diagram of FIG.
  • the logical sum (OR) of the error signals s_ERR0_0 to s_ERR0_31 is connected to the registers STS_REG_0 and STS_REG_1 in the module FB_ERR. Therefore, in the register specification table 320 of FIG.
  • FB_ERR is stored in the connection destination block name 320-2 of the signal name (320-1) s_ERR0_0 to s_ERR0_31
  • STS_REG_0 is stored in the connection destination register name 320-3.
  • STS_REG_1 is stored.
  • register variable names may be names unique within the module. Therefore, register variables with the same name may be defined in different modules.
  • FIG. 5 shows a register specification table 320 for the register STS_REG_0 in the module FB_ERR in the circuit diagram of FIG.
  • no error signal is output from the module FB_ERR to another module. Therefore, in the register specification table 320 of FIG. 5, invalid values (null) are stored in the connection destination block name 320-2 and the connection destination register name 320-3. In other words, if “null” is stored in the connection destination block name 320-2 and the connection destination register name 320-3, it means that the error signal is not propagated to another module any more.
  • connection destination of the error signal between modules is recorded in the register specification table 320, and the error signal is propagated by tracing the connection destination block name 320-2 and the connection destination register name 320-3.
  • Block or register (or block or register of aggregation destination) can be specified. That is, the register specification table 320 has a tree structure.
  • the assertion description 310, the firing expectation assertion list 350, the assertion result log 360, the test result log 370, and the assertion result list 380 will be described in the process of explaining the flow of the verification process.
  • assertion-based verification is performed. Therefore, before verification using the simulator 125, it is necessary to prepare so that the assertion description generated and the assertion generated when the verification using the simulator 125 is performed properly function.
  • the assertion created in this embodiment is created for each module.
  • Each assertion outputs an error message to the assertion result log 360 when the module error signal is turned ON (1).
  • the assertion created for the module B00-31 outputs an error message.
  • the assertion enters a state where an error message is output it is expressed as a state where the assertion has fired.
  • the created assertion description functions properly at the time of verification (that is, the assertion is ignited when the error signal is turned ON). It is necessary to set to. This process is called “incorporating assertions”.
  • the assertion description may be directly embedded in the verification target circuit data described in VHDL or the like, or the assertion description is stored in a file separate from the verification target circuit data. You may be made to do. In this embodiment, the description will be focused on an example in which the generated assertion description is stored in a file different from the verification target circuit data.
  • test using the test execution program 122 is performed.
  • a test pattern 330 created in advance is used as input information. Therefore, the verifier of the circuit to be verified needs to create the test pattern 330 and store it in the volume 31 at least before the test using the test execution program 122 is performed. Since the specific contents of the test pattern 330 are not directly related to the verification processing according to the present embodiment, description thereof is omitted in the present embodiment.
  • the operation of the verification target circuit is simulated when the input information described in the test pattern 330 is input to the verification target circuit.
  • the test execution program 122 calls the simulator 125 to cause the simulator 125 to simulate the operation of the verification target circuit.
  • the error signal is turned ON, the assertion is fired and an error message is output to the assertion result log 360.
  • the determination program 123 is executed to determine the validity of the test result.
  • the verifier needs to create the test parameter 340 and the register specification table 320 and store them in the volume at least up to this point.
  • the test parameter 340 and the register specification table 320 may be created before the test.
  • the logic circuit to be verified Is designed as expected.
  • the determination program 123 determines whether the signal of the signal name 344 is ON by comparing the contents of the assertion result log 360 with the contents of the test parameter 340.
  • an error signal may be propagated to another module, and the error signal may be stored in a register of another module (referred to as a propagation destination register).
  • the operation expected for the circuit to be verified is that the propagation destination register is also turned ON. Therefore, the determination program 123 determines whether there is a propagation destination register by referring to the register specification table 320. If there is a propagation destination register, the determination program 123 also determines whether the value of the propagation destination register (or an error signal connected to the propagation destination register) is ON.
  • the determination program 123 determines whether a signal that is not expected to be ON is ON.
  • the determination program 123 extracts only the output different from the output expected by the designer (verifier) of the circuit to be verified from a large number of messages, and outputs the extracted result to the test result log 370 and the assertion result list 380. To do. Thereby, the confirmation efficiency of a test result can be improved.
  • FIG. 6 is a processing flow of the assertion generation program 121.
  • the verifier instructs the server 1 to start the assertion generation program 121 using the HID 25 of the terminal
  • the assertion generation program 121 is started on the server 1.
  • the assertion generation program 121 reads the verification target circuit data from the volume 31 (step a-1), and selects one module from the verification target circuit data (step a-2). Subsequently, the assertion generation program 121 determines whether or not a failure register variable is defined in the read circuit data to be verified (step a-4). As described above, the verification method according to this embodiment is based on the premise that the fault register variable name includes the character string “ERR”. Therefore, in step a-4, a variable including the character string “ERR” is searched. If the fault register variable is not defined (a-4: N), the process proceeds to step a-8.
  • the assertion generation program 121 determines whether the fault register variable is used in the read circuit data to be verified (step a-5). This determination is performed, for example, by determining whether a description in which the failure register variable is set to 1 exists in the verification target circuit data.
  • step a-6 If the fault register variable is not used in the read circuit data to be verified (a-5: N), steps a-6 and a-7 are not executed, and step a-8 is performed next.
  • the failure register variable is used (a-5: Y)
  • the assertion generation program 121 When the failure register variable is used (a-5: Y), the assertion generation program 121 generates an assertion (step a-6).
  • the assertion generation program 121 creates an assertion for each failure register variable.
  • the failure register variable is a variable of a plurality of bits (for example, 32 bits)
  • an assertion is generated for each bit of the failure register variable. That is, when the fault register variable is a 32-bit variable, 32 assertions are generated.
  • the assertion generation program 121 In step a-6, the assertion generation program 121 generates an assertion for outputting a message for each bit of the fault register variable when the bit of the fault register variable changes from 0 to 1.
  • the assertion generation program 121 has an algorithm for generating an assertion name, and generates an assertion name according to the algorithm.
  • the algorithm for generating the assertion name outputs (generates) the assertion name using the name of the functional block to be asserted and the name of the fault register variable and the bit position of the fault register variable.
  • An expected value generation program 1231 described later also has the same algorithm as the assertion name generation algorithm used by the assertion generation program 121. Therefore, if the name of the functional block, the name of the fault register variable, and the bit position of the fault register variable are given, the same assertion name as the assertion name generated by the assertion generation program 121 can be generated.
  • the assertion generation program 121 stores the generated assertion description 310 in the volume 31 (step a-7).
  • the generated assertion is stored in the volume 31 as data (assertion description 310) different from the verification target circuit data (circuit data 300).
  • the assertion description may be directly embedded in the circuit data. That is, in step a-7, processing for inserting an assertion description into the description of the module defining the functional block in the verification target circuit data may be performed.
  • step a-8 the assertion generation program 121 determines whether the processing from step a-1 to step a-7 has been performed for all modules. When it is confirmed that the processing up to step a-7 has been performed for all the modules (step a-8: Y), the assertion generation program 121 ends the processing. If a module that has not been processed remains (step a-8: N), the assertion generation program 121 repeats the processing from step a-2.
  • test execution program 122 When the verifier instructs the server 1 to start a test using the HID 25 of the terminal, the test execution program 122 is started.
  • the test execution program 122 calls the simulator 125 to start a test (simulation) of the verification target circuit data (step s1-1). Details of the processing performed in step s1-1 will be described later.
  • step s1-2 When the simulation by the simulator 125 is completed, the status is returned from the simulator 125 to the test execution program 122 (step s1-2). If the status is “ok” (step s1-3: Y), it means that the simulation has been completed normally. Therefore, in this case, the test execution program 122 writes in the test result log 370 that the test has been completed normally (step s1-4).
  • step s1-3: N If the status is “NG” (step s1-3: N), the test execution program 122 writes in the test result log 370 that the test ended abnormally (step s1-5), and the test execution program 122 performs processing. Exit.
  • FIG. 8 shows an example of the test result recorded in the test result log 370.
  • the test result includes information of a test name 501, simulation end status 502, expected value generation status 503, assertion determination result 504, error assertion name 505, expected 506, and actual 507.
  • the value of the simulation end status 502 is “ok”, it means that the test pattern specified by the test name 501 is normally executed by the simulator 125.
  • the value of the simulation end status 502 is “NG”, it means that the process in the simulator 125 has ended abnormally during the execution of the test pattern specified by the test name 501.
  • As a cause of abnormal termination there is a case where there is a defect in the verification target circuit data, for example.
  • the expected value generation status 503, the assertion determination result 504, the error assertion name 505, the expected 506, and the actual 507 are not recorded ("null" is recorded).
  • the output trigger of these pieces of information and the contents of the information will be described later.
  • 8 shows an example in which the data structure of the test result log 370 is a table, the output data structure (format) may be arbitrary.
  • the test name 501, the simulation end status 502, the expected value generation status 503, the assertion determination result 504, the error assertion name 505, the expected 506, and the actual 507 are separated by commas (so-called CSV format). It may be output.
  • test execution program 122 calls the determination program 123 and performs determination processing (s2). After the determination process ends, the test execution program 122 ends. Details of the processing of s2 will be described later.
  • step s1-1 Outlines the processing performed in step s1-1.
  • simulation of circuit data to be verified is started. Strictly speaking, in order to test the verification target circuit data, it is necessary to prepare a test environment (test bench) of the verification target circuit. Here, an example in which the test bench is already prepared will be described.
  • the verifier instructs the server 1 to start a test using the HID 25 of the terminal, but designates one of the test patterns 330 input to the verification target circuit. Specifically, a test name (any one test name registered in the test name 341) is designated.
  • ⁇ Assertion may fire when simulation of the verification target circuit is executed. As described above, when an assertion is fired, a message indicating that the assertion has fired is output to the assertion result log 360.
  • assertion result log 360 An example of the assertion result log 360 is shown in FIG. When the assertion is fired, the assertion firing time (360-0) and the assertion name (360-1) are output to the assertion result log 360 together with the message “ASSERTION FAILED”.
  • the determination program 123 selects a record in which the test name 341 matches the test name specified by the verifier in step s1-1 from the test parameter 340 row (hereinafter referred to as “record”).
  • the test attribute 342 of the record is acquired (step s2-1).
  • the determination program 123 determines whether the test attribute 342 acquired in step s2-1 is “normal system” or “failure system”.
  • step s2-2 normal system
  • the determination program 123 executes the result determination program 1232 (step s4) and ends the process.
  • the processing content of the result determination program 1232 will be described later.
  • the determination program 123 executes the expected value generation program 1231 (step s3).
  • the processing content of the expected value generation program 1231 will be described later.
  • the expected value generation program 1231 outputs information such as status to the test result log 370 at the end, and details of the information output to the test result log 370 will be described later.
  • the determination program 123 reads the status output from the expected value generation program 1231 from the test result log 370 (step s2-3), and determines whether the expected value generation program 1231 has ended normally (step s2-4). When the expected value generation program 1231 ends normally (step s2-4: Y), the determination program 123 executes the result determination program 1232 (step s4) and ends the process. If the expected value generation program 1231 does not end normally (step s2-4: N), the determination program 123 ends the process without executing the result determination program 1232.
  • the expected value generation program 1231 analyzes the test parameter 340, the register specification table 320, and the verification target circuit data, and specifies the name of the assertion description that should be fired if the verification target circuit data is correctly designed.
  • the name of the identified assertion description is stored in the ignition expectation assertion list 350.
  • step s3-1 the expected value generation program 1231 acquires the function block name 343 and the signal name 344 from the test parameter 340 record selected in s2-1.
  • the signal line specified by the function block name 343 and the signal name 344 acquired here is referred to as a “failure detection target signal”.
  • the failure detection target signal is expected to be turned on when the test specified by the record of the test parameter 340 selected in s2-1 is executed.
  • step s3-2 the expected value generation program 1231 reads the verification target circuit data, and in step s3-3, the (sub) module to which the failure detection target signal is connected and its ( Identify fault register variables defined in sub) modules.
  • step s3-3 specifically, the instance name of the module to which the failure detection target signal is connected is specified.
  • the assertion incorporated in the functional block (module) specified here is an assertion that is expected to be ignited when the test using the test parameter 340 selected in step s2-1 is performed.
  • the error signal s_ERR0_31 is connected to the submodule B00-31 in FB0. Therefore, when s_ERR0_31 is specified as the failure detection target signal in step s3-1, in step s3-3, the submodule B00-31 and the fault register variable defined in the submodule B00-31 are specified.
  • step s3-5 the expected value generation program 1231 generates an assertion name using the information of the (sub) function block and the fault register variable specified in step s3-3.
  • the assertion name generated here is a name recorded in the assertion result log when the assertion is fired.
  • the expected value generation program 1231 reads the plurality of register specification tables 320 stored in the volume 31, and registers the failure detection target signal registered in the signal name 320-1 from among them.
  • the specification table 320 is specified.
  • the expected value generation program 1231 identifies the register name 322 registered in the register specification table 320.
  • step s3-6 if the register specification table 320 in which the failure detection target signal is registered does not exist in the signal name 320-1 (step s3-7: N), the expected value generation program 1231 A status (character string “exp_NG”) indicating that the expected value generation program 1231 has ended abnormally is written in the expected value generation status 503 of the test result log 370 (step s3-17), and the processing ends.
  • the expected value generation program 1231 A status (character string “exp_NG”) indicating that the expected value generation program 1231 has ended abnormally is written in the expected value generation status 503 of the test result log 370 (step s3-17), and the processing ends.
  • the expected value generation program 1231 displays the register name 322 and the failure detection target of the register specification table 320. Using the bit (320-0) corresponding to the signal, an assertion name expected to fire is generated (step s3-9). For example, when s_ERR0_31 is specified as the failure detection target signal and the contents of the register specification table 320 are those described in FIG. 4, the expected value generation program 1231 sets “3” as the register name 322 in step s3-9.
  • STS_REG_ERR_0 is specified, and bit (320-0) of the line where" s_ERR0_31 "is registered in the signal name 320-1, that is," 31 "is specified. Then, an assertion name including these pieces of information (“STS_REG_ERR — 0” and “31”) is generated.
  • step s3-10 the expected value generation program 1231 extracts the connection destination register name 320-3 and the bit (320-0) corresponding to the failure detection target signal from the register specification table 320 specified in step s3-6.
  • the connection destination block name 320-2 and the connection destination register name 320-3 may not be stored in the register specification table 320, and in this case, steps s3-11 and s3-12 are not performed.
  • the expected value generation program 1231 checks the validity of the register specification table 320 specified in step s3-6 (or step s3-14 described later). In step s3-11, the expected value generation program 1231 checks whether the connection destination register name 320-3 extracted in step s3-10 exists in the other register specification table 320.
  • step s3-11: N If the connection destination register name 320-3 extracted in step s3-10 does not exist in the other register specification table 320 (step s3-11: N), this means that there is an error in the contents of the register specification table 320. In that case, the expected value generation program 1231 executes step s3-17 and ends the process.
  • connection destination register name 320-3 extracted in step s3-10 exists in the other register specification table 320 (step s3-11: Y)
  • the expected value generation program 1231 is extracted in step s3-10. It is checked whether the connection destination register name 320-3 exists in the previously checked register specification table 320 (step s3-12).
  • connection destination register name 320-3 extracted in step s3-10 exists in the register specification table 320 checked previously (step s3-12: Y), this means that the connection destination register is looped. To do. In this case, the expected value generation program 1231 performs step s3-17 and ends the process. If the connection destination register name 320-3 extracted in step s3-10 does not exist in the previously-registered register specification table 320 (step s3-12: N), step s3-13 is performed.
  • the expected value generation program 1231 refers to the test parameter 340 to identify the signal line (signal name 344) where the error occurs (turns ON), and further refers to the register specification table 320 (for example, FIG. 4).
  • the function block and the register (connection destination block name (320-2), connection destination register name (320-3)) to which this signal line is connected are specified (this is the process of steps s3-6 to s3-10) Is).
  • the expected value generation program 1231 repeats the processing of steps s3-9 to s3-14, thereby register specification table 320 (for example, FIG. 5) of the functional block (register) to which the specified functional block (register) is connected. ) Is repeated.
  • the expected value generation program 1231 can trace the propagation destination of the error (signal output to s_ERR0_31) generated in the functional block B00-31 in FIG. 2, for example. All can be identified.
  • connection destination block name (320-2) and the connection destination register name (320-3) are “null”, meaning that no error signal propagates before the function block FB_ERR. It has become.
  • the register specification table 320 is manually created (by a verifier) based on the design specifications of the logic circuit. For this reason, an error may be included in the contents of the register specification table 320 due to an error of the creator (verifier).
  • connection destination block name (320-2) and connection destination register name (320-3) in FIG. 5 are checked before the register specification table 320 in FIG. 5 is checked.
  • the function block names and register names (failure register variables defined in the function block FB0 and function block FB0 (for example, STS_REG_ERR_0)) of the specified register specification table 320 (for example, FIG. 4) are stored.
  • the register specification table 320 is in such a state, it means that the circuit has a circuit configuration in which an error is infinitely looped so that an error signal propagated from the functional block FB0 to the functional block FB_ERR returns to FB0. However, this is a circuit design that is impossible in practice. In step s3-12, such an error is detected.
  • steps s3-11 and s3-12 are performed as the check of the contents of the register specification table 320 has been described. However, other checks may be performed. .
  • step s3-13 If the connection destination block name 320-2 and the connection destination register name 320-3 are stored in the register specification table 320 to be checked up to step s3-12 (step s3-13: Y), the expected value The generation program 1231 specifies the register specification table 320 in which the connection destination block name 320-2 and the connection destination register name 320-3 are registered (step s3-14). Then, the expected value generation program 1231 performs the processes of steps s3-9 to s3-12 on the specified register specification table 320.
  • connection destination block name 320-2 and the connection destination register name 320-3 are not stored in the register specification table 320 to be checked up to step s3-12 (step s3-13: N), expected value generation
  • the program 1231 performs the processing after step s3-15.
  • step s3-15 the expected value generation program 1231 stores the assertion names generated in steps s3-5 and s3-9 in the ignition expected assertion list 350 (step s3-15), and the expected value in the test result log 370.
  • a status (character string “exp_ok”) indicating that the expected value generation program 1231 has been normally terminated is written in the generation status 503 (step s3-16), and the processing is terminated.
  • the expected ignition assertion list 350 stores the assertion names generated in steps s3-5 and s3-9 in the expected ignition assertion name 602. Further, the test name 201 stored in the record of the test parameter 340 selected in s2-1 is stored in the test name 601.
  • the result determination program 1232 reads the ignition expectation assertion list 350 generated by the expected value generation program 1231 (step s4-1) and the assertion result log 360 (step s4-2).
  • the result determination program 1232 determines whether or not the assertion name (assertion name expected to be ignited) stored in the expected ignition assertion list 350 exists in the read assertion result log 360 (step s4-4). . If there is no assertion expected to be fired in the assertion result log 360 (step s4-4: N), the result determination program 1232 generates failure assertion error information (step s4-5).
  • the failure assertion error information is a set of information to be stored in the test result log 370.
  • step s4-5 (or step s4-7)
  • the result determination program 1232 generates information corresponding to the error assertion name 505, expected 506, and actual 507 as failure assertion error information. Details of the error assertion name 505, the expected 506, and the actual 507 will be described later.
  • the result determination program 1232 determines whether there is an assertion name that is not stored in the ignition expectation assertion list 350 in the read assertion result log 360 (step s4-6). If an assertion name that is not stored in the firing expectation assertion list 350 exists in the assertion result log 360 (step s4-6: Y), it means that an assertion that is not originally expected to fire is firing. . Also in this case, the result determination program 1232 generates failure assertion error information (step s4-7).
  • step s4-8 When failure assertion error information is generated as a result of the processing up to step s4-7 (step s4-8: Y), the result determination program 1232 stores “FAIL” in the assertion determination result 504 of the test result log 370 ( In step s4-10), the failure assertion error information generated in step s4-5 or s4-7 is stored in the error assertion name 505, expected 506, and actual 507 of the test result log 370 (step s4-11).
  • step s4-8 If failure assertion error information is not generated as a result of the processing up to step s4-7 (step s4-8: N), the result determination program 1232 stores “PASS” in the assertion determination result 504 of the test result log 370. (Step s4-9). Finally, the result determination program 1232 adds the contents stored in the test result log 370 in steps s4-8 to s4-11 to the assertion result list 380 (step s4-12), and ends the process.
  • FIG. 16 shows an example of the contents of the test result log 370 after the execution of the process of the result determination program 1232.
  • FIG. 16A shows an example of the test result log 370 when the test pattern with the test name “TEST_FB0_ERR0_31” is executed.
  • assertion determination result 504 is “PASS” (that is, if step s4-5 or s4-7 has not been executed)
  • “PASS” is recorded in the assertion determination result 504
  • the error assertion name 505, expected 506, actual 507 are recorded.
  • “Null” is recorded in (FIG. 16B).
  • the assertion result list 380 is a file in which a plurality of test results are accumulated. As described above, since the same contents as the contents stored in the test result log 370 are stored in the assertion result list 380, the test name 501 and the simulation end status are stored in the assertion result list 380 in the same manner as the test result log 370. Information of 502, expected value generation status 503, assertion determination result 504, error assertion name 505, expected 506, and actual 507 is stored. However, when the test execution program 122 is executed for n test patterns, n execution results are accumulated in the assertion result list 380.
  • the server that executes the verification method according to the present embodiment creates a list of assertions that are expected to fire based on the test parameters for the circuit to be verified and the contents of the register specification table. Then, the server that executes the verification method according to the present embodiment collates the contents of the assertion result log generated by executing the simulation of the circuit to be verified with the contents of the list of assertions expected to fire. And as a result of this collation, among the assertions that are expected to fire, create a list of assertions that did not actually fire, and a list of assertions that were fired even though they were not expected to fire, and output them as errors To do. At the same time, the server also checks the contents of the register specification table in the process of creating a list of assertions that are expected to fire. As a result, information to be verified by the verifier is greatly narrowed down, and verification costs can be reduced.
  • test execution program 122 when executed once, verification using one test pattern is executed once.
  • verification when the test execution program 122 is executed once, verification may be performed using a plurality of test patterns.
  • n test patterns 330 are stored in the volume 31, the test execution program 122 may be executed n times to perform verification using the n test patterns.
  • the assertion determination result is output to the file of the volume 31.
  • the result is output to the file of the terminal 2 in addition to outputting to the file. May be.
  • the assertion generation program 121 is executed to incorporate the assertion into the circuit data, and then the test execution program 122 is executed to perform simulation of the circuit data and the validity determination of the test result is described.
  • the assertion generation program 121 is not essential for verification.
  • the above-described verification can be performed by executing the test execution program 122 without executing the assertion generation program 121.
  • the assertion name of the assertion incorporated in the circuit data needs to be generated according to the same rule as the assertion name generation algorithm of the expected value generation program 1231.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Tests Of Electronic Circuits (AREA)

Abstract

本発明の論理回路の検証方法は、エラー発生時にエラー信号を出力するとともに、出力されたエラー信号の格納用のレジスタを備えた機能ブロックを複数有する論理回路をハードウェア記述言語で記述した論理回路記述に対して、アサーションを組み込む工程と、テストパターンと、テストパターンが入力されることによりエラーが発生することが期待される機能ブロックのエラー信号の名称とから構成されるテストパラメータを読み込む工程と、機能ブロックから出力されるエラー信号の名称と、エラー信号の出力値を格納する機能ブロック内のレジスタであるエラーレジスタの名称と、エラー信号の伝搬先のレジスタ及び機能ブロックの名称とから構成されるレジスタ仕様とに基づいて、論理回路記述に組み込まれたアサーションのうち、テストパターンを用いた論理回路のテストを実行した時に発火することが期待されるアサーションの一覧を生成する工程とを実行する。

Description

論理回路の検証方法
　本発明は、論理回路の検証技術に関する。
　情報処理技術の進歩に伴って、情報処理装置に搭載される半導体集積回路の大規模化が進んできている。また、情報処理装置に対する高性能化や高機能化の要求に伴って、半導体集積回路の内部の構成が、非常に複雑になってきている。
　大規模で複雑化した半導体集積回路を適切に設計し、品質の高い製品を得るために、半導体集積回路の設計においては、機能検証などを行う検証工程に多くの時間や工数が費やされる。検証工程に要する時間や工程数の増加は、製品のコストの増大に繋がる。そのため、大規模で複雑化した半導体集積回路の検証を効率よく実行することが望ましい。
　半導体集積回路の検証工程で用いられる技術の一つとして、アサーションベース検証が知られている。アサーションとは、設計した回路で期待されている状態や動作、または禁止されている状態や動作などを、検証用言語（アサーション記述言語）あるいはハードウェア記述言語を用いて記述したものである。アサーションベース検証とは、アサーションを検証対象回路のモデル内に組み込むことで、検証対象の回路の動作の確認を行う方法である。アサーションを組み込むことで、検証対象回路のシミュレーション中に想定していない状態が発生した場合に、シミュレーションを実行している計算機の表示装置やログファイルに、異常が発生したことを示す情報（エラー情報）が出力される。そのため検証者は容易に検証対象回路の不具合を特定できる。
　さらに、アサーションベース検証における、検証精度の向上や解析作業工数の削減のための技術も知られている。特許文献１に開示の設計検証方法では、設計検証装置が、ある試験パターンの要求が実行される時に、実行が期待されるアサーションの実行回数を記録したアサーション期待値テーブルを生成し、このアサーション期待値テーブルの内容と、論理シミュレーションの実行結果との整合性を判定する。設計検証装置がアサーション期待値テーブルの生成を行う際、オペレータにより、各アサーションを試験パターンの各要求に対して実行するか否かの情報、及び実行する場合の実行回数の情報（アサーション制約情報）が設計検証装置に与えられる。
特開２０１２－１５０７２３号公報
　試験対象の回路が大規模化すればするほど、テストパターンとアサーションの数は膨大になり、その組合せ数はさらに膨大となる。しかしながら、特許文献１の従来技術では、オペレータにより各アサーションを試験パターンの各要求に対して実行するか否かの情報を設計検証装置に与えなければならないため、検証コストが増加してしまう。
　本発明の一観点に係る論理回路の検証方法は、エラー発生時にエラー信号を出力するとともに、前記出力されたエラー信号の格納用のレジスタを有する機能ブロックを複数有する論理回路について、ハードウェア記述言語で記述された論理回路記述を用いて検証を行う。当該方法では論理回路への入力情報であるテストパターンの名称と、前記テストパターンが入力されることによりエラーが発生することが期待される機能ブロックのエラー信号の名称とを有するテストパラメータを読み込む工程と、機能ブロックから出力されるエラー信号の名称と、当該エラー信号の出力値を格納する機能ブロック内のレジスタであるエラーレジスタの名称と、エラー信号の伝搬先のレジスタ及び当該レジスタを有する機能ブロックの名称とを有する、１以上のレジスタ仕様と、テストパラメータとに基づいて、論理回路記述に組み込まれたアサーションのうち、テストパターンを用いた前記論理回路のテストを実行した時に発火することが期待されるアサーションの一覧を生成する工程とを実行する。
　本発明の一観点に係る検証方法によれば、大規模な論理回路の検証コストを低減することができる。
実施例に係る計算機システムの構成図である。 検証対象回路の一例である。 テストパラメータの例である。 レジスタ仕様テーブルの例である。 レジスタ仕様テーブルの例（２）である。 アサーション生成プログラムの実施する処理のフローチャートである。 テスト実行処理のフローチャートである。 テスト結果ログの例である。 アサーション結果ログの例である。 テスト判定プログラムの実施する処理のフローチャートである。 期待値生成プログラムの実施する処理のフローチャートである。 期待値生成プログラムの実施する処理のフローチャート（２）である。 発火期待アサーションリストの例である 結果判定プログラムの実施する処理のフローチャートである。 結果判定プログラムの実施する処理のフローチャート（２）である。 結果判定プログラム実行後のテスト結果ログの例である。
　以下、本発明の実施例について、図面を用いて説明する。なお、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
　また、以下で検証処理等の流れを説明する際、「プログラムは、…を行う」のような表現で処理内容を説明することがある。プログラムはプロセッサ（ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ））によって実行されることで、定められた処理を計算機に行わせるものであるから、プログラムが動作主体となる表現は必ずしも正確な表現ではない。ただし説明が冗長になることを防ぐため、以後の説明では「プログラム」を主語として、処理の内容を説明することがある。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって、プログラムを使用するユーザに提供され、プログラムを実行する計算機にインストールされてもよい。計算機が読み取り可能な記憶メディアとは、非一時的なコンピュータ可読媒体で、例えば、ＩＣカード、ＳＤカード、ＤＶＤ等の不揮発性記憶媒体である。また、プログラムの一部または全てが専用ハードウェアによって実現されてもよい。
　実施例の説明に入る前に、以下で説明する実施例で用いられる各種用語について説明する。
　本実施例の検証処理（論理検証処理）は、実際の半導体集積回路（以下、「論理回路」と呼ぶ）のテスト等の検証作業を行うものではなく、サーバ等の計算機上で動作する論理検証ツール（シミュレータ）を用いて論理回路の動作のシミュレーションを行うことで、論理回路の検証を行う。この時、論理回路の検証者は、ハードウェア記述言語で記述された論理回路の動作仕様（振る舞い）の情報をシミュレータに与えることで、シミュレータに論理回路の動作のシミュレーションを行わせる。本実施例では、ハードウェア記述言語で記述された論理回路の動作仕様の情報のことを「回路データ」と呼ぶ。また、シミュレータに回路データを与えて論理回路の動作のシミュレーションを行う作業・処理のことを、「論理回路のシミュレーションを行う」と表現する。
　「アサーション」とは、設計した論理回路で期待されている状態や動作、または禁止されている状態や動作などを、検証専用言語（アサーション記述言語）あるいはハードウェア記述言語を用いて記述したものである。アサーションは、「アサーション記述」と呼ばれることもある。検証者がアサーションを回路データに組み込み、このアサーションの組み込まれた回路データを用いたシミュレーションを行うと、たとえばその論理回路で禁止されている状態が発生した場合に、シミュレーションを実行している計算機の表示装置にエラー情報が出力される、あるいはログファイルに異常が発生したことを示す情報が出力される。
　「モジュール」とは、回路データに含まれる、一部の機能についての回路記述のことを意味する。大規模な論理回路の設計では、設計者は論理回路を幾つかの機能ブロックに分割して、機能ブロックごとに設計を行う。そして設計された複数の機能ブロックを接続することで、論理回路が構成される。さらに階層的な設計が行われることもあり、その場合、機能ブロックがいくつかのサブ機能ブロックに分割され、サブ機能ブロック毎の設計が行われる。本実施例では、機能ブロックについての回路記述のことを「モジュール」と呼ぶ。またサブ機能ブロックについての回路記述のことを「サブモジュール」と呼ぶ。ただし以下では、機能ブロックとサブ機能ブロックとを区別せずに「機能ブロック」と呼ぶこともある。同様に、モジュールとサブモジュールとを区別せずに「モジュール」と呼ぶこともある。また、回路と回路データを区別して表現する必要がない場合には、モジュールのことを「機能ブロック」と呼ぶこともある。
　「インスタンス」とは、上位のモジュールから部品として呼び出されるサブモジュールのことを意味する。階層的な論理回路の設計が行われる場合、回路データは、最上位階層に位置するモジュール（トップモジュール）の下位に１以上のサブモジュールが存在する構成になる。上位階層に位置するモジュールから下位のモジュール（サブモジュール）を呼び出すことを「インスタンス化」と呼び、インスタンス化されたモジュールのことを「インスタンス」と呼ぶ。
　続いて実施例の説明を行う。図１は、本実施例に係る検証処理で用いられる計算機システムの構成例を示している。計算機システムは、サーバ１、端末２、ストレージ装置３を有する。サーバ１と端末２は、例えばイーサネット（Ｅｔｈｅｒｎｅｔ）を用いて構成されたローカルエリアネットワーク（ＬＡＮ）４を介して、相互通信可能に接続される。サーバ１は、たとえばファイバチャネル（ＦｉｂｒｅＣｈａｎｎｅｌ）を用いて構成されたネットワーク５（またはＳＡＮ５と呼ばれる）を介して、ストレージ装置３と接続される。
　サーバ１は、論理回路の検証処理を実施するためのコンピュータで、ＣＰＵ１１、メモリ１２、ＬＡＮ４に接続するためのＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃｏｎｔｒｏｌｌｅｒ）１３、そしてＳＡＮ５に接続するためのＨＢＡ（Ｈｏｓｔ　Ｂｕｓ　Ａｄａｐｔｅｒ）１４を有する。メモリ１２はたとえばＤＲＡＭ等の記憶デバイスで、ＣＰＵ１１がプログラムを実行する時に、そのプログラムまたはプログラムの実行時に用いられる制御情報等を格納するために用いられる。ＣＰＵ１１は本実施例に係る検証処理を実施するためのプログラムを実行するコンポーネントである。
　端末２は、論理回路の検証者がサーバ１に対して検証処理の実行を指示する、または検証処理の結果を参照するために用いられる計算機である。端末２は、ＣＰＵ２１、メモリ２２、ＬＡＮ４に接続するためのＮＩＣ２３、プログラム等の格納に用いられるＨＤＤ２４、そして検証者が入出力処理を行うために用いるヒューマンインタフェースデバイス（ＨＩＤ）２５を有する。ＨＩＤ２５には、キーボードやマウスなどの入力装置の他、ディスプレイ等の表示（出力）装置も含まれる。
　ストレージ装置３は、サーバ１が使用するプログラムや検証用データを格納するための記憶装置である。ストレージ装置３は、磁気ディスク等の不揮発性記憶デバイスで構成される記憶領域であるボリューム３１と、サーバ１からのＩ／Ｏ要求の処理を行うコントローラ３０（ＣＴＬ３０と略記されることもある）を有する。ボリューム３１とＣＴＬ３０の数は複数でもよい。また、ボリューム３１は、いわゆるディスクアレイ（またはＲＡＩＤ）のように、複数の磁気ディスクから構成される記憶領域であってもよい。またボリューム３１を構成する記憶デバイスには、磁気ディスク以外の任意の不揮発性記憶デバイスが用いられて良い。たとえばフラッシュメモリを用いた記憶デバイス（ＳＳＤ）が用いられてもよい。
　続いてサーバ１で実行されるプログラムのうち、本実施例に係る論理検証処理に関係するプログラムについて説明する。本実施例に係る論理検証処理では、ＶＨＤＬ等の、論理回路用の記述言語（ハードウェア記述言語）で記述された論理回路記述（回路データ）と後述するテストパターンをシミュレータに与えることで、論理回路の設計者が設計した論理回路の動作のシミュレーションを行う。そしてシミュレータで実行される論理回路の動作が妥当であるか（設計者や検証者が期待した動作を行っているか）を検証することで、回路データ（つまり設計された論理回路）の検証を行う。
　以下、本実施例に係る論理検証処理で検証対象とされる論理回路（検証対象回路）の回路データのことを「検証対象回路データ」と呼ぶ。なお検証対象回路データは、設計者によってテキストエディタなどを用いて作成されることもあれば、公知の論理回路設計用プログラム（論理設計ツール）を用いて作成されることもある。また検証対象回路データは、設計者がサーバ１上で論理設計ツール等を実行することで作成したものでもよいが、サーバ１以外の計算機で作成されたものであってもよい。
　本実施例に係る論理検証処理では、いわゆるアサーションベース検証が行われる。つまり、アサーションが組み込まれた検証対象回路データを用いて、検証対象回路のシミュレーションが行われる。図１のメモリ１２内に記載の各プログラムのうち、シミュレータ１２５（または「論理検証ツール１２５」とも呼ばれる）が、検証対象回路のシミュレーションを行うためのプログラムである。本実施例に係る論理検証方法では、シミュレータ１２５は、ハードウェア記述言語によって記述された回路データの動作のシミュレーションを行うことができるプログラムであれば、任意のプログラムでよい。たとえば公知の論理検証ツールを採用可能である。
　なお、図１では、各プログラムがメモリ１２上に存在する構成例が示されているが、実際には各プログラムは、実行されていない状態のときはストレージ装置３のボリューム３１等の不揮発性記憶媒体に格納されている。そして各プログラムはＣＰＵ１１によって実行される時に、ボリューム３１からメモリ１２上に読み出される。
　アサーションベース検証では、シミュレータ１２５はアサーションが組み込まれた検証対象回路データを用いて、検証対象回路の動作のシミュレーションを行う。アサーションが組み込まれていると、シミュレーション中に検証対象回路で期待されていない状態が発生した場合、シミュレーションを実行している計算機（サーバ１）のディスプレイにエラー情報が表示される、あるいはログファイルに異常が発生したことを示す情報が出力される。
　アサーション生成プログラム１２１は、検証対象回路に組み込むべきアサーションを生成するためのプログラムである。テスト実行プログラム１２２は、アサーションの組み込まれた検証対象回路データのテストを行う。テストの際、テスト実行プログラム１２２はシミュレータ１２５を呼び出して、シミュレータ１２５に検証対象回路のシミュレーションを行わせる。
　判定プログラム１２３は、テスト実行プログラム１２２の実行後、検証対象回路データの妥当性のチェックを行うためのプログラムである。判定プログラム１２３は、期待値生成プログラム１２３１と結果判定プログラム１２３２を含む。期待値生成プログラム１２３１と結果判定プログラム１２３２は、判定プログラム１２３から呼び出されることで実行される。
　図１に示された計算機システムの構成は一例であり、これ以外の構成であっても本実施例に係る検証処理は実施可能である。たとえばサーバ１にヒューマンインタフェースデバイス（ＨＩＤ）を設けてもよい。この場合検証を行うユーザは、端末２の代わりにサーバ１のＨＩＤを用いて検証処理の実行の指示や結果の参照を行うようにしてもよい。
　またサーバ１とストレージ装置３を、ＬＡＮ４と異なるＳＡＮ５で接続するのではなく、ストレージ装置３をＬＡＮ４に接続した構成でも良い。この場合、サーバ１とストレージ装置３は、ｉＳＣＳＩプロトコル、あるいはＮＦＳやＣＩＦＳ等のファイルアクセスプロトコルを用いて通信する。
　あるいは、ストレージ装置３を設ける代わりに、サーバ１内にＨＤＤ等の記憶デバイスを設ける構成にしてもよい。または、ストレージ装置３に加えてサーバ１内にもＨＤＤ等の不揮発性記憶デバイスを設け、サーバ１が使用するプログラムやデータのうち、いくつかのプログラムまたはデータがサーバ１内に設けられたＨＤＤ等の不揮発性記憶デバイスに格納されるようにしてもよい。
　また、サーバ１が複数あってもよい。たとえばサーバ１を複数設け、アサーション生成プログラム１２１が第１のサーバ１で実行され、アサーションの組み込まれた検証対象回路データのシミュレーションは第２のサーバ１で行われる（第２のサーバ１でシミュレータ１２５が実行される）ようにしてもよい。その他さまざまな構成をとりえる。
　続いて、本実施例に係る論理検証処理で検証対象となる回路（検証対象回路）の一部の例、及び検証処理で用いられる各種情報について説明する。
　本実施例で検証対象となる論理回路の機能ブロックは、出力信号の一つとして、エラーが発生した場合に、エラーが発生したことを外部に通知するための信号（エラー信号と呼ぶ）を出力し、エラー信号の値を保持するためのレジスタ（エラーレジスタと呼ぶ）を有する。そして大規模な論理回路では、各機能ブロックのエラー信号を集約し、集約された信号をエラー信号用のレジスタに入力するよう構成される。図２は、検証対象回路の一部を記述した回路図である。図２の例では、各機能ブロックのエラー信号を中心に記述しており、各機能ブロックの具体的な回路図については記載を略している。
　図２において、ＦＢ０、ＦＢ１、ＦＢ＿ＥＲＲはそれぞれ機能ブロックである。ＦＢ０内のボックス（Ｂ００－０、．．．Ｂ００－３０、Ｂ００－３１、Ｂ０１－０、．．．Ｂ０１－３０、Ｂ０１－３１）、そしてＦＢ１内のボックス（Ｂ１０－０、．．．Ｂ１０－３０、Ｂ１０－３１）は、機能ブロックＦＢ０、ＦＢ１内のサブ機能ブロックを表す。各サブ機能ブロック（Ｂ００－３１等）から出る線（ｓ＿ＥＲＲ０＿３１等）がエラー出力用の信号線（エラー信号線）を表している。図２では、たとえば機能ブロックＦＢ０の信号線としては、ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１、ｓ＿ＥＲＲ１＿０～ｓ＿ＥＲＲ１＿３１が存在している。
　図２の回路図例では、各サブ機能ブロックからそれぞれ１つ（１ビット）のエラー信号が出力される。機能ブロックＦＢ０内の各サブ機能ブロックから出力されたエラー信号は、信号線ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１を介して、レジスタｒ００に入力される（つまりエラー信号が出力されると、レジスタｒ００に値が格納される）。また信号線ｓ＿ＥＲＲ１＿０～ｓ＿ＥＲＲ１＿３１が接続されているサブ機能ブロック（Ｂ０１－０～Ｂ０１－３１）から出力されるエラー信号は、レジスタｒ０１に入力される。また機能ブロックＦＢ１内の信号線ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１が接続されているサブ機能ブロック（Ｂ１０－０～Ｂ１０－３１）は、レジスタｒ１０に入力される。なお図２において、レジスタｒ００は３２ビットレジスタであり、ｓ＿ＥＲＲ０＿ｎ（ｎは０から３１までの整数値を表す）にエラー信号が出力された時、出力された値（信号）はレジスタｒ００のｎビット目に格納される。レジスタｒ０１、ｒ１０についても同様の関係にある。
　そして各エラー信号は機能ブロック内のレジスタに入力されるとともに、集約されて機能ブロックＦＢ＿ＥＲＲのレジスタｒ２０とｒ２１へも入力される。具体的には、たとえば機能ブロックＦＢ０内の信号線ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１に出力されるエラー信号については、機能ブロックＦＢ０内でこれらのエラー信号の論理和（ＯＲ）が算出され、算出結果はレジスタｒ２０とｒ２１の特定ビットへ入力される。また機能ブロックＦＢ１内の信号線ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１についても同様に、ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１に出力されるエラー信号の論理和が、レジスタｒ２０とｒ２１の特定ビットへ入力される。つまり、サブ機能ブロックでエラーが発生した場合（いずれかのエラー信号が出力された場合）、その結果が集約されて、機能ブロックＦＢ１のレジスタｒ２０、ｒ２１へと格納される。
　また、図２の回路図例では、実際の検証対象回路データの一部のみを図示したもので、実際の検証対象回路には３つよりも多くの機能ブロックが含まれることがある。また図２では、機能ブロックＦＢ０、ＦＢ１のエラー信号が機能ブロックＦＢ＿ＥＲＲ内のレジスタｒ２０、ｒ２１へ集約される例のみが示されているが、入力されたエラー信号をさらに集約または加工した信号をＦＢ＿ＥＲＲ内で生成し、その信号が別の機能ブロックのレジスタへと入力されるような回路構成もあり得る。
　続いて検証処理で用いられる各種情報について、再び図１を用いて説明する。本実施例に係る計算機システムはボリューム３１に、回路データ３００、アサーション記述３１０、レジスタ仕様テーブル３２０、テストパターン３３０、テストパラメータ３４０、発火期待アサーションリスト３５０、アサーション結果ログ３６０、テスト結果ログ３７０、アサーション結果リスト３８０を格納する。これらの情報はそれぞれ、ボリューム３１内の１ファイルあるいは複数のファイルとして格納される。
　回路データ３００は、ハードウェア記述言語を用いて設計者が作成した検証対象回路の回路データである。なお、回路データ３００を用いた検証（シミュレーション）が行われる時、実際には回路データ３００に入力信号を加えるための回路記述や、出力信号の観測を行うための回路記述が必要で、これらの回路記述は「テストベンチ」と呼ばれる。本実施例では説明の簡単化のため、回路データ３００内にテストベンチが含まれているものとして説明を行う。しかし別の実施形態として、テストベンチは回路データ３００と別の情報としてボリューム３１に格納されていてもよい。
　テストパターン３３０は、シミュレータ１２５で検証対象回路の動作を検証する時に用いられる、検証対象回路への入力情報（データパターン）である。テストパターン３３０は、検証対象回路の設計者（または検証者）によって、事前に（検証処理前に）作成される。検証では、検証対象回路に対して多くの種類のデータパターンを与え、データパターンごとに検証対象回路の動作の妥当性のチェックが行われる。そのため、複数のデータパターンが作成される。本実施例では、１つのデータパターンが１つのファイルに格納される前提で説明する。そして特に断りのない限り、各データパターンが格納されたファイルのそれぞれを「テストパターン３３０」と呼ぶ。各テストパターン３３０には一意な識別子（具体的にはファイル名）が付される。この識別子（ファイル名）を「テスト名」と呼ぶ。ただし別の実施形態として、複数のデータパターンが１ファイルに格納され、ファイル内に格納された複数のデータパターンのそれぞれに、何らかの識別子（テスト名称）が付されるように構成されていてもよい。
　テストパラメータ３４０は、各テストパターン３３０に関する情報を含む。図３を用いてテストパラメータ３４０の内容の例を説明する。テストパラメータ３４０は、テストパターンごとに、テストパターンのテスト名３４１、テスト属性３４２、機能ブロック名３４３、信号名３４４の情報を含んだ管理情報である。
　テスト名３４１は上で述べたとおり、テストパターンの識別子（たとえばファイル名）である。テスト属性３４２には、テスト名３４１で特定されるテストパターンが、正常系テスト（検証対象回路でエラーが発生しないことが期待されるテスト）のテストパターンか、あるいは障害系テスト（検証対象回路でエラーが発生することが期待されるテスト）のテストパターンかを示す情報が含まれる。
　テスト属性３４２に「正常系」が格納されている場合、テストパターンが正常系テストのテストパターンであることを意味する。逆にテスト属性３４２に「障害系」が格納されている場合、テストパターンが障害系テストのテストパターンであることを意味する。障害系テストのテストパターンは、検証対象回路内のいずれか１つのモジュールに対し、実際には発生し得ないパターンの信号が入力され、そのモジュールでエラー信号が出力されることが期待されるテストパターンである。
　機能ブロック名３４３と信号名３４４は、テスト属性３４２が「障害系」の場合のみ有効な情報である。本実施例に係る検証処理で検証の対象とされる論理回路は、障害（エラー）が発生した時（障害系テストが実行された場合）、検証対象回路内の各モジュールがエラー出力用の信号（少なくとも１ビット以上の信号）と、この信号の内容を保持するためのエラー出力用レジスタを有していることが前提の回路である。あるモジュールでエラーが発生した時には、そのモジュールのエラー出力用の信号ビットがＯＮ（１）になり、そしてその情報はエラー出力用レジスタにも格納される。
　なお、エラー出力用レジスタは、ＶＨＤＬ等のハードウェア記述言語ではレジスタ変数として定義される。本実施例では、このエラー出力用レジスタとして定義されるレジスタ変数を、障害レジスタ変数と呼ぶ。また、本実施例に係る検証処理で検証対象とされる論理回路を設計者がハードウェア記述言語で記述する時、この障害レジスタ変数の変数名に、文字列“ＥＲＲ”が含めることとしている（そして障害レジスタ変数以外のレジスタ変数では、文字列“ＥＲＲ”が用いられない）。ただし障害レジスタ変数の名称に文字列が“ＥＲＲ”でなければならないわけではない。回路データ内で、障害レジスタ変数の名称に用いられるべき文字列が一意に定まっていればよい。
　機能ブロック名３４３には、テスト名３４１で特定されるテストパターンが入力された時に、エラー信号が出力されることが期待されるモジュール（機能ブロック）の名称が格納される。機能ブロック名３４３に格納される名称は、正確には機能ブロック（モジュール）がインスタンス化されたインスタンス名である。ただし説明が冗長になることを防ぐため、以下では単に機能ブロック名として説明する。信号名３４４にはその時にＯＮになることが期待されるエラー信号の名称である。テストパラメータ３４０は、テストパターン３３０と同時に検証対象回路の設計者（または検証者）によって作成される。
　レジスタ仕様テーブル３２０は、エラー出力用レジスタの仕様及びエラー信号の伝搬先を表す情報である。またレジスタ仕様テーブル３２０はテストパラメータ３４０等と同様、検証対象回路の設計者（または検証者）によって事前に（検証前に）作成される情報である。図４を用いてレジスタ仕様テーブル３２０の内容の例を説明する。レジスタ仕様テーブル３２０はモジュール（機能ブロック）内のエラー信号状態を保持するレジスタごとに１つ作成される。レジスタ仕様テーブル３２０には、機能ブロック名３２１、レジスタ名３２２、（レジスタの）ｂｉｔ（３２０－０）、信号名３２０－１、接続先ブロック名３２０－２、接続先レジスタ名３２０－３が含まれる。
　機能ブロック名３２１、レジスタ名３２２にはそれぞれ、エラー信号の出力元の機能ブロック（モジュール）の名称、エラー出力用レジスタの名称（障害レジスタ変数の名称）が格納される。信号名３２０－１は、機能ブロック名３２１で特定される機能ブロックから出力されるエラー信号を他の機能ブロックに伝搬するために用いられる信号線（エラー信号線）の名称である。信号名３２０－１で特定される信号線に出力される値は、レジスタ名３２２で特定されるエラー出力用レジスタにも格納される。図４を参照すると、信号名３２０－１の前にｂｉｔ（３２０－０）が存在するが、ｂｉｔ（３２０－０）は、エラー出力用レジスタ（レジスタ名３２２で特定されるレジスタ）の中のビットのうち、特定のビットを表す情報である。なお、レジスタ名３２２、ｂｉｔ（３２０－０）、信号名３２０－１は以下の関係にある。たとえば図４において、ｂｉｔ（３２０－０）が“３０”の行の信号名３２０－１は、“ｓ＿ＥＲＲ０＿３０”である。この場合レジスタＳＴＳ＿ＲＥＧ＿ＥＲＲ＿０の３０ビット目には、信号線ｓ＿ＥＲＲ０＿３０の値が格納されることを表している。
　そして接続先ブロック名３２０－２と接続先レジスタ名３２０－３はそれぞれ、エラー信号の伝搬先となるモジュールの名称、レジスタの名称が格納される。また、接続先レジスタ名３２０－３に格納される情報のうち、括弧内の数値は、エラー信号の格納先となるレジスタのビット位置を表す。またエラー信号の格納先となるレジスタは複数存在することもあり、その場合接続先レジスタ名３２０－３には複数のレジスタ名が格納される。
　図４は、図２の回路図におけるモジュールＦＢ０内のエラー信号ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１の伝搬先の情報を格納したレジスタ仕様テーブル３２０の内容を表している。図２の回路図では、エラー信号ｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１の論理和（ＯＲ）が、モジュールＦＢ＿ＥＲＲ内のレジスタＳＴＳ＿ＲＥＧ＿０及びＳＴＳ＿ＲＥＧ＿１へと接続されている。そのため図４のレジスタ仕様テーブル３２０では、信号名（３２０－１）がｓ＿ＥＲＲ０＿０～ｓ＿ＥＲＲ０＿３１の接続先ブロック名３２０－２には“ＦＢ＿ＥＲＲ”が格納され、接続先レジスタ名３２０－３には“ＳＴＳ＿ＲＥＧ＿０”及び“ＳＴＳ＿ＲＥＧ＿１”が格納されている。
　なお、本実施例で説明される回路記述の例では、レジスタ変数名などの、各モジュール内で定義されるシンボルは、モジュール内で一意な名称であればよい。そのため、異なるモジュール内で同一の名称のレジスタ変数が定義されることがある。
　また図５には、図２の回路図におけるモジュールＦＢ＿ＥＲＲ内のレジスタＳＴＳ＿ＲＥＧ＿０についてのレジスタ仕様テーブル３２０が示されている。図２の回路図では、モジュールＦＢ＿ＥＲＲから別のモジュールへはエラー信号が出力されていない。そのため、図５のレジスタ仕様テーブル３２０では、接続先ブロック名３２０－２及び接続先レジスタ名３２０－３には無効値（ｎｕｌｌ）が格納される。言い換えれば接続先ブロック名３２０－２及び接続先レジスタ名３２０－３に “ｎｕｌｌ”が格納されている場合、エラー信号がそれ以上別のモジュールに伝搬していないことを意味する。
　このように、レジスタ仕様テーブル３２０には、モジュール間のエラー信号の接続先が記録され、接続先ブロック名３２０－２、接続先レジスタ名３２０－３を辿っていくことで、エラー信号の伝搬されるブロックやレジスタ（または集約先のブロックやレジスタ）を特定することができる。即ち、レジスタ仕様テーブル３２０はツリー構造である。
　アサーション記述３１０、発火期待アサーションリスト３５０、アサーション結果ログ３６０、テスト結果ログ３７０、アサーション結果リスト３８０については、検証処理の流れを説明する過程において説明する。
　続いて、各プログラムが行う処理の流れを説明する。まず、本実施例に係る計算機システムで行われる検証処理の流れの概略を述べる。
　本実施例に係る検証処理では、アサーションベース検証が行われる。そのため、シミュレータ１２５を用いた検証の前に、アサーション記述の作成と、シミュレータ１２５を用いた検証を行った際に作成したアサーションが適切に機能するように準備を行う必要がある。
　また本実施例に係る検証処理では、障害系テスト実施時の各モジュールのエラー信号出力の妥当性を容易に判断できるようにすることを目的の一つとしている。そのため、本実施例で作成されるアサーションはモジュール毎に作成される。各アサーションは、モジュールのエラー信号がＯＮ（１）になったことを契機に、エラーメッセージをアサーション結果ログ３６０に出力する。シミュレータ１２５を用いた検証中に、たとえば図２のモジュールＢ００－３１のエラー信号ｓ＿ＥＲＲ０＿３１がＯＮになった場合、モジュールＢ００－３１用に作成されたアサーションは、エラーメッセージを出力する。本実施例では、アサーションがエラーメッセージを出力する状態になった場合、「アサーションが発火した」状態と表現する。
　シミュレータ１２５を用いた検証の前には、アサーション記述を作成することに加え、作成されたアサーション記述が、検証時に適切に機能する（つまり、エラー信号がＯＮになった時にアサーションが発火する）ように設定しておく必要がある。この処理のことを「アサーションを組み込む」と呼ぶ。作成されたアサーションを組み込む際に、ＶＨＤＬ等で記述されている検証対象回路データ内に直接アサーション記述が埋め込まれるようにしてもよいし、或いはアサーション記述が検証対象回路データとは別のファイルに格納されるようにしてもよい。本実施例では、作成されたアサーション記述は検証対象回路データとは別のファイルに格納される場合の例について中心に、説明が行われる。
　アサーションの組み込みの後、テスト実行プログラム１２２を用いたテストが行われる。ここではあらかじめ作成されたテストパターン３３０が入力情報として用いられる。そのため、検証対象回路の検証者は少なくとも、テスト実行プログラム１２２を用いたテストが行われる前までに、テストパターン３３０を作成し、ボリューム３１に格納しておく必要がある。テストパターン３３０の具体的内容は、本実施例に係る検証処理とは直接関係しないもののため、本実施例では説明を略す。
　テスト実行プログラム１２２によるテストでは、テストパターン３３０に記述された入力情報を検証対象回路に入力した時の、検証対象回路の動作のシミュレーションが行われる。テスト実行プログラム１２２はシミュレータ１２５を呼び出すことで、シミュレータ１２５に検証対象回路の動作のシミュレーションを行わせる。シミュレーションの結果、エラー信号がＯＮになると、アサーションが発火し、エラーメッセージがアサーション結果ログ３６０に出力される。
　テストの後、判定プログラム１２３が実行されることで、テストの結果の妥当性の判定が行われる。ここでテストパラメータ３４０とレジスタ仕様テーブル３２０が用いられるので、検証者は少なくともこの時点までには、テストパラメータ３４０とレジスタ仕様テーブル３２０を作成し、ボリュームに格納しておく必要がある。もちろんテストの前にテストパラメータ３４０とレジスタ仕様テーブル３２０が作成されていてもよい。
　テストパターン３３０のうち、テスト属性３４２が「障害系」のテストパターン３３０を用いたテストを実行した結果、そのテストパターン３３０に対応した信号名３４４の信号がＯＮになれば、検証対象の論理回路が期待通りに設計されていることを意味する。判定プログラム１２３はアサーション結果ログ３６０の内容とテストパラメータ３４０の内容とを照合することで、信号名３４４の信号がＯＮになっているかを判定する。
　また、回路設計によっては、エラー信号が他のモジュールに伝搬し、他のモジュールのレジスタ（伝搬先レジスタと呼ぶ）にエラー信号が格納されていることもある。その場合、伝搬先レジスタもＯＮになることが、検証対象回路に期待される動作である。そのため判定プログラム１２３はレジスタ仕様テーブル３２０を参照することで、伝搬先レジスタがあるか否かを判定する。そして伝搬先レジスタがある場合には、判定プログラム１２３は伝搬先レジスタの値（もしくは伝搬先レジスタに接続されているエラー信号）がＯＮになっているかも判定する。
　逆にテストパターン３３０を用いたテストを実行した結果、回路の設計に不具合がある場合、ＯＮになることが期待されていない信号がＯＮになることもある。判定プログラム１２３はＯＮになることが期待されていない信号がＯＮになっていないかについても判定を行う。
　検証対象回路の規模が大きいほど、エラー信号の数も多い。そのため、アサーション結果ログ３６０には大量のメッセージが出力されることがある。判定プログラム１２３は大量のメッセージの中から、検証対象回路の設計者（検証者）の期待した出力とは異なる出力のみを抽出し、テスト結果ログ３７０やアサーション結果リスト３８０に抽出された結果を出力する。これにより、テスト結果の確認効率を向上させることができる。
　以下、図６から図１５を用いて、各プログラムで実行される処理の流れ、及び各プログラムが出力する情報について説明する。図６はアサーション生成プログラム１２１の処理フローである。検証者が端末のＨＩＤ２５を用いて、サーバ１に対してアサーション生成プログラム１２１の起動を指示すると、サーバ１でアサーション生成プログラム１２１が開始される。
　最初にアサーション生成プログラム１２１は、ボリューム３１から検証対象回路データを読み込み（ステップａ－１）、検証対象回路データ内からモジュールを１つ選択する（ステップａ－２）。続いてアサーション生成プログラム１２１は、読み込んだ検証対象回路データに、障害レジスタ変数が定義されているか判定する（ステップａ－４）。先にも述べたが、本実施例に係る検証方法では、障害レジスタ変数名には文字列“ＥＲＲ”が含まれていることが前提である。そのためステップａ－４では、文字列“ＥＲＲ”を含む変数の検索が行われる。障害レジスタ変数が定義されていない場合（ａ－４：Ｎ）、処理はステップａ－８に進む。
　障害レジスタ変数が定義されている場合（ａ－４：Ｙ）、アサーション生成プログラム１２１は、障害レジスタ変数が、読み込んだ検証対象回路データ内で使用されているか判定する（ステップａ－５）。この判定はたとえば、障害レジスタ変数が１に設定される記述が検証対象回路データに存在するかを判定することで行われる。
　読み込んだ検証対象回路データ内で障害レジスタ変数が使用されていない場合（ａ－５：Ｎ）、ステップａ－６、ａ－７は実行されず、次にステップａ－８が行われる。障害レジスタ変数が使用されている場合（ａ－５：Ｙ）、アサーション生成プログラム１２１はアサーションの生成を行う（ステップａ－６）。本実施例に係るアサーション生成プログラム１２１は、障害レジスタ変数ごとにアサーションを作成する。また障害レジスタ変数が複数ビット（たとえば３２ビット）の変数である場合、障害レジスタ変数のビットごとにアサーションが生成される。つまり障害レジスタ変数が３２ビットの変数の場合、３２個のアサーションが生成される。ステップａー６では、アサーション生成プログラム１２１は、障害レジスタ変数のビットが０から１に変化したことを契機にメッセージを出力するアサーションを、障害レジスタ変数のビットごとに生成する。
　本実施例に係るアサーション生成プログラム１２１は、アサーション名を生成するアルゴリズムを有しており、そのアルゴリズムに従ってアサーションの名称を生成する。また本実施例では、アサーション名を生成するアルゴリズムは、アサーション生成対象の機能ブロックの名称と障害レジスタ変数及び障害レジスタ変数のビット位置の名称を用いて、アサーション名称を出力（生成）するものとする。また、後述する期待値生成プログラム１２３１も、アサーション生成プログラム１２１が使用するアサーション名称の生成アルゴリズムと同じアルゴリズムを有している。そのため機能ブロックの名称と、障害レジスタ変数の名称及び障害レジスタ変数のビット位置が与えられれば、アサーション生成プログラム１２１が生成するアサーション名と同じアサーション名を生成することができる。
　アサーション生成の後、アサーション生成プログラム１２１は生成したアサーション記述３１０をボリューム３１に格納する（ステップａ－７）。本実施例では、生成されたアサーションは、検証対象回路データ（回路データ３００）とは異なるデータ（アサーション記述３１０）として、ボリューム３１に格納される。ただし別の実施形態として、検証対象回路データと異なるデータとしてアサーションを格納する代わりに、回路データに直接アサーション記述が埋め込まれてもよい。つまりステップａ－７で、検証対象回路データ内の、機能ブロックを定義しているモジュールの記述の中に、アサーション記述が挿入される処理が行われてもよい。
　ステップａ－８でアサーション生成プログラム１２１は、ステップａ－１からステップａ－７までの処理を全てのモジュールに対して実施したか判定する。全てのモジュールに対してステップａ－７までの処理が行われたことが確認されたら（ステップａ－８：Ｙ）、アサーション生成プログラム１２１は処理を終了する。処理が行われていないモジュールが残っている場合（ステップａ－８：Ｎ）、アサーション生成プログラム１２１はステップａ－２から処理を繰り返す。
　続いて、図７を用いて、テスト実行プログラム１２２の処理の流れを説明する。検証者が端末のＨＩＤ２５を用いて、サーバ１に対してテスト開始の指示を行うと、テスト実行プログラム１２２が開始される。テスト実行プログラム１２２はシミュレータ１２５を呼び出すことで、検証対象回路データのテスト（シミュレーション）を開始する（ステップｓ１－１）。ステップｓ１－１で行われる処理の内容については後述する。
　シミュレータ１２５によるシミュレーションが完了すると、シミュレータ１２５からステータスがテスト実行プログラム１２２に返却される（ステップｓ１－２）。ステータスが「ｏｋ」であった場合（ステップｓ１－３：Ｙ）、シミュレーションが正常に終了したことを意味する。そのためこの場合、テスト実行プログラム１２２はテスト結果ログ３７０に、テストが正常に完了した旨を書き込む（ステップｓ１－４）。
　ステータスが「ＮＧ」であった場合（ステップｓ１－３：Ｎ）、テスト実行プログラム１２２はテスト結果ログ３７０に、テストが異常終了した旨を書き込み（ステップｓ１－５）、テスト実行プログラム１２２は処理を終了する。
　図８にテスト結果ログ３７０に記録されるテスト結果の一例を示す。テスト結果には、テスト名５０１、シミュレーション終了ステータス５０２、期待値生成ステータス５０３、アサーション判定結果５０４、エラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７の情報が含まれる。シミュレーション終了ステータス５０２の値が「ｏｋ」の場合、テスト名５０１で特定されるテストパターンが、シミュレータ１２５によって正常に実行されたことを意味する。一方シミュレーション終了ステータス５０２の値が「ＮＧ」の場合、テスト名５０１で特定されるテストパターンの実行中、シミュレータ１２５での処理が異常終了したことを表す。異常終了する要因としては、たとえば検証対象回路データに不具合があった場合がある。なおここでは、期待値生成ステータス５０３、アサーション判定結果５０４、エラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７の記録は行われない（“ｎｕｌｌ”が記録される）。これらの情報の出力契機や情報の内容については、後述する。また、図８では、テスト結果ログ３７０のデータ構造がテーブルである例が示されているが、出力データの構造（フォーマット）は任意でよい。たとえばテスト結果ログ３７０に、テスト名５０１、シミュレーション終了ステータス５０２、期待値生成ステータス５０３、アサーション判定結果５０４、エラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７の値をそれぞれカンマで区切った形式（いわゆるＣＳＶ形式）で出力されるようにしてもよい。
　ｓ１－４の後、テスト実行プログラム１２２は判定プログラム１２３を呼び出し、判定処理を行う（ｓ２）。判定処理の終了後、テスト実行プログラム１２２は終了する。ｓ２の処理の詳細は後述する。
　ステップｓ１－１で行われる処理を概説する。ステップｓ１－１でシミュレータ１２５が実行されることにより、検証対象回路データのシミュレーションが開始される。厳密には検証対象回路データのテストを行うために、検証対象回路のテスト環境（テストベンチ）も用意される必要があるが、ここではテストベンチはすでに用意されている場合の例を説明する。
　この時検証者は、端末のＨＩＤ２５を用いて、サーバ１に対してテスト開始の指示を行うが、検証対象回路に入力されるテストパターン３３０の一つを指定する。具体的にはテスト名（テスト名３４１に登録されている、いずれか１つのテスト名）が指定される。
　検証対象回路のシミュレーションが実行されると、アサーションが発火することがある。先に述べたとおり、アサーションが発火すると、アサーションが発火したことを表すメッセージがアサーション結果ログ３６０に出力される。
　アサーション結果ログ３６０の例を図９に示す。アサーションが発火すると、“ASSERTION　FAILED”のメッセージと共に、アサーションの発火時刻（３６０－０）とアサーション名（３６０－１）がアサーション結果ログ３６０に出力される。
　次に、ステップｓ２で行われる、判定プログラム１２３の処理の流れを、図１０を用いて説明する。判定プログラム１２３は最初に、テストパラメータ３４０の行（以下では「レコード」と呼ぶ）のうち、テスト名３４１がステップｓ１－１で検証者が指定したテスト名と一致しているレコードを選択し、そのレコードのテスト属性３４２を取得する（ステップｓ２－１）。ステップｓ２－２では、判定プログラム１２３は、ステップｓ２－１で取得したテスト属性３４２が、「正常系」、「障害系」のいずれかを判定する。
　テスト属性３４２が「正常系」の場合（ステップｓ２－２：正常系）、判定プログラム１２３は結果判定プログラム１２３２を実行し（ステップｓ４）、処理を終了する。結果判定プログラム１２３２の処理内容については後述する。
　テスト属性３４２が「障害系」の場合（ステップｓ２－２：障害系）、判定プログラム１２３は期待値生成プログラム１２３１を実行する（ステップｓ３）。期待値生成プログラム１２３１の処理内容については後述する。期待値生成プログラム１２３１は終了時に、ステータス等の情報をテスト結果ログ３７０に出力するが、テスト結果ログ３７０に出力する情報の詳細についても後述する。
　判定プログラム１２３はテスト結果ログ３７０から、期待値生成プログラム１２３１の出力したステータスを読み込み（ステップｓ２－３）、期待値生成プログラム１２３１が正常終了したか判定する（ステップｓ２－４）。期待値生成プログラム１２３１が正常終了した場合（ステップｓ２－４：Ｙ）、判定プログラム１２３は、結果判定プログラム１２３２を実行し（ステップｓ４）、処理を終了する。期待値生成プログラム１２３１が正常終了しなかった場合（ステップｓ２－４：Ｎ）、判定プログラム１２３は、結果判定プログラム１２３２を実行せずに処理を終了する。
　続いてｓ３の処理、つまり期待値生成プログラム１２３１の処理の流れを、図１１、図１２を用いて説明する。期待値生成プログラム１２３１は、テストパラメータ３４０、レジスタ仕様テーブル３２０、検証対象回路データを解析することで、検証対象回路データが正しく設計されていれば発火するはずのアサーション記述の名称を特定する。また特定されたアサーション記述の名称は、発火期待アサーションリスト３５０に格納される。
　ステップｓ３－１で期待値生成プログラム１２３１は、ｓ２－１で選択されたテストパラメータ３４０のレコードのなかから、機能ブロック名３４３、信号名３４４を取得する。ここで取得された機能ブロック名３４３、信号名３４４で特定される信号線を、「障害検出対象信号」と呼ぶ。障害検出対象信号は、ｓ２－１で選択されたテストパラメータ３４０のレコードで特定されるテストが実行された時にＯＮになることが期待されるものである。
　続いてステップｓ３－２で期待値生成プログラム１２３１は、検証対象回路データを読み込み、ステップｓ３－３では検証対象回路データの中から、障害検出対象信号が接続されている（サブ）モジュール及びその（サブ）モジュールの中で定義されている障害レジスタ変数を特定する。なお、ステップｓ３－３では具体的には、障害検出対象信号が接続されているモジュールのインスタンス名が特定される。また、ここで特定された機能ブロック（モジュール）に組み込まれているアサーションは、ステップｓ２－１で選択されたテストパラメータ３４０によるテストが実施される時に、発火が期待されるアサーションである。図２の例では、エラー信号ｓ＿ＥＲＲ０＿３１は、ＦＢ０内のサブモジュールＢ００－３１に接続されている。そのためステップｓ３－１で障害検出対象信号としてｓ＿ＥＲＲ０＿３１が特定された場合、ステップｓ３－３では、サブモジュールＢ００－３１が、そしてサブモジュールＢ００－３１で定義されている障害レジスタ変数が特定される。
　ステップｓ３－５で期待値生成プログラム１２３１は、ステップｓ３－３で特定された（サブ）機能ブロックと障害レジスタ変数の情報を用いてアサーション名を生成する。ここで生成するアサーション名は、アサーションが発火した時にアサーション結果ログに記録される名称である。
　続いてステップｓ３－６で期待値生成プログラム１２３１は、ボリューム３１内に格納されている複数のレジスタ仕様テーブル３２０を読み出し、その中から信号名３２０－１に障害検出対象信号が登録されているレジスタ仕様テーブル３２０を特定する。そして期待値生成プログラム１２３１は、そのレジスタ仕様テーブル３２０に登録されているレジスタ名３２２を特定する。ステップｓ３－６の処理の結果、信号名３２０－１に障害検出対象信号の登録されているレジスタ仕様テーブル３２０が存在しなかった場合（ステップｓ３－７：Ｎ）、期待値生成プログラム１２３１は、テスト結果ログ３７０の期待値生成ステータス５０３に、期待値生成プログラム１２３１が異常終了した旨のステータス（文字列“ｅｘｐ＿ＮＧ”）の書き込み（ステップｓ３－１７）を実施し、処理を終了する。
　障害検出対象信号を含むレジスタの登録されているレジスタ仕様テーブル３２０が存在する場合（ステップｓ３－７：Ｙ）は、期待値生成プログラム１２３１は、そのレジスタ仕様テーブル３２０のレジスタ名３２２と障害検出対象信号に対応するｂｉｔ（３２０－０）を用いて、発火が期待されるアサーション名を生成する（ステップｓ３－９）。たとえば障害検出対象信号としてｓ＿ＥＲＲ０＿３１が特定されている場合、かつレジスタ仕様テーブル３２０の内容が図４に記載されたものである場合、期待値生成プログラム１２３１はステップｓ３－９で、レジスタ名３２２として“ＳＴＳ＿ＲＥＧ＿ＥＲＲ＿０”を特定し、信号名３２０－１に“ｓ＿ＥＲＲ０＿３１”が登録されている行のｂｉｔ（３２０－０）、つまり“３１”を特定する。そしてこれらの情報（“ＳＴＳ＿ＲＥＧ＿ＥＲＲ＿０”と“３１”）を含むアサーション名を生成する。
　ステップｓ３－１０では、期待値生成プログラム１２３１はステップｓ３－６で特定したレジスタ仕様テーブル３２０から、接続先レジスタ名３２０－３と障害検出対象信号に対応するｂｉｔ（３２０－０）を抽出する。なお、レジスタ仕様テーブル３２０に接続先ブロック名３２０－２、接続先レジスタ名３２０－３が格納されていないこともあり、その場合にはステップｓ３－１１とステップｓ３－１２は行われない。
　ステップｓ３－１１とステップｓ３－１２で、期待値生成プログラム１２３１は、ステップｓ３－６（あるいは後述するステップｓ３－１４）で特定されたレジスタ仕様テーブル３２０の妥当性のチェックを行う。ステップｓ３－１１では期待値生成プログラム１２３１は、ステップｓ３－１０で抽出された接続先レジスタ名３２０－３が、他のレジスタ仕様テーブル３２０に存在するかチェックする。
　ステップｓ３－１０で抽出された接続先レジスタ名３２０－３が他のレジスタ仕様テーブル３２０に存在しない場合（ステップｓ３－１１：Ｎ）、レジスタ仕様テーブル３２０の内容に誤りがあることを意味する。その場合には、期待値生成プログラム１２３１はステップｓ３－１７を実施し、処理を終了する。
　ステップｓ３－１０で抽出された接続先レジスタ名３２０－３が他のレジスタ仕様テーブル３２０に存在する場合（ステップｓ３－１１：Ｙ）、期待値生成プログラム１２３１は、ステップｓ３－１０で抽出された接続先レジスタ名３２０－３が、以前にチェックしたレジスタ仕様テーブル３２０内に存在していないかチェックする（ステップｓ３－１２）。
　ステップｓ３－１０で抽出された接続先レジスタ名３２０－３が、以前にチェックしたレジスタ仕様テーブル３２０内に存在する場合（ステップｓ３－１２：Ｙ）、接続先レジスタがループしていることを意味する。この場合には、期待値生成プログラム１２３１はステップｓ３－１７を実施し、処理を終了する。ステップｓ３－１０で抽出された接続先レジスタ名３２０－３が、以前にチェックしたレジスタ仕様テーブル３２０内に存在しない場合（ステップｓ３－１２：Ｎ）は、ステップｓ３－１３が行われる。
　ここで図２～図５を参照しながら、ステップｓ３－１１、ｓ３－１２のチェック処理について概説する。期待値生成プログラム１２３１はテストパラメータ３４０を参照することで、エラーが発生する（ＯＮになる）信号線（信号名３４４）を特定し、さらにレジスタ仕様テーブル３２０（たとえば図４）を参照することで、この信号線が接続されている機能ブロック、レジスタ（接続先ブロック名（３２０－２）、接続先レジスタ名（３２０－３））を特定する（これはステップｓ３－６～ｓ３－１０の処理である）。さらに期待値生成プログラム１２３１は、ステップｓ３－９～ｓ３－１４の処理を繰り返すことで、特定された機能ブロック（レジスタ）の接続先となる機能ブロック（レジスタ）のレジスタ仕様テーブル３２０（たとえば図５）を特定する処理を繰り返す。この処理を行うことで、期待値生成プログラム１２３１は、たとえば図２の機能ブロックＢ００－３１で発生したエラー（ｓ＿ＥＲＲ０＿３１に出力される信号）の伝搬先を辿ることができ、エラー伝搬先のレジスタをすべて特定することができる。
　図５では、接続先ブロック名（３２０－２）、接続先レジスタ名（３２０－３））の値は“ｎｕｌｌ”であり、機能ブロックＦＢ＿ＥＲＲよりも先にエラー信号が伝搬しないことを意味する状態になっている。ただし、レジスタ仕様テーブル３２０は、論理回路の設計仕様などをもとに、人手で（検証者によって）作成される。そのため、作成者（検証者）のミスにより、レジスタ仕様テーブル３２０の内容に誤りが含まれていることがある。
　誤りの一つとして、たとえば図５の接続先ブロック名（３２０－２）、接続先レジスタ名（３２０－３））に、図５のレジスタ仕様テーブル３２０のチェックを行うよりも前にチェックが行われたレジスタ仕様テーブル３２０（たとえば図４）の機能ブロック名やレジスタ名（機能ブロックＦＢ０、機能ブロックＦＢ０内で定義されている障害レジスタ変数（たとえばＳＴＳ＿ＲＥＧ＿ＥＲＲ＿０））が格納されている場合を想定する。レジスタ仕様テーブル３２０がそのような状態になっている場合、機能ブロックＦＢ０から機能ブロックＦＢ＿ＥＲＲに伝搬してきたエラー信号がＦＢ０に戻るような、エラーが無限ループする回路構成になっていることを意味するが、これは実際にはあり得ない回路設計である。ステップｓ３－１２ではこのような誤りが検出される。
　また、図５の接続先ブロック名（３２０－２）、接続先レジスタ名（３２０－３））に、他のレジスタ仕様テーブル３２０に存在していない値（機能ブロック名、レジスタ名）が格納されている場合、それもあり得ない回路設計である。ステップｓ３－１１ではこのような誤りが検出される。なお、図１２の例では、レジスタ仕様テーブル３２０の内容のチェックとして、２つのチェック（ステップｓ３－１１、ｓ３－１２）が行われる例を説明したが、これ以外のチェックが行われてもよい。
　ステップｓ３－１３以降の説明に戻る。ステップｓ３－１２迄でチェック対象としたレジスタ仕様テーブル３２０に、接続先ブロック名３２０－２、接続先レジスタ名３２０－３が格納されている場合（ステップｓ３－１３：Ｙ）には、期待値生成プログラム１２３１はこの接続先ブロック名３２０－２、接続先レジスタ名３２０－３が登録されているレジスタ仕様テーブル３２０を特定する（ステップｓ３－１４）。そして期待値生成プログラム１２３１は、この特定されたレジスタ仕様テーブル３２０について、ステップｓ３－９～ｓ３－１２の処理を実施する。ステップｓ３－１２迄でチェック対象としたレジスタ仕様テーブル３２０に接続先ブロック名３２０－２、接続先レジスタ名３２０－３が格納されていない場合（ステップｓ３－１３：Ｎ）には、期待値生成プログラム１２３１はステップｓ３－１５以降の処理を実施する。
　ステップｓ３－１５では期待値生成プログラム１２３１は、ステップｓ３－５、ｓ３－９で生成されたアサーション名を、発火期待アサーションリスト３５０に格納し（ステップｓ３－１５）、テスト結果ログ３７０の期待値生成ステータス５０３に、期待値生成プログラム１２３１が正常終了した旨のステータス（文字列“ｅｘｐ＿ｏｋ”）の書き込みを行い（ステップｓ３－１６）、処理を終了する。
　発火期待アサーションリスト３５０の例を図１３に示す。ステップｓ３－１５で発火期待アサーションリスト３５０には、ステップｓ３－５、ｓ３－９で生成されたアサーション名が発火期待アサーション名６０２に格納される。またｓ２－１で選択されたテストパラメータ３４０のレコードに格納されているテスト名２０１が、テスト名６０１に格納される。
　続いてｓ４の処理、つまり結果判定プログラム１２３２の処理の流れを、図１４、図１５を用いて説明する。最初に結果判定プログラム１２３２は、期待値生成プログラム１２３１によって生成された発火期待アサーションリスト３５０の読み込み（ステップｓ４－１）と、アサーション結果ログ３６０の読み込み（ステップｓ４－２）を行う。
　続いて結果判定プログラム１２３２は、読み込んだアサーション結果ログ３６０内に、発火期待アサーションリスト３５０に格納されているアサーション名（発火が期待されるアサーション名）が存在するか判定する（ステップｓ４－４）。発火が期待されるアサーションがアサーション結果ログ３６０内に存在しない場合（ステップｓ４－４：Ｎ）には、結果判定プログラム１２３２は障害アサーションエラー情報を生成する（ステップｓ４－５）。なお障害アサーションエラー情報とは、テスト結果ログ３７０に格納すべき情報のセットのことである。ステップｓ４－５（またはステップｓ４－７）で結果判定プログラム１２３２は、エラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７に相当する情報を、障害アサーションエラー情報として生成する。エラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７の詳細は、後述する。
　次に結果判定プログラム１２３２は、読み込んだアサーション結果ログ３６０内に、発火期待アサーションリスト３５０に格納されていないアサーション名が存在するか判定する（ステップｓ４－６）。発火期待アサーションリスト３５０に格納されていないアサーション名がアサーション結果ログ３６０内に存在する場合（ステップｓ４－６：Ｙ）、本来発火することが期待されていないアサーションが発火していることを意味する。この場合にも、結果判定プログラム１２３２は障害アサーションエラー情報を生成する（ステップｓ４－７）。
　ステップｓ４－７までの処理の結果、障害アサーションエラー情報が生成された場合（ステップｓ４－８：Ｙ）、結果判定プログラム１２３２はテスト結果ログ３７０のアサーション判定結果５０４に“ＦＡＩＬ”を格納し（ステップｓ４－１０）、テスト結果ログ３７０のエラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７に、ステップｓ４－５またはｓ４－７で生成された障害アサーションエラー情報を格納する（ステップｓ４－１１）。
　ステップｓ４－７までの処理の結果、障害アサーションエラー情報が生成されなかった場合（ステップｓ４－８：Ｎ）、結果判定プログラム１２３２はテスト結果ログ３７０のアサーション判定結果５０４に“ＰＡＳＳ”を格納する（ステップｓ４－９）。最後に結果判定プログラム１２３２は、アサーション結果リスト３８０に、ステップｓ４－８～ｓ４－１１でテスト結果ログ３７０に格納された内容を追記し（ステップｓ４－１２）、処理を終了する。
　結果判定プログラム１２３２の処理実行後の、テスト結果ログ３７０の内容の一例を、図１６に示す。図１６の（ａ）では、テスト名が“TEST_FB0_ERR0_31”のテストパターンが実行された場合のテスト結果ログ３７０の例が示されている。
　発火することが期待されていたアサーションが発火しなかった場合、発火しなかったアサーションの名称がエラーアサーション名５０５に格納され、ｅｘｐｅｃｔｅｄ５０６には“ｄｏｎｅ”が、ａｃｔｕａｌ５０７には“ｕｎｄｏｎｅ”が格納される。
　逆に発火が期待されていないアサーションが発火した場合、発火したアサーションの名称がエラーアサーション名５０５に格納され、ｅｘｐｅｃｔｅｄ５０６には“ｕｎｄｏｎｅ”が、ａｃｔｕａｌ５０７には“ｄｏｎｅ”が格納される。１個のテストパターン３３０を用いたテストを実施した結果、発火することが期待されていたアサーションが発火しない事象、または発火が期待されていないアサーションが発火した事象は、複数発生することがある。その場合、発火することが期待されていたのに発火しなかったすべてのアサーション名、または発火が期待されていないが発火した全てのアサーション名が、テスト結果ログ３７０に格納される。
　もしアサーション判定結果５０４が“ＰＡＳＳ”の場合（つまりステップｓ４－５またはｓ４－７が実行されなかった場合）、アサーション判定結果５０４には“ＰＡＳＳ”が記録され、エラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７には“ｎｕｌｌ”が記録される（図１６（ｂ））。
　アサーション結果リスト３８０は、複数のテスト結果が蓄積されるファイルである。先に述べたとおり、アサーション結果リスト３８０にはテスト結果ログ３７０に格納された内容と同じものが格納されるため、アサーション結果リスト３８０にはテスト結果ログ３７０と同じく、テスト名５０１、シミュレーション終了ステータス５０２、期待値生成ステータス５０３、アサーション判定結果５０４、エラーアサーション名５０５、ｅｘｐｅｃｔｅｄ５０６、ａｃｔｕａｌ５０７の情報が格納される。ただし、ｎ個のテストパターンに対してテスト実行プログラム１２２を実行した場合、アサーション結果リスト３８０には、ｎ回個分の実行結果が蓄積される。
　以上が本発明の一実施形態に係る、論理回路の検証方法の説明である。論理回路の規模が大規模なものになると、必要なテストパターンの数も増加し、またテストパターンを用いた検証を実行した結果、発火するアサーションの数も膨大になり、その妥当性を人手で判定することはコスト（時間）のかかる処理となる。
　本実施例に係る検証方法を実行するサーバは、検証対象回路用のテストパラメータとレジスタ仕様テーブルの内容をもとに、発火が期待されるアサーションのリストを作成する。そして本実施例に係る検証方法を実行するサーバは、検証対象回路のシミュレーションを実行することで生成されるアサーション結果ログの内容と、発火が期待されるアサーションのリストの内容を照合する。そしてこの照合の結果、発火が期待されるアサーションのうち、実際に発火しなかったアサーションの一覧、そして発火することが期待されていないにもかかわらず発火したアサーションの一覧を作成し、エラーとして出力する。また同時にサーバは、発火が期待されるアサーションのリストを作成する過程で、レジスタ仕様テーブルの内容のチェックも実施する。これにより、検証者が確認すべき情報が大幅に絞り込まれるため、検証のコストを削減することができる。
　以上、本発明の実施例を説明したが、これは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。
　たとえば上では、テスト実行プログラム１２２を１回実行すると、１つのテストパターンを用いた検証が１回実行される例が説明された。しかし別の実施形態として、テスト実行プログラム１２２を１回実行すると、複数のテストパターンを用いて検証が行われてもよい。たとえばボリューム３１にテストパターン３３０がｎ個格納されている時、テスト実行プログラム１２２をｎ回実行し、ｎ個のテストパターンを用いた検証が行われるようにしてもよい。
　また上では、アサーション判定結果をボリューム３１のファイルに出力する例が説明されているが、別の実施形態として、結果をファイルに出力することに加えて、端末２のディスプレイ等に出力するようにしてもよい。
　また上では、アサーション生成プログラム１２１を実行することで、回路データにアサーションを組み込み、その後テスト実行プログラム１２２を実行して、この回路データのシミュレーション及びテスト結果の妥当性判定が行われる例を説明した。しかしアサーション生成プログラム１２１は、検証において必須ではない。たとえば別の実施形態として、アサーションを組み込み済みの回路データがある場合、アサーション生成プログラム１２１を実行せずに、テスト実行プログラム１２２を実行しても、上で説明した検証が可能である。ただしこの場合、回路データに組み込まれるアサーションのアサーション名が、期待値生成プログラム１２３１の有するアサーション名生成アルゴリズムと同じルールで生成されたものである必要がある。
１：サーバ、２：端末、３：ストレージ装置、４：ＬＡＮ、５：ＳＡＮ

Claims (12)

  1. 　エラー発生時にエラー信号を出力するとともに、前記出力されるエラー信号の値を格納するレジスタを備えた機能ブロックを複数有する論理回路の検証を、ハードウェア記述言語で記述した論理回路記述を用いて行う論理回路の検証方法であって、前記方法は少なくとも、
    　前記論理回路への入力情報であるテストパターンの名称と、前記テストパターンが入力されることによりエラーが発生することが期待される前記機能ブロックの前記エラー信号の名称とを有するテストパラメータを読み込む工程と、
    　前記機能ブロックから出力される前記エラー信号の名称と、前記エラー信号の値を格納する前記機能ブロック内のレジスタであるエラーレジスタの名称と、前記エラー信号の伝搬先のレジスタ及び前記レジスタを有する機能ブロックの名称とを有する、１以上のレジスタ仕様と、前記テストパラメータとに基づいて、前記論理回路記述に組み込まれたアサーションのうち、前記テストパターンを用いた前記論理回路のテストを実行した時に発火することが期待されるアサーションの一覧を生成する工程と、
    を計算機が実行する、
    論理回路の検証方法。
  2. 　前記計算機がさらに、
    　前記テストパターンと前記論理回路記述を用いて前記論理回路のシミュレーションを実行する工程と、
    　前記シミュレーションの結果、出力されたアサーション結果ログの内容と、前記アサーションの一覧とを比較することで、前記論理回路の妥当性を判定する工程と、
    を実行する、請求項１に記載の論理回路の検証方法。
  3. 　前記計算機がさらに、
    　前記シミュレーションの実行前に、前記論理回路記述にアサーションを組み込む工程を実行する、請求項２に記載の論理回路の検証方法。
  4. 　前記計算機が前記論理回路の妥当性を判定する工程で、
    　前記アサーション結果ログに出力されているが、前記アサーションの一覧には存在しない前記アサーションがある場合、または
    　前記アサーション結果ログに出力されていないが、前記アサーションの一覧には存在している前記アサーションがある場合、
    　前記論理回路が妥当でないと判定する、
    請求項２に記載の論理回路の検証方法。
  5. 　前記計算機が前記アサーションの一覧を生成する工程で、前記レジスタ仕様の妥当性を判定する工程を含む、
    請求項１に記載の論理回路の検証方法。
  6. 　前記レジスタ仕様は、前記エラーレジスタごとに設けられており、
    　前記レジスタ仕様の妥当性を判定する工程は、
    　前記テストパラメータに含まれる前記エラー信号の名称が含まれる前記レジスタ仕様が存在するか判定し、
    　前記エラー信号が含まれる前記レジスタ仕様が存在する場合、前記レジスタ仕様に含まれる前記エラー信号の伝搬先のレジスタについてのレジスタ仕様を順次探索し、前記エラー信号の伝搬先のレジスタの名称が、探索済の前記レジスタ仕様に格納されている場合、前記レジスタ仕様の内容に誤りがあると判定する工程である、
    請求項５に記載の論理回路の検証方法。
  7. 　エラー発生時にエラー信号を出力するとともに、前記出力されたエラー信号の格納用のレジスタを備えた機能ブロックを複数有する論理回路の検証を、ハードウェア記述言語で記述した論理回路記述を用いて行うコンピュータに実行させるプログラムが記録された、コンピュータ読み取り可能な記憶媒体であって、前記プログラムは少なくとも、
    　前記論理回路への入力情報であるテストパターンの名称と、前記テストパターンが入力されることによりエラーが発生することが期待される前記機能ブロックの前記エラー信号の名称とを有するテストパラメータを読み込む工程と、
    　前記機能ブロックから出力される前記エラー信号の名称と、前記エラー信号の出力値を格納する前記機能ブロック内のレジスタであるエラーレジスタの名称と、前記エラー信号の伝搬先のレジスタ及び前記レジスタを有する機能ブロックの名称とを有する、１以上のレジスタ仕様と、前記テストパラメータとに基づいて、前記論理回路記述に組み込まれたアサーションのうち、前記テストパターンを用いた前記論理回路のテストを実行した時に発火することが期待されるアサーションの一覧を生成する工程と、
    をコンピュータに実行させる、
    コンピュータ読み取り可能な記憶媒体。
  8. 　前記プログラムはさらに、前記コンピュータに、
    　前記テストパターンと前記論理回路記述を用いて前記論理回路のシミュレーションを実行する工程と、
    　前記シミュレーションの結果、出力されたアサーション結果ログの内容と、前記アサーションの一覧とを比較することで、前記論理回路の妥当性を判定する工程と、
    を実行させる、
    請求項７に記載のコンピュータ読み取り可能な記憶媒体。
  9. 　前記プログラムはさらに、前記コンピュータに、
    　前記シミュレーションの実行前に、前記論理回路記述にアサーションを組み込む工程を実行させる、請求項８に記載のコンピュータ読み取り可能な記憶媒体。
  10. 　前記論理回路の妥当性を判定する工程で、前記プログラムは前記コンピュータに、
    　前記アサーション結果ログに出力されているが、前記アサーションの一覧には存在しない前記アサーションがある場合、または
    　前記アサーション結果ログに出力されていないが、前記アサーションの一覧には存在している前記アサーションがある場合、
    　前記論理回路が妥当でないと判定する処理を実行させる、
    請求項８に記載のコンピュータ読み取り可能な記憶媒体。
  11. 　前記アサーションの一覧を生成する工程は、前記レジスタ仕様の妥当性を判定する工程を含む、
    請求項７に記載のコンピュータ読み取り可能な記憶媒体。
  12. 　前記レジスタ仕様は、前記エラーレジスタごとに設けられており、
    　前記レジスタ仕様の妥当性を判定する工程は、
    　前記テストパラメータに含まれる前記エラー信号の名称が含まれる前記レジスタ仕様が存在するか判定し、
    　前記エラー信号が含まれる前記レジスタ仕様が存在する場合、前記レジスタ仕様に含まれる前記エラー信号の伝搬先のレジスタについてのレジスタ仕様を順次探索し、前記エラー信号の伝搬先のレジスタの名称が、探索済の前記レジスタ仕様に格納されている場合、前記レジスタ仕様の内容に誤りがあると判定する工程を含む、
    請求項１１に記載のコンピュータ読み取り可能な記憶媒体。
PCT/JP2015/070945 2015-07-23 2015-07-23 論理回路の検証方法 WO2017013783A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/070945 WO2017013783A1 (ja) 2015-07-23 2015-07-23 論理回路の検証方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/070945 WO2017013783A1 (ja) 2015-07-23 2015-07-23 論理回路の検証方法

Publications (1)

Publication Number Publication Date
WO2017013783A1 true WO2017013783A1 (ja) 2017-01-26

Family

ID=57834268

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/070945 WO2017013783A1 (ja) 2015-07-23 2015-07-23 論理回路の検証方法

Country Status (1)

Country Link
WO (1) WO2017013783A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112380798A (zh) * 2020-11-16 2021-02-19 海光信息技术股份有限公司 参数检查方法、装置、设备和存储介质
CN118228670A (zh) * 2024-05-24 2024-06-21 上海泰矽微电子有限公司 一种基于断言的数模混合soc的验证方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0512369A (ja) * 1991-07-05 1993-01-22 Hokuriku Nippon Denki Software Kk テストパタン作成方式
JPH10312311A (ja) * 1997-05-13 1998-11-24 Mitsubishi Electric Corp 論理シミュレーション方法及び論理シミュレーション方法を実現させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2008107872A (ja) * 2006-10-23 2008-05-08 Oki Electric Ind Co Ltd 半導体集積回路

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0512369A (ja) * 1991-07-05 1993-01-22 Hokuriku Nippon Denki Software Kk テストパタン作成方式
JPH10312311A (ja) * 1997-05-13 1998-11-24 Mitsubishi Electric Corp 論理シミュレーション方法及び論理シミュレーション方法を実現させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2008107872A (ja) * 2006-10-23 2008-05-08 Oki Electric Ind Co Ltd 半導体集積回路

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112380798A (zh) * 2020-11-16 2021-02-19 海光信息技术股份有限公司 参数检查方法、装置、设备和存储介质
CN112380798B (zh) * 2020-11-16 2022-11-11 海光信息技术股份有限公司 参数检查方法、装置、设备和存储介质
CN118228670A (zh) * 2024-05-24 2024-06-21 上海泰矽微电子有限公司 一种基于断言的数模混合soc的验证方法

Similar Documents

Publication Publication Date Title
US7404160B2 (en) Method and system for hardware based reporting of assertion information for emulation and hardware acceleration
US9990458B2 (en) Generic design rule checking (DRC) test case extraction
US8892386B2 (en) Method and apparatus for post-silicon testing
TW201405306A (zh) 測試用例創建系統及方法
US8875064B2 (en) Automated design rule checking (DRC) test case generation
CN112417798B (zh) 一种时序测试方法、装置、电子设备及存储介质
US5878050A (en) Method and apparatus for data compare detection of memory errors on a computers memory subsystem
Potyra et al. Evaluating fault-tolerant system designs using FAUmachine
Choudhary et al. Software testing
US10592623B2 (en) Assertion statement check and debug
Gharehbaghi et al. Transaction-based post-silicon debug of many-core system-on-chips
US11514219B1 (en) System and method for assertion-based formal verification using cached metadata
WO2017013783A1 (ja) 論理回路の検証方法
US20210326243A1 (en) Dynamic reordering of test case execution
JP2006309576A (ja) 論理システムの検証装置及び検証方法、記憶媒体及びコンピュータプログラム
CN115176233B (zh) 以确定性顺序执行测试
CN115757099A (zh) 平台固件保护恢复功能自动测试方法和装置
US8639978B2 (en) Topology independent network-based automation infrastructure
CN116048887A (zh) 一种芯片验证方法及装置、系统、电子设备、存储介质
Vankeirsbilck et al. Software-implemented fault injection for physical and simulated embedded cpus
US20050120278A1 (en) Systems and methods for verifying lockstep operation
CN117313650B (zh) 一种芯片测试验证方法及其应用装置
US7210111B1 (en) Systems and methods for conducting future signal checks
Gupta et al. Embracing the FPGA challenge for processor design verification
CN117034824B (zh) 复用测试用例和验证环境的仿真验证系统、方法、终端及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15898942

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15898942

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP