JP2005321848A - System simulation execution program and hardware description conversion program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable high speed simulation while coordinating a hardware simulator and a software simulator.
A debug software execution unit 103 that executes software to be debugged 102, an executable hardware description unit 104 that operates in cooperation with the debug software execution unit 103, and hardware elements that are unnecessary for simulation are specified. A hardware element deactivation designating unit 105 for outputting an instruction to partially suppress hardware simulation to the hardware description unit 104 based on the hardware element deactivation location information 106, By suppressing hardware simulation unnecessary for debugging, the execution speed of the entire co-simulation is increased.
[Selection] Figure 1

Description

  The present invention relates to a system simulation that performs simulation by coordinating hardware and software, and more particularly, to a system simulation execution program that can easily execute software debugging and a hardware description conversion program that is used in the system simulation.

  Hardware / software co-simulation is conventionally known as a simulation system that performs simulation by coordinating hardware and software. According to this, it is possible to detect hardware problems early by debugging software using virtual hardware without using actual hardware, debugging software, or the entire system. The effect of raising the quality and completeness of the product in a short time can be expected.

  Conventionally, there have been known three main methods of collaborative simulation in which simulation is performed by linking both software running on a microcomputer and hardware around the microcomputer.

  The first is a method of abstracting the movement of hardware to some extent and describing it as a part of software, creating an executable file directly linked with the software, and executing it.

  The second is a method in which an interface is provided for each of the software simulator and the hardware simulator to be linked. In other words, two large applications perform a simulation in conjunction with each other.

The third method is to integrate a software simulator and a hardware simulator as one application and provide an interface for each process to link them.
JP 2002-244883 A JP 2001-1555047 A Japanese Patent Laid-Open No. 2001-290860 JP-A-10-74214 Japanese Patent Laid-Open No. 10-91480

  In recent years, the scale of software has increased. When debugging software by simulation, the speed of execution of the simulation is very important, and how to increase the speed is a problem.

  In the case of the first method described above, in which hardware movement is abstracted to some extent and described as software, and an executable file is created after being linked with software, the execution speed as a simulator is high. However, there are problems that the man-hours for abstracting the movement of hardware are large, and that the abstraction is very different from the actual movement of hardware. However, at present, this method is most often used because the simulation speed is high.

  The second method of simulating by linking two different simulators, a software simulator and a hardware simulator, eliminates the task of hardware abstraction, so the problem with the first method is solved. The However, as the size of hardware to be simulated increases, hardware simulation becomes very slow, and it has become unable to withstand software debugging. Furthermore, in the co-simulation, the hardware simulator and the software simulator operate in parallel at the same time or frequently exchange information with each other. There was also a problem of slowing down.

  In the case of the third method, in which a software simulator and a hardware simulator are integrated into one application, and an interface is provided for each simulation execution unit, the hardware and software simulators interact with each other. Since it is performed in one application, it can be exchanged at high speed. However, there is a problem that even if the hardware simulator alone is operated, it is much slower than the actual hardware.

  An object of the present invention is to enable high-speed simulation while performing a hardware simulation and a software simulation using a hardware description at a level used in actual semiconductor device design.

  In the present invention, in order to speed up the operation of the hardware simulator, the hardware part unnecessary for software debugging is specified and simulation is suppressed only for that part, or the simulation state of the hardware or software is specified. In this state, it is possible to suppress or execute simulation of a specific part of hardware, or to describe the process of directly operating the internal node of the hardware in the description of the software to be debugged. Simulation by suppressing simulation of some hardware, or by omitting simulation of part of software processing by allowing software simulator operations to be described in the hardware description Save time, Or, it is possible to or shortening of the hardware of the simulation time the aim of abstraction of the hardware description. Further, according to the present invention, when a developer modifies a file containing a hardware description that has already been abstracted, the abstraction time is saved by reusing the result of the abstraction already made, thereby reducing the total development man-hours. You can also

  First, a system simulation execution program according to a first aspect of the present invention is a debugged software execution unit that executes software to be debugged, a hardware description that is compiled, and executes a hardware simulation based on the hardware description. In addition, the hardware description part that operates in conjunction with the debugged software execution part and the hardware element inactivation location information that specifies the hardware elements that are not required for the simulation are partially suppressed. A hardware element deactivation designation unit that outputs an instruction to be performed to the hardware description unit.

  A system simulation execution program according to a second aspect of the present invention includes a debugged software execution unit that executes software to be debugged, and hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. Hardware description execution unit and hardware that outputs an instruction to partially suppress hardware simulation to the hardware description execution unit based on hardware element deactivation location information in which hardware elements unnecessary for simulation are specified And a wear element deactivation designation unit.

  A system simulation execution program according to a third aspect of the invention includes a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description. No need to search for hardware elements that are not required for simulation based on the hardware description part that operates in conjunction with the debug software execution part, the hardware description structure information indicating the relationship between hardware elements, and the required hardware element list A hardware element search unit and a hardware element inactivation specifying unit that outputs an instruction to partially suppress hardware simulation based on the search result to the hardware description unit.

  A system simulation execution program according to a fourth aspect of the invention includes a debugged software execution unit that executes software to be debugged, and hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. A hardware description execution unit, an unnecessary hardware element search unit that searches for hardware elements unnecessary for simulation based on hardware description structure information indicating a relationship between hardware elements, and a required hardware element list, and a search result thereof And a hardware element deactivation designation unit that outputs an instruction to partially suppress hardware simulation to the hardware description execution unit.

  A system simulation execution program according to a fifth aspect of the present invention is a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description. Hardware description part that operates in cooperation with the debug software execution part, hardware element active state acquisition part for monitoring the operating state of the hardware description part and acquiring the hardware element active state, and hardware element activation An unnecessary hardware element search unit that searches for hardware elements unnecessary for simulation based on the hardware description structure information indicating the relationship between the result acquired by the state acquisition unit and the hardware elements and the required hardware element list, and Hard based on search results And a hardware elements inactivation designation unit for outputting an instruction to partially suppress the simulation E A hardware description section.

  A system simulation execution program according to a sixth aspect of the invention includes a debugged software execution unit that executes software to be debugged, and a hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. Hardware description execution unit, hardware element active state acquisition unit for monitoring the operating state of the hardware description execution unit and acquiring the hardware element active state, and the results and hardware acquired by the hardware element active state acquisition unit An unnecessary hardware element search unit that searches for hardware elements unnecessary for simulation based on hardware description structure information indicating a relationship between hardware elements and a required hardware element list, and hardware information based on the search result Partially suppressed simulation Instructing that comprises a hardware element inactivation designation unit for outputting to the hardware description executing section.

  According to the first to sixth aspects of the invention, hardware elements that are not related to software debugging are identified as hardware elements that are unnecessary for simulation, and the simulation of the hardware of the portion is suppressed to reduce the speed of the entire simulation. Can be speeded up.

  A system simulation execution program according to a seventh aspect of the invention is a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description. Hardware description part that operates in cooperation with the debug software execution part, hardware element state acquisition part for acquiring the hardware element state in the hardware description part, and results acquired by the hardware element state acquisition part Based on the simulation condition determination unit that determines whether to simulate each hardware element, and an instruction to partially suppress hardware simulation based on the determination result of the simulation condition determination unit to the hardware description unit Output And a Dowea elements inactivation specifying unit.

  A system simulation execution program according to an eighth aspect of the present invention includes a debug software execution unit that executes software to be debugged, and a hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debug software execution unit. Hardware description execution unit, hardware element state acquisition unit for acquiring the hardware element state in the hardware description execution unit, and simulation of each hardware element based on the result acquired by the hardware element state acquisition unit Hardware condition deactivation that outputs to the hardware description execution unit an instruction to partially suppress hardware simulation based on the determination result of the simulation condition determination unit Provided with designated part That.

  According to the seventh and eighth aspects of the invention, it is possible to suppress the simulation of a part of hardware according to the hardware element state and increase the speed of the entire simulation.

  A system simulation execution program according to a ninth aspect of the present invention includes a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description. Based on the results obtained by the hardware description part operating in cooperation with the debug software execution part, the software execution state acquisition part for acquiring the software execution state in the debugged software execution part, and the software execution state acquisition part And a hardware description part that instructs to partially suppress hardware simulation based on the judgment result of the simulation condition judgment part. And a hardware elements inactivation designation unit for outputting.

  A system simulation execution program according to a tenth aspect of the invention includes a debugged software execution unit that executes software to be debugged, and a hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. The hardware description execution unit, the software execution state acquisition unit for acquiring the software execution state in the debugged software execution unit, and whether to simulate each hardware element based on the results acquired by the software execution state acquisition unit Hardware condition deactivation specification that outputs to the hardware description execution unit an instruction to partially suppress hardware simulation based on the determination result of the simulation condition determination unit Provided with a door.

  According to the ninth and tenth aspects of the invention, simulation of some hardware can be suppressed according to the state of software, and the speed of the entire simulation can be increased.

  A system simulation execution program according to an eleventh aspect of the invention is a debugged software execution unit that executes debugged software, a compiled hardware description, and executes hardware simulation based on the hardware description. Whether the hardware description section that operates in conjunction with the debug software execution section and whether the debugged software execution section monitors access to the virtual memory space of the hardware description section and whether to permit the access according to the contents of the access A condition determination unit that determines whether or not and an access control unit that controls whether or not to execute access to the virtual memory space of the hardware description unit from the debugged software execution unit based on the determination result of the condition determination unit .

  A system simulation execution program according to a twelfth aspect of the invention includes a debug software execution unit that executes software to be debugged, and hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debug software execution unit. A hardware description execution unit, a condition determination unit that monitors access from the debugged software execution unit to the virtual memory space of the hardware description execution unit, and determines whether to permit the access according to the content of the access; An access control unit that controls whether or not to access the virtual memory space of the hardware description execution unit from the debugged software execution unit based on the determination result of the condition determination unit.

  According to the eleventh and twelfth inventions, the simulation can be suppressed and the speed of the entire simulation can be increased by stopping the access unnecessary for debugging in the hardware access from the software side.

  A hardware description conversion program according to a thirteenth invention includes a periodic circuit extraction unit that extracts a periodic circuit from the hardware description, and a periodic circuit parameter calculation that calculates a periodic circuit parameter from the periodic circuit extracted by the periodic circuit extraction unit. And a periodic circuit conversion unit that rewrites the periodic circuit portion in the hardware description into another process based on the periodic circuit parameter calculated by the periodic circuit parameter calculation unit.

  A system simulation execution program according to a fourteenth aspect of the invention includes a debugged software execution unit that executes software to be debugged and hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. Hardware description execution unit, a periodic circuit extraction unit for extracting a periodic circuit from the hardware description executed by the hardware description execution unit, and a cycle for calculating a periodic circuit parameter from the periodic circuit extracted by the periodic circuit extraction unit A hardware parameter execution unit that, instead of executing the periodic circuit part in the hardware description, determines the characteristics of the periodic circuit based on the periodic circuit parameter calculated by the periodic circuit parameter calculation unit. Realize.

  According to the thirteenth and fourteenth aspects, when performing hardware simulation, it is possible to increase the speed of the entire simulation by simplifying and executing the simulation description of the periodic circuit.

  A hardware description conversion program according to a fifteenth aspect of the invention is a combination circuit extraction unit that extracts a combinational circuit from the hardware description, and a combinational circuit parameter calculation that calculates combinational circuit parameters from the combinational circuit extracted by the combinational circuit extraction unit. And a combinational circuit conversion unit that rewrites the combinational circuit portion in the hardware description to another process based on the combinational circuit parameter calculated by the combinational circuit parameter calculation unit.

  According to a sixteenth aspect of the present invention, there is provided a system simulation execution program for executing a software to be debugged for executing software to be debugged; Hardware description execution unit, combinational circuit extraction unit that extracts a combinational circuit from the hardware description executed by the hardware description execution unit, and combination circuit parameter calculation from the combinational circuit extracted by the combinational circuit extraction unit A hardware parameter execution unit, wherein the hardware description execution unit calculates the characteristics of the combinational circuit based on the combinational circuit parameter calculated by the combinational circuit parameter calculation unit, instead of executing the combinational circuit part in the hardware description. Realize.

  According to the fifteenth and sixteenth aspects, when performing hardware simulation, the simulation description of the combinational circuit can be simplified and executed to increase the speed of the entire simulation.

  A system simulation execution program according to a seventeenth aspect of the invention is a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description. Whether the hardware description section that operates in conjunction with the debug software execution section and whether the debugged software execution section monitors access to the virtual memory space of the hardware description section and whether to permit the access according to the contents of the access A condition determining unit for determining whether or not an access control unit for executing access to the virtual memory space of the hardware description unit from the debugged software execution unit when the determination result of the condition determining unit permits access, and a condition determining unit Judgment result permits access And a hardware element operating portion for operating the particular hardware elements in the hardware description directly in the absence.

  A system simulation execution program according to an eighteenth aspect of the invention is a debugged software execution unit that executes software to be debugged, and hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. A hardware description execution unit, a condition determination unit that monitors access from the debugged software execution unit to the virtual memory space of the hardware description execution unit, and determines whether to permit the access according to the content of the access; An access control unit that executes access to the virtual memory space of the hardware description execution unit from the debugged software execution unit when the determination result of the condition determination unit permits access, and the determination result of the condition determination unit does not permit access In the hardware description And a hardware element operating portion for operating the hardware elements directly.

  According to the seventeenth and eighteenth aspects of the invention, when the result of determination by the condition determination unit is that access from the software side to the hardware is not permitted, instead of operating the hardware external bus signal or the like from the software side By directly manipulating elements inside the hardware circuit from the software side, it is not necessary to simulate the hardware elements that reach the circuit, and the speed of the entire simulation can be increased.

  A system simulation execution program according to a nineteenth aspect of the invention is a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description. Analysis results of the hardware description section that operates in cooperation with the debug software execution section, the hardware operation command analysis section that analyzes the hardware operation commands described in the debugged software, and the hardware operation command analysis section And a hardware element operation unit that directly operates the hardware elements in the hardware description.

  A system simulation execution program according to a twentieth aspect of the invention is a debugged software execution unit that executes software to be debugged, and hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. Hardware description execution unit, hardware operation command analysis unit that analyzes hardware operation commands described in the software to be debugged, and hardware in the hardware description based on the analysis results of the hardware operation command analysis unit A hardware element operation unit that directly operates the hardware element.

  According to the nineteenth and twentieth inventions, by directly manipulating elements in the hardware circuit from the software side, it is not necessary to simulate the hardware elements that reach it, and the speed of the entire simulation can be increased. it can.

  A system simulation execution program according to a twenty-first aspect of the invention is a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes hardware simulation based on the hardware description. A hardware description part that operates in cooperation with the debug software execution part, and a software operation command analysis part that analyzes the debug software execution part operation command described in the hardware description part and operates the debug software execution part With.

  A system simulation execution program according to a twenty-second aspect of the invention is a debugged software execution unit that executes software to be debugged, and a hardware that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit. A hardware description execution unit, and a software operation command analysis unit that analyzes a debugged software execution unit operation command described in the hardware description and operates the debugged software execution unit.

  According to the twenty-first and twenty-second aspects of the present invention, by directly operating the inside of the software simulator from the hardware side, part of the hardware element simulation and software simulation is omitted, and the speed of the entire simulation is increased. can do.

  A system simulation execution program according to a twenty-third aspect of the invention is a debugged software execution unit that executes software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description. A hardware description section that operates in cooperation with the debug software execution section, a test script execution section that executes a test script, a hardware operation command analysis section that analyzes a hardware operation command described in the test script, a hardware Based on the analysis result of the hardware operation command analysis unit, the hardware element operation unit that directly operates the hardware elements in the hardware description and the debug software execution unit operation command described in the test script are solved. And and a software operation command analyzing unit for operating the debug target software execution unit.

  A system simulation execution program according to a twenty-fourth aspect of the invention is a debugged software execution unit that executes software to be debugged, and hardware that executes hardware simulation based on hardware description and operates in cooperation with the debugged software execution unit. Based on the analysis results of the hardware description execution unit, the test script execution unit that executes the test script, the hardware operation command analysis unit that analyzes the hardware operation command described in the test script, and the hardware operation command analysis unit The hardware element operation unit that directly operates the hardware elements in the hardware description and the software that operates the debugged software execution unit by analyzing the debugged software execution unit operation commands described in the test script. And a Towea operation command analysis unit.

  According to the twenty-third and twenty-fourth aspects of the invention, when an automatic test is performed by linking a software simulator and a hardware simulator, the inside of the software simulator or the inside of the hardware simulator is directly taken from the test script. By operating, part of the hardware element simulation and software simulation can be omitted, and the speed of the entire simulation can be increased.

  A hardware description conversion program according to a twenty-fifth aspect of the invention is an existing abstraction part extraction unit that extracts a part equivalent to a part for which abstraction work has been completed in the past, and an existing abstraction part in the hardware description. A hardware description replacing unit that replaces the extracted part by the abstracting unit extracting unit with an abstracted description for which abstraction work has been completed in the past.

  A system simulation execution program according to a twenty-sixth aspect of the invention is a debugged software execution unit that executes software to be debugged, and hardware that executes hardware simulation based on hardware description and operates in cooperation with the debugged software execution unit. Hardware description execution unit, and an existing abstraction unit extraction unit that extracts from the hardware description executed by the hardware description execution unit, a part equivalent to a part for which abstraction work has been completed in the past. The description execution unit executes an abstracted description for which the abstraction work has been completed in the past, instead of executing a part equivalent to the part of the hardware description for which the abstraction work has been completed in the past.

  According to the twenty-fifth and twenty-sixth aspects, by using the result of abstraction performed in the past, it is possible to perform a simulation quickly without performing abstraction work. Moreover, the speed of the entire simulation can be increased by executing the abstracted description.

  A system simulation execution program of a twenty-seventh aspect includes a plurality of simulation execution units operating in parallel with each other, an event reservation registration unit accessed from the simulation execution unit, and an event set in the event reservation registration unit One simulation execution unit, comprising: a simulation execution instruction unit that changes the movement of the simulation according to the timing; and a simulation state restoration unit that restores the simulation state to a state at a specific point in time using the recorded simulation execution state Sets an event timing in the event reservation registration unit when an event related to another simulation execution unit is recognized.

  According to the twenty-seventh aspect, for example, when two simulation execution units operate in parallel with each other, the simulation is executed independently until the time when the events related to each other occur, If an event related to the movement of the other simulation occurs before the specified event occurrence time, by restoring the state of both simulations to the simulation state at the simulation time when the event occurred, The overhead due to frequent switching of the simulation execution unit for synchronization can be reduced, and the simulation can be speeded up.

  In recent years, the complexity and scale of the system have been remarkably increased, and the increase in software debugging and verification man-hours has come to put pressure on management. It is also becoming increasingly difficult to obtain hardware used for software debugging and verification at the necessary timing.

  According to the present invention, it is possible to simulate hardware and software in a high-speed cooperative manner, and it is possible to efficiently solve complex problems caused by the interrelationship between hardware and software before the actual hardware is completed. . This can contribute to shortening the period for new product development and reducing costs.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

