JP2006011927A - Function verification device, test bench, simulator program, and storage medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a function verification device capable of verifying with ease and high accuracy interrupts to a model designed using a hardware description language, a test bench, a simulator program, and a storage medium. <P>SOLUTION: To conduct a confirmation test on interrupts to the model 50 designed using a hardware description language, an abnormal response generation flag 103 showing a request for an abnormal response from a test scenario 102 to a bus model 104 is sent while an interrupt anticipation flag 106 is asserted. When a CPU bus model 105 connected to the model 50 by a bus receives an interrupt signal from the model 50, an interrupt is recognized to be as expected if the interrupt anticipation flag 106 is asserted, and a verifier is informed that the expected interrupt signal has been received. In this way, any interrupts to the model 50 can be verified with ease and high accuracy. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a function verification device, a test bench, a simulator program, and a storage medium that perform function verification on a model designed in a hardware description language based on a simulation result using a test bench.

  In recent years, the design method of ASIC (Application Specified IC) has shifted from the design based on a circuit diagram to the digital circuit design based on HDL (hardware description language) with a high degree of abstraction as the circuit scale increases. The circuit diagram designed by the HDL is extremely enormous and the operation becomes extremely complicated. For this reason, a circuit designed by HDL needs to perform a function verification work by using an HDL simulator that performs simulation or the like together with other modules described in HDL.

  More specifically, the HDL simulator is used in all aspects of the process, and confirms that there is no fundamental difference in simulation results at each level. Such an HDL simulator adds a new HDL description called a test bench for testing the HDL model (ASIC) to be verified. The test bench includes a test stimulus (test vector), which is given to an HDL model (ASIC) to be tested, and a procedure for automatically executing a simulation is described in HDL. That is, one model having the test bench module as the highest level as shown in FIG. 6 is completed. This is compiled and linked to create an execution module on the computer, and the function is verified by observing the waveform while controlling the execution on the simulator control panel.

  For example, Patent Document 1 proposes a test program for verifying the function of a semiconductor integrated circuit device by computer simulation using a test bench.

