JP2009223762A - Cooperation verification device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enhance processing speed of a cooperation verification device. <P>SOLUTION: The cooperation verification device 100 includes: a processor 120 for attaining a simulator 130 which performs simulation; an emulator 140 which performs emulation; a transactor 150 which performs transfer of transactions between the simulator 130 and the emulator 140; and a transfer part which transfers a simulation result of the simulator 130 to the emulator 140 and transfers an emulation result of the emulator 140 to the simulator 130. The simulator 130 further includes a simulation control part which suspends the simulation upon establishment of a change condition of a change file and instructs a change in configuration of simulation circuit based on a setting content of a setting file, and the emulator 140 further includes an emulation control part which suspends the emulation upon establishment of the change condition of the condition file, and instructs a change in configuration of an emulation circuit based on the setting content of the setting file. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a cooperative verification apparatus, and more particularly to a cooperative verification apparatus for verifying a system LSI.

  As a general verification device, an RTL simulator that performs RTL (Register Transfer Level) simulation and an FPGA emulator that performs Field Programmable Gate Array (FPGA) emulation are known.

  In recent years, a cooperative verification apparatus is known in which a simulator that performs RTL simulation and an emulator that performs FPGA emulation operate cooperatively.

  In the conventional collaborative verification apparatus, first, after the module of the circuit to be verified is divided into the RTL module that is the target of RTL simulation and the FPGA module that is the target of FPGA emulation, the collaborative verification process is executed.

  In such a collaborative verification environment, the RTL simulator can execute a simulation such as observing an internal state of a flip-flop (hereinafter referred to as “FF”) or a signal freely. The processing speed of the collaborative verification device decreases as the speed decreases and the number of RTL modules increases.

  On the other hand, the FPGA emulator can execute high-speed emulation, but cannot observe internal states such as FFs and signals. Therefore, the module that is required to observe the internal state is divided into RTL modules. Is done. However, in the conventional collaborative verification apparatus, the configuration of the RTL module and the FPGA module cannot be dynamically changed during the execution of the collaborative verification operation after the module is first divided. The confirmed RTL module is verified as an RTL module in the verification process of another module. As a result, RTL simulation is also performed for normal modules, so that the processing speed of the collaborative verification device decreases.

  Further, in the cooperative verification environment as described above, it is difficult to provide a verification environment having a different module configuration for each person in charge of developing each module.

  Patent Document 1 discloses a technique for statically changing the module configuration of a hardware simulator and a software simulator and switching between a cycle level and an operation level.

  However, the technique of Patent Document 1 cannot dynamically change the module configuration between the RTL simulator and the FPGA emulator.

  Patent Document 2 discloses a technology in which a CPU on an emulator and an instruction set simulator (hereinafter referred to as “ISS”) are provided, high-speed execution of the CPU is performed by an emulator, and debugging is performed by an ISS software debugger. .

However, since the technique of Patent Document 2 switches only the CPU, it cannot switch any module. The purpose is only to improve the efficiency of software debugging.
JP 2006-79417 A JP 2007-58813 A

  An object of the present invention is to improve the processing speed of the cooperative verification apparatus.

