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

Abstract

PROBLEM TO BE SOLVED: To improve the speed of cooperation verification.SOLUTION: In a cooperation verification device for verifying the operation of an electronic circuit by combining software simulation with hardware emulation, a CPU 30 is incorporated in an FPGA(Field-Programmable Gate Array) 20 for performing hardware emulation, and the CPU 30 is allowed to execute software simulation. Then, the CPU 30 simulates the operation of a part of the electronic circuit, and the FPGA 20 emulates the operation of the other part of the electronic circuit, and signal transmission/reception between a part of the electronic circuit and the other part of the electronic circuit is simulated by signal transmission/reception between the FPGA 20 and the CPU 30.

Description

  The present invention relates to a collaborative verification apparatus and a collaborative verification method for verifying the operation of an electronic circuit by combining software simulation and hardware emulation.

  Conventionally, when designing an integrated circuit, it has been verified by simulation whether or not the function and performance of the integrated circuit are exhibited as expected. This simulation is performed by HDL simulation in which the circuit structure is described in HDL (Hardware Description Language) and the operation of the circuit is simulated on a computer. This HDL simulation has the advantage of good debugability.

  However, when many functions are installed in a circuit such as SOC (System On a Chip), the scale of the circuit increases, and the data and programs necessary for the HDL simulation increase accordingly, and the processing takes a long time. It has become like this. For this reason, it is difficult to perform verification including OS (Operating System) and verification of comprehensive verification items, and it has become difficult to verify all operations of the circuit by HDL simulation.

In order to cope with such a problem, a technique called collaborative verification is used in which part of the logic of the circuit to be verified is incorporated into an FPGA (Field-Programmable Gate Array), and verification is performed by combining emulation by this FPGA and HDL simulation. It has become like this.
As technologies related to this cooperative verification, for example, those described in Patent Documents 1 to 3 are known.

Patent Document 1 discloses a technique for improving the processing speed of the collaborative verification apparatus by dynamically changing the configuration of a circuit emulated by an FPGA emulator and a circuit simulated by an HDL simulator.
In Patent Document 2, the amount of communication between the hardware emulator and the system simulator is reduced by causing the system simulator to capture the output signal only when the output signal output from the hardware emulator to the system simulator changes. Technology is disclosed.

Patent Document 3 discloses that verification is performed while switching a normal operation mode and a debug mode while mapping a verification target circuit excluding a CPU core and a CPU core on an emulator. Of these, the normal operation mode allows the emulator's CPU core to operate and enables high-speed processing, while the debug mode enables effective debugging by running the emulator and verifying software execution with an instruction set simulator on the computer. Is.
The technique of Patent Document 3 can switch between a mode that prioritizes high speed and a mode that prioritizes debugging, but a mode that combines high speed and debugging is not prepared. .

  By the way, the cooperation verification apparatus for performing a cooperation verification was conventionally the structure shown, for example in FIG. 17 thru | or FIG. FIG. 17 is a diagram illustrating a hardware configuration of the cooperative verification apparatus. FIG. 18 is a diagram showing functions provided in the PC of FIG. FIG. 19 is a diagram schematically illustrating a verification operation performed by the cooperative verification apparatus in FIG.

  First, as hardware, as shown in FIG. 17, an FPGA board 210 equipped with an FPGA 220 used for hardware emulation is connected to a PC (personal computer) 230, which is a computer that performs HDL simulation, by a communication cable 240. Was.

In the PC 230, as shown in FIG. 18, the CPU 231 executes an OS (Operating System) 250 such as Linux (registered trademark), and an HDL simulator 260 and a test bench application 270 that are applications operating on the OS 250. Run. Further, the CPU 231 performs data transmission / reception between the FPGA board 210 and the FPGA 220 via the bus and communication I / F included in the PC 230 and further via the communication cable 240.

The HDL simulator 260 has a function of simulating the operation of the circuit based on HDL data in which the circuit configuration is described in HDL.
The test bench application 270 has a function of generating an input signal or input data for verifying the operation of the circuit and supplying the input signal or input data to the HDL simulator 260 or the FPGA 220. In addition, it has a function of monitoring output data and output signals output from the HDL simulator 260 and the FPGA 220 in accordance with the input signals or input data, and monitoring whether the contents are appropriate. If the expected output from the HDL simulator 260 and the FPGA 220 returns to the input, it can be determined that the circuit to be verified operates as expected.

Here, it is assumed that the circuit to be verified is configured by the first to third modules.
In this case, as shown in FIG. 19, circuits corresponding to some of the modules (here, the first and second modules) are programmed into the FPGA 220 as the first module 221 and the second module 222 by programming the FPGA 220. Form. This causes FPGA 220 to emulate the functions of these modules.
Further, the configuration of the remaining third module is described in HDL, and is input to the HDL simulator 260 that is an application (application) executed by the PC 230. Thus, the HDL simulator simulates the function of the third module as the third module 233.

  Then, the test bench 132 realized by the test bench application 270 supplies input data or an input signal to the first module 221, the second module 222, and the third module 233, respectively. The test bench 232 collects output data and output signals from each of these modules. Furthermore, each module may transmit and receive data or signals to and from other modules during operation.

  Among these, transmission / reception between the first module 221 and the second module 222 can be performed using a signal line in the FPGA 220. Transmission / reception between the third module 233 and the test bench 232 can be performed by inter-process communication in the PC 230. For these communication paths, a wide communication band can be secured relatively easily by the program of the FPGA 220 or the programs of the HDL simulator 260 and the test bench application 270.

  However, transmission / reception across the PC 230 and the FPGA 220, that is, communication between the third module 233 and the test bench 232 and the first and second modules 221 and 222 is performed via the communication cable 240. With regard to communication via the communication cable 240, data format conversion in accordance with the communication standard of the communication cable 240 is necessary, and it is difficult to change the configuration. The expansion was not easy.