JP 2002-83010 A

  However, the test program of Patent Document 1 is for checking whether the operation of the entire semiconductor integrated circuit device is normal by a test bench, and determining whether or not it is normal, but does not verify interrupts to the circuit. .

  It is an object of the present invention to provide a function verification device, a test bench, a simulator program, and a storage medium that can easily and accurately verify an interrupt for a model designed in a hardware description language.

  The function verification apparatus according to claim 1 is a function verification apparatus that performs function verification on a model designed in a hardware description language based on a simulation result using a test bench, wherein the test bench includes the model A bus model for responding to or accessing the I / F system bus, register settings for the model and operation function settings for the bus model, and issuing instructions for causing the model to perform various test operations A test scenario, a CPU bus model that is a virtual CPU bus-connected to the model, a means for asserting a flag indicating interrupt expectation, and a bus model from the test scenario after asserting the flag indicating interrupt expectation Means for sending an abnormal response occurrence flag indicating a request for an abnormal response to Means for receiving the interrupt signal from the CPU bus model, means for checking whether or not a flag indicating an interrupt expectation is asserted when the interrupt signal from the model is received by the CPU bus model, Means for notifying that an intended interrupt signal has been received when a flag indicating expectation is asserted.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Is sent. When the CPU bus model connected to the model receives an interrupt signal from the model, if the interrupt expectation flag is asserted, the interrupt is recognized as expected, and the interrupt signal is received as intended. This is notified to the verifier.

  The invention according to claim 2 is the function verification device according to claim 1, wherein the test bench receives an interrupt signal from the model by the CPU bus model, and a flag indicating an interrupt expectation is asserted. Negates a flag indicating interrupt expectation.

  Therefore, it is possible to reliably end the interrupt confirmation test for the model designed by the hardware description language.

  According to a third aspect of the present invention, in the functional verification device according to the first or second aspect, the test bench receives an interrupt signal from the model by the CPU bus model, and a flag indicating an interrupt expectation is not asserted. In this case, it is notified that an unintended interrupt signal has been received.

  Therefore, when an interrupt signal from a model is received by a CPU bus model connected to the model bus, it is not an interrupt confirmation test unless the interrupt expectation flag is asserted. To be notified.

  According to a fourth aspect of the present invention, in the functional verification device according to any one of the first to third aspects, the test bench receives an interrupt signal from the model by the CPU bus model, and a flag indicating an interrupt expectation is provided. If not, stop the simulation.

  Therefore, when an interrupt signal from a model is received by a CPU bus model connected to the model, it is not an interrupt confirmation test unless the interrupt expectation flag is asserted. Stopped.

  According to a fifth aspect of the present invention, in the functional verification device according to any one of the first to fourth aspects, the test bench receives an interrupt signal from the model within a predetermined time after asserting a flag indicating an interrupt expectation. Is not received by the CPU bus model, it is notified that the intended interrupt is not issued within a predetermined time.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Will be sent, but if the interrupt signal from the model is not received by the CPU bus model within the predetermined time after asserting the flag indicating interrupt expectation, the intended interrupt signal will not be issued within the predetermined time This is notified to the verifier.

  According to a sixth aspect of the present invention, in the functional verification device according to any one of the first to fifth aspects, the test bench receives an interrupt signal from the model within a predetermined time after asserting a flag indicating an interrupt expectation. Is not received by the CPU bus model, the simulation is stopped.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Will be sent, but if the interrupt signal from the model is not received by the CPU bus model within the predetermined time after asserting the flag indicating interrupt expectation, the intended interrupt signal will not be issued within the predetermined time Therefore, the simulation is stopped.

  According to a seventh aspect of the present invention, in the function verification device according to the fifth or sixth aspect, the predetermined time after the flag indicating the interrupt expectation can be set at any time.

  Therefore, it is possible to improve the reusability and maintainability of verification regarding interrupts.

  The test bench according to claim 8 is a test bench for performing various simulations on a model designed in a hardware description language, and a bus model for responding to or accessing an I / F bus of the model, A test scenario for setting a register in a model and setting an operation function for the bus model and instructing the model to execute various test operations, and a CPU that is a virtual CPU connected to the model by a bus A bus model, means for asserting a flag indicating interrupt expectation, and means for transmitting an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model after asserting the flag indicating interrupt expectation Means for receiving an interrupt signal from the model by the CPU bus model; When an interrupt signal from the model is received by the CPU bus model, a means for confirming whether a flag indicating an interrupt expectation is asserted, and an interrupt signal as intended when the flag indicating an interrupt expectation is asserted And means for notifying that it has been received.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Is sent. When the CPU bus model connected to the model receives an interrupt signal from the model, if the interrupt expectation flag is asserted, the interrupt is recognized as expected, and the interrupt signal is received as intended. This is notified to the verifier.

  According to a ninth aspect of the present invention, in the test bench according to the eighth aspect, when the interrupt signal from the model is received by the CPU bus model and the flag indicating the interrupt expectation is asserted, the flag indicating the interrupt expectation is set. Negate.

  Therefore, it is possible to reliably end the interrupt confirmation test for the model designed by the hardware description language.

  According to a tenth aspect of the present invention, in the test bench according to the eighth or ninth aspect, when an interrupt signal from the model is received by the CPU bus model and a flag indicating an interrupt expectation is not asserted, an unintended interrupt signal Is received.

  Therefore, when an interrupt signal from a model is received by a CPU bus model connected to the model bus, it is not an interrupt confirmation test unless the interrupt expectation flag is asserted. To be notified.

  The invention according to claim 11 is the test bench according to any one of claims 8 to 10, wherein an interrupt signal from the model is received by the CPU bus model, and a flag indicating an interrupt expectation is not asserted. Stop the simulation.

  Therefore, when an interrupt signal from a model is received by a CPU bus model connected to the model, it is not an interrupt confirmation test unless the interrupt expectation flag is asserted. Stopped.

  According to a twelfth aspect of the present invention, in the test bench according to any one of the eighth to eleventh aspects, an interrupt signal from the model is transmitted to the CPU bus model within a predetermined time after asserting a flag indicating an interrupt expectation. If not received, a notification is made that the intended interrupt is not issued within a predetermined time.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Will be sent, but if the interrupt signal from the model is not received by the CPU bus model within the predetermined time after asserting the flag indicating interrupt expectation, the intended interrupt signal will not be issued within the predetermined time This is notified to the verifier.

  According to a thirteenth aspect of the present invention, in the test bench according to any one of the eighth to twelfth aspects, an interrupt signal from the model is transmitted to the CPU bus model within a predetermined time after asserting a flag indicating an interrupt expectation. If not received, the simulation is stopped.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Will be sent, but if the interrupt signal from the model is not received by the CPU bus model within the predetermined time after asserting the flag indicating interrupt expectation, the intended interrupt signal will not be issued within the predetermined time Therefore, the simulation is stopped.

  According to a fourteenth aspect of the present invention, in the test bench according to the twelfth or thirteenth aspect, the predetermined time after the flag indicating the interrupt expectation can be set at any time.

  Therefore, it is possible to improve the reusability and maintainability of verification regarding interrupts.

  A simulator program according to claim 15 is a computer-readable simulator program for causing a computer to execute various simulations for a model designed in a hardware description language, and responds to or accesses an I / F bus of the model. A function for generating a bus model for generating a test scenario, a function for generating a test scenario for setting a register in the model and an operation function for the bus model, and issuing instructions for causing the model to perform various test operations A function for generating a CPU bus model that is a virtual CPU bus-connected to the model, a function for asserting a flag indicating interrupt expectation, and a flag indicating interrupt expectation. Abnormal response required for bus model A function of transmitting an abnormal response occurrence flag indicating the function, a function of receiving an interrupt signal from the model by the CPU bus model, and a flag indicating an interrupt expectation when the interrupt signal from the model is received by the CPU bus model The computer is caused to execute a function for confirming whether or not is asserted and a function for notifying that an intended interrupt signal has been received when a flag indicating an interrupt expectation is asserted.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Is sent. When the CPU bus model connected to the model receives an interrupt signal from the model, if the interrupt expectation flag is asserted, the interrupt is recognized as expected, and the interrupt signal is received as intended. This is notified to the verifier.

  According to a sixteenth aspect of the present invention, in the simulator program according to the fifteenth aspect, when the interrupt signal from the model is received by the CPU bus model and the flag indicating the interrupt expectation is asserted, the flag indicating the interrupt expectation is set. Negate.

  Therefore, it is possible to reliably end the interrupt confirmation test for the model designed by the hardware description language.

  According to a seventeenth aspect of the present invention, in the simulator program according to the fifteenth or sixteenth aspect, when an interrupt signal from the model is received by the CPU bus model and a flag indicating an interrupt expectation is not asserted, an unintended interrupt signal Is received.

  Therefore, when an interrupt signal from a model is received by a CPU bus model connected to the model bus, it is not an interrupt confirmation test unless the interrupt expectation flag is asserted. To be notified.

  The invention according to claim 18 is the simulator program according to any one of claims 15 to 17, wherein an interrupt signal from the model is received by the CPU bus model, and a flag indicating an interrupt expectation is not asserted. Stop the simulation.

  Therefore, when an interrupt signal from a model is received by a CPU bus model connected to the model, it is not an interrupt confirmation test unless the interrupt expectation flag is asserted. Stopped.

  According to a nineteenth aspect of the present invention, in the simulator program according to any one of the fifteenth to eighteenth aspects, an interrupt signal from the model is transmitted to the CPU bus model within a predetermined time after the flag indicating an interrupt expectation is asserted. If not received, a notification is made that the intended interrupt is not issued within a predetermined time.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Will be sent, but if the interrupt signal from the model is not received by the CPU bus model within the predetermined time after asserting the flag indicating interrupt expectation, the intended interrupt signal will not be issued within the predetermined time This is notified to the verifier.

  According to a twentieth aspect of the present invention, in the simulator program according to any one of the fifteenth to nineteenth aspects, an interrupt signal from the model is transmitted to the CPU bus model within a predetermined time after the flag indicating an interrupt expectation is asserted. If not received, the simulation is stopped.

  Therefore, when performing an interrupt confirmation test for a model designed in the hardware description language, an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model with the interrupt expectation flag asserted. Will be sent, but if the interrupt signal from the model is not received by the CPU bus model within the predetermined time after asserting the flag indicating interrupt expectation, the intended interrupt signal will not be issued within the predetermined time Therefore, the simulation is stopped.

  According to a twenty-first aspect of the present invention, in the simulator program according to the nineteenth or twentieth aspect, the predetermined time after the flag indicating the interrupt expectation can be set at any time.

  Therefore, it is possible to improve the reusability and maintainability of verification regarding interrupts.

  A storage medium according to a twenty-second aspect stores a computer-readable simulator program according to any one of the fifteenth to twenty-first aspects.

  Accordingly, the same effect as that of any one of claims 15 to 21 can be attained.

  According to the present invention, it is possible to easily and accurately perform interrupt verification for a model designed by a hardware description language.

  An embodiment of the present invention will be described with reference to FIGS.

  FIG. 1 is a block diagram schematically showing a hardware configuration of a function verification apparatus 1 to which the present invention is applied. As shown in FIG. 1, the function verification apparatus 1 is a personal computer or a workstation, for example, and includes a CPU (Central Processing Unit) 2 that is a main part of the computer and controls each part centrally. The CPU 2 is connected by a bus 5 to a ROM (Read Only Memory) 3 which is a read-only memory storing BIOS and a RAM (Random Access Memory) 4 which stores various data in a rewritable manner.

  Further, the bus 5 has an HDD (Hard Disk Drive) 6 that stores various programs and the like, and a CD-ROM drive 8 that reads a CD (Compact Disc) -ROM 7 as a mechanism for reading computer software that is a distributed program. A communication control apparatus 10 that controls communication between the function verification apparatus 1 and the network 9, an input device 11 such as a keyboard and a mouse for performing various operation instructions at the time of function verification, and a CRT that displays a simulation result at the time of function verification. A display device 12 such as a (Cathode Ray Tube) or an LCD (Liquid Crystal Display) is connected via an I / O (not shown).

  Since the RAM 4 has the property of storing various data in a rewritable manner, it functions as a work area for the CPU 2 and functions as a buffer.

  A CD-ROM 7 shown in FIG. 1 implements the storage medium of the present invention, and stores an OS (Operating System) and various programs. The CPU 2 reads the program stored in the CD-ROM 7 with the CD-ROM drive 8 and installs it in the HDD 6.

  As the storage medium, not only the CD-ROM 7 but also various types of media such as semiconductor memory such as various optical disks such as DVD, various magnetic disks such as various magneto-optical disks and flexible disks, and the like can be used. Alternatively, the program may be downloaded from the network 9 such as the Internet via the communication control device 10 and installed in the HDD 6. In this case, the storage device storing the program in the server on the transmission side is also a storage medium of the present invention. Note that the program may operate on a predetermined OS (Operating System), and in that case, the OS may take over the execution of some of the various processes described later, It may be included as a part of a group of program files constituting the application software or OS.

  The CPU 2 that controls the operation of the entire system executes various processes based on a program loaded on the HDD 6 used as the main storage of the system.

  Next, among the functions that the various programs installed in the HDD 6 of the function verification apparatus 1 cause the CPU 2 to execute, the characteristic functions provided in the function verification apparatus 1 of the present embodiment will be described. Here, an HDL simulator function that the HDL simulator program causes the CPU 2 to execute will be described. The HDL simulator function generally performs simulation on a model designed by HDL (hardware description language).

  FIG. 2 is a functional block diagram schematically showing a related configuration between the test bench 101 of the HDL simulator 100 and the verification target ASIC 50. The HDL simulator 100 exhibits an HDL simulator function for the verification target ASIC 50 which is a model designed by HDL. As shown in FIG. 2, the test bench 101 of the HDL simulator 100 includes a test scenario 102, an abnormal response occurrence flag 103, a bus model 104, a CPU bus model 105, and an interrupt expectation flag 106. Such a test bench 101 is coded using a language such as Verilog, VHDL, C / C ++, E language, Vera, etc. in order to verify the verification target ASIC 50.

  The bus model 104 is for responding to or accessing an I / F bus (not shown) of the verification target ASIC 50.

  The CPU bus model 105 is a software (virtual CPU written in software) obtained by modeling a CPU (not shown) connected to the verification target ASIC 50 and receives an interrupt signal from the verification target ASIC 50. .

  The test scenario 102 is a program for causing the verification target ASIC 50 to perform various operations, and performs register setting to the verification target ASIC 50 and operation function setting to the bus model 104 via the CPU bus model 105. The verification target ASIC 50 incorporates a register (function for controlling various operations of the ASIC), and the verification target ASIC 50 executes a desired operation by accessing or instructing the register from the test scenario 102.

  The test bench 101 according to the present embodiment is characterized in that the bus model 104, the test scenario 102, and the CPU bus model 105 are handled as different files (files or functions that are independent from each other) as files, and the test scenario 102, the bus model 104, The communication between the test scenario 102 and the bus model 104 is performed using the shared flag (abnormal response occurrence flag 103). The abnormal response occurrence flag 103 indicates a request for an abnormal response, and when the verification target ASIC 50 receives this, an error interrupt is generated.

  In addition, communication between the test scenario 102 and the CPU bus model 105 is also performed using the shared flag (interrupt expectation flag 106). The interrupt expectation flag 106 includes a flag indicating an interrupt expectation (Int_Expect) and an interrupt detection period (Int_TimeOut) indicating a time for waiting for an interrupt.