(Embodiment 1)
FIG. 1 shows a system simulation execution program according to a first embodiment corresponding to the first invention. In the first embodiment, when a simulation is performed by linking a software simulator and a hardware simulator, hardware simulation that is not related to software debugging is suppressed to increase the speed of the entire simulation. . For example, when simulating a system in which software 2801 and hardware 2802 are connected as shown in FIG. 28 and modules M1 to M7 are connected in the hardware 2802 as shown in FIG. M1, M2, M3, M6, and M7 are modules that may change the value of the module, and the modules of M4 and M5 do not affect the operation of the software. Therefore, from the viewpoint of debugging software when simulating the hardware 2802, if the modules M4 and M5 which are useless are not simulated, the overall simulation execution speed is improved accordingly.

  The debug software execution unit 103 in FIG. 1 reads the debug software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the executable hardware description unit 104 operate in cooperation to enable simulation combining software and hardware. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation. The hardware element inactivation specifying unit 105 reads the hardware element inactivation location information 106 and tells the hardware description unit 104 which part of the simulation is to be suppressed. Here, the hardware element often refers to what is called a signal line or a node of a circuit, but in some cases, a module or a function is also handled as a hardware element. Here, activation means that a state of the signal line or a circuit node is changed by operation.

Next, the operation of the first embodiment will be described.
FIG. 29 is a processing flow for inactivating a hardware element in the executable hardware description unit 104. In hardware simulation, processing for setting signal values for signal lines and circuit nodes is frequently performed. In the case of a compiled executable hardware description section, a signal setting function is called to set a signal value from the hardware description. Therefore, the process of S402 is performed at the head of the function to set the signal value. To determine whether or not The inhibition signal name list 2901 is a data string set by the hardware element deactivation designation unit 105. Since the simulation is performed while responding to the signal change in the hardware simulator, the simulation can be suppressed by controlling the signal change with or without setting the signal value.

  Similarly, in some simulators, in order to realize hardware parallelism, module functions may be threaded and executed in a time-sharing manner, and it is also effective to suppress simulation for each module function. Therefore, in the parallel execution processing loop as in S404, it is determined whether or not the module is a suppression module as in S406, and if it is suppression, the simulation is suppressed by not calling the module function. The suppression module name list 2903 is a data string set by the hardware element inactivation specifying unit 105.

  FIG. 30 shows an example of the hardware element inactivation location information 106. The signal name, node name, and module function name to be deactivated are designated. In addition, the hardware element deactivation designation unit 105 can specify which process using the symbol information of the executable hardware description unit 104 in this case. In the executable hardware description unit 104, the code is compiled in advance so that the simulation can be controlled line by line.

  The hardware element inactivation location information 106 may be described by the developer as text data. However, the hardware element inactivation location may be specified through the setting GUI, and the information may be stored in binary format. .

  The hardware element inactivation specifying unit 105 sets the suppression signal name list 2901 and the suppression module name list 2903 through the API of the hardware description unit 104 that can be executed from the hardware element inactivation location information 106.

(Embodiment 2)
FIG. 2 shows a system simulation execution program according to the second embodiment corresponding to the second invention. In the second embodiment, similarly to the first embodiment, when simulating a software simulator and a hardware simulator in cooperation, the simulation speed of the entire simulation is suppressed by suppressing hardware simulation that is not related to software debugging. Is to speed up. The difference from the first embodiment is that the executable hardware description unit 104 in FIG. 1 is the hardware description execution unit 202 in FIG. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be adopted, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  By suppressing the simulation of the portion of the hardware description 201 that is not necessary for debugging the software 102 to be debugged, the simulation can be speeded up and the software can be debugged efficiently.