Therefore, when the number of times of transmission / reception across the PC 230 and the FPGA 220 and the amount of data increase, there is a problem that the communication speed is restricted and the speed of cooperative verification is reduced.
Patent Documents 1 to 3 do not describe a technique for solving such a problem.
An object of the present invention is to solve such problems and improve the speed of collaborative verification.

  In order to achieve the above object, the present invention provides a collaborative verification apparatus that verifies the operation of an electronic circuit by combining software simulation and hardware emulation, and incorporates a CPU in the programmable circuit that performs the hardware emulation. The software simulation is executed.

  According to the above configuration, the speed of cooperative verification can be improved.

It is a figure which shows the hardware constitutions of 1st Embodiment of the cooperative verification apparatus of this invention. It is a figure for demonstrating the operating environment of CPU shown in FIG. It is a figure which shows typically the mode of the verification operation | movement by the cooperative verification apparatus of FIG. It is a figure corresponding to FIG. 2 for demonstrating another example of the operating environment of CPU. It is a figure corresponding to Drawing 3 showing typically another example of verification operation by a cooperation verification device. It is a figure corresponding to FIG. 2 for demonstrating another example of the operating environment of CPU. It is a figure corresponding to Drawing 3 showing still another example of verification operation by a cooperation verification device typically. It is a figure corresponding to FIG. 2 for demonstrating another example of the operating environment of CPU. It is a figure corresponding to Drawing 3 showing still another example of verification operation by a cooperation verification device typically. It is a figure which shows typically the mode of verification operation | movement by 2nd Embodiment of the cooperative verification apparatus of this invention. It is a flowchart which shows operation | movement of each part at the time of the 1st transmission / reception module transmitting data to the 2nd transmission / reception module in the cooperation verification apparatus shown in FIG. Similarly, it is a flowchart which shows operation | movement of each part at the time of a 2nd transmission / reception module transmitting data to a 1st transmission / reception module. Similarly, it is a flowchart which shows operation | movement of each part at the time of a 2nd transmission / reception module transmitting data to a 1st transmission / reception module in error mode. It is a flowchart which shows the continuation of FIG. It is a figure which shows the hardware structure of a 1st comparative example, and the structure of the function implement | achieved by each hardware. It is a figure which shows the hardware structure of a 2nd comparative example, and the structure of the function implement | achieved by each hardware. It is a figure which shows the hardware constitutions of an example of the conventional cooperation verification apparatus. It is a figure for demonstrating the operating environment of CPU in PC shown in FIG. It is a figure which shows typically the mode of the verification operation | movement by the cooperative verification apparatus shown in FIG.

Hereinafter, embodiments for carrying out the present invention will be specifically described.
[First Embodiment: FIGS. 1 to 9]
First, FIG. 1 shows a hardware configuration of an embodiment of the cooperative verification apparatus of the present invention.
The cooperative verification apparatus of this embodiment is configured as an FPGA (Field-Programmable Gate Array) board 10 and a memory 40 shown in FIG. The FPGA board 10 is connected to the PC 50 by a connection cable 60, and the PC 50 functions as a user interface of the cooperative verification apparatus. Therefore, the PC 50 can be regarded as a cooperative verification device.

Among these, the FPGA board 10 includes a communication interface (I / F) 11 and an FPGA 20.
The communication I / F 11 is an interface for connecting a communication line 60 for communicating with the PC 50, and any standard can be adopted. Although wired here is shown, wireless communication can also be adopted.

The FPGA 20 is a programmable circuit in which a large number of logic gates are arranged and a connection circuit between the gates can be rewritten by a program. This program can be set from the PC 50 via the communication I / F 11.
The FPGA 20 has a built-in CPU 30. Although the circuit configuration is fixed, the CPU 30 can flexibly execute various types of information processing by reading and executing a desired program.

  Further, the memory 40 is connected to the FPGA board 10. The memory 40 is a storage unit that stores a program executed by the CPU 30, data used for cooperative verification, an execution result log of the cooperative verification, and the like. Memory of any standard such as DDR (Double-Data-Rate) RAM, SD (Synchronous Dynamic) RAM, USB (Universal Serial Bus) memory, NAND flash memory can be used.