[Interrupt issue confirmation sequence]
Next, an interrupt issue confirmation sequence by the test bench 101 of the HDL simulator 100 will be described with reference to the flowchart of FIG. As shown in FIG. 3, the test bench 101 negates a flag (Int_Expect) indicating interrupt expectation (Int_Expect = 0) at the start of simulation (step S1).

  When the test bench 101 executes a test for confirming that an interrupt is generated, the test bench 101 asserts a flag (Int_Expect = 1) indicating an interrupt expectation (Int_Expect = 1) (step S2), and between the test scenario 102 and the bus model 104 The abnormal response of the bus model 104 is requested with the shared flag (abnormal response occurrence flag 103) (step S3). As a result, the verification target ASIC 50 can be in a state of issuing an interrupt signal.

  The verification target ASIC 50 that has received an abnormal response from the test bench 101 issues an interrupt signal to the CPU bus model 105 of the test bench 101 (step T1).

  When the CPU bus model 105 of the test bench 101 receives an interrupt signal from the verification target ASIC 50, it checks whether or not a flag (Int_Expect) indicating interrupt expectation is asserted (Int_Expect = 1) (step S4).

  If the flag (Int_Expect) indicating interrupt expectation is asserted (Int_Expect = 1), the fact that the interrupt was received as intended is displayed in a log, and the flag (Int_Expect) indicating interrupt expectation is negated (Int_Expect = 0). (Step S5). In this way, after displaying that the interrupt was received as intended, the flag (Int_Expect) indicating the interrupt expectation is negated (Int_Expect = 0), thereby ensuring the interrupt confirmation test for the verification target ASIC 50. It can be terminated.