(Embodiment 3)
FIG. 3 shows a system simulation execution program according to the third embodiment corresponding to the third invention. In the third embodiment, when simulating a software simulator and a hardware simulator in cooperation, a hardware part not related to software debugging is automatically determined, and the simulation of that part is suppressed. The speed of the entire simulation is increased. For example, assume that a system in which software 3101 is accessing hardware 3102 as shown in FIG. 31 is simulated. Here, description will be made on the assumption that there are nodes N1 to N16 in the circuit of the hardware 3102. In addition, the output side and the input side are indicated by the directions of the arrows. It is assumed that the software 3101 performs a node setting operation on N1, and acquires the node state as data from the node N16. The node 14 is an external terminal of the LSI, and the external terminal is operated by N15. The debugging of software requires an appropriate reaction of the node N16, and the node N16 may change depending on the access to the node N1 from the software. Therefore, simulation of the path from N1 to N16 becomes important. On the other hand, the simulation of the nodes such as N6, N7, N8, N11, and N12 is not related to software debugging, and thus the simulation may be omitted.

  The debug software execution unit 103 in FIG. 3 reads the debug software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the executable hardware description unit 104 operate in cooperation to enable simulation combining software and hardware. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  The hardware description structure information 301 expresses the relationship between the hardware elements represented by the hardware description unit 104, and is obtained by parsing the source code of the hardware description unit 104, or the hardware description If there is a part for acquiring the association between hardware elements in the part 104, the information is obtained by extracting from the part.

  The indispensable hardware element list 303 is a hardware element that becomes an external interface of hardware such as the nodes N1, N16, and N14 in FIG. Marking called a directive is attached to the source code of the section 104, and it is automatically collected by a tool or the like.

  The unnecessary hardware element search unit 302 uses the hardware description structure information 301 and the essential hardware element list 303 to specify a part unnecessary for the simulation. 32 and 33 show the processing flow. FIG. 32 is a schematic flow of unnecessary hardware element search processing. First, in S501, a path and a hardware element inside a hardware circuit effective for software debugging are searched. In step S502, other hardware elements are set as elements that do not require simulation. S600 in FIG. 33 is a flow for searching for an effective path. In the essential hardware element list 303, essential input hardware elements such as nodes N1 and N14 in FIG. 31 and essential output hardware elements such as node N16 are recorded as a list. In S600, the processing is performed on the essential output hardware elements. In step S602, the essential output hardware element extracted from the essential hardware element list 303 is set as a base element, and in step S603, the input hardware element is searched. S604 is a flow for searching for an essential input hardware element from the base point element. In this flow, elements that are output with respect to the base element are traced back to search for essential input hardware elements. If the required input hardware element is found, the hardware element on the previous path is valid, and the hardware elements before that are recorded as valid elements. This information is transmitted to the hardware element deactivation designation unit 105 in FIG. 3, and the hardware element deactivation designation unit 105 suppresses the simulation through the API of the hardware description unit 104 to increase the simulation speed. . The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the first embodiment.

(Embodiment 4)
FIG. 4 shows a system simulation execution program according to the fourth embodiment corresponding to the fourth invention. In the fourth embodiment, similarly to the third embodiment, when simulating a software simulator and a hardware simulator in cooperation, a hardware portion not related to software debugging is automatically determined. The simulation of the part is suppressed and the speed of the entire simulation is increased. The difference from the third embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The software to be debugged 103 shown in FIG. 4 reads the software to be debugged 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the hardware description execution unit 202 operate in cooperation to enable simulation combining software and hardware. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  The hardware description structure information 301 expresses the relationship between the hardware elements represented by the hardware description 201 as in the third embodiment, and is obtained by parsing the source code of the hardware description 201. Or, if there is a part that acquires the relationship between hardware elements in the hardware description 201, the information is obtained by extracting from there.

  The unnecessary hardware element search unit 302 specifies a part unnecessary for the simulation using the hardware description structure information 301 and the essential hardware element list 303 as in the third embodiment. This information is transmitted to the hardware element deactivation designation unit 105, and the hardware element deactivation designation unit 105 suppresses the simulation through the API of the hardware description execution unit 202, thereby increasing the simulation speed. The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the second embodiment.

(Embodiment 5)
FIG. 5 shows a system simulation execution program according to the fifth embodiment corresponding to the fifth invention. In the fifth embodiment, similarly to the third embodiment, when simulating a software simulator and a hardware simulator in cooperation, a hardware portion not related to software debugging is automatically determined. The simulation of the part is suppressed and the speed of the entire simulation is increased. The difference from the third embodiment is that the hardware simulation is performed once, and from the record of the active state of the hardware elements at that time, more elements that are truly unnecessary for the software debugging are found than the third embodiment, and the simulation is further performed. The speed is increased.

  For example, assume that a system in which software 3401 is accessing hardware 3402 as shown in FIG. 34 is simulated. Here, description will be made on the assumption that there are nodes N1 to N16 in the circuit of the hardware 3402. Further, the output side and the input side are indicated by the directions of the arrows. The software 3401 performs a node setting operation on N1, and acquires the node state as data from the node N16. The node 14 is an external terminal of the LSI, and the external terminal is operated by N15. The debugging of the software requires an appropriate reaction of the node N16, and the node N16 may change depending on the access to the node N1 from the software. Therefore, simulation of the path from N1 to N16 becomes important. On the other hand, since the simulation of the nodes such as N6 and N12 is not related to software debugging, the simulation may be omitted. In the third embodiment, since N10 is also a node outputting to N16, it is determined as a necessary hardware element. However, if N10 has never changed due to some factor in the past simulation process Therefore, it can be determined that the simulation of the N9 node connected thereto is also unnecessary for software debugging. In this way, it is possible to increase the simulation speed by performing a simulation once, finding more unnecessary hardware elements than the third embodiment from the results, and suppressing them in the next simulation.

  The debug software execution unit 103 in FIG. 5 reads the debug software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the executable hardware description unit 104 operate in cooperation to enable simulation combining software and hardware. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  The hardware element activation state acquisition unit 501 records the hardware element activation state in the hardware element activation history record 502 in response to the state setting call from the hardware description unit 104. Here, the activation means that the state of the signal line or the circuit node is changed and the state thereof changes, and the active state means the state where they have changed. FIG. 35 shows a part for calling the hardware element active state acquisition unit 501 in the hardware description unit 104. Since the hardware description unit 104 simulates hardware, a value is set for a signal line in the circuit, or a module function is called to make the circuit appear to operate in parallel. . The hardware element active state acquisition unit 501 is called in S702 and S705 immediately after these processes S701 and S704. FIG. 36 shows the processing flow of the hardware element activation state setting process of the hardware element activation state acquisition unit 501. Since the hardware element activation history record 502 records whether or not each hardware element in the hardware description unit 104 has been operated even once, the hardware element activation state acquisition unit 501 performs the determination, The state is recorded in the hardware element activation history record 502 only at the first operation. FIG. 37 shows an example of the hardware element activation history record 502. This is for the case of C language union type data. One data includes an activation data type and an activation data name, and the format of the activation data name changes according to the contents of the activation data type. Actually, in order to improve the searchability of data, the way of holding data becomes more complicated, such as using a hash table.

  The hardware description structure information 301 represents the relationship between the hardware elements represented by the hardware description unit 104 as in the third embodiment, and the source code of the hardware description unit 104 is parsed. Or information obtained by extracting from the hardware description part 104 if there is a part that acquires the relationship between hardware elements.

  The essential hardware element list 303 is a hardware element that is an external interface of hardware such as the nodes N1, N16, and N14 in FIG. Alternatively, markings called directives are attached to the source code of the hardware description unit 104, and these are automatically collected by a tool or the like.

  The unnecessary hardware element search unit 503 uses the hardware description structure information 301 and the essential hardware element list 303 to specify a part unnecessary for the simulation. Although the flow is the same as that of the unnecessary hardware element search unit 302 of the third embodiment, the flow for searching for the essential input hardware element from the base point element to reflect the hardware element activation history record 502 is slightly changed. Yes. FIG. 38 shows the flow. In the case of a hardware element without a record activated by the processing of S906, the next connection is searched.

  Information of the searched unnecessary hardware element is transmitted to the hardware element deactivation designation unit 105 in FIG. 5, and the hardware element deactivation designation unit 105 suppresses the simulation through the API of the hardware description unit 104, Increase the simulation speed. The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the first embodiment.

(Embodiment 6)
FIG. 6 shows a system simulation execution program according to the sixth embodiment corresponding to the sixth invention. In the sixth embodiment, similarly to the fifth embodiment, when simulating a software simulator and a hardware simulator in cooperation with each other, a hardware part that is not related to software debugging is automatically determined. The simulation of the part is suppressed and the speed of the entire simulation is increased. The difference from the fifth embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The debugged software execution unit 103 in FIG. 6 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the hardware description execution unit 202 operate in cooperation to enable simulation combining software and hardware. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  Furthermore, since the hardware description execution unit 202 simulates hardware, values are set for signal lines in the circuit as in the hardware description unit 104 of the fifth embodiment as shown in FIG. Or call a module function to make the circuit seem to operate in parallel. The hardware element active state acquisition unit 501 is called in S702 and S705 immediately after these processes S701 and S704. In response to the state setting call from the hardware description execution unit 202, the hardware element activation state acquisition unit 501 records the hardware element activation state in the hardware element activation history record 502 as in the fifth embodiment.

  The hardware description structure information 301 expresses the relationship between the hardware elements represented by the hardware description 201 as in the fifth embodiment, and is obtained by parsing the source code of the hardware description 201. Or, if there is a part that acquires the relationship between hardware elements in the hardware description 201, the information is obtained by extracting from there.

  The unnecessary hardware element search unit 503 specifies a part unnecessary for the simulation by using the hardware element activation history recording unit 502, the hardware description structure information 301, and the essential hardware element list 303 as in the fifth embodiment. . This information is transmitted to the hardware element deactivation designation unit 105, and the hardware element deactivation designation unit 105 suppresses the simulation through the API of the hardware description execution unit 202, thereby increasing the simulation speed. The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the second embodiment.