The program stored in the memory 40 provides an HDL simulator for realizing the function of simulating the operation of the circuit in the CPU 30, a test bench application for realizing the function of the test bench in the CPU 30, and an execution environment thereof. OS is included. As the OS, for example, Linux (registered trademark) can be used.
The data stored in the memory 40 includes HDL data that is application data of the HDL simulator, and RTL data in which the configuration of a circuit to be simulated by the HDL simulator is described in RTL (Register Transfer Level). Also included are signals and data that cause the test bench application to input each module, and test bench data that describes the expected output signals and output data.

  As schematically shown in FIG. 2, the CPU 30 inputs and outputs data and signals through wiring on the FPGA 20. This includes access to the memory 40. Then, the CPU 30 reads out the OS 36, the HDL simulator 37, and the test bench application 38 from the memory 40 and executes them, thereby realizing the function of simulating the function of the circuit to be verified and the function of the test bench.

  Note that the memory 40 can also be accessed from the PC 50 via the FPGA boat 10. Accordingly, the user can set the HDL data and the test bench data in the memory 40 by operating the PC 50. Further, the user can refer to the execution result by operating the PC 50 and reading the execution log of the cooperative verification from the memory 40.

  In addition, the execution start instruction and the interruption instruction of the cooperative verification can be performed by transmitting a necessary signal from the PC 50 to the FPGA board 10. Upon receiving this signal, the FPGA board 10 inputs a signal instructing the CPU 30 to start or stop execution through the wiring of the FPGA 20. For example, when receiving an input of a signal for instructing the start of verification, the CPU 30 reads out necessary programs and data from the memory 40 and starts simulating the operation of the circuit, and also starts the operation verification by the test bench. The result is recorded in the memory 40 as a log.

Here, FIG. 3 schematically shows a verification operation by the cooperative verification apparatus of FIG.
Here, it is assumed that the circuit to be verified is constituted by the first to third modules as in the case of FIG.

In this case, as shown in FIG. 3, circuits corresponding to some of the modules (here, the first and second modules) are programmed into the FPGA 20 as the first module 21 and the second module 22 by programming the FPGA 20. Form. This causes the FPGA 20 to emulate the functions of these modules. Setting of the program in the FPGA 20 can be performed from the PC 50 via the communication I / F 11.
Further, the configuration of the remaining third module is described in HDL, and the HDL data is stored in the memory 40. As a result, the CPU 30 reads out the HDL data and simulates the operation of the third module as the third module 31.

  The test bench 32 realized by the test bench application 38 supplies input data or input signals to the first module 21, the second module 22, and the third module 31, respectively. The test bench 32 collects output data and output signals from each of these modules. Furthermore, each module may transmit and receive data or signals to and from other modules during operation.

Among these, transmission / reception between the first module 21 and the second module 22 can be simulated by signal transmission / reception using a signal line in the FPGA 20. Transmission / reception between the third module 31 and the test bench 32 can be simulated by inter-process communication within the PC 30.
Further, transmission / reception between the CPU 30 and the FPGA 20, that is, signal transmission / reception between the third module 31 and the test bench 32 and the first and second modules 21 and 22 is simulated by signal transmission / reception between the CPU 30 and the FPGA 20. can do. This signal transmission / reception is indicated by a broken line in the figure, and can be performed via the wiring of the FPGA 20 to which the CPU 30 is connected.

  Therefore, communication can be performed at a higher speed than when communication is performed via the communication I / F 11 like the communication line 60. In addition, when the amount of data and signals to be communicated and the frequency of communication are high, by changing the program of the FPGA 20, although there is a restriction on the number of terminals of the CPU 30, the communication buffer is increased and the bandwidth is expanded. It can be done relatively easily.

  For this reason, compared with the case of the configuration as shown in FIG. 17 in which the CPU 30 is provided outside the FPGA 20, particularly outside the FPGA board 10, the verification speed is less likely to be lowered due to the restriction on the communication speed between the CPU and the FPGA. Further, it is possible to improve the verification speed when the operation of the electronic circuit is collaboratively verified by combining software simulation and hardware emulation.

The cooperative verification apparatus shown in FIG. 1 can also perform cooperative verification in an environment different from that shown in FIG. 3 by changing programs and data stored in the memory 40.
For example, as shown in FIG. 4, it is conceivable to cause the CPU 30 to execute a virtual hardware (HW) application 39 in addition to the HDL simulator 37 as an application for simulating the operation of the circuit. The virtual HW application 39 is an application that provides a simulation environment using a model written in a language such as SystemC and having a higher abstraction level than the RTL description.

In this case, as shown in FIG. 5, the operation of separate modules can be simulated by the HDL simulator 37 and the virtual HW application 39 in the CPU 30.
In the example of FIG. 5, the circuit to be verified is configured by first to fourth modules. Among them, the functions of the first and second modules are emulated by the FPGA 20 as in the case of FIG. The operation of the third module is simulated by the CPU 30 by the HDL simulator 37. The operation of the fourth module is simulated by the CPU 30 by the virtual HW application 39. The test bench is the same as in FIG.

In this case, the CPU 30 simulates the operation of a plurality of modules, but communication between these modules can be simulated by inter-process communication between processes executed by the CPU 30.
Further, signal transmission / reception between the module emulated by the FPGA 20 and the module simulated by the CPU 30 can be simulated by signal transmission / reception between the CPU 30 and the FPGA 20 as in the case of FIG. Of course, this signal transmission / reception can be performed via the wiring of the FPGA 20 to which the CPU 30 is connected, as in the case of FIG. Therefore, as in the case of FIG. 3, the speed of cooperative verification can be improved.