[Unintentional interrupt issue confirmation sequence]
Next, an unintended interrupt issuance confirmation sequence by the test bench 101 of the HDL simulator 100 will be described with reference to the flowchart of FIG. As shown in FIG. 4, the test bench 101 negates a flag (Int_Expect) indicating interrupt expectation (Int_Expect = 0) at the start of simulation (step S11).

  If there is a circuit bug in the verification target ASIC 50, the verification target ASIC 50 issues an interrupt signal to the CPU bus model 105 of the test bench 101 (step T11).

  When receiving the interrupt signal from the verification target ASIC 50, the CPU bus model 105 of the test bench 101 checks whether the flag (Int_Expect) indicating the interrupt expectation is asserted (Int_Expect = 1) (step S12).

  If the flag (Int_Expect) indicating interrupt expectation is not asserted (Int_Expect = 1), that is, if the flag indicating interrupt expectation (Int_Expect) is negated (Int_Expect = 0), a log display indicating that an unintended interrupt has been received Then, the simulation is stopped (step S13).

[Confirmation sequence that interrupt is not issued]
Next, a sequence for confirming that no interrupt is issued by the test bench 101 of the HDL simulator 100 will be described with reference to the flowchart of FIG. As shown in FIG. 5, the test bench 101 negates a flag (Int_Expect) indicating an interrupt expectation (Int_Expect = 0) at the start of simulation (step S21).

  When the test bench 101 executes a test for confirming that an interrupt is generated, the test bench 101 asserts a flag (Int_Expect = 1) indicating an interrupt expectation (Int_Expect = 1), and at an interrupt detection period (Int_TimeOut) indicating a wait time for an interrupt A predetermined time (Int_TimeOut = 1000) is set (step S22), and an abnormal response of the bus model 104 is requested with a shared flag (abnormal response occurrence flag 103) between the test scenario 102 and the bus model 104 (step S23). . As a result, the verification target ASIC 50 can be in a state of issuing an interrupt signal.

  Here, the verification target ASIC 50 that has received an abnormal response from the test bench 101 issues an interrupt signal to the CPU bus model 105 of the test bench 101. If the verification target ASIC 50 has a circuit bug, An interrupt signal cannot be issued.

  Therefore, the CPU bus model 105 of the test bench 101 subtracts a predetermined time (Int_TimeOut = 1000) every unit time until an interrupt signal is received from the verification target ASIC 50 (step S24).

  When the CPU bus model 105 cannot receive the interrupt signal from the verification target ASIC 50 and the interrupt detection period (Int_TimeOut) becomes “0” (step S25), a log display is displayed that the intended interrupt is not issued within the predetermined time. Then, the simulation is stopped (step S26).

  With the processing operations described above, it becomes possible to recognize interrupts as expected or unexpected, and by notifying the verifier of this by displaying the log or stopping simulation, etc. Verification accuracy can be improved.

  In addition, when the verification target ASIC 50 has a circuit bug and the expected interrupt does not occur, the verification accuracy regarding the interrupt can be easily improved by notifying the verifier by displaying the log or stopping the simulation. Further, the time until the occurrence of an interrupt varies depending on the production of the circuit, and the predetermined time can be set at any time, so that the reusability and maintainability of the verification regarding the interrupt can be improved.

  As described above, according to the present embodiment, when the interrupt confirmation test is performed on the verification target ASIC 50 designed in the hardware description language, the bus model is started from the test scenario 102 with the interrupt expectation flag 106 asserted. An abnormal response occurrence flag 103 indicating an abnormal response request is transmitted to 104. When the CPU bus model 105 connected to the verification target ASIC 50 receives an interrupt signal from the verification target ASIC 50, if the interrupt expectation flag 106 is asserted, it is recognized that the interrupt is as expected. The verifier is notified that the interrupt signal has been received. As a result, the verification of the interrupt to the verification target ASIC 50 can be performed easily and with high accuracy.