(Embodiment 7)
FIG. 7 shows a system simulation execution program according to the seventh embodiment corresponding to the seventh invention. In the seventh embodiment, when a simulation is performed by linking a software simulator and a hardware simulator, a part of the simulation in the hardware description is suppressed according to the state of the hardware, and the speed of the entire simulation is increased. It is to become. For example, when the valid flag of a certain function indicates OFF, the simulation of the entire function related thereto is stopped.

  The debug software execution unit 103 in FIG. 7 reads the debug software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the executable hardware description unit 104 operate in cooperation to enable simulation combining software and hardware. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  Since the simulation condition determination is performed at the change timing of the hardware element, the hardware description unit 104 uses the API of the hardware element state acquisition unit 701 when operating a signal or calling a module function as shown in FIG. call. The hardware element state acquisition unit 701 calls the simulation condition determination unit 702 in response to a state setting call from the hardware description unit 104 and acquires information necessary for condition determination from the hardware description unit 104. Conditions used for simulation condition determination are prepared in the simulation condition recording unit 703. FIG. 40 shows an example of the simulation condition recording unit 703. When the simulation condition recording unit 703 is recorded in a form that can be understood by humans, the signal name and the node name may be described by alphanumeric characters such as symbols. The description symbol information 704 is used to solve which part of the actual circuit.

  The simulation condition determination unit 702 called by the hardware element state acquisition unit 701 determines whether the conditions of the simulation condition recording unit 703 are satisfied, and suppresses the simulation in the hardware element or cancels the suppression. The information is transmitted to the hardware element deactivation designation unit 105. The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the first embodiment.

  The seventh embodiment will be described in more detail. The condition type data recorded in the simulation condition recording unit 703 in FIG. 40 indicates the type of data stored in the next condition data. For example, if the condition type is “signal state”, it indicates that “signal name + comparison value” is stored in the condition data. “Signal name + comparison value” is “Signal A”, “1”, and so on. If the condition type is “signal change”, it indicates that “signal name + change type” is stored. “Signal name + change type” is “SignalB”, “0”, etc. In this case, the number 0 indicates a change from high level to low level, and if the number is 1, the change from low level to high level Indicates. Similarly, the inactivation element type indicates the type of the next inactivation element name. If the inactivation element type is “signal”, the signal name is stored in the inactivation element name. If the inactivation element type is “module function”, the module function name is stored. Such data retention is realized by a union which is one of the functions of the programming language.

  Next, the determination method will be described. For example, the condition type data is “signal state”, the condition data is “Signal A”, “1”, the inactivation element type data is “signal name”, and the inactivation element name is “ If SignalB ″ is stored, the hardware element state acquisition unit 701 acquires the state of SignalA and designates the hardware element inactivation so as to suppress the simulation of SignalB during the period when it is “1”. Call the unit 105. More specifically, the hardware element state acquisition unit 701 acquires in advance what kind of conditions to determine, and if there is a change in, for example, “Signal A”, the simulation condition determination unit 702 is determined. Call with signal name and status. Incidentally, the processing time can be shortened by calling using an ID given in advance instead of the signal name. The called simulation condition determination unit 702 determines whether or not the specified condition is satisfied by comparing with the contents of the simulation condition recording unit 703. If it is determined that the specified condition is met, the hardware condition is not detected. For example, the activation designation unit 105 is instructed to stop the simulation of the signal “SignalB”.

(Embodiment 8)
FIG. 8 shows a system simulation execution program according to the eighth embodiment corresponding to the eighth invention. As in the seventh embodiment, the eighth embodiment suppresses a part of the simulation in the hardware description according to the state of the hardware when simulating the software simulator and the hardware simulator in cooperation with each other. This speeds up the overall simulation speed. The difference from the seventh embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The debugged software execution unit 103 in FIG. 8 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the hardware description execution unit 202 operate in cooperation to enable simulation combining software and hardware. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  Since the simulation condition determination is performed at the change timing of the hardware element, the hardware description execution unit 202 performs the API of the hardware element state acquisition unit 701 when operating a signal or calling a module function as shown in FIG. Call. The hardware element state acquisition unit 701 calls the simulation condition determination unit 702 in response to a state setting call from the hardware description unit 104 and acquires information necessary for condition determination from the hardware description execution unit 202. Conditions used for simulation condition determination are prepared in the simulation condition recording unit 703. FIG. 40 shows an example of the simulation condition recording unit 703. When the simulation condition recording unit 703 is recorded in a form that can be understood by humans, the signal name and the node name may be described by alphanumeric characters such as symbols. Necessary information is acquired from the description execution unit 202 or the like, and a solution to which part of the actual circuit is obtained is attempted.

  The simulation condition determination unit 702 called by the hardware element state acquisition unit 701 determines whether the conditions of the simulation condition recording unit 703 are satisfied, and suppresses the simulation in the hardware element or cancels the suppression. The information is transmitted to the hardware element deactivation designation unit 105. The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the second embodiment.

(Embodiment 9)
FIG. 9 shows a system simulation execution program according to the ninth embodiment corresponding to the ninth invention. In the ninth embodiment, when simulating a software simulator and a hardware simulator in cooperation, some simulations in the hardware description are suppressed according to the state of the software to increase the speed of the entire simulation. To do. For example, if a variable handled in the debugged software has a value within a specified range, the simulation of a part of the specified hardware is stopped. As a result, only hardware elements necessary for software debugging can be simulated, the simulation speed can be improved, and debugging efficiency can be increased.

  The debugged software execution unit 103 in FIG. 9 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the executable hardware description unit 104 operate in cooperation to enable simulation combining software and hardware. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  The debugged software execution unit 103 calls the software execution state acquisition unit 901 at the timing of virtual microcomputer memory access or register access. The software execution state acquisition unit 901 acquires data required by the simulation condition determination unit 902 from the debugged software execution unit 103. When the simulation condition recording unit 703 is recorded in a form that can be understood by humans, a variable name or the like may be expressed by an alphanumeric character such as a symbol. Necessary information such as information about symbols is obtained from 103 and the like, and a solution to which variable in the software is pointed out is attempted.

  The simulation condition determination unit 902 called by the software execution state acquisition unit 901 determines whether the conditions of the simulation condition recording unit 703 are satisfied, and suppresses the simulation or cancels the suppression among the hardware elements. Is transmitted to the hardware element deactivation designation unit 105. The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the first embodiment.

  The ninth embodiment will be described in more detail. The inside of the simulation condition recording unit 703 is almost the same as that of the seventh embodiment. However, different from the example of FIG. 40, the condition type data “signal state”, “signal change”, and “module execution” “Signal name + comparison value”, “Signal name + change type” and “module name” of data disappear, and instead, for example, “variable status”, “data access”, “function call” as condition type data, As condition data, “variable name + comparison value”, “start address + end address”, “function name”, and the like are added.

  If the condition type is “variable state”, the software execution state acquisition unit 901 resolves the storage location of the variable and the size of the variable with debug information, and the debugged software execution unit 103 accesses the address. The acquired data contents are acquired and passed to the simulation condition judgment unit 902 together with the variable name. If the condition type is “function name”, the function name accessed when the debugged software execution unit 103 accesses the function is passed to the simulation condition determination unit 902. Note that the processing speed can be improved by exchanging with a predetermined ID instead of exchanging function names. The simulation condition determination unit 902 performs determination based on the received information and the contents of the simulation condition recording unit 703, and uses the deactivation element type and deactivation element name to the hardware element deactivation designation unit 105. Pass the information of the part you want to deactivate.

(Embodiment 10)
FIG. 10 shows a system simulation execution program according to the tenth embodiment corresponding to the tenth invention. In the tenth embodiment, similar to the ninth embodiment, when a simulation is performed by linking a software simulator and a hardware simulator, simulation is performed by suppressing a part of the simulation in the hardware description according to the state of the software. The overall speed is increased. The difference from the ninth embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The debugged software execution unit 103 in FIG. 10 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The debugged software execution unit 103 and the hardware description execution unit 202 operate in cooperation to enable simulation combining software and hardware. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  The debugged software execution unit 103 calls the software execution state acquisition unit 901 at the timing of virtual microcomputer memory access or register access. The software execution state acquisition unit 901 acquires data required by the simulation condition determination unit 902 from the debugged software execution unit 103. When the simulation condition recording unit 703 is recorded in a form that can be understood by humans, since the variable or the like may be expressed by alphanumeric characters such as symbols, the software execution state acquisition unit 901 includes the debugged software execution unit 103. The necessary information such as the symbol information is obtained from the software, etc., and the software is pointed out.

  The simulation condition determination unit 902 called by the software execution state acquisition unit 901 determines whether the conditions of the simulation condition recording unit 703 are satisfied, and suppresses the simulation or cancels the suppression among the hardware elements. Is transmitted to the hardware element deactivation designation unit 105. The hardware element deactivation designation unit 105 is the same as the hardware element deactivation designation unit 105 of the second embodiment.

(Embodiment 11)
FIG. 11 shows a system simulation execution program according to the eleventh embodiment corresponding to the eleventh invention. In the eleventh embodiment, when simulating by linking a software simulator and a hardware simulator, the simulation is suppressed by stopping access unnecessary for debugging during access to the hardware from the software side. It is intended to increase the overall speed and increase the efficiency of software debugging.

  The debugged software execution unit 103 in FIG. 11 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  The debugged software execution unit 103 calls the condition determination unit 1102 when operating a register in the hardware. The condition determination unit 1102 obtains conditions for permitting or denying access from the access control address recording unit 1103, and performs determination according to the flow as shown in FIG. FIG. 41 shows an example of data in the access control address recording unit 1103. When the access control address recording unit 1103 is recorded in a form that can be understood by humans, an address value or the like may be expressed by an alphanumeric character such as a symbol. Necessary information such as information on the symbol is acquired and a numerical value of the symbol is specifically solved. When access permission is determined by the condition determination unit 1102, the access control unit 1101 accesses the hardware by operating the address bus signal, data bus signal, etc. of the hardware description unit 104 that can be executed in the flow as shown in FIG. To do.

  I will explain a little more in detail. For example, assuming that the access control address recording unit 1103 describes address 100 as start address data, address 200 as end address data, write as an access type, and non-permission as a control method. When the unit 103 tries to access the hardware description unit 104, for example, when writing data at address 110, the address is transmitted to the condition determining unit 1102, and the condition determining unit 1102 receives the access control address recording unit 1103. It is judged whether the condition is satisfied in light of the contents of. In the above example, since the condition is satisfied, the condition determination unit 1102 notifies the access control unit 1101 of the disapproval, and the access control unit 1101 receives this and ignores the access to the address 110, and sends it to the hardware description unit 104. Do not access.

(Embodiment 12)
FIG. 12 shows a system simulation execution program according to the twelfth embodiment corresponding to the twelfth invention. In the twelfth embodiment, as in the eleventh embodiment, when simulating a software simulator and a hardware simulator in cooperation, access unnecessary for debugging in the access to the hardware from the software side is stopped. Therefore, the simulation is suppressed to increase the speed of the entire simulation and to improve the efficiency of software debugging. The difference from the eleventh embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The debugged software execution unit 103 in FIG. 12 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. Similarly, the hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is first converted into an intermediate language and then the intermediate language is executed. However, a just-in-time compiler method that partially compiles at the time of execution may be adopted, or hardware description contents may be converted into data that can be easily executed by the simulator and executed while referring to the data. .

  The debugged software execution unit 103 calls the condition determination unit 1102 when operating a register in the hardware. The condition determination unit 1102 obtains conditions for permitting or denying access from the access control address recording unit 1103, and performs determination according to the flow as shown in FIG. FIG. 41 shows an example of data in the access control address recording unit 1103. When the access control address recording unit 1103 is recorded in a form that can be understood by humans, an address value or the like may be expressed by an alphanumeric character such as a symbol. The necessary information such as information on the symbol is obtained from the above, and the numerical value of the symbol is specifically solved. When access permission is determined by the condition determination unit 1102, the access control unit 1101 operates the address bus signal, data bus signal, and the like of the hardware description execution unit 202 that can be executed according to the flow shown in FIG. to access.