Further, as shown in FIG. 6, the operation of the circuit in the CPU 30 can be simulated only by the virtual HW application 39. However, even if the application used for the simulation changes, as shown in FIG. 7, the outline of the simulation is the same as in FIG.
That is, the CPU 30 simulates the operation of some modules in the verification target circuit, and the FPGA 20 emulates the operation of other modules in the verification target circuit. In addition, signal transmission / reception between the FPGA 20 and the CPU 30 simulates signal transmission / reception between the module simulated by the CPU 30 and the module emulated by the FPGA 20.
The only difference from FIG. 5 is that the third module 31 ′ is simulated by the virtual HW application 39.

The effect of improving the speed of cooperative verification can be obtained regardless of the type of application used by the CPU 30 for simulation.
In designing an actual electronic circuit, a circuit configuration is described using a description method having different abstraction levels, and each operation is verified. However, by using the collaborative verification device of this embodiment and storing data of an appropriate application and circuit configuration in the memory 40, high-speed collaborative verification is possible regardless of the degree of abstraction.

Moreover, the cooperative verification apparatus of this embodiment can also be used for equivalence verification. Equivalence verification is to verify whether the description of each method is equivalent based on whether the circuit simulated or emulated based on the description of different methods returns the same output for the same input. .
When performing this equivalence verification, as shown in FIG. 8, the CPU 30 causes the equivalence verification application 41 to be executed instead of the test bench application 38. As an application for simulating the operation of the circuit, an application corresponding to a description method for which equivalence is to be verified with a gate level description describing the circuit configuration of the FPGA 20 is used.

  Then, as shown in FIG. 9, the FPGA 20 emulates the operation of a circuit module (here, the first module), and the CPU 30 also simulates the operation of the same circuit module. Here, when the emulation circuit is formed in the FPGA 20, the circuit configuration is described at the gate level. When the CPU 30 performs the simulation, the circuit configuration is described in HDL or RTL having a higher abstraction level. If a virtual HW environment is used, it can be described in a more abstract manner.

  The CPU 30 implements the function of the equivalence verification test bench 35 by executing the equivalence verification application 41. Then, the same input signal (or its data) is given to the first module 21 emulated by the FPGA 20 and the first module 34 simulated by the CPU 30 to obtain an output signal (or its data). The equivalence verification test bench 35 compares the output signals from both, and if they match, the description at the gate level given to the FPGA 20 and the description at a higher abstraction level given to the CPU 30 are equivalent. Judge. If they do not match, it is determined that they are not equivalent.

At this time, the equivalence verification test bench 35 communicates with the first module 34 on the CPU 30 side by inter-process communication in the CPU 30, and the CPU 30 is connected to the communication with the first module 21 on the FPGA 20 side. This is performed via the wiring of the FPGA 20.
Here, when the equivalence verification test bench 35 gives various types of inputs to each module and obtains the outputs one by one, a large amount of communication occurs between the FPGA 20 and the CPU 30. However, by incorporating the CPU 30 in the FPGA 20 as in the present embodiment, the verification speed is less likely to decrease due to the restriction on the communication speed between the CPU and the FPGA. Therefore, the speed of equivalence verification can be improved as in the case of FIG.

[Second Embodiment: FIGS. 10 to 14]
Next, a second embodiment of the cooperative verification apparatus of the present invention will be described.
FIG. 10 schematically shows a verification operation according to the second embodiment of the cooperative verification apparatus of the present invention.
Also in the second embodiment, the FPGA 20 including the CPU 30 is provided on the FPGA board 10, and the memory 40 is connected to the FPGA board 10 to configure the collaborative verification device in the case of the first embodiment. It is the same.

  However, as a user interface, a monitor 51 is provided instead of the PC 50 in the first embodiment. The monitor 51 has a function of displaying the content as a waveform, a numerical value, or the like so that the user can refer to the content based on the verification result data transmitted from the FPGA board 10. In addition, it has a function of displaying a GUI for accepting settings such as parameters indicating verification contents, receiving a user operation on the GUI, and passing the operation contents to the FPGA board 10.

The function of providing data necessary for display to the monitor 51 and setting each part of the FPGA board 10 including the FPGA 20 according to the operation content data transmitted from the monitor 51 is that the CPU 30 executes a necessary program. To achieve.
By the way, in this 2nd Embodiment, a cooperation verification apparatus performs verification regarding the data transmission / reception function between two transmission / reception modules. Then, the FPGA 20 emulates the function of one of the modules as the first transmission / reception module 61. Further, the CPU 30 simulates the function of the other module as the second transmission / reception module 71.

  In addition, a transfer unit for monitoring and operating the communication status is provided between these transmission / reception modules. On the first transmission / reception module 61 side, the FPGA 20 realizes the function of the first transfer unit 62 as the first transfer means. On the second transmission / reception module 71 side, the CPU 30 realizes the function of the second transfer unit 72 as the second transfer means.

  When simulating data transmission from the first transmission / reception module 61 to the second transmission / reception module 71, the first transmission / reception module 61 first transmits data to be transmitted to the second transmission / reception module 71 to the first transfer unit 62. . Here, the first transfer unit 62 temporarily holds the data and stores it in the first storage unit 63 so that it can be referred to in the order of transmission / reception as a log later in post-debugging or the like. The first storage unit 63 can be provided in the memory 40.