It is a block diagram which shows roughly the hardware constitutions of the function verification apparatus of one Embodiment of this invention. It is a functional block diagram which shows roughly the relevant structure of the test bench of HDL simulator, and verification object ASIC. It is a flowchart which shows the sequence of interrupt issue confirmation. It is a flowchart which shows the sequence of unintentional interrupt issue confirmation. It is a flowchart which shows the sequence of confirmation that an interruption is not issued. It is a schematic diagram which shows the structure of an HDL simulator roughly.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Function verification apparatus 7 Storage medium 50 Model designed by the hardware description language 101 Test bench 102 Test scenario 103 Abnormal response generation flag 104 Bus model 105 CPU bus model 106 Flag which shows interruption expectation

Claims (22)

In a functional verification device that performs functional verification on a model designed in a hardware description language based on simulation results using a test bench,
The test bench is
A bus model for responding to or accessing the I / F bus of the model;
A test scenario that performs register setting to the model and operation function setting to the bus model and issues instructions for causing the model to perform various test operations;
A CPU bus model which is a virtual CPU bus-connected to the model;
Means for asserting a flag indicating an interrupt expectation;
Means for transmitting an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model after asserting a flag indicating an interrupt expectation;
Means for receiving an interrupt signal from the model at the CPU bus model;
Means for checking if an interrupt expectation flag is asserted when an interrupt signal from the model is received by the CPU bus model;
When a flag indicating interrupt expectation is asserted, means for notifying that an intended interrupt signal has been received,
A function verification apparatus comprising: The test bench receives an interrupt signal from the model by the CPU bus model and negates a flag indicating an interrupt expectation when a flag indicating an interrupt expectation is asserted.
The function verification apparatus according to claim 1. The test bench receives an interrupt signal from the model by the CPU bus model, and informs that an unintended interrupt signal has been received when a flag indicating interrupt expectation is not asserted.
The function verification apparatus according to claim 1 or 2, wherein The test bench receives an interrupt signal from the model by the CPU bus model, and stops a simulation when a flag indicating an interrupt expectation is not asserted.
The function verification apparatus according to claim 1, wherein the function verification apparatus is a function verification apparatus. If the test bench does not receive the interrupt signal from the model within the predetermined time after asserting the flag indicating the interrupt expectation, the intended interrupt is not issued within the predetermined time. To inform,
The function verification apparatus according to claim 1, wherein the function verification apparatus is a function verification apparatus. The test bench stops simulation if the CPU bus model does not receive an interrupt signal from the model within a predetermined time after asserting a flag indicating interrupt expectation.
The function verification apparatus according to claim 1, wherein the function verification apparatus is a function verification apparatus. The predetermined time after asserting the flag indicating interrupt expectation can be set at any time.
7. The function verification apparatus according to claim 5, wherein In a test bench that performs various simulations for models designed in a hardware description language,
A bus model for responding to or accessing the I / F bus of the model;
A test scenario that performs register setting to the model and operation function setting to the bus model and issues instructions for causing the model to perform various test operations;
A CPU bus model which is a virtual CPU bus-connected to the model;
Means for asserting a flag indicating an interrupt expectation;
Means for transmitting an abnormal response occurrence flag indicating a request for an abnormal response from the test scenario to the bus model after asserting a flag indicating an interrupt expectation;
Means for receiving an interrupt signal from the model at the CPU bus model;
Means for checking if an interrupt expectation flag is asserted when an interrupt signal from the model is received by the CPU bus model;
When a flag indicating interrupt expectation is asserted, means for notifying that an intended interrupt signal has been received,
A test bench characterized by comprising: When the interrupt signal from the model is received by the CPU bus model and the flag indicating the interrupt expectation is asserted, the flag indicating the interrupt expectation is negated.
The test bench according to claim 8, wherein: An interrupt signal from the model is received by the CPU bus model, and when an interrupt expectation flag is not asserted, it is notified that an unintended interrupt signal has been received.
The test bench according to claim 8 or 9, wherein When the interrupt signal from the model is received by the CPU bus model and the flag indicating the interrupt expectation is not asserted, the simulation is stopped.
The test bench according to any one of claims 8 to 10, wherein: If the interrupt signal from the model is not received by the CPU bus model within a predetermined time after asserting a flag indicating an interrupt expectation, a notification is made that the intended interrupt is not issued within the predetermined time.
The test bench according to claim 8, wherein the test bench is provided. If the interrupt signal from the model is not received by the CPU bus model within a predetermined time after asserting the flag indicating the interrupt expectation, the simulation is stopped.
The test bench according to any one of claims 8 to 12, characterized in that: The predetermined time after asserting the flag indicating interrupt expectation can be set at any time.
The test bench according to claim 12 or 13, characterized in that: In a computer-readable simulator program that causes a computer to execute various simulations for a model designed in a hardware description language,
A function of generating a bus model for responding to or accessing the I / F bus of the model;
A function for generating a test scenario for performing an instruction to perform various test operations on the model by setting a register in the model and an operation function setting on the bus model;
A function of generating a CPU bus model, which is a virtual CPU bus-connected to the model;
A function to assert a flag indicating an interrupt expectation,
A function of transmitting an abnormal response occurrence flag indicating an abnormal response request from the test scenario to the bus model after asserting a flag indicating an interrupt expectation;
A function of receiving an interrupt signal from the model by the CPU bus model;
A function for checking whether an interrupt expectation flag is asserted when an interrupt signal from the model is received by the CPU bus model;
When a flag indicating an interrupt expectation is asserted, a function for notifying that an interrupt signal is received as intended,
Is executed by the computer. When the interrupt signal from the model is received by the CPU bus model and the flag indicating the interrupt expectation is asserted, the flag indicating the interrupt expectation is negated.
The simulator program according to claim 15. An interrupt signal from the model is received by the CPU bus model, and when an interrupt expectation flag is not asserted, it is notified that an unintended interrupt signal has been received.
The simulator program according to claim 15 or 16, characterized in that When the interrupt signal from the model is received by the CPU bus model and the flag indicating the interrupt expectation is not asserted, the simulation is stopped.
The simulator program according to any one of claims 15 to 17, characterized in that: If the interrupt signal from the model is not received by the CPU bus model within a predetermined time after asserting a flag indicating an interrupt expectation, a notification is made that the intended interrupt is not issued within the predetermined time.
The simulator program according to any one of claims 15 to 18, characterized in that: If the interrupt signal from the model is not received by the CPU bus model within a predetermined time after asserting the flag indicating the interrupt expectation, the simulation is stopped.
20. A simulator program according to any one of claims 15 to 19, characterized in that: The predetermined time after asserting the flag indicating interrupt expectation can be set at any time.
21. The simulator program according to claim 19 or 20, wherein: A storage medium storing a computer-readable simulator program according to any one of claims 15 to 21.

Images