(Embodiment 13)
FIG. 13 shows a hardware description conversion program according to a thirteenth embodiment corresponding to the thirteenth invention. In the thirteenth embodiment, when a hardware simulation is performed, the simulation description of a periodic circuit is simplified to increase the speed of the entire simulation. By simulating in conjunction with software simulation, software can be debugged efficiently using a simulator.

  For example, assume that there is a counter circuit described in Verilog HDL such as P300 in FIG. This circuit is an 8-bit period counter, and “repeat # signal” becomes 1 only when the counter value reaches 100. In such a description, every time the clock rises, the module starting from the L08 line is evaluated, and the counter value is incremented by one, which makes a very time-consuming simulation. Therefore, in consideration of the premise that the clock cycle is fixed, rewriting is performed like P301 so that “repeat # signal” periodically changes. In the case of this description, the circuit description is evaluated only by the signal change, and the counter is not counted up, so that high-speed simulation is possible.

  The hardware description 1301 in FIG. 13 is the original description, and a hardware description 1306 capable of high-speed simulation is generated through the hardware description conversion program 1302. The hardware description conversion program 1302 includes a periodic circuit extraction unit 1303 that extracts a periodic circuit in the hardware description 1301, and a periodic circuit parameter calculation unit 1304 that calculates a period time of the periodic circuit after extracting the periodic circuit. is there. After these processes, the contents of the hardware description 1301 are modified by the periodic circuit conversion unit 1305 to create a hardware description 1306.

  FIG. 45 shows counter circuit search processing in the periodic circuit extraction unit 1303. In the case of a counter, since there is a place to be added to a circuit element, a module including it is searched. If a module including a counter can be found, the counter circuit generally includes an initialization process such as clearing, so that process is also extracted. Also, the counter clock signal name is extracted in order to calculate the counter cycle later. If there is a function for turning the counter operation ON or OFF, the conditional expression is also extracted.

  FIG. 46 shows a flow of periodic signal search processing in the periodic circuit extraction unit 1303. In general, a signal that performs a periodic operation is often described so as to react with a constant value of the counter value. Therefore, a portion that is compared with the counter value is extracted.

  FIG. 47 shows a flow of the periodic circuit parameter calculation unit 1304. The counter period is obtained from the counter clock period and the counter bit width. The period of the periodic signal is obtained from the comparison value of the counter value.

  FIG. 48 shows a flow of periodic circuit conversion processing of the periodic circuit conversion unit 1305. First, the expression and module of the counter circuit in the hardware description 1301 are deleted, and further, the expression making the periodic signal is also deleted. After that, an alternative expression and a module containing it are created and inserted so that a periodic signal with the same specifications as the original circuit description is obtained.

(Embodiment 14)
FIG. 14 shows a system simulation execution program according to the fourteenth embodiment corresponding to the fourteenth invention. In the fourteenth embodiment, as in the thirteenth embodiment, when the hardware simulation is performed, the simulation description of the periodic circuit is simplified to increase the speed of the entire simulation. The difference from the thirteenth embodiment is that the hardware description execution unit directly executes the code described in hardware, instead of compiling after converting the hardware description at high speed at the source code level. Furthermore, instead of executing the hardware according to the hardware description, only the operation satisfying the specification of the periodic signal generated using the periodic circuit is performed instead of executing the periodic circuit to be speeded up.

  The periodic circuit extraction unit 1401 and the periodic circuit parameter calculation unit 1402 in FIG. 14 are the same as those in the thirteenth embodiment. Information obtained by these is transferred to the hardware description execution unit 1303. The hardware description execution unit 1303 analyzes and executes the hardware description 201. However, when trying to execute the extracted periodic circuit, the execution of the description is stopped and a change of the periodic signal is caused instead. Like that. Generally, a hardware description execution unit has a mechanism for registering a change in a signal that will occur in the future as an event reservation, and this is used to realize the movement of a periodic signal. Accordingly, the same effect can be obtained by a simple simulation process without simulating the counter circuit with the original description, and the simulation speed can be increased.

(Embodiment 15)
FIG. 15 shows a hardware description conversion program according to a fifteenth embodiment corresponding to the fifteenth invention. The fifteenth embodiment is intended to increase the speed of the entire simulation by simplifying the simulation description of the combinational circuit when performing a hardware simulation. By simulating in conjunction with software simulation, software can be debugged efficiently using a simulator.

  For example, assume that there is a combinational circuit described in Verilog HDL such as P400 in FIG. This circuit performs arithmetic processing on three input signals, but each processing has a slightly different delay time, so the output waveform may change in complex ways depending on changes in the input signal. is there. In addition, when a circuit including a large amount of delay time is simulated in this way, many fine signal changes occur and the simulation takes a very long time. On the other hand, when simulating hardware for software debugging, strict signal changes are often not required. Therefore, rewriting as in P401 can omit the simulation of the intermediate signal leading to the output signal, and the simulation can be speeded up. In this example, the longest time that the change of the input signal is transmitted to the output is related to the input signal “in # C”, so the output signal “out # X” changes with a delay time of 40 + 50 + 30 = 120.

  The hardware description 1301 in FIG. 15 is the original description, and a modified hardware description 1306 that can be simulated at high speed is generated via the hardware description conversion program 1302. The hardware description conversion program 1302 includes a combinational circuit extraction unit 1501 that extracts a combinational circuit in the hardware description 1301, and a combinational circuit parameter calculation unit 1502 that calculates a delay time of the combinational circuit after extracting the combinational circuit. is there. After these processes, the combinational circuit converter 1503 modifies the contents of the hardware description 1301 to create a hardware description 1306.

  FIG. 50 shows a combinational circuit search flow in the combinational circuit extraction unit 1501. Search all modules and extract assignment statements.

  FIG. 51 shows a flow of combination circuit parameter calculation processing in the combination circuit parameter calculation unit 1502. The assignment statement obtained by the combinational circuit extraction unit 1501 is expanded on the right side while paying attention to the scope. Process while finding the maximum delay time during deployment. Record the maximum delay of assignment statements at the end of expansion.

  FIG. 52 shows a flow of combinational circuit conversion processing of the combinational circuit conversion unit 1503. First, the assignment statement of the combinational circuit in the hardware description 1301 is deleted. After that, an expanded assignment statement with a delay time is inserted.

(Embodiment 16)
FIG. 16 shows a system simulation execution program according to the sixteenth embodiment corresponding to the sixteenth invention. In the sixteenth embodiment, as in the fifteenth embodiment, when the hardware simulation is performed, the simulation description of the combinational circuit is simplified to increase the speed of the entire simulation. The difference from the fifteenth embodiment is that the hardware description execution unit directly executes the code described in hardware, instead of compiling after converting the hardware description at high speed at the source code level. Furthermore, a simplified combinational circuit is executed instead of the hardware description.

  The combinational circuit extraction unit 1501 and combinational circuit parameter calculation unit 1502 in FIG. 16 are the same as those in the fifteenth embodiment. Information obtained by these is transferred to the hardware description execution unit 1603. The hardware description executing unit 1603 executes the analysis after analyzing the hardware description 201. When attempting to execute the extracted combinational circuit, the hardware description execution unit 1603 stops executing the description and instead uses a simplified combinational circuit. Make it run. In general, the hardware description execution unit has a mechanism for registering a change in a signal that will occur in the future as an event reservation, and the motion of the signal substituted by the combinational circuit is realized using this mechanism. As a result, almost the same effect can be obtained by a simple simulation process without performing the simulation with the original description, and the simulation speed can be increased.

(Embodiment 17)
FIG. 17 shows a system simulation execution program according to the seventeenth embodiment corresponding to the seventeenth invention. In the seventeenth embodiment, when simulating a software simulator and a hardware simulator in cooperation, elements in the hardware circuit are directly connected from the software side instead of operating the external bus signal of the hardware from the software side. By manipulating it, the simulation of the hardware elements that reach it is made unnecessary, thereby increasing the speed of the entire simulation and increasing the efficiency of software debugging.

  The debug software execution unit 103 in FIG. 17 reads the debug software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  The debugged software execution unit 103 calls the condition determination unit 1102 when operating a register in the hardware. The condition determination unit 1102 acquires conditions for permitting or disabling access to the hardware bus from the hardware element operation information recording unit 1701, and performs determination according to the flow shown in FIG. FIG. 54 shows an example of data stored in the hardware element operation information recording unit 1701, which includes bus access conditions used for determination, information on hardware element operations performed instead of hardware bus access, and the like. It is. When the data content of the hardware element operation information recording unit 1701 is recorded in a form that can be understood by humans, the address value may be expressed by an alphanumeric character such as a symbol. Necessary information such as information related to symbols is acquired from the execution unit 103 or the symbol information 1703 of the software to be debugged, and so on, to solve the specific value of the symbol. When access permission is determined by the condition determination unit 1102, the access control unit 1101 accesses the hardware by operating the address bus signal and data bus signal of the hardware description unit 104 that can be executed in the flow as shown in FIG. To do. On the other hand, when access denial is determined by the condition determination unit 1102, the hardware element operation unit 1702 replaces the hardware bus access with the hardware element operation unit 1702 as shown in FIG. Operate directly using the flow. Which element is to be operated is written in the hardware element operation information recording unit 1701, but when the data content is recorded in a form that can be understood by humans, the signal name and node name are alphanumeric characters such as symbols. The hardware element operation unit 1702 obtains necessary information such as information related to the symbol from the hardware description symbol information 704 obtained when the hardware description 107 is compiled, and the symbol is displayed. Try to solve which part of the circuit.

  I will explain a little more in detail. For example, the hardware element operation information recording unit 1701 is set with address 200 as start address data, write as access type data, Hardware.v as the file name of the node to be operated, and module1.register1 as the node name of the node to be operated If the debugged software execution unit 103 accesses the address 200 to the hardware description unit 104, the condition determination unit 1102 detects it and does not permit the access control unit 1101 to access. To be notified. Further, the data to be written to the hardware element operation unit 1702 at address 200 is set in module1.register1. If the actual hardware description is simulated as it is, many nodes must operate until the data is set in the module1.register1 node from the software side, which requires simulation time. In this method, module1.register1 is directly used. Can be skipped, and the speed is increased accordingly. The hardware element operation information recording unit 1701 is based on the premise that the access size from the software execution unit 103 is the same as the node size, but the association between the access data bit from the software execution unit 103 and the hardware node. The range of use will be widened.

  Also, FIG. 56 showing the operation of the hardware element operation unit 1702 shows a flow when the access type of the hardware element operation information recording unit 1701 is write, and when reading, “hardware” is used instead of the contents of S2202. The value of the specified hardware element is acquired by calling the API of the hardware description part ”. The “specified value” described in S2202 when the access type is write is data received from the debugged software execution unit 103 by the condition determination unit 1102, and the hardware element operation information recording unit in FIG. The data received from the debugged software execution unit 103 is set at “node name of the node to be operated” shown in 1701. When the access type is read, the node state is acquired from the “node name of the node to be operated” indicated in the hardware element operation information recording unit 1701, and the state is read as read data to the debugged software execution unit 103. return.

(Embodiment 18)
FIG. 18 shows a system simulation execution program according to the eighteenth embodiment corresponding to the eighteenth invention. In the eighteenth embodiment, as in the seventeenth embodiment, instead of operating a hardware external bus signal or the like from the software side, a hardware element reaching the hardware circuit directly by directly operating an element in the hardware circuit from the software side This eliminates the need for simulation, thereby increasing the speed of the entire simulation and improving the efficiency of software debugging. The difference from the seventeenth embodiment is that the hardware description execution unit executes the code described in the hardware as in the second embodiment.

  The debugged software execution unit 103 in FIG. 18 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  The debugged software execution unit 103 calls the condition determination unit 1102 when operating a register in the hardware. The condition determination unit 1102 acquires a condition for permitting or disabling access to the hardware bus from the hardware element operation information recording unit 1701 and performs determination. When the data contents of the hardware element operation information recording unit 1801 are recorded in a form that can be understood by humans, the condition determination unit 1102 relates to symbols from the debugged software execution unit 103 or the symbol information 1703 of the debugged software. Acquire necessary information such as information and try to solve it. When access permission is determined by the condition determination unit 1102, the access control unit 1101 operates the address bus signal or data bus signal of the hardware description execution unit 202 to access the hardware. On the other hand, when access permission is determined by the condition determination unit 1102, the hardware element operation unit 1802 directly operates the hardware element in the hardware description execution unit 202 instead of accessing the hardware bus. Which element is to be operated is written in the hardware element operation information recording unit 1801, but when the data content is recorded in a form that can be understood by humans, the hardware element operation unit 1802 has a hardware description. Necessary information such as information related to symbols is acquired from the execution unit 202 or the like to solve the problem.