The first transfer unit 62 transfers data received from the first transmission / reception module 61 to the second transfer unit 72. The second transfer unit 72 temporarily holds the data and stores it in the second storage unit 73 so that it can be referred to in the order of transmission / reception as a log later in post-debugging or the like. Although the second storage unit 73 is shown as a function realized by the CPU 30, the second storage unit 73 may be provided in the memory 40 instead of the internal memory of the CPU 30.
Thereafter, the second transfer unit 72 transfers the data received from the first transfer unit 62 to the second transmission / reception module 71.

  Thus, data transmission from the first transmission / reception module 61 to the second transmission / reception module 71 is completed. Data transmission from the second transceiver module 71 to the first transceiver module 61 is performed in the reverse order. In the above transmission process, the first transfer unit 62 and the second transfer unit 72 also function as an accumulation unit that accumulates in the storage unit so that the transmitted / received data can be referred to in the order of transmission / reception later.

In the above transmission process, the first transfer unit 62 and the second transfer unit 72 deliberately change the transfer order of continuously transmitted data, change data header information, or transmit data. It is possible to perform an error mode operation such as delaying the operation. The data stored in each storage unit can be used for data transfer order management when performing these operations. Of course, it can also be used for transmission order management in the case of normal transmission.
If there is no need to refer to the log later, if there is a large limitation on the capacity of the storage means provided with the storage unit, only the amount of data necessary for the above transmission order management is stored in each storage unit. Also good.

  In FIG. 10, an ISS (Instruction Set Simulator) 74 is a CPU model that moves with instruction accuracy. When verification using the FPGA board 10 is performed, the ISS 74 controls the operation of each module to be simulated (including those emulated by the FPGA 20). In FIG. 10, the 1st transmission / reception module 61, the 1st transfer part 62, the 2nd transmission / reception module 71, and the 2nd transfer part 72 correspond to a control object.

The work memory 75 is a memory used by the ISS 74 for control operations.
The peripheral device 76 is a group of modules with a high abstraction level used by the ISS 74 for control, such as a UART (Universal Asynchronous Receiver Transmitter) and a timer.
The functions of the ISS 74, work memory 75, and peripheral device 76 are also realized by the CPU 30 executing necessary programs.

Next, the operations performed by the units shown in FIG. 10 when simulating data transmission / reception between the first transmission / reception module 61 and the second transmission / reception module 71 in the cooperative verification apparatus shown in FIG. This will be described with reference to the flowchart of FIG.
Of the operations shown in these flowcharts, the operations performed by each unit provided in the FPGA 20 are performed based on the control of the ISS 74 by the hardware logic programmed in the FPGA 20. The operations performed by each unit provided in the CPU 30 are performed by the CPU 30 executing a required program.

First, FIG. 11 shows an operation when the first transmission / reception module 61 transmits data to the second transmission / reception module 71.
In this operation, first, the ISS 74 instructs the first transmission / reception module 61 to transmit data (S11). At this time, data to be transmitted is also specified.

  In response to this, the first transmission / reception module 61 determines whether or not it can transmit data (S12). If it is in a transmittable state, processing at the time of transmission is performed on the data to be transmitted (S13). This processing is, for example, header processing when using a TOE (TCP / IP Offload Engine). When this transmission / reception process is completed, the first transmission / reception module 61 transmits the processed data to the first transfer unit 62 (S14).

  Receiving this, the first transfer unit 62 writes the data in the first storage unit 63 (S15). Then, it is determined whether or not the previous data transfer is completed in the first transfer unit 62 (S16). If completed, the first transfer unit 62 transmits the data received in step S14 to the second transfer unit 72 (S17).

Receiving this, the second transfer unit 72 writes the data in the second storage unit 73 (S18) and transmits the received data to the receiving unit of the second transmission / reception module 71 (S19).
The second transmission / reception module 71 performs reception processing on the data received here (S20), and the simulation of one data transmission from the first transmission / reception module 61 to the second transmission / reception module 71 is completed. .

In the case of NO in step S12, the first transmission / reception module 61 cannot immediately transmit data. In this case, if the first transmission / reception module 61 is set to discard data when transmission is impossible in the register (YES in S21), the first transmission / reception module 61 discards data instructed to be transmitted (S22). In this case, the data transmission operation according to the instruction from the ISS 74 in step S11 is thus completed.
If it is not set to be discarded in step S21, the process returns to step S12 and is repeated.

  If NO in step S16, the first transfer unit 62 cannot immediately transmit data. In this case, if the register is set to discard the data when the first transfer unit 62 cannot transmit (YES in S23), the first transfer unit 62 discards the data instructed to transmit (S24). In this case, the data transmission operation according to the instruction from the ISS 74 in step S11 is thus completed.

If it is not set to be discarded in step S23, the process returns to step S16 and is repeated.
If neither the first transmission / reception module 61 nor the first transfer unit 62 is set to discard data, the process finally proceeds to step S17 and the following steps to transfer data from the first transmission / reception module 61 to the second transmission / reception module 71. Transmission will be executed.