According to the first aspect of the present invention, a simulation program, a simulation circuit that is a circuit to be verified, a condition file that describes conditions for changing the simulation circuit and an emulation circuit that is a circuit to be verified, and the simulation circuit and the emulation circuit A storage unit for storing a setting file in which changes are described;
A processor for realizing a simulator for simulating an effective module having all information of the circuit to be verified by activating the simulation program;
An emulator that has all the information of the circuit to be verified and emulates a valid module;
A transactor for transferring transactions between the simulator and the emulator;
A transfer unit for transferring the simulation result of the simulator to the emulator and transferring the emulation result of the emulator to the simulator based on the setting contents of the setting file when a condition for changing the condition file is satisfied; Prepared,
The simulator further includes a simulation control unit that interrupts the simulation when a condition for changing the condition file is satisfied, and instructs the change of the configuration of the simulation circuit based on the setting content of the setting file,
The emulator further includes an emulation control unit that interrupts the emulation when the condition file change condition is satisfied, and instructs the change of the configuration of the emulation circuit based on the setting contents of the setting file. A collaborative verification device is provided.

  According to the present invention, the processing speed of the cooperative verification apparatus can be improved.

  Embodiments of the present invention will be described below with reference to the drawings. The following examples are one embodiment of the present invention and do not limit the scope of the present invention.

  First, Example 1 of the present invention will be described.

  FIG. 1 is a block diagram illustrating a configuration of a cooperative verification apparatus 100 according to the first embodiment of the present invention.

  The cooperative verification apparatus 100 according to the first embodiment of the present invention includes a storage unit 110, a processor 120, an emulator 140, a transactor 150, and a transfer unit 160.

  The storage unit 110 stores a simulation program 111, a condition file 112, a setting file 113, and verification target circuit data 114.

  The simulation program 111 is an application program for realizing the simulator 130.

  The condition file 112 is a file in which conditions (hereinafter referred to as “change conditions”) for switching between valid / invalid of modules of a simulation circuit 131 and an emulation circuit 141 to be described later are described.

  The setting file 113 is a file in which contents (hereinafter referred to as “setting contents”) for switching between valid / invalid of modules of a simulation circuit 131 and an emulation circuit 141 to be described later are described.

  The verification target circuit data 114 is data describing a simulation circuit 131 that is a verification target circuit of the simulator 130. For example, the verification target circuit data 114 is RTL description data.

  The processor 120 implements the simulator 130 by starting the simulation program 111 stored in the storage unit 110.

  The simulator 130 has all the information of the simulation circuit 131 described later, and simulates an effective module. For example, the simulator 130 is an RTL (Register Transfer Level) simulator.

  The emulator 140 has all information of an emulation circuit 141 described later, and performs emulation of a valid module. For example, the emulator 140 is an FPGA (Field Programmable Gate Array) emulator.

  The transactor 150 generates and transfers a transaction between the simulator 130 and the emulator 140. The transaction is information for synchronizing between a simulation circuit 131 (described later) and an emulation circuit 141 (described later), and may include bus access information.

  The transfer unit 160 transfers the simulation result of the simulator 130 to the emulator 140 and transfers the emulation result of the emulator 140 to the simulator 130 based on the setting content of the setting file 113 when the condition for changing the condition file 112 is satisfied. . When the condition for changing the condition file 112 is satisfied and the valid / invalid of the modules of the simulation circuit 131 and the emulation circuit 141 to be described later are switched, the transfer unit 160 performs flip-flops (hereinafter referred to as flip-flops) , "FF"), the simulation result such as the internal information such as the signal and the number of executed clocks is transferred to the emulator 140 to enable the module of the emulation circuit 141, and the FF and signal of the module in which the emulator 140 is disabled The internal result such as the above and the emulation result such as the number of executed clocks are transferred to the simulator 130 to enable the module of the simulation circuit 131.

  In the first embodiment of the present invention, the transactor 150 and the transfer unit 160 are modules shared by the simulator 130 and the emulator 140.

  FIG. 2 is a block diagram illustrating configurations of the simulator 130 and the emulator 140 according to the first embodiment of the present invention.

  The simulator 130 includes a simulation circuit 131, a simulation control unit 132, and a simulation bridge 133. For example, the simulator 130 is an RTL simulator.

  The simulation circuit 131 is an RTL model verification target circuit including a plurality of simulation target modules (CPU, memory, media processors M1 and M2, and hardware (hereinafter referred to as “HW”)).

  The simulation control unit 132 monitors whether or not the change condition of the condition file 112 is satisfied for the simulation circuit 131. If the change condition is satisfied, the simulation is interrupted and the simulation is performed based on the setting contents of the setting file 113. In order to change the configuration of the circuit 131, an instruction to enable / disable the module is given.

  The simulation bridge 133 manages the validity / invalidity of the module of the simulation circuit 131, and the bus access output from the valid module of the simulation circuit 131 is for the internal module of the simulator 130 or for the external module (that is, If it is internal, the internal module is accessed, and if it is external, the transactor 150 is instructed to transfer the transaction to the emulator 140.

  The emulator 140 includes an emulation circuit 141, an emulation control unit 142, and an emulation bridge 143. For example, the emulator 140 is an FPGA emulator.

  The emulation circuit 141 is an FPGA design verification target circuit including a plurality of emulation target modules (CPU, memory, media processors M1, M2, and HW) that are the same as the simulation circuit 131.

  The emulation control unit 142 monitors whether or not the condition for changing the condition file 112 is satisfied for the emulation circuit 141. When the condition for changing is satisfied, the emulation is interrupted and the emulation is performed based on the setting contents of the setting file 113. In order to change the configuration of the circuit 141, an instruction to switch the module between valid / invalid is given.

  The emulation bridge 143 manages the validity / invalidity of the module of the emulation circuit 141, and the bus access output from the valid module of the emulation circuit 141 is for the internal module of the emulator 140 or the external module (that is, If it is internal, the internal module is accessed, and if it is external, it instructs the transactor 150 to transfer the transaction to the simulator 130.

  FIG. 3 is a schematic diagram illustrating an example of a change condition of the condition file 112.

  The change condition of the condition file 112 in FIG. 3 is that the module is switched between valid / invalid when the time 1000 ns elapses, the signal A becomes 0, and the CPU program counter value PC becomes “0x80020000”. It shows that.

  FIG. 4 is a schematic diagram illustrating an example of setting contents of the setting file 113.

  The settings in the setting file 113 in FIG. 4 are as follows: in the initial state (0 ns), all the modules of the simulation circuit 131 are disabled, all the modules of the emulation circuit 141 are enabled, and in the state after the simulation is executed (1000 ns) It shows that the CPU and HW of the simulation circuit 131 are enabled and the CPU and HW of the emulation circuit 141 are disabled. The setting contents of the setting file 113 in FIG. 4 are that the simulation circuit 131 and the emulation circuit 141 are enabled / disabled when the signal A becomes 0 or the PC becomes “0x80020000”. Indicates.

  FIG. 5 is a flowchart illustrating the processing procedure of the cooperative verification processing according to the first embodiment of the present invention.

  First, the simulation control unit 132 instructs the simulation circuit 131 to start simulation, and the emulation control unit 142 instructs the emulation circuit 141 to start emulation, thereby starting simulation and emulation (S501). At this time, the simulation control unit 132 monitors the simulation circuit 131 and the emulation control unit 142 monitors the emulation circuit 141 for whether or not the condition for changing the condition file 112 is satisfied.

  When the condition for changing the condition file 112 is satisfied (S502-YES), the simulation control unit 132 interrupts the simulation, and the emulation control unit 142 interrupts the emulation (S503).

  Next, based on the setting contents of the setting file 113, the transfer unit 160 transfers the simulation result of S501 to the emulator 140, and performs module execution state transfer that transfers the emulation result to the simulator 130 (S504). For example, the simulation result and the emulation result to be transferred are all the internal information such as all FFs and signals in the valid module indicated in the setting contents of the setting file 113 and the number of executed clocks.

  When the module execution state transfer is completed, the configuration of the simulation circuit 131 is changed based on the setting contents of the setting file 113, and the configuration of the emulation circuit 141 is changed (S505).

  Thereafter, the simulation control unit 132 and the emulation control unit 142 resume execution of simulation and emulation (S506).

  S501 to S506 are repeated until the cooperative verification process is completed (S507-NO). The collaborative verification process ends, for example, when a predetermined time has passed or when a user's end instruction is received from an input device such as a keyboard or a mouse (not shown).

  FIG. 6 is a sequence diagram illustrating an outline of the cooperative verification process.

  FIG. 6 shows that collaborative verification starts from an initial state in which all modules of the simulation circuit 131 are invalid and all modules of the emulation circuit 141 are valid, and the change condition of the condition file 112 is the time N (Nth cycle). Shows a state where the module is switched between valid / invalid, and the setting contents of the setting file 113 indicate that the CPU and HW of the simulation circuit 131 are enabled and the memory and media processors M1 and M2 of the emulation circuit 141 are enabled. It is an example.

  At time 0 to N, as shown in FIG. 7, since all modules of the simulation circuit 131 are invalid and all modules of the emulation circuit 141 are valid, emulation is executed for all modules of the emulation circuit 141. Is done.

At time N, the emulation control unit 142 interrupts the emulation, and the transfer unit 160 transfers the module execution state.

  FIG. 9 is a schematic diagram illustrating an example of a data structure of data transferred in the module execution state transfer.

  Data transferred in the module execution state transfer includes module information and the number of clocks. The module information includes a module name, a hierarchy name, an FF name, a signal name, and a value thereof.

  When the module execution state transfer is performed, the validity / invalidity of the module is switched, and as shown in FIG. 8, the CPU and HW of the emulation circuit 141 become invalid, and the CPU and HW of the simulation circuit 131 become valid.

After the module execution state transfer and the module validity / invalidity are switched, the cooperative operation is resumed . As shown in FIG. 10, the simulation control unit 132 and the emulation control unit 142 perform a cooperative operation while synchronizing based on the transaction transferred by the transactor 150.

  In the cooperative operation after time N, a simulation is executed for an effective module of the simulation circuit 131. After the simulation is completed, the transaction is transferred through a route of simulation bridge 133 -transactor 150 -emulation bridge 143. Thereafter, emulation is executed for a valid module of the emulation circuit 141. After the emulation is completed, the transaction is transferred through a route of emulation bridge 143 -transactor 150 -simulation bridge 133. Thereafter, the process of executing the simulation for the simulation circuit 131 is repeated again.

  Note that the synchronization method of the transactor 150 may be a method of generating one transaction per clock, or another method.

  In the cooperative operation after time N, the simulation control unit 132 and the emulation control unit 142 monitor whether the condition for changing the condition file 112 is satisfied. The simulation control unit 132 and the emulation control unit 142 suspend the cooperative operation when the change condition is satisfied, and switch between valid / invalid of the modules of the simulation circuit 131 and the emulation circuit 141 based on the setting contents of the setting file 113. At that time, the transfer unit 160 transfers the simulation result to the emulation circuit 141 and transfers the emulation result to the simulation circuit 131. Thereafter, the simulation control unit 132 and the emulation control unit 142 resume the cooperative operation.

  As shown in FIG. 11, when there is a bus access from a CPU that is a valid module of the simulation circuit 131 to a memory that is a valid module of the emulation circuit 141, the simulation bridge 133 stores the memory of the emulation circuit 141. Is valid, the transactor 150 is instructed to transfer the transaction to the emulator 140. Transactor 150 creates a transaction with bus access information and transmits it to emulator 140. The emulation bridge 143 receives the transaction transferred by the transactor 150, transmits bus access information to the emulation circuit 141, and accesses the memory.

  As shown in FIG. 12, when there is a bus access from the CPU, which is an effective module of the simulation circuit 131, to the HW, the simulation bridge 131 has the simulation circuit 131 because the HW of the simulation circuit 131 is effective. The contents of the bus access are transmitted to and the HW is accessed.

  According to the first embodiment of the present invention, when the simulator 130 and the emulator 140 perform a cooperative operation, the validity / invalidity of the module of the simulation circuit 131 and the module of the emulation circuit 141 can be dynamically changed. Cooperative verification by the circuit configuration becomes possible, and the processing speed of the cooperative verification device can be improved.

  Further, according to the first embodiment of the present invention, the validity / invalidity of the module is dynamically changed during the execution of the collaborative verification operation, so that the processing speed of the collaborative verification apparatus is improved and various modules can be debugged easily. Can be built.

It is a block diagram which shows the structure of the cooperation verification apparatus 100 which concerns on Example 1 of this invention. 1 is a block diagram illustrating configurations of a simulator 130 and an emulator 140 according to Embodiment 1 of the present invention. FIG. 5 is a schematic diagram illustrating an example of a change condition of a condition file 112. 5 is a schematic diagram illustrating an example of setting contents of a setting file 113. FIG. It is a flowchart which shows the process sequence of the cooperative verification process which concerns on Example 1 of this invention. It is a sequence diagram which shows the outline of a cooperation verification process. It is a block diagram explaining the cooperation operation | movement which concerns on Example 1 of this invention. It is a block diagram explaining the cooperation operation | movement which concerns on Example 1 of this invention. It is the schematic which shows an example of the data structure of the data transferred in module execution state transfer. It is a block diagram explaining the cooperation operation | movement which concerns on Example 1 of this invention. It is a block diagram explaining the cooperation operation | movement which concerns on Example 1 of this invention. It is a block diagram explaining the cooperation operation | movement which concerns on Example 1 of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 Cooperative verification apparatus 110 Memory | storage part 120 Processor 130 Simulator 131 Simulation circuit 132 Simulation control part 133 Simulation bridge 140 Emulator 141 Emulation circuit 142 Emulation control part 143 Emulation bridge 150 Transactor 160 Transfer part

Claims (5)

A simulation program, a simulation circuit that is a circuit to be verified, a condition file that describes conditions for changing the simulation circuit and an emulation circuit that is a circuit to be verified, and a setting file that describes changes to the simulation circuit and the emulation circuit A storage unit
A processor for realizing a simulator for simulating an effective module having all information of the circuit to be verified by activating the simulation program;
An emulator that has all the information of the circuit to be verified and emulates a valid module;
A transactor for transferring transactions between the simulator and the emulator;
A transfer unit for transferring the simulation result of the simulator to the emulator and transferring the emulation result of the emulator to the simulator based on the setting contents of the setting file when a condition for changing the condition file is satisfied; Prepared,
The simulator further includes a simulation control unit that interrupts the simulation when a condition for changing the condition file is satisfied, and instructs the change of the configuration of the simulation circuit based on the setting content of the setting file,
The emulator further includes an emulation control unit that interrupts emulation when a condition for changing the condition file is satisfied, and instructs the change of the configuration of the emulation circuit based on the setting contents of the setting file. A collaborative verification device.   The transfer unit performs module execution state transfer for transferring the simulation result or the emulation result to the emulator or the simulator based on the setting contents of the setting file when the configuration of the simulation circuit or the emulation circuit is changed. The cooperative verification apparatus according to claim 1 to be performed. The simulation control unit interrupts the simulation when the condition file change condition is satisfied during the execution of the simulation, and enables or disables each module constituting the simulation circuit based on the setting contents of the setting file. Set it to disabled,
The emulation control unit interrupts the emulation when the condition file change condition is satisfied during the execution of the emulation, and enables or disables each module constituting the emulation circuit based on the setting contents of the setting file. The cooperative verification apparatus according to claim 1, wherein the cooperation verification apparatus is set to be invalid. The simulator further includes a simulation bridge for instructing a transaction to the transactor when accessing a module of a simulation circuit invalidated by the simulation control unit during the simulation execution,
The emulator further includes an emulation bridge for instructing a transaction to the transactor when accessing a module of an emulation circuit invalidated by the emulation control unit during the execution of the emulation,
4. The cooperative verification apparatus according to claim 3, wherein the transactor transfers a transaction instructed by the simulation bridge to the emulator, and transfers a transaction instructed by the emulation bridge to the simulator. The simulation bridge instructs the transactor to transfer the transaction when the module of the simulation circuit set to be invalid by the simulation control unit corresponds to the module set to be valid by the emulation control unit,
The emulation bridge instructs the transactor to transfer the transaction when the module of the emulation circuit disabled by the emulation controller corresponds to the module enabled by the simulation controller. Item 5. The cooperative verification device according to Item 4.

Images