(Embodiment 19)
FIG. 19 shows a system simulation execution program according to the nineteenth embodiment corresponding to the nineteenth invention. In the nineteenth embodiment, when simulating a software simulator and a hardware simulator in cooperation, it is not necessary to directly simulate the elements inside the hardware circuit from the software side, thereby making it unnecessary to simulate the hardware elements that reach it. Thus, the speed of the entire simulation is increased to increase the efficiency of software debugging. For example, as shown in FIG. 57, in the actual source code, the memory space of the microcomputer is directly accessed as in the line L09, but when debugging in simulation, the internal signal of the hardware simulator is used as in the line L07. Set the value directly. When directly accessing the memory space of a microcomputer during simulation, even if only a part of the hardware circuit is accessed, many hardware elements connected to the data bus of the microcomputer are simulated. Time is wasted. Therefore, by directly manipulating the inside of the hardware as shown in FIG. 57, the useless simulation is not performed and the simulation can be speeded up. Further, according to the present invention, hardware operation processing can be easily described in software source code.

  The debugged software execution unit 103 in FIG. 19 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  The flow of software execution processing in the debugged software execution unit 103 is as shown in FIG. Normally, instructions are executed one after another as in S2306. However, if there is a function call instruction, it is determined whether the function call is a function for hardware operation, and if it is a function for hardware operation. For example, the contents of the argument added at the time of the function call are acquired, and the hardware operation command analysis unit 1901 in FIG. 19 is called.

  The hardware operation command analysis unit 1901 performs processing according to the flow shown in FIG. First, from the character string of the hardware operation command obtained by the debugged software execution unit 103, the command type and the parameter of the command are decomposed and obtained. Next, the hardware operation command analysis unit 1901 calls the hardware element operation unit 1702 according to the analyzed command, and the hardware element operation unit 1702 directly operates the hardware element in the hardware description unit 104. The element to be operated is written in the command parameter analyzed by the hardware operation command analysis unit 1901. If the data content is recorded in a form that can be understood by humans, the signal name, node name, etc. The hardware element operation unit 1702 obtains necessary information such as information related to symbols from the hardware description symbol information 704 obtained when the hardware description unit 104 is compiled. To determine which part of the circuit the symbol points to.

(Embodiment 20)
FIG. 20 shows a system simulation execution program according to the twentieth embodiment corresponding to the twentieth invention. In the twentieth embodiment, similar to the nineteenth embodiment, when simulating a software simulator and a hardware simulator in cooperation with each other, the hardware reaching to the hardware circuit is directly operated from the software side. This eliminates the need for hardware element simulation, thereby speeding up the overall simulation and increasing the efficiency of software debugging. The difference from the nineteenth embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The debugged software execution unit 103 in FIG. 20 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  The flow of software execution processing in the debugged software execution unit 103 is as shown in FIG. Normally, instructions are executed one after another as in S2306. However, if there is a function call instruction, it is determined whether the function call is a function for hardware operation, and if it is a function for hardware operation. For example, an argument added at the time of the function call is acquired, and the hardware operation command analysis unit 1901 in FIG. 20 is called.

  The hardware operation command analysis unit 1901 performs processing according to the flow shown in FIG. First, from the character string of the hardware operation command obtained by the debugged software execution unit 103, the command type and the parameter of the command are decomposed and obtained. Next, the hardware operation command analysis unit 1901 calls the hardware element operation unit 1802 according to the analyzed command, and the hardware element operation unit 1802 directly operates the hardware element in the hardware description unit 104. Which element is operated is written in the command parameter analyzed by the hardware operation command analysis unit 1901. If the data contents are recorded in a form that can be understood by humans, the signal name and node name are The hardware element operation unit 1802 obtains necessary information such as information on the symbol from the hardware description execution unit 202 or the like, and resolves which part of the circuit the symbol indicates. Plan.

(Embodiment 21)
FIG. 21 shows a system simulation execution program according to the twenty-first embodiment corresponding to the twenty-first invention. In the twenty-first embodiment, when simulating a software simulator and a hardware simulator in cooperation, a hardware element simulation or a part of software simulation is performed by directly operating the inside of the software simulator from the hardware side. This is intended to increase the speed of the entire simulation and increase the efficiency of software debugging. For example, if there is a process that generates an interrupt from the hardware simulator side to the software side, the software side performs an interrupt process, and sets the variable contents, the final purpose is to set the variable contents. If software variables can be set in the hardware description, it is possible to omit simulation of intermediate processing. FIG. 60 shows a description example using Verilog HDL, and the L14th line is a part for operating a software simulator. According to the present invention, the operation command of the software simulator can be easily described in the hardware description, and the software can be debugged efficiently.

  The debugged software execution unit 103 in FIG. 21 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  When a function that performs software operation is called in the executable hardware description unit 104, the software operation command analysis unit 2101 is called with the parameters. As shown in the flow of FIG. 61, the software operation command analysis unit 2101 analyzes the command character string, extracts the command type and parameters, and calls the debugged software execution unit 103. When command parameters extracted by the software operation command analysis unit 2101 are written in a form that can be understood by humans, variables, address values, and the like may be expressed by alphanumeric characters such as symbols. Obtains necessary information such as information related to symbols from the symbol information 1703 of software obtained when compiling the debugged software 102, and solves what the symbol indicates.

(Embodiment 22)
FIG. 22 shows a system simulation execution program according to the twenty-second embodiment corresponding to the twenty-second invention. In the twenty-second embodiment, similar to the twenty-first embodiment, when simulating a software simulator and a hardware simulator in cooperation, the hardware element is simulated by directly operating the inside of the software simulator from the hardware side. And a part of the software simulation are omitted, thereby increasing the speed of the entire simulation and improving the efficiency of software debugging. The difference from the twenty-first embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The debugged software execution unit 103 in FIG. 22 reads the debugged software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  When the hardware description execution unit 202 calls a function for performing a software operation, the software operation command analysis unit 2101 is called with the parameters. As shown in the flow of FIG. 61, the software operation command analysis unit 2101 analyzes the command character string, extracts the command type and parameters, and calls the debugged software execution unit 103. When command parameters extracted by the software operation command analysis unit 2101 are written in a form that can be understood by humans, variable names, address values, and the like may be expressed by alphanumeric characters such as symbols. 103 obtains necessary information such as information on the symbol from the symbol information 1703 of the software obtained when the debugged software 102 is compiled, and solves what the symbol indicates.

(Embodiment 23)
FIG. 23 shows a system simulation execution program according to the twenty-third embodiment corresponding to the twenty-third invention. In the twenty-third embodiment, when an automatic test by simulation is performed by linking a software simulator and a hardware simulator, the hardware is controlled by directly operating the inside of the software simulator or the inside of the hardware simulator from a test script. By omitting part of the element simulation and software simulation, the speed of the entire simulation is increased to increase the efficiency of the automatic test. For example, when it is desired to set hardware or software to a specific state, it may take a lot of simulation time to move to that state only by operating an external signal of the hardware. Therefore, for example, as shown in FIG. 62, the state inside the hardware simulator or the software simulator is directly operated by the test script, so that the state necessary for the test is quickly created and the system verification time is shortened.

  The debug software execution unit 103 in FIG. 23 reads the debug software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The executable hardware description unit 104 performs hardware operations using a program language such as C language or C ++ language, a system description language such as SystemC or SpecC, or a hardware description language such as VHDL or VerilogHDL. Compiled so that the described source code can be executed on a host computer such as a personal computer or a workstation.

  The test script execution unit 2301 reads the test script 2302 and executes it. The test script may be compiled immediately before execution of the test script, and the compiled version may be executed. The test script execution unit 2301 determines whether the command of the test script is a hardware operation command or a software operation command as shown in the flow of FIG. 63, and the hardware operation command analysis unit 1901 or the software operation command analysis unit 2101 is determined accordingly. call.

  The hardware operation command analysis unit 1901 analyzes the command as in the nineteenth embodiment, calls the hardware element operation unit 1702, and the hardware element operation unit 1702 calls the API of the hardware description unit 104 to simulate hardware. To control.

  The software operation command analysis unit 2101 analyzes the command as in the twenty-first embodiment and calls the software execution unit 103 to control the software simulation.

(Embodiment 24)
FIG. 24 shows a system simulation execution program according to the twenty-fourth embodiment corresponding to the twenty-fourth invention. In the twenty-fourth embodiment, in the same way as the twenty-third embodiment, when the software simulator and the hardware simulator are linked to perform an automatic test by simulation, the inside of the software simulator or the inside of the hardware simulator is directly taken from the test script. By operating, part of the hardware element simulation and software simulation are omitted, thereby increasing the speed of the entire simulation and increasing the efficiency of the automatic test. The difference from the twenty-third embodiment is that the hardware description execution unit executes the code described in hardware as in the second embodiment.

  The debug software execution unit 103 in FIG. 24 reads the debug software 102 and executes it. The debugged software execution unit 103 may be an instruction set simulation ISS that executes each instruction of the microcomputer one by one, or may be of a type that executes the debugged software 102 converted into an intermediate language. The hardware description execution unit 202 reads the hardware description 201 and executes the description contents. Generally, an interpreter is used, and the intermediate language is often executed after first converting to an intermediate language. However, a just-in-time compiler method that partially compiles at the time of execution may be employed, or the hardware description content may be converted into data that can be easily executed by the simulator and executed while referring to the data.

  The test script execution unit 2301 reads the test script 2302 and executes it. The test script may be compiled immediately before execution of the test script, and the compiled one may be executed. The test script execution unit 2301 determines whether the command of the test script is a hardware operation command or a software operation command as shown in the flow of FIG. 63, and the hardware operation command analysis unit 1901 or the software operation command analysis unit 2101 is determined accordingly. call.

  The hardware operation command analysis unit 1901 analyzes the command as in the twentieth embodiment, calls the hardware element operation unit 1802, and the hardware element operation unit 1802 calls the API of the hardware description execution unit 202 to Control the simulation.

  The software operation command analysis unit 2101 analyzes the command as in the twenty-second embodiment and calls the software execution unit 103 to control the software simulation.