Next, FIG. 12 shows an operation when the second transmission / reception module 71 transmits data to the first transmission / reception module 61. In this operation, data is transmitted in the same procedure as that shown in FIG.
In this operation, first, the ISS 74 instructs the second transmission / reception module 71 to transmit data (S31). At this time, data to be transmitted is also specified.

  In response to this, the second transmission / reception module 71 determines whether or not it can transmit data (S32). If transmission is possible, transmission processing is performed on the data to be transmitted (S33). This processing is, for example, header processing when using a TOE (TCP / IP Offload Engine). When this transmission / reception process is completed, the second transmission / reception module 71 transmits the processed data to the second transfer unit 72 (S34).

  Receiving this, the second transfer unit 72 writes the data to the second storage unit 73 (S35). Then, it is determined whether or not the previous data transfer is completed in the second transfer unit 72 (S36). If completed here, the second transfer unit 72 transmits the data received in step S34 to the first transfer unit 62 (S37).

Receiving this, the first transfer unit 62 writes the data in the first storage unit 63 (S38) and transmits the received data to the reception unit of the first transmission / reception module 61 (S39).
The first transmission / reception module 61 performs reception processing on the data received here (S40), and the simulation of one data transmission from the second transmission / reception module 71 to the first transmission / reception module 61 is completed. .

  In the case of NO in step S32, the second transmission / reception module 71 cannot immediately transmit data. In this case, if the second transmission / reception module 71 is set in the register to discard data when transmission is impossible (YES in S41), the second transmission / reception module 71 discards data instructed to be transmitted (S42). In this case, the data transmission operation according to the instruction from the ISS 74 in step S31 is completed so far.

If it is not set to be discarded in step S41, the process returns to step S32 and the process is repeated.
If NO in step S36, the second transfer unit 72 cannot immediately transmit data. In this case, if the second transfer unit 72 is set to discard data when transmission is impossible in the register (YES in S43), the second transfer unit 72 discards data instructed to be transmitted (S44). In this case, the data transmission operation according to the instruction from the ISS 74 in step S31 is completed so far.

If it is not set to discard in step S43, the process returns to step S36 and the process is repeated.
If neither the first transmission / reception module 61 nor the first transfer unit 62 is set to discard the data, the process finally proceeds to step S37 and the subsequent steps to transfer data from the first transmission / reception module 61 to the second transmission / reception module 71. Transmission will be executed.

Next, FIGS. 13 and 14 show an operation when the second transmission / reception module 71 transmits data to the first transmission / reception module 61 in the error mode.
In this operation, first, the ISS 74 sets an error mode in the register (S51). At this time, the type of error to be generated is also set.

Thereafter, from the time when the ISS 74 instructs the second transmission / reception module 71 to transmit data until the second transfer unit 72 writes the transmission data to the second storage unit 73, steps S31 to S35 and S41, S42 in FIG. The same is true (S52 to S58).
After step S56, the operation proceeds to the portion shown in FIG. Then, the second transfer unit 72 determines the type of the set error mode, and thereafter performs an operation according to the type of the error mode. Although not shown, when the error mode is not set, the same processing as in FIG. 12 is performed.

  If the order is changed in step S59, the second transfer unit 72 waits until the next data is transmitted from the second transmission / reception module 71 (S60). The order change error mode is set when a plurality of data is transmitted sequentially, and the second data should be transmitted from the second transmission / reception module 71 based on an instruction of the ISS 74.

  When the next data is received, the second transfer unit 72 transmits the (next) data transmitted later to the first transfer unit 62 (S61). Receiving this, the first transfer unit 62 writes the data in the first storage unit 63 (S62) and transmits the received data to the receiving unit of the first transmission / reception module 61 (S63).

  The first transmission / reception module 61 performs reception processing on the data received here (S40), and the simulation of the transmission of “next data” from the second transmission / reception module 71 to the first transmission / reception module 61 is completed. Complete. Note that the second transfer unit 72 may write the data to the second storage unit 73 when transmitting data transmitted later in step S61.

  After step S64, the second transfer unit 72 transmits the “data previously transmitted” received in step S55 to the first transfer unit 62 (S65). If the second transfer unit 72 does not have a memory for storing this data during steps S61 to S64, the data to be transmitted may be read from the second storage unit 73.

Receiving this, the first transfer unit 62 writes the data in the first storage unit 63 (S70), and transmits the received data to the receiving unit of the first transmission / reception module 61 (S71).
The first transmission / reception module 61 performs reception processing on the data received here (S72), and transmission of “data transmitted earlier” from the second transmission / reception module 71 to the first transmission / reception module 61 is completed. The simulation is complete.
In addition, the transmission simulation from the second transmission / reception module 71 to the first transmission / reception module 61 in which the order of the two data is changed due to an error is completed.

  When the header information is changed in step S59, the second transfer unit 72 changes the header information of the data received in step S55. The header information is, for example, an IP address and a version when using IP (Internet Protocol) for data transfer. Any part of the header can be changed.