(Embodiment 25)
FIG. 25 shows a hardware description conversion program according to a twenty-fifth embodiment corresponding to the twenty-fifth invention. The twenty-fifth embodiment is a program for reflecting, when a hardware description is corrected, an abstraction process performed for speeding up the hardware description before the correction to the corrected hardware description. As a result, time-consuming abstraction processing can be minimized and efficient debugging using a simulator becomes possible.

  The new hardware description 2501 in FIG. 25 is a hardware description after being corrected for some reason, and the abstracted hardware description 2502 and the information shown in FIG. There is an abstracted part record 2503 such as In the abstracted hardware description 2502, for example, the lines from L08 line to L26 line of P301 in FIG. 44 are recorded.

  By passing through the hardware description conversion program 2504, a modified hardware description 1306 that can perform high-speed simulation is generated. The hardware description conversion program 2504 includes an already abstracted part extracting unit 2505 that extracts an already abstracted part in the hardware description 2501. After this processing, the hardware description replacement unit 2506 modifies the contents of the new hardware description 2501 to create a hardware description 1306.

  First, the already abstracted part extracting unit 2505 uses the information in the abstracted part record 2503 in the flow shown in FIG. 65 to search for a part that has already been abstracted from the new hardware description 2501 and extracts the abstracted part extracted record. Record in 2507.

  Next, the hardware description replacement unit 2506 copies the contents of the new hardware description 2501 as shown in FIG. 66, and deletes the code before being abstracted therein using the abstraction unit extraction record 2507. The contents of the abstracted hardware description 2502 are acquired and inserted into the hardware description 1305 after the change.

  In this way, by using the result of the abstraction that has already been performed, it is possible to perform a simulation quickly without performing abstraction work.

(Embodiment 26)
FIG. 26 shows a system simulation execution program according to the twenty-sixth embodiment corresponding to the twenty-sixth invention. In the twenty-sixth embodiment, when the hardware description is modified as in the twenty-fifth embodiment, the hardware description is executed using the abstraction result obtained for speeding up the hardware description before the modification, Abstraction work can be omitted and debugging can be performed efficiently. The difference from the twenty-fifth embodiment is that the hardware description execution unit directly executes the hardware description code instead of compiling after converting the hardware description at the source code level for speeding up. is there. Furthermore, an abstracted circuit is executed instead of executing according to the hardware description.

  The new hardware description 2501 in FIG. 26 is a hardware description after being corrected for some reason. In addition, the abstracted hardware description 2502 and the information shown in FIG. There is an abstracted part record 2503 such as In the abstracted hardware description 2502, for example, the lines from L08 line to L26 line of P301 in FIG. 44 are recorded. Alternatively, the data may be recorded in a data format that the hardware description execution unit 2601 can easily execute.

  First, the already abstracted part extracting unit 2505 uses the information in the abstracted part record 2503 in the flow shown in FIG. 65 to search for a part that has already been abstracted from the new hardware description 2501 and extracts the abstracted part extracted record. Record in 2507.

  Next, the hardware description execution unit 2601 executes the contents of the new hardware description 2501 as shown in the flow of FIG. At the time of execution, it is determined whether the hardware description has been abstracted in the past based on the abstraction part extraction record 2507, and if it has been abstracted in the past, the abstracted one is executed.

  In this way, by using the result of the abstraction that has already been performed, it is possible to perform a simulation quickly without performing abstraction work.

(Embodiment 27)
FIG. 27 shows a simulation system execution program according to a twenty-seventh embodiment corresponding to the twenty-seventh aspect. In the twenty-seventh embodiment, when two simulators operate in parallel with each other, the simulation is independently performed until the time when the events related to each other occur, and the event occurrence time specified in advance in the simulation is executed. If an event related to the movement of the other simulation has occurred by the time, the simulation execution unit is synchronized by restoring the state of both simulations to the simulation state at the simulation time at which the event occurred. Therefore, it is possible to reduce the overhead due to frequent switching to increase the speed of simulation.

  The simulation execution unit A2701 and the simulation execution unit B2702 in FIG. 27 cooperate and execute in parallel. In general, synchronization is achieved by switching between executions in a short cycle, but in the present invention, switching is performed at a longer time interval or at the timing of occurrence of an event. When each of the simulation execution units 2701 and 2702 recognizes that an event related to the other simulation execution occurs, it registers the event in the event reservation registration unit 2703, and the event reservation registration unit 2703 is as shown in FIG. Event reservation information 2704 is registered.

  As shown in the flow of FIG. 70, the simulation execution instructing unit 2705 acquires information on the event that will occur in the near future in the event reservation information 2704, and advances the simulation independently until the simulation time at which the event occurred. To the simulation execution unit A2701 and the simulation execution unit B2702. However, if the interval is too large, the penalty when a situation in which the simulation time has to be restored and restored is large, so the interval is based on the information of the simulation switching time interval information 2710 as shown in FIG. Adjust so that it is not too large.

  The simulation execution units 2701 and 2702 operate as shown in the flow of FIG. The contents of the simulation execution are recorded in the execution history recording units 2706 and 2707 as shown in FIG. When an event related to the other simulation execution unit occurs while the simulation execution unit is executing the simulation, if it is closer than the time instructed to the simulation execution instruction unit 2705, it is transmitted to the simulation execution instruction unit 2705, The simulation execution instruction unit 2705 instructs the simulation state restoration unit A 2708 or the simulation state restoration unit B 2709 to restore the simulation state, and instructs the simulation state to be continued after the restoration.

  The simulation system according to the present invention can perform high-speed simulation while coordinating a hardware simulator and a software simulator, and is useful for hardware and software development of various electronic devices using a microprocessor. It is also useful in developing the microprocessor itself and in developing peripheral LSIs connected to the microprocessor.

The figure which shows the example of the system simulation execution program in Embodiment 1 of this invention The figure which shows the example of the system simulation execution program in Embodiment 2 of this invention The figure which shows the example of the system simulation execution program in Embodiment 3 of this invention The figure which shows the example of the system simulation execution program in Embodiment 4 of this invention The figure which shows the example of the system simulation execution program in Embodiment 5 of this invention The figure which shows the example of the system simulation execution program in Embodiment 6 of this invention The figure which shows the example of the system simulation execution program in Embodiment 7 of this invention The figure which shows the example of the system simulation execution program in Embodiment 8 of this invention The figure which shows the example of the system simulation execution program in Embodiment 9 of this invention The figure which shows the example of the system simulation execution program in Embodiment 10 of this invention The figure which shows the example of the system simulation execution program in Embodiment 11 of this invention The figure which shows the example of the system simulation execution program in Embodiment 12 of this invention The figure which shows the example of the hardware description conversion program in Embodiment 13 of this invention The figure which shows the example of the system simulation execution program in Embodiment 14 of this invention The figure which shows the example of the hardware description conversion program in Embodiment 15 of this invention The figure which shows the example of the system simulation execution program in Embodiment 16 of this invention The figure which shows the example of the system simulation execution program in Embodiment 17 of this invention The figure which shows the example of the system simulation execution program in Embodiment 18 of this invention The figure which shows the example of the system simulation execution program in Embodiment 19 of this invention The figure which shows the example of the system simulation execution program in Embodiment 20 of this invention The figure which shows the example of the system simulation execution program in Embodiment 21 of this invention The figure which shows the example of the system simulation execution program in Embodiment 22 of this invention The figure which shows the example of the system simulation execution program in Embodiment 23 of this invention The figure which shows the example of the system simulation execution program in Embodiment 24 of this invention The figure which shows the example of the hardware description conversion program in Embodiment 25 of this invention The figure which shows the example of the system simulation execution program in Embodiment 26 of this invention The figure which shows the example of the system simulation execution program in Embodiment 27 of this invention The figure which shows the example of the hardware constitutions of Embodiment 1 of this invention The figure which shows the flow of the hardware description part of Embodiment 1 of this invention. The figure which shows the example of the hardware element inactivation location information of Embodiment 1 of this invention The figure which shows the example of the hardware constitutions of Embodiment 3 of this invention The figure which shows the flow of the unnecessary hardware element search part of Embodiment 3 of this invention. The figure which shows the flow of the unnecessary hardware element search part of Embodiment 3 of this invention. The figure which shows the example of the hardware constitutions of Embodiment 5 of this invention The figure which shows the flow of the hardware description part of Embodiment 5 of this invention. The figure which shows the flow of the hardware element active state acquisition part of Embodiment 5 of this invention. The figure which shows the example of the hardware element activation log | history recording of Embodiment 5 of this invention The figure which shows the flow of the unnecessary hardware element search part of Embodiment 5 of this invention. The figure which shows the flow of the hardware description part of Embodiment 7 of this invention. The figure which shows the example of the simulation condition recording part of Embodiment 7 of this invention The figure which shows the example of the access control address recording part of Embodiment 11 of this invention The figure which shows the flow of the condition determination part of Embodiment 11 of this invention The figure which shows the flow of the access control part of Embodiment 11 of this invention. The figure which shows the code example of Embodiment 13 of this invention The figure which shows the flow of the periodic circuit extraction part of Embodiment 13 of this invention. The figure which shows the flow of the periodic circuit extraction part of Embodiment 13 of this invention. The figure which shows the flow of the periodic circuit parameter calculation part of Embodiment 13 of this invention. The figure which shows the flow of the periodic circuit conversion part of Embodiment 13 of this invention. The figure which shows the code example of Embodiment 15 of this invention The figure which shows the flow of the combinational circuit extraction part of Embodiment 15 of this invention. The figure which shows the flow of the combinational circuit parameter calculation part of Embodiment 15 of this invention. The figure which shows the flow of the combinational circuit conversion part of Embodiment 15 of this invention. The figure which shows the flow of the condition determination part of Embodiment 17 of this invention. The figure which shows the example of the hardware element operation information recording part of Embodiment 17 of this invention. The figure which shows the flow of the access control part of Embodiment 17 of this invention. The figure which shows the flow of the hardware element operation part of Embodiment 17 of this invention. The figure which shows the code example of Embodiment 19 of this invention The figure which shows the flow of the to-be-debugged software execution part of Embodiment 19 of this invention. The figure which shows the flow of the hardware operation command analysis part of Embodiment 19 of this invention. The figure which shows the code example of Embodiment 21 of this invention. The figure which shows the flow of the software operation command analysis part of Embodiment 21 of this invention. The figure which shows the code example of Embodiment 23 of this invention The figure which shows the flow of the test script execution part of Embodiment 23 of this invention. The figure which shows the example of the abstract location recording of Embodiment 25 of this invention The figure which shows the flow of the already abstracted part extraction part of Embodiment 25 of this invention. The figure which shows the flow of the hardware description replacement part of Embodiment 25 of this invention. The figure which shows the flow of the hardware description execution part of Embodiment 26 of this invention. The figure which shows the example of the event reservation information of Embodiment 27 of this invention The figure which shows the example of the switching time interval information of Embodiment 27 of this invention The figure which shows the flow of the simulation execution instruction | indication part of Embodiment 27 of this invention. The figure which shows the flow of the simulation execution part of Embodiment 27 of this invention. The figure which shows the example of the execution log recording of Embodiment 27 of this invention

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 System simulation execution program 102 Debugged software 103 Debugged software execution part 104 Executable hardware description part 105 Hardware element inactivation designation | designated part 107 Hardware description 108 Compiler 201 Hardware description 202 Hardware description execution part 302 Unnecessary Hardware element search unit 501 Hardware element active state acquisition unit 702 Simulation condition determination unit 901 Software execution state acquisition unit 1101 Access control unit 1102 Condition determination unit 1302 Hardware description conversion program 1303 Periodic circuit extraction unit 1304 Periodic circuit parameter extraction unit 1305 Periodic circuit conversion unit 1306 Hardware description after change 1307 Compiler 1501 Combination circuit extraction unit 1502 Combination Route parameter calculation unit 1503 Combination circuit conversion unit 1701 Hardware element operation information recording unit 1702 Hardware element operation unit 1901 Hardware operation command analysis unit 2101 Software operation command analysis unit 2301 Test script execution unit 2504 Hardware description conversion program 2505 Already abstract Extraction unit 2506 Hardware description replacement unit