Thereafter, the second transfer unit 72 transmits the data after the header information change to the first transfer unit 62 (S67). Thereafter, the first transfer unit 62 and the first transmission / reception module 61 perform the same operations of steps S70 to S72 as in the case of the order change described above.
This completes the transmission simulation from the second transmission / reception module 71 to the first transmission / reception module 61 in which the header information has been changed due to an error.

  Further, in the case of a delay in step S59, the second transfer unit 72 gives a delay to the data transmission by waiting for a predetermined time longer than that during normal transmission (S68). Thereafter, the second transfer unit 72 transmits the data received in step S55 to the first transfer unit 62 (S69). Thereafter, the first transfer unit 62 and the first transmission / reception module 61 perform the same operations of steps S70 to S72 as in the case of the order change described above.

  This completes the simulation of transmission from the second transmission / reception module 71 to the first transmission / reception module 61 in which a delay has occurred due to errors, processing concentration, or the like. Here, the example in which the second transfer unit 72 performs the error mode operation has been described. However, when the first transfer unit 61 transmits data to the second transmit / receive module 71, the first transfer unit 62 has a similar error. It is preferable that mode operation can be performed.

According to the cooperative verification apparatus of the second embodiment, it is possible to verify the inter-module communication operation in consideration of the occurrence of the error as described above.
Also in the above configuration, as in the case of the first embodiment, there is no need for a PC for starting the simulator, and there is no need to transfer data between the PC and the FPGA. It is difficult for the verification speed to decrease due to restrictions on the communication speed. That is, the verification speed can be improved.

  Furthermore, since the transmission / reception module opposite to the transmission / reception module provided in the FPGA can also be provided in the same FPGA board, verification can be performed with one FPGA board. For this reason, it is not necessary to prepare an additional FPGA board for providing the opposing module, and labor and cost are reduced.

  In addition, for the transmission / reception module to be simulated by the CPU, register access, function execution, memory information, and the like can be easily visualized, and analysis information can be acquired. Further, since the first and second transfer units are provided to store the data to be transferred, the transfer contents can be easily analyzed later.

[Comparative example of the second embodiment: FIGS. 15 and 16]
Next, a comparative example of the above-described second embodiment will be described.
First, FIG. 15 shows a hardware configuration of the first comparative example and a configuration of functions realized by each hardware.
In the first comparative example, a first FPGA board 110 and a second FPGA board 130 are sequentially connected to a PC 150. Among these, the FPGA 120 of the first FPGA board 110 does not contain a CPU, and the FPGA 140 of the second FPGA board 130 contains a CPU 142.

  Then, by programming the FPGA 120, the function of the first transmission / reception module 121 is emulated. Further, by programming the FPGA 140, the function of the second transmission / reception module 141 facing the first transmission / reception module 121 is emulated.

  Also. In the PC 150, the functions of the ISS 161, work memory 162, and peripheral device 163 are realized by causing the CPU to execute a required program. The functions of these units are the same as those shown in FIG. The control of the second transmission / reception module 141 may be handled by the ISS 161 or the CPU 142.

  In this way, in the configuration in which the FPGA emulates the functions of the transmission / reception module, the functions of the two transmission / reception modules are emulated using two FPGA boards. For this reason, the effort and cost which construct | assemble a cooperation verification apparatus become large. Further, if the function of the ISS 161 is realized in the PC 150, the cost is increased by the provision of the PC 150. Furthermore, since the data transfer between the transmission / reception modules cannot be visualized by the simulator, there is a problem that the debugging performance is poor. Furthermore, if the data transfer between the PC 150 and the FPGA boards 110 and 130 increases, the verification speed decreases due to the restriction on the communication speed.

Next, FIG. 16 shows a hardware configuration of the second comparative example and a configuration of functions realized by each hardware.
In the second comparative example, the functions of the ISS 161, the work memory 162, and the peripheral device 163 are realized by incorporating the CPU 122 in the FPGA 120 ′ mounted on the first FPGA board 110 and causing the CPU 122 to execute a required program. The point is different from the first comparative example.
For this reason, the PC 150 is unnecessary, and a monitor 51 similar to that in the second embodiment is provided instead.

In this configuration, a PC for starting the simulator is not necessary, and there is no data transfer between the PC and the FPGA board, so that the verification speed is less likely to decrease compared to the configuration of the first comparative example. However, there is no change in the use of two FPGA boards to emulate the functions of the two transmission / reception modules. For this reason, the effort and cost which construct | assemble a cooperation verification apparatus become large. Moreover, since the data transfer between the transmission / reception modules cannot be visualized by the simulator, the problem that the debugging performance is poor also remains.
However, with the configuration of the second embodiment described above, verification can be performed with a single FPGA board, and since the first and second transfer units are provided, such a problem does not occur.

[Modification]
Although the description of the embodiment has been completed above, in the present invention, the specific configuration of each unit, the contents of processing, the data format, the configuration of the verification target circuit, and the like are not limited to those described in the embodiment.
For example, in the above-described embodiment, the example in which the memory 40 is provided outside the FPGA board 10 has been described, but the memory 40 may be mounted on the FPGA board 10.