Claims (27)

  A debugged software execution unit that executes the software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit Hardware that outputs to the hardware description part an instruction to partially suppress the hardware simulation based on the hardware description part and hardware element inactivation location information in which a hardware element unnecessary for the simulation is specified A system simulation execution program comprising a wear element deactivation designation unit.   A debugged software execution unit that executes software to be debugged, a hardware description execution unit that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and is unnecessary for the simulation A hardware element deactivation designation unit that outputs an instruction to partially suppress hardware simulation based on hardware element deactivation point information in which the hardware element is designated to the hardware description execution unit; System simulation execution program provided.   A debugged software execution unit that executes the debugged software and a compiled hardware description that performs hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit An unnecessary hardware element search unit that searches for a hardware element that is unnecessary for the simulation based on a hardware description part, hardware description structure information indicating a relationship between hardware elements, and a required hardware element list, and a search result thereof A system simulation execution program comprising: a hardware element inactivation specifying unit that outputs an instruction to partially suppress hardware simulation to the hardware description unit.   Between a hardware element and a hardware description execution unit that executes a software to be debugged, executes a hardware simulation based on the hardware description, and operates in cooperation with the debugged software execution unit The hardware description search section that searches for hardware elements that are unnecessary for the simulation based on the hardware description structure information indicating the relationship between the hardware and the required hardware element list, and the hardware simulation based on the search results A system simulation execution program comprising: a hardware element deactivation designation unit that outputs an instruction to be suppressed automatically to the hardware description execution unit.   A debugged software execution unit that executes the software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A hardware description part, a hardware element active state acquisition part for monitoring the operating state of the hardware description part and acquiring a hardware element active state, and a result acquired by the hardware element active state acquisition part; An unnecessary hardware element search unit that searches for a hardware element that is unnecessary for simulation based on hardware description structure information indicating a relationship between hardware elements and a required hardware element list, and hardware based on the search result Partially suppress the simulation of Simulation program and a hardware elements inactivation designation unit for outputting instructs to the hardware description section.   A debugged software execution unit that executes the debugged software, a hardware description execution unit that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the hardware description A hardware element active state acquisition unit for monitoring the operating state of the execution unit to acquire a hardware element active state, and a hardware indicating a relationship between the result acquired by the hardware element active state acquisition unit and the hardware element Unnecessary hardware element search unit for searching for unnecessary hardware elements based on the hardware description structure information and the required hardware element list, and an instruction to partially suppress the hardware simulation based on the search result Is output to the hardware description execution unit Simulation program and a that hardware elements inactivation specifying unit.   A debugged software execution unit that executes the software to be debugged, a compiled hardware description, and executes a hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A hardware description unit, a hardware element state acquisition unit for acquiring a hardware element state in the hardware description unit, and a result of the acquisition by the hardware element state acquisition unit A simulation condition determination unit that determines whether to perform a simulation, and a hardware element that outputs an instruction to partially suppress hardware simulation to the hardware description unit based on the determination result of the simulation condition determination unit. With activation designation part System simulation program to obtain.   A debugged software execution unit that executes the debugged software, a hardware description execution unit that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the hardware description A hardware element state acquisition unit for acquiring a hardware element state in the execution unit, and a simulation for determining whether to simulate each hardware element based on a result acquired by the hardware element state acquisition unit A system comprising: a condition determining unit; and a hardware element deactivation specifying unit that outputs an instruction to partially suppress hardware simulation to the hardware description executing unit based on the determination result of the simulation condition determining unit Simulation execution program Grams.   A debugged software execution unit that executes the debugged software and a compiled hardware description that performs hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A hardware description unit, a software execution state acquisition unit for acquiring a software execution state in the debugged software execution unit, and a simulation of each hardware element based on the result acquired by the software execution state acquisition unit A simulation condition determining unit that determines whether or not to perform hardware element deactivation that outputs an instruction to partially suppress hardware simulation to the hardware description unit based on a determination result of the simulation condition determining unit System simulation program and a tough.   A debugged software execution unit that executes the debugged software, a hardware description executing unit that executes a hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the debugged software A software execution state acquisition unit for acquiring a software execution state in the execution unit, and a simulation condition determination unit that determines whether to simulate each hardware element based on the result acquired by the software execution state acquisition unit And a hardware element deactivation designation unit that outputs an instruction to partially suppress hardware simulation to the hardware description execution unit based on the determination result of the simulation condition determination unit Line program.   A debugged software execution unit that executes the debugged software and a compiled hardware description that performs hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A hardware description section; a condition determination section that monitors access from the debugged software execution section to the virtual memory space of the hardware description section and determines whether to permit the access according to the contents of the access; A system simulation execution program comprising: an access control unit that controls whether or not to execute access to the virtual memory space of the hardware description unit from the debugged software execution unit based on the determination result of the condition determination unit.   A debugged software execution unit that executes the debugged software; a hardware description executing unit that executes hardware simulation based on a hardware description and operates in cooperation with the debugged software executing unit; and the debugged software A condition determination unit that monitors access from the execution unit to the virtual memory space of the hardware description execution unit and determines whether to permit the access according to the content of the access, and a determination result of the condition determination unit A system simulation execution program comprising: an access control unit for controlling whether or not to execute access to the virtual memory space of the hardware description execution unit from the debugged software execution unit.   A periodic circuit extraction unit for extracting a periodic circuit from the hardware description, a periodic circuit parameter calculation unit for calculating a periodic circuit parameter from the periodic circuit extracted by the periodic circuit extraction unit, and a calculation by the periodic circuit parameter calculation unit A hardware description conversion program comprising: a periodic circuit conversion unit that rewrites a periodic circuit portion in the hardware description to another process based on the periodic circuit parameters that have been set. A debugged software execution unit that executes the debugged software, a hardware description execution unit that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the hardware description A periodic circuit extraction unit for extracting a periodic circuit from the hardware description executed by the execution unit, and a periodic circuit parameter calculation unit for calculating a periodic circuit parameter from the periodic circuit extracted by the periodic circuit extraction unit,
The hardware description executing unit is a system simulation for realizing the characteristics of the periodic circuit based on the periodic circuit parameters calculated by the periodic circuit parameter calculating unit, instead of executing the periodic circuit part in the hardware description. Execution program.   A combinational circuit extraction unit for extracting a combinational circuit from the hardware description, a combinational circuit parameter calculation unit for calculating a combinational circuit parameter from the combinational circuit extracted by the combinational circuit extraction unit, and a calculation by the combinational circuit parameter calculation unit A hardware description conversion program comprising: a combinational circuit conversion unit that rewrites a combinational circuit portion in the hardware description to another process based on the combinational circuit parameter that is set A debugged software execution unit that executes the debugged software, a hardware description execution unit that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the hardware description A combinational circuit extraction unit for extracting a combinational circuit from the hardware description executed by the execution unit, and a combinational circuit parameter calculation unit for calculating a combinational circuit parameter from the combinational circuit extracted by the combinational circuit extraction unit,
The hardware description execution unit executes a system simulation for realizing the characteristics of the combinational circuit based on the combinational circuit parameter calculated by the combinational circuit parameter calculation unit, instead of executing the combinational circuit part in the hardware description. program.   A debugged software execution unit that executes the debugged software and a compiled hardware description that performs hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A hardware description section; a condition determination section that monitors access from the debugged software execution section to the virtual memory space of the hardware description section and determines whether to permit the access according to the contents of the access; An access control unit for executing access to the virtual memory space of the hardware description unit from the debugged software execution unit when the determination result of the condition determination unit permits access; and a determination result of the condition determination unit If you do not allow access to the hardware System simulation program and a hardware element operating portion for operating the particular hardware elements in the predicate directly.   A debugged software execution unit that executes the debugged software; a hardware description executing unit that executes hardware simulation based on a hardware description and operates in cooperation with the debugged software executing unit; and the debugged software A condition determination unit that monitors access from the execution unit to the virtual memory space of the hardware description execution unit and determines whether to permit the access according to the content of the access, and a determination result of the condition determination unit is An access control unit that executes access to the virtual memory space of the hardware description execution unit from the debugged software execution unit when access is permitted, and the hardware when the determination result of the condition determination unit does not permit access Specific hardware elements in the hardware description System simulation program and a hardware element operating portion for operating.   A debugged software execution unit that executes the debugged software and a compiled hardware description that performs hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A hardware description section, a hardware operation command analysis section for analyzing a hardware operation command described in the debugged software, and the hardware description based on the analysis result of the hardware operation command analysis section. A system simulation execution program comprising a hardware element operation unit that directly operates hardware elements therein.   A debugged software execution unit that executes the debugged software, a hardware description executing unit that executes a hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the debugged software Hardware operation command analysis unit for analyzing hardware operation commands described in the hardware, and hardware for directly operating hardware elements in the hardware description based on the analysis result of the hardware operation command analysis unit A system simulation execution program comprising a wear element operation unit.   A debugged software execution unit that executes the debugged software and a compiled hardware description that performs hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A system simulation execution program comprising: a hardware description part; and a software operation command analysis part for analyzing a debugged software execution part operation command described in the hardware description part and operating the debugged software execution part.   A debugged software execution unit that executes the debugged software, a hardware description execution unit that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the hardware description A system simulation execution program comprising: a software operation command analysis unit that analyzes a debug software execution unit operation command described in the command and operates the debug software execution unit.   A debugged software execution unit that executes the debugged software and a compiled hardware description that performs hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit A hardware description part, a test script execution part for executing a test script, a hardware operation command analysis part for analyzing a hardware operation command described in the test script, and an analysis result of the hardware operation command analysis part A hardware element operation unit for directly operating hardware elements in the hardware description based on the above, and a debugged software execution unit operation command described in the test script to analyze the debugged software execution unit System simulation program and a software operation command analyzing unit for operating.   A debug software execution unit that executes the debug target software, a hardware description execution unit that operates in cooperation with the debug target software execution unit, and a test script that executes hardware simulation based on the hardware description In the hardware description based on the analysis result of the hardware operation command analysis unit, the hardware operation command analysis unit that analyzes the hardware operation command described in the test script, A hardware element operation unit that directly operates hardware elements; and a software operation command analysis unit that analyzes a debugged software execution unit operation command described in the test script and operates the debugged software execution unit. System simulation program to obtain.   An already abstracted part extracting unit that extracts a part equivalent to a part that has been abstracted in the past from the hardware description, and an extracted part by the already abstracted part extracting unit in the hardware description A hardware description conversion program comprising a hardware description replacement unit that replaces an abstracted description for which abstraction work has been completed in the past. A debugged software execution unit that executes the debugged software, a hardware description execution unit that executes hardware simulation based on the hardware description and operates in cooperation with the debugged software execution unit, and the hardware description An abstraction part extraction unit that extracts a part equivalent to a part of abstraction work completed in the past from the hardware description executed by the execution part,
The hardware description execution unit is an abstraction in which the abstraction work has been completed in the past, instead of executing a part equivalent to the part in the hardware description in which the abstraction work has been completed in the past. System simulation execution program that executes the specified description.   A plurality of simulation execution units that operate in parallel with each other, an event reservation registration unit that is accessed from the simulation execution unit, and a change in simulation according to the event timing set in the event reservation registration unit And a simulation state restoration unit that restores the simulation state to a state at a specific time point using a recording of the simulation execution state. One simulation execution unit is connected to the other simulation execution unit. A system simulation execution program that sets an event timing in the event reservation registration unit when a related event is recognized.

Images