Further, the application that the CPU 30 uses for simulating the operation of the circuit is not limited to the HDL simulator 37 and the virtual HW application 39.
The virtual HW application can simulate a CPU, a bus, and the like as a virtual model. A virtual platform can be constructed by connecting virtual HW models, and the OS can be run in that environment. Accordingly, it is possible to make the virtual HW application behave as a test bench.

  Further, the user interface of the cooperative verification apparatus is not limited to the PC 50, and may be a dedicated control apparatus including a display unit and an operation unit. For example, it is conceivable to provide an interface for connecting a keyboard (or console) and a display to the FPGA board 10. Then, it is conceivable to input a signal for instructing the CPU 30 to start or stop execution through this interface by operating the keyboard so that the execution result generated by the CPU 30 can be displayed on the display. If it does in this way, it is not necessary to provide PC50.

Further, the verification performed by the cooperative verification apparatus is not limited to that described in the above embodiment. The number of modules emulated by the FPGA 20 and the number of modules simulated by the CPU 30 are not limited to those described in the above embodiment.
Further, the programmable circuit that emulates the verification target circuit is not limited to the FPGA. Furthermore, it is possible to incorporate a plurality of CPUs in the programmable circuit.
Moreover, it is needless to say that the configurations of the embodiment and the modified examples described above can be arbitrarily combined and implemented as long as they do not contradict each other.

10, 210: FPGA board, 11: Communication I / F, 20, 120, 140, 220: FPGA, 21, 34, 221: First module, 22, 222: Second module, 30, 122, 142, 231: CPU 31, 31 ', 233: third module, 32, 232: test bench, 33: fourth module, 35: equivalence verification test bench, 36, 250: OS, 37, 260: HDL simulator, 38, 270: Test bench application, 39: Virtual HW application, 40: Memory, 41: Equivalence verification application, 50, 150, 230: PC, 51: Display, 60: Communication line, 240: Communication cable, 61, 121: No. 1 transmission / reception module, 62: first transfer unit, 63: first storage unit, 71, 141: second transmission / reception module, 72: second transfer , 73: second storage unit, 74,161: ISS, 75,162: working memory, 76,163: peripheral device, 110: first 1FPGA board, 130: first 2FPGA board, 160: Simulator

JP 2009-223762 A Japanese Patent No. 4470582 JP 2007-58813 A

Claims (10)

A collaborative verification device that verifies the operation of an electronic circuit by combining software simulation and hardware emulation,
A co-verification apparatus, wherein a CPU is built in a programmable circuit that performs hardware emulation, and the CPU executes the software simulation. The collaborative verification device according to claim 1,
The CPU simulates the operation of a part of the electronic circuit, the programmable circuit emulates the operation of another part of the electronic circuit, and transmits and receives signals between the programmable circuit and the CPU. A cooperative verification apparatus simulating signal transmission / reception between a part of the electronic circuit and another part. The collaborative verification device according to claim 2,
The programmable circuit comprises first transfer means for temporarily holding data transmitted and received by the other part of the emulated electronic circuit;
The CPU realizes a function of second transfer means for temporarily holding data transmitted and received by the part of the simulated electronic circuit,
A cooperative verification apparatus simulating signal transmission / reception between a part of the electronic circuit and another part by signal transmission / reception between the first transfer means and the second transfer means. The collaborative verification device according to claim 3,
The cooperative verification apparatus, wherein the first transfer unit and the second transfer unit include a storage unit that stores the transmitted and received data in a storage unit so that the transmitted and received data can be referred to in the order of transmission and reception later. The collaborative verification device according to claim 3 or 4,
At least one of the first transfer means and the second transfer means is
A collaborative verification apparatus comprising: at least one of means for changing the order of data to be transmitted, means for changing header information of data to be transmitted, and means for delaying data transmission. The collaborative verification device according to claim 1,
The CPU executes a software simulation that simulates the operation of the same electronic circuit as that emulated by the hardware emulation, and compares the result of the software simulation with the result of the hardware emulation to verify equivalence. The collaborative verification apparatus characterized by performing. A collaborative verification method that verifies the operation of an electronic circuit by combining software simulation and hardware emulation,
A cooperative verification method, comprising: a programmable circuit having a CPU built therein; causing the programmable circuit to execute the hardware emulation; and causing the CPU to execute the software simulation. The cooperative verification method according to claim 7,
By causing the CPU to simulate the operation of a part of the electronic circuit, to cause the programmable circuit to emulate the operation of another part of the electronic circuit, and by transmitting and receiving signals between the programmable circuit and the CPU, A cooperative verification method characterized by simulating signal transmission / reception between a part of the electronic circuit and another part. It is the cooperation verification method of Claim 8, Comprising:
Realizing the function of the first transfer means for temporarily holding the data transmitted and received by the other part of the emulated electronic circuit in the programmable circuit;
Causing the CPU to realize a function of second transfer means for temporarily holding data transmitted and received by the part of the simulated electronic circuit;
A cooperative verification method, wherein signal transmission / reception between a part of the electronic circuit and another part is simulated by signal transmission / reception between the first transfer means and the second transfer means. The cooperative verification method according to claim 7,
The CPU is caused to execute a software simulation for simulating the operation of the same electronic circuit as the electronic circuit to be emulated by the hardware emulation, and the equivalence verification is performed by comparing the result of the software simulation with the result of the hardware emulation. A collaborative verification method characterized by

Images