Debug apparatus, control method for debug apparatus, and control program for debug apparatus

Abstract

To provide a debug apparatus capable of simultaneously verifying software and hardware modules while suppressing an increase in verification costs.SOLUTION: A debag apparatus 1 comprises: a simulator for executing a simulation; a monitoring control unit for providing instructions for monitoring and controlling a software execution file, the execution state of a processor, program variables, and a plurality of memory circuits of the processor; and a simulator control unit for causing the simulator to execute the simulation. The simulator control unit causes the simulator to execute a simulation so as to monitor and control the data stored in a plurality of internal storage circuits and an external storage circuit, as well as input / output data of the processor, and provides the results of the simulation to the monitoring control unit if the simulator control unit determines that the instructions for monitoring and controlling is related to data stored in the plurality of internal storage circuits and the external storage circuit, and the input / output data of the processor.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a debugging device, a control method for a debugging device, and a control program for a debugging device. [Background technology]

[0002] In a digital system in the embedded field, a technique is known in which a hardware circuit including a CPU and software executed by the CPU are debugged in cooperation before an actual device is manufactured, thereby shortening the development period and improving the quality. For example, Patent Document 1 discloses a verification device having a CPU model described in a hardware description language (HDL) and an HDL simulator that simulates the operation of the CPU that executes the process described in the software and displays the simulation result. The verification device described in Patent Document 1 can verify the operation of the cooperative process between the hardware and software with the HDL simulator without using an expensive logic emulator. However, the verification device described in Patent Document 1 has a large amount of waveform data stored by the HDL simulator, which increases the memory capacity and simulation time, which may increase the verification cost.

[0003] Patent Document 2 describes a technique for setting log control information including acquisition necessity information indicating whether or not to acquire log information in a description file of an LSI model described in HDL, and determining whether or not to store the transferred transfer information based on the log control information. The technique described in Patent Document 2 can improve the efficiency of verification of software that runs on an embedded system by not storing unnecessary transfer information.

[0004] Furthermore, Patent Document 3 describes a technique for sequentially reading multiple output data when it is determined that any of the output data has changed when detecting an operation associated with software processing of a functional block constructed by programmable elements. The technique described in Patent Document 3 can reduce verification costs by reading output data only when it is determined that any of the output data has changed.

[0005] However, in the techniques described in Patent Documents 2 and 3, the amount of waveform data stored by the simulator is reduced compared to the technique described in Patent Document 1, but it is not unlikely that verification costs will increase due to the storage of waveform data.

[0006] On the other hand, Patent Document 4 describes a technique for synthesizing a logic circuit from a logic circuit description written in a programming language for writing software, such as C and C++. Non-Patent Document 1 describes a technique for applying the technique for synthesizing a logic circuit from a logic circuit description written in a programming language to the design of a CPU. Non-Patent Document 2 describes a technique for extending the technique for synthesizing a logic circuit from a logic circuit description written in a programming language to the design of an SoC in which various circuits including a CPU are implemented. The techniques described in Patent Document 4 and Non-Patent Documents 1 and 2 make it possible to describe the entire SoC in which various circuits including a CPU are implemented in a programming language, and generate a logic circuit in the Register Transfer Level (RTL) description of the entire SoC.

[0007] Non-Patent Document 3 describes a technique for monitoring and controlling the execution state of software to be verified using the GNU Debugger (GDB) as a symbolic debugger, and for monitoring and controlling the operation of registers in a hardware module using a JTAG test method. The technique described in Non-Patent Document 3 allows the CPU and IP cores implemented in an SoC to be debugged consistently with the software by utilizing the GDB interface used for debugging the software.

Prior Art Documents

Patent Documents

[0008]

Patent Document 1

Patent Document 2

Patent Document 3

Patent Document 4

Non-Patent Documents

[0009]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

[0010] As described above, the techniques described in Patent Documents 1 to 3 may increase the verification cost. In addition, Patent Document 4 and Non-Patent Documents 1 and 2 do not describe the simultaneous execution of debugging of software describing the processing to be executed by a processor and a hardware module including the processor. In addition, the technique described in Non-Patent Document 3 describes the simultaneous execution of verification of software and hardware, but the verification cost increases because a process of adding a scan circuit for JTAG testing to a logic gate level circuit generated by logic synthesis is performed. Furthermore, in the technique described in Non-Patent Document 3, the operation of a logic gate level circuit to which a scan circuit for JTAG testing is added is confirmed by simulation, so that the simulation time increases and the verification cost may further increase.

[0011] The present invention is devised to solve such problems, and has an object to provide a debugging device capable of simultaneously executing verification of software and hardware modules while suppressing increases in verification costs. [Means for solving the problem]

[0012] A debugging device according to the present invention includes a hardware module model generated by compiling a hardware source file describing the operation of a hardware module including a processor having a plurality of internal storage circuits for storing data, the processor executing a process in response to input of data and outputting data in accordance with an execution state, and an external storage circuit connected to the processor for storing data; a memory unit for storing a software executable file generated by compiling a software source file including a plurality of program variables and describing a process including a plurality of steps to be executed by the processor; a simulator for simulating the process described in the software source file using the hardware module model and the software executable file; and a software module model generating a software executable file ... The system includes a monitoring control unit that provides monitoring and control instructions for an executable file, program variables, execution state data indicating the execution state of the processor, memory data stored in a plurality of internal memory circuits and an external memory circuit possessed by the processor, and input / output data input and output by the processor, and a simulator control unit that causes a simulator to execute a simulation, wherein the simulator control unit determines whether the monitoring and control instruction relates to the program variables, the execution state data, the memory data, or the input / output data, and when it determines that the monitoring and control instruction relates to the execution state data, the memory data, or the input / output data, causes the simulator to execute a simulation to monitor and control the execution state data, the memory data, and the input / output data, and provides execution result information indicating the execution result of the simulation to the monitoring control unit, and the monitoring control unit outputs the execution result information.

[0013] Furthermore, in the debugging device of the present invention, it is preferable that the simulator has a simulation data structure indicating execution state data, memory data, and input / output data, an instruction operation unit that updates the data corresponding to the simulation data structure and executes a process including multiple steps described in the software source file, and a CPU memory that stores each of the software executable file, program variables, and a dummy structure that is dummy data for the simulation data structure.

[0014] Furthermore, in the debugging device of the present invention, it is preferable that the monitoring control unit provides a monitoring control instruction in association with an address value of an area in which either a program variable or a dummy structure is stored, and the simulator control unit determines based on the address value whether it relates to a program variable, execution state data, memory data, or input / output data.

[0015] Furthermore, in the debugging device of the present invention, it is preferable that the dummy structure is not updated by the simulator, and the simulator control unit obtains the execution result information from the simulation data structure when the address value input together with the monitoring control instruction is associated with the dummy structure.

[0016] Furthermore, in the debugging device according to the present invention, it is preferable that the hardware module further includes a logical hardware model which is at least one of a hardware accelerator, a bus module, and an I / O circuit, the execution state data indicates the execution state of the logical hardware model in addition to the execution state of the processor, the stored data includes data stored in the logical hardware model in addition to data stored in the multiple internal storage circuits and the external storage circuit, and the input / output data includes data input / output to / from the logical hardware model in addition to data input / output to / from the processor, and the simulator has a simulation data structure indicating the execution state data, the stored data, and the input / output data, an instruction operation unit that updates the data corresponding to the simulation data structure and executes a process including multiple steps described in the software source file, a logic operation unit that updates the data corresponding to the simulation data structure and executes a logical operation of the logical hardware model, and a CPU memory that stores each of the software execution file, the program variables, and a dummy structure which is dummy data of the simulation data structure.

[0017] Furthermore, in the debugging device according to the present invention, the hardware module model is preferably declared as a global variable in the software source file.

[0018] A control method of a debugging device according to the present invention includes a hardware module model generated by compiling a hardware source file describing the operation of a hardware module including a processor having a plurality of internal storage circuits for storing data, the processor executing a process in response to input of data and outputting data in accordance with an execution state, and an external storage circuit connected to the processor for storing data; a storage unit for storing a software executable file generated by compiling a software source file including a plurality of program variables and describing a process including a plurality of steps to be executed by the processor; a simulator for simulating the process described in the software source file using the hardware module model and the software executable file; and a monitoring control unit that provides monitoring and control instructions for a software executable file, a program variable, execution state data indicating an execution state of a processor, stored data stored in a plurality of internal storage circuits and an external storage circuit of the processor, and input / output data input and output by the processor, and a simulator control unit that causes a simulator to execute a simulation, the method including: determining whether the monitoring and control instruction relates to any of the program variables, the execution state data, the stored data, and the input / output data; and, when it is determined that the monitoring and control instruction relates to any of the execution state data, the stored data, and the input / output data, causing the simulator to execute a simulation so as to monitor and control the execution state data, the stored data, and the input / output data; providing execution result information indicating an execution result of the simulation to the monitoring control unit; and outputting the execution result information.

[0019] Furthermore, a control program for a debugging device according to the present invention includes a hardware module model generated by compiling a hardware source file describing the operation of a hardware module including a processor having a plurality of internal storage circuits for storing data, the processor executing a process in response to input of data and outputting data in accordance with an execution state, and an external storage circuit connected to the processor for storing data; a storage unit for storing a software executable file generated by compiling a software source file including a plurality of program variables and describing a process including a plurality of steps to be executed by the processor; a simulator for simulating the process described in the software source file using the hardware module model and the software executable file; and A control program for a debugging device having a monitoring control unit that provides monitoring and control instructions for files, program variables, execution state data indicating the execution state of a processor, memory data stored in a plurality of internal memory circuits and an external memory circuit possessed by the processor, and input / output data input and output by the processor, and a simulator control unit that causes a simulator to execute a simulation, the control program determining whether the monitoring and control instruction relates to any of the program variables, the execution state data, the memory data, and the input / output data, and when it is determined that the monitoring and control instruction relates to any of the execution state data, the memory data, and the input / output data, causes the simulator to execute a simulation to monitor and control the execution state data, the memory data, and the input / output data, provides execution result information indicating the execution result of the simulation to the monitoring control unit, and causes a computer to execute a process of outputting the execution result information. Effect of the Invention

[0020] The debugging device according to the present invention can simultaneously verify software and hardware modules while suppressing increases in verification costs. [Brief description of the drawings]

[0021] [Figure 1]FIG. 1 is a schematic diagram of a debugging device according to a comparative example. [Diagram 2] 1 is a schematic diagram of a debugging device according to a first embodiment; [Diagram 3] 1 is a block diagram of a debugging device according to a first embodiment. [Figure 4] 4 is a flowchart of a CPU simulator generation process executed by the debugging device shown in FIG. 3. [Diagram 5] FIG. 2A is a diagram showing an example of a CPU model corresponding to a target CPU, and FIG. 2B is a diagram showing a hardware configuration of a target CPU corresponding to the CPU model shown in FIG. [Figure 6] FIG. 3 illustrates an example of an application source program illustrated in FIG. 2. [Figure 7] 4 is a flowchart of a debugging process executed by the debugging device shown in FIG. 3. [Figure 8] FIG. 11 is a schematic diagram of a debugging device according to a second embodiment. [Figure 9] 9A is a schematic diagram of the SoC model shown in FIG. 8, and FIG. 9B is a diagram showing the data structure of the data structure shown in FIG. [Figure 10] FIG. 11 is a block diagram of a debugging device according to a second embodiment. [Figure 11] 11 is a flowchart of a CPU simulator generation process executed by the debugging device shown in FIG. [Figure 12] 9(a) is a diagram showing an example of an SoC model corresponding to the SoC shown in FIG. 8, (b) is a diagram showing an example of a sub-model of the SoC model shown in (a), and (c) is a diagram showing the hardware configuration of an SoC corresponding to the SoC model shown in (a). [Figure 13] FIG. 9 is a diagram illustrating an example of an application source program illustrated in FIG. 8. [Figure 14] 11 is a flowchart of a debugging process executed by the debugging device shown in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Hereinafter, a debugging device, a control method for a debugging device, and a control program for a debugging device according to an embodiment will be described with reference to the accompanying drawings. Similar or corresponding elements are given the same reference numerals, and duplicated descriptions will be omitted. The scale of the drawings may be changed to facilitate understanding.

[0023] (Overview of the debugging device according to the first embodiment) Fig. 1 is a schematic diagram of a debugging device according to a comparative example, and Fig. 2 is a schematic diagram of a debugging device according to the first embodiment. The debugging device 100 according to the comparative example and the debugging device 1 according to the first embodiment are cross-development software (hereinafter simply referred to as SW) debugging devices. Note that cross-development is SW development adopted when the host CPU for developing SW and the CPU (hereinafter also referred to as target CPU) mounted in the embedded system that executes SW are different, such as SW development in an embedded system.

[0024] The debugging device 100 according to the comparative example includes a symbolic debugger 101, a debug server 102, and a CPU simulator 103. When an application program to be developed does not run on a target CPU, the debugging device 100 provides a development environment that supports a debugging operation for correcting bugs inherent in the application program and realizing a desired operation of the application program. The application program is also called an application execution file 113.

[0025] The symbolic debugger 101 is an interface between the SW developer who operates the debugging device 100 to debug SW and the debugging device 100. The symbolic debugger 101 controls the execution state of the application executable file 113, such as pausing the program at a desired step and pausing due to updates of variables included in the application executable file 113, in response to an instruction from the SW developer. The variables included in the application executable file 113 are also called program variables. The symbolic debugger 101 also monitors and controls the program variables in response to an instruction from the SW developer while the application executable file 113 is paused. The symbolic debugger 101 provides an efficient SW debugging function by monitoring and controlling the program variables, such as investigating the cause of a SW bug by changing the program variables and observing the operation of the application executable file 113 after changing the program variables.

[0026] The debug server 102 provides the debug command provided from the symbolic debugger 101 to the CPU simulator 103. In response to providing the debug command, the debug server 102 provides the debug response provided from the CPU simulator 103 to the symbolic debugger 101. The debug server 102 is a relay module that relays data between the symbolic debugger 101 and the CPU simulator 103.

[0027] The CPU simulator 103 is also called an instruction set simulator, and includes a simulation data structure 120, a CPU memory 121, and an instruction operation unit 24. The CPU simulator 103 is generated by compiling a CPU simulator source file 110 and a CPU model source file 111, both of which are written in a programming language, for example, the C++ language. The CPU model source file 111 is an example of a hardware source file that describes, in a predetermined programming language, the operation of a hardware module including a processor having multiple internal storage circuits and an external storage circuit connected to the processor.

[0028] The simulation data structure 120 is a simulation of an internal data structure of a target CPU having storage data stored in a plurality of internal storage circuits and an external storage circuit, and input / output data inputted and outputted by a processor. The simulation data structure 120 stores data stored in registers and the like arranged inside the target CPU when the CPU simulator 103 simulates the instruction operation of the target CPU.

[0029] The CPU memory 121 simulates a memory area when the target CPU executes processing, and includes an application program section 122 and an application data section 123. The application program section 122 stores an application execution file 113 generated by the target CPU compiling the application source program 112. The application data section 123 stores program variables used when the CPU simulator 103 simulates the instruction operation of the target CPU.

[0030] The instruction operation unit 24 simulates the operation of the CPU and executes processing according to the debug command provided by the debug server 102. The instruction operation unit 24 executes processing such as registering an execution interruption condition of the application execution file 113, rewriting data included in the simulation data structure 120, and reading and rewriting program variables stored in the CPU memory. The instruction operation unit 24 provides the debug server 102 with a debug response indicating the processing result of the debug command.

[0031] In the debug process executed by the debug device 100, first, the symbolic debugger 101 provides the debug server 102 with a debug command in response to an instruction from a software developer (S11). The debug command provided by the symbolic debugger 101 includes data indicating the execution state of the application executable file 113 and monitoring control of program variables. Specifically, the debug command includes a command to specify a condition for interrupting the execution of the application executable file 113, and a command to monitor the execution state of the application executable file 113, such as a command to specify a condition for executing the application executable file 113 step by step. The monitoring of the execution state of the application executable file 113 includes pausing the application executable file 113 at a desired point, and pausing the application executable file 113 with an update of the program variables. The debug command also includes a command to observe program variables and the like stored in the CPU memory, and a command to control program variables and the like stored in the CPU memory. The command to observe and the command to control program variables and the like include intentionally overwriting program variables and observing the operation of the application executable file 113 after the overwriting to investigate the cause of a bug in the application executable file 113.

[0032] Next, the debug server 102 provides the debug instruction provided by the symbolic debugger 101 to the instruction operation unit 24 (S12).

[0033] Next, in response to the debug command provided by the debug server 102, the instruction operation unit 24 executes processing according to the debug command (S13). The instruction operation unit 24 executes the debug command indicating reading and rewriting of program variables as processing for the CPU memory 121.

[0034] Next, the command operating unit 24 provides a debug response corresponding to the provided debug command to the debug server 102 (S14). Then, the debug server 102 provides the debug response provided by the command operating unit 24 to the symbolic debugger 101 (S15).

[0035] The debugging device 100 can provide an efficient SW debugging function by monitoring and controlling the execution state and program variables of the application execution file 113 according to instructions from a SW developer. However, since it is premised on the CPU simulator 103 faithfully reproducing the instruction operations of the target CPU, there is a possibility that the target CPU will not function normally when the CPU model source file 111 is under development or when the design of the target CPU is changed. Furthermore, when a malfunction occurs in the CPU simulator 103, it is not easy for the debugging device 100 to specifically investigate the malfunction.

[0036] The debugging device 1 according to the first embodiment includes a symbolic debugger 21, a debug server 22, and a CPU simulator 23. In the debugging device 1, the debugging instructions provided by the symbolic debugger 21 include monitoring and controlling data program variables indicating the execution state of the application executable file 113, as well as monitoring and controlling data held in a simulation data structure 120. By monitoring and controlling the data held in the simulation data structure 120, the debugging device 1 can debug the target CPU in addition to debugging the application executable file 113.

[0037] The symbolic debugger 21 and the debug server 22 have the same configuration and function as the symbolic debugger 101 and the debug server 102, respectively. The symbolic debugger 21 is an example of a monitoring control unit that provides a monitoring control instruction for a software execution file, a program variable, execution state data indicating the execution state of a processor, storage data stored in a plurality of internal storage circuits and an external storage circuit of the processor, and input / output data input / output by the processor in a simulation by a simulator. The program variable is data related to a software source file, and the execution state data, storage data, and input / output data are data related to a hardware source file. The debug server 22 is an example of a simulator control unit that causes a simulator to execute a simulation and provides execution result information indicating the execution result of the simulation to the monitoring control unit. The CPU simulator 23 differs from the CPU simulator 103 in that the CPU memory 121 has a dummy structure unit 124. The CPU simulator 23 is an example of a simulator that executes a simulation of a process described in a software source file by using a hardware module model and a software execution file.

[0038] The dummy structure unit 124 stores an application execution file 133 obtained by compiling an application source program 132 in the CPU memory, whereby a dummy structure that is dummy data of the simulation data structure 120 is stored in the CPU memory 121 .

[0039] The application source program 132 differs from the application source program 112 in that a hardware module model indicating hardware including the simulation data structure 120 is declared as a global variable. In the application source program 132, the hardware module model including the simulation data structure 120 is declared as a global variable, and thus the dummy structure is stored in the dummy structure unit 124 of the CPU memory 121.

[0040] In the debugging process executed by the debugging device 1, first, the symbolic debugger 21 provides a debugging command to the debug server 22 in response to an instruction from the SW developer (S21). The debugging command provided by the symbolic debugger 21 includes an observation command for displaying data held in the simulation data structure 120 and a control command for rewriting data held in the simulation data structure 120. The observation command and the control command for displaying data held in the simulation data structure 120 include intentionally overwriting the debugging command provided by the symbolic debugger 21 and observing the operation of the target CPU after the overwriting, thereby investigating the cause of a bug in the target CPU.

[0041] Next, the debug server 22 provides the debug instructions provided by the symbolic debugger 21 to the CPU simulator 23 (S22).

[0042] Next, in response to the debug command provided by the debug server 22, the instruction operating unit 24 executes processing according to the debug command (S23). The instruction operating unit 24 executes debug commands instructing registration of an execution interruption condition for the application execution file 113 and reading and rewriting data included in the simulation data structure 120 as processing for the simulation data structure 120 in which the corresponding data is stored. Also, the instruction operating unit 24 executes debug commands instructing reading and rewriting program variables as processing for the CPU memory 121.

[0043] Next, the command operating unit 24 provides a debug response corresponding to the provided debug command to the debug server 22 (S24). Then, the debug server 22 provides the debug response provided by the command operating unit 24 to the symbolic debugger 21 (S25).

[0044] The debugging device 1 can debug the target CPU and the application executable file 113 by monitoring and controlling the execution state of the application executable file 113, program variables, and data held in the simulation data structure 120 in accordance with instructions from a software developer.

[0045] (Configuration and Functions of the Debugging Device According to the First Embodiment) FIG. 3 is a block diagram of the debugging device according to the first embodiment.

[0046] The debugging device 1 includes a communication unit 11, a storage unit 12, an operation unit 13, a display unit 14, and a processing unit 20, and is, for example, a personal computer. The communication unit 11 is configured to enable the debugging device 1 to communicate with an external device (not shown), and includes a communication interface circuit. The communication interface circuit is, for example, a communication interface circuit for a wired LAN, a wireless LAN, or an LTE. The communication unit 11 supplies data received from the external device (not shown) to the processing unit 20, and transmits data supplied from the processing unit 20 to the external device (not shown).

[0047] The storage unit 12 is configured to store data and programs, and includes, for example, a semiconductor memory. The storage unit 12 stores an operating system program, a driver program, an application program, data, and the like used in processing by the processing unit 20. The storage unit 12 stores, for example, a debug program for causing the processing unit 20 to execute a debug process for debugging a target CPU and an application execution file 115. The debug program is installed in the storage unit 12 from a computer-readable and non-transient portable storage medium, such as a CD-ROM or a DVD-ROM. The storage unit 12 also stores various data and information used when executing the debug process. For example, the storage unit 12 stores a simulation data structure 120.

[0048] Moreover, the storage unit 12 has an application program unit 122, an application data unit 123, and a dummy structure unit 124. The application program unit 122, the application data unit 123, and the dummy structure unit 124 form a CPU memory 121. The application program unit 122 is an area where an application execution file 115 is stored. The application data unit 123 is an area where program variables are stored when the application execution file 115 is executed. The dummy structure unit 124 is an area where a dummy structure, which is dummy data of the simulation data structure 120, is stored.

[0049] The operation unit 13 is configured to receive operations by an operator who uses the debugging device 1, and includes, for example, a keypad. The operation unit 13 generates a signal in response to the operation by the operator and supplies the signal to the processing unit 20.

[0050] The display unit 14 is configured to display an image, and includes a display such as a liquid crystal display or an organic EL display. The display unit 14 generates an image based on a signal supplied from the processing unit 20 and displays it.

[0051] The processing unit 20 has one or more processors and their peripheral circuits. The processing unit 20 centrally controls the overall operation of the debugging device 1, and is, for example, a CPU. The processing unit 20 executes processing based on programs (driver programs, operating system programs, application programs, etc.) stored in the storage unit 12. The processing unit 20 can also execute multiple programs (application programs, etc.) in parallel.

[0052] The processing unit 20 has a symbolic debugger 21, a debug server 22, an instruction operation unit 24, a compiler 25, and a file acquisition unit 26. The symbolic debugger 21, the debug server 22, the instruction operation unit 24, the compiler 25, and the file acquisition unit 26 are functional modules realized by a program executed by a processor included in the processing unit 20. Alternatively, the symbolic debugger 21, the debug server 22, the instruction operation unit 24, the compiler 25, and the file acquisition unit 26 may be implemented in the debugging device 1 as firmware. The instruction operation unit 24, together with the simulation data structure 120 and the CPU memory 121, forms a CPU simulator 23.

[0053] (CPU simulator generation process executed by the debugging device according to the first embodiment) Fig. 4 is a flowchart of a CPU simulator generation process executed by the debugging device 1. The CPU simulator generation process shown in Fig. 4 is executed mainly by the processing unit 20 in cooperation with each element of the debugging device 1, based on a program stored in advance in the storage unit 12.

[0054] First, the compiler 25 compiles the CPU model source file 111 (S101). The CPU model source file 111 is written in the C++ language. The compiler 25 stores the compiled CPU model source file 111 in the storage unit 12.

[0055] FIG. 5(a) is a diagram showing an example of a CPU model source file 111 corresponding to a target CPU, and FIG. 5(b) is a diagram showing a hardware configuration of the target CPU corresponding to the CPU model source file 111 shown in FIG. 5(a).

[0056] The target CPU 50 has a fetch unit 51, a decode unit 52, an execution unit 53, a memory unit 54, and a write-back unit 55, reads data from the CPU memory 56, executes a predetermined process, and writes execution result information indicating the execution result to the CPU memory 56. The fetch unit 51 has a fetch circuit 51a and an instruction cache memory 51b, and reads an instruction code from the CPU memory 56. The decode unit 52 has a decode circuit 52a and a general-purpose register 52b also called a CPU register, and analyzes the instruction code read by the fetch unit 51. The execution unit 53 has an execution circuit 53a, and executes an operation corresponding to the instruction code in an arithmetic unit (not shown) arranged inside the target CPU 50. The memory unit 54 has a memory circuit 54a and a data cache memory 54b, and stores the result of the operation executed by the execution unit 53. The write-back unit 55 writes the result of the operation executed by the execution unit 53 to the general-purpose register 52b and the CPU memory 56. The target CPU 50 is an example of a processor, the instruction cache memory 51b, the general-purpose register 52b and the data cache memory 54b are examples of a plurality of internal storage circuits, and the CPU memory 56 is an example of an external storage circuit connected to the processor.

[0057] The CPU model source file 111 has models corresponding to the instruction cache memory 51b, the general-purpose register 52b, and the data cache memory 54b. The CPU model source file 111 also has models corresponding to input / output terminals of the fetch unit 51, the decode unit 52, the execution unit 53, the memory unit 54, and the write-back unit 55, and internal registers of the fetch unit 51, the decode unit 52, the execution unit 53, the memory unit 54, and the write-back unit 55. The simulation data structure 120 stores data of internal storage circuits such as registers included in the CPU model source file 111, and input / output terminals of the fetch unit 51 to the write-back unit 55, which are functional blocks included in the CPU model source file 111.

[0058] Next, the compiler 25 compiles the CPU simulator source file 110 (S102). The CPU simulator source file 110 is written in the C++ language, similar to the CPU model source file 111. The compiler 25 stores the compiled CPU simulator source file 110 in the storage unit 12.

[0059] Next, the file acquisition unit 26 acquires the application execution file 115 generated by compiling the application source program 114 by the target CPU (S103). The application source program 114 is an example of a software source file including a plurality of program variables and describing a process including a plurality of steps to be executed by a processor in a programming language. The programming language in which the application source program 114 is described may be the same as or different from the programming language in which the CPU model source file 111 is described. The file acquisition unit 26 stores the acquired application execution file 115 in the application program section 122 of the storage unit 12. In response to the application execution file 115 being stored in the application program section 122 of the storage unit 12, the dummy structure is stored in the dummy structure section 124.

[0060] FIG. 6 is a diagram showing an example of the application source program 114. As shown in FIG.

[0061] The application source program 114 has a declaration section “CPU cpu;.” Since the application source program 114 has the declaration section “CPU cpu;,” the CPU model source file 111 shown in FIG.

[0062] The file acquisition unit 26 acquires the application execution file 115, whereby the CPU simulator 23 is formed.

[0063] Then, the file acquisition unit 26 acquires address values ​​indicating the area where the simulation data structure 120 is stored, the application program section 122, the application data section 123, and the dummy structure section 124 (S104). The file acquisition unit 26 acquires address values ​​indicating the area where the simulation data structure 120 is stored, which is included in the CPU simulator source file 110 compiled in the process of S102. The file acquisition unit 26 also acquires address values ​​indicating the application program section 122, the application data section 123, and the dummy structure section 124 where the application execution file 115, program variables, and dummy structures are stored. The file acquisition unit 26 stores the acquired address values ​​in the storage unit 12 in association with the area where the simulation data structure 120 is stored, the application program section 122, the application data section 123, and the dummy structure section 124, respectively.

[0064] (Debugging process executed by the debugging device according to the first embodiment) Fig. 7 is a flowchart of the debugging process executed by the debugging device 1. The debugging process shown in Fig. 7 is executed mainly by the processing unit 20 in cooperation with each element of the debugging device 1, based on a program stored in advance in the storage unit 12.

[0065] First, the symbolic debugger 21 acquires a debug instruction (S201). The symbolic debugger 21 acquires a debug instruction from the SW developer via the operation unit 13. The symbolic debugger 21 stores the acquired instruction in the storage unit 12.

[0066] Next, the symbolic debugger 21 provides the debug instruction acquired in the process of S201 to the debug server 22 (S202). When the debug instruction includes an instruction to monitor and control a program variable, the symbolic debugger 21 provides the debug instruction in association with an address value indicating the application data unit 123. When the debug instruction includes an instruction to monitor and control data stored in the simulation data structure 120, the symbolic debugger 21 provides the debug instruction in association with an address value indicating the dummy structure unit 124. The debug server 22 stores the provided debug instruction in the storage unit 12.

[0067] Next, the debug server 22 provides the provided debug instruction to the instruction operation unit 24 (S203). The debug server 22 determines whether the debug instruction is related to a program variable, memory data stored in a plurality of internal memory circuits such as registers of the CPU and an external memory circuit, or input / output data input / output by the processor. Specifically, the debug server 22 determines whether the debug instruction is associated with an address value indicating either the application data unit 123 or the dummy structure unit 124. When the debug server 22 determines that the debug instruction is associated with an address value indicating the application data unit 123, the debug server 22 determines that the debug instruction is related to a program variable, and rewrites the variable stored in the application execution file stored in the application program unit 122. When the debug server 22 determines that the debug instruction is associated with an address value indicating the dummy structure unit 124, the debug server 22 determines that the debug instruction is related to any of memory data stored in a plurality of internal memory circuits and an external memory circuit, or input / output data input / output by the processor, and rewrites the data held in the simulation data structure 120.

[0068] Next, the instruction operation unit 24 executes processing according to the debug instruction provided from the debug server in the processing of S203 (S204). The instruction operation unit 24 stores execution result information indicating the execution result of the processing in the simulation data structure 120 and the application data unit 123.

[0069] Next, the debug server 22 acquires execution result information of the process from the CPU simulator 23 (S205). The debug server 22 determines whether a debug instruction is associated with an address value indicating either the application data unit 123 or the dummy structure unit 124. When the debug server 22 determines that a debug instruction is associated with an address value indicating the application data unit 123, the debug server 22 reads out program variables stored in the application data unit 123. When the debug server 22 determines that a debug instruction is associated with an address value indicating the dummy structure unit 124, the debug server 22 reads out data held in the simulation data structure 120. The debug server 22 stores the acquired execution result information in the storage unit 12.

[0070] Next, the debug server 22 provides the execution result information acquired in the process of S205 to the symbolic debugger 21 as a debug response (S206). The symbolic debugger 21 stores the provided debug response in the storage unit 12.

[0071] Then, the symbolic debugger 21 outputs the debug response provided in the process of S206 to the display unit 14 (S207). In response to the input of the debug response, the display unit 14 displays a debug response image indicating the debug response. The SW developer visually recognizes the debug response image displayed on the display unit 14.

[0072] (Functions and Effects of the Debugging Device According to the First Embodiment) The debugging device 1 allows the CPU simulator 120 to execute a simulation so that the debug server 22 monitors and controls the simulation data structure 120, thereby making it possible to simultaneously execute verification of software and hardware modules while suppressing increases in verification costs.

[0073] Furthermore, the debugging device 1 can monitor and control the simulation data structure 120 since the CPU memory 121 has a dummy structure section 124 that stores dummy data of the simulation data structure 120 .

[0074] Furthermore, the debugging device 1 can easily determine whether the debugging instruction relates to a program variable or the simulation data structure 120 based on the address values ​​of the application data portion 123 and the dummy structure portion 124 .

[0075] In addition, the debugging device 1 does not update the dummy structure stored in the dummy structure section 124, and instead obtains execution result information from the simulation data structure 120, thereby omitting the process of updating the dummy structure and reducing verification costs.

[0076] Furthermore, the debugging device 1 can easily store the dummy structure in the dummy structure unit 124 by declaring the CPU model as a global variable in the application source program.

[0077] (Overview of the debugging device according to the second embodiment) 8 is a schematic diagram of a debugging device according to the second embodiment. The debugging device 2 according to the second embodiment is a cross-development SW debugging device.

[0078] The debugging device 2 according to the second embodiment differs from the debugging device 1 in that it has an SoC simulator 28 instead of the CPU simulator 23. The configurations and functions of the components of the debugging device 2 other than the SoC simulator 28 are the same as the configurations and functions of the components of the debugging device 1 that are given the same reference numerals, and therefore detailed description will be omitted here. The SoC simulator 28 is another example of a simulator that executes a simulation of processing described in software using a hardware module model and a software execution file.

[0079] The SoC simulator 28 includes a simulation data structure 320, a CPU memory 321, an instruction operation unit 41, a bus logic operation unit 42, and a first hardware logic operation unit 431 to an N-th hardware logic operation unit 43N. The SoC simulator 28 is generated by compiling an SoC simulator source file 130 and an SoC model source file 131 written in a programming language, for example, the C++ language.

[0080] The SoC simulator source file 130 executes processing in response to a debug command provided by the debug server 22. The SoC simulator source file 130 executes processing such as registering an execution interruption condition for the application execution file 133, reading and rewriting data included in the simulation data structure 320, and reading and rewriting program variables stored in the CPU memory 321. The SoC simulator source file 130 provides the debug server 22 with a debug response indicating the processing result of the debug command.

[0081] FIG. 9A is a schematic diagram of the SoC model source file 131. As shown in FIG.

[0082] The SoC model source file 131 includes a CPU model 131a that simulates a CPU mounted on the SoC, and a bus module model 131b that simulates a bus module that connects the CPU to other hardware modules. The SoC model source file 131 also includes a first hardware module model 131c1 to an N-th hardware module model 131cN that simulate hardware modules connected to the CPU via the bus modules. The hardware modules simulated by the first hardware module model 131c1 to the N-th hardware module model 131cN include at least one of a hardware accelerator and an I / O circuit.

[0083] The CPU model 131a has a CPU internal hardware state data structure 131d that simulates the internal data structure of the CPU. It has a bus internal state data structure 131e that simulates the internal data structure of a bus module. The first hardware module model 131c1 to the Nth hardware module model 131cN are models that simulate the internal data structures of hardware modules. The first hardware module model 131c1 to the Nth hardware module model 131cN have a first hardware internal state data structure 131f1 to the Nth hardware internal state data structure 131fN.

[0084] The data structure 320 is a simulation of the internal data structure of the target CPU, and stores data that is stored in registers and the like arranged inside the target CPU when the CPU simulator 103 simulates the instruction operation of the target CPU.

[0085] FIG. 9B is a diagram showing the data structure of the simulation data structure 320. As shown in FIG.

[0086] The simulation data structure 320 includes a CPU internal hardware state data structure 320a, a bus internal state data structure 320b, and a first hardware internal state data structure 320c1 through an N-th hardware internal state data structure 320cN. The data structure 320 is generated by compiling the SoC model source file 131. The CPU internal hardware state data structure 320a corresponds to the CPU internal hardware state data structure 131d, and the bus internal state data structure 320b corresponds to the bus internal state data structure 131e. The first hardware internal state data structure 320c1 through the N-th hardware internal state data structure 320cN correspond to the first hardware internal state data structure 131f1 through the N-th hardware internal state data structure 131fN.

[0087] The instruction operation unit 41 simulates the operation of a CPU implemented in the SoC, and executes processing according to a debug instruction provided by the debug server 102. The bus logic operation unit 42 simulates the logical operation of a bus module that connects the CPU and hardware modules implemented in the SoC. The first hardware logic operation unit 431 to the Nth hardware logic operation unit 43N simulate the logical operation of the hardware modules implemented in the SoC.

[0088] The CPU memory 321 simulates a memory area when a CPU implemented in an SoC executes processing, and includes an application program section 322, an application data section 323, and a dummy structure section 324. The application program section 322 stores an application execution file 133 generated by compiling an application source program 132 by the target CPU. The application data section 323 stores program variables used when the SoC simulator 28 simulates the instruction operation of the CPU.

[0089] The dummy structure unit 324 stores the application execution file 133 compiled from the application source program 132 in the CPU memory, whereby a dummy structure that is dummy data of the simulation data structure 320 is stored in the CPU memory 121 .

[0090] A hardware module model indicating the SoC is declared as a global variable in the application source program 132. By declaring the SoC as a global variable in the application source program 132, a dummy structure is stored in the dummy structure unit 324 of the CPU memory 321.

[0091] In the debugging process executed by the debugging device 2, first, the symbolic debugger 21 provides a debugging command to the debug server 22 in response to an instruction from the SW developer (S31). The debugging command provided by the symbolic debugger 21 includes an observation command for displaying data held in the simulation data structure 320 and a control command for rewriting the data held in the simulation data structure 320.

[0092] Next, the debug server 22 provides the debug command provided by the symbolic debugger 21 to the command execution unit 41 (S32).

[0093] Next, in response to the debug command provided by the debug server 22, the instruction operating unit 41 executes processing according to the debug command (S33). The instruction operating unit 41 executes debug commands instructing to register an execution interruption condition for the application execution file 113 and to read and rewrite data included in the simulation data structure 320 as processing for the simulation data structure 320 in which the corresponding data is stored. Also, the instruction operating unit 41 executes debug commands instructing to read and rewrite program variables as processing for the CPU memory 321.

[0094] Next, the command operating unit 41 provides a debug response corresponding to the provided debug command to the debug server 22 (S34). Then, the debug server 22 provides the debug response provided by the command operating unit 41 to the symbolic debugger 21 (S35).

[0095] The debugging device 2 can debug the SoC and the application executable file 133 by monitoring and controlling the execution state of the application executable file 133, program variables, and data held in the simulation data structure 320 in accordance with instructions from the SW developer.

[0096] (Configuration and Functions of Debugging Device According to Second Embodiment) FIG. 10 is a block diagram of a debugging device according to the second embodiment.

[0097] The debug device 2 differs from the debug device 1 in that the debug device 2 has a storage unit 32 and a processing unit 40 instead of the storage unit 12 and the processing unit 20. The configurations and functions of the components of the debug device 2 other than the storage unit 32 and the processing unit 40 are the same as the configurations and functions of the components of the debug device 1 with the same reference numerals, and therefore detailed description thereof will be omitted here.

[0098] The storage unit 32 differs from the storage unit 12 in that the storage unit 32 stores a simulation data structure 320 instead of the simulation data structure 120. The storage unit 32 differs from the storage unit 12 in that the storage unit 32 has an application program section 322, an application data section 323, and a dummy structure section 324 instead of the application program section 122, the application data section 123, and the dummy structure section 124. The application program section 322, the application data section 323, and the dummy structure section 324 form a CPU memory 321. The application program section 322 is an area in which the application execution file 133 is stored. The application data section 323 is an area in which program variables are stored when the application execution file 133 is executed. The dummy structure section 324 is an area in which a dummy structure, which is dummy data of the simulation data structure 320, is stored.

[0099] The processing unit 40 differs from the processing unit 20 in that it has an instruction operation unit 41, a bus logic operation unit 42, and first hardware logic operation units 431 to Nth hardware logic operation units 43N instead of the instruction operation unit 24. The configurations and functions of the processing unit 40 other than the instruction operation unit 41, the bus logic operation unit 42, and the first hardware logic operation units 431 to Nth hardware logic operation units 43N are the same as those of the processing unit 20, so detailed description will be omitted here. The instruction operation unit 41 forms the CPU simulator 28 together with the simulation data structure 320 and the CPU memory 321.

[0100] (SoC simulator generation process executed by the debug device according to the second embodiment) Fig. 11 is a flowchart of the SoC simulator generation process executed by the debugging device 2. The SoC simulator generation process shown in Fig. 11 is executed mainly by the processing unit 40 in cooperation with each element of the debugging device 2, based on a program stored in advance in the storage unit 32.

[0101] First, the compiler 25 compiles the SoC model source file 131 (S301). The SoC model source file 131 is written in the C++ language. The compiler 25 stores the compiled SoC model source file 131 in the storage unit 32.

[0102] FIG. 12(a) is a diagram showing an example of an SoC model source file 131 corresponding to an SoC, FIG. 12(b) is a diagram showing an example of a sub-model of the SoC model source file 131 shown in FIG. 12(a), and FIG. 12(c) is a diagram showing the hardware configuration of an SoC corresponding to the SoC model source file 131.

[0103] The SoC 60 has a CPU 50, a CPU memory 56, a bus module 61, and a first hardware module 621 to an Nth hardware module 62N. The CPU 50 and the CPU memory 56 have been described with reference to FIG. 5, and detailed description thereof will be omitted here. The bus module 61 connects the CPU 50, the CPU memory 56, and the first hardware module 621 to the Nth hardware module 62N so that they can communicate with each other. The first hardware module 621 to the Nth hardware module 62N are hardware circuits implemented in the SoC 60.

[0104] The SoC model source file 131 has models corresponding to the CPU 50, CPU memory 56, bus module 61, and first hardware module 621 to Nth hardware module 62N. The simulation data structure 320 stores data of internal storage circuits such as registers included in the CPU model 131a, and input / output terminals of the fetch unit 51 to write-back unit 55 which are functional blocks included in the CPU model 131a. The simulation data structure 320 also stores data of input / output terminals of the bus module 61, and the first hardware module 621 to Nth hardware module 62N.

[0105] Next, the compiler 25 compiles the SoC simulator source file 130 (S302). The SoC simulator source file 130 is written in the C++ language, similar to the SoC model source file 131. The compiler 25 stores the compiled SoC simulator source file 130 in the storage unit 32.

[0106] Next, the file acquisition unit 26 acquires the application execution file 133 generated by compiling the application source program 132 by the target CPU (S303). The file acquisition unit 26 stores the acquired application execution file 133 in the application program section 322 of the storage unit 32. In response to the application execution file 133 being stored in the application program section 322 of the storage unit 12, the dummy structure is stored in the dummy structure section 324.

[0107] FIG. 13 is a diagram showing an example of the application source program 132. As shown in FIG.

[0108] The application source program 132 has a declaration section “SoC soc;.” Since the application source program 132 has the declaration section “SoC soc;,” the SoC model source file 131 shown in FIG.

[0109] The file acquisition unit 26 acquires the application execution file 133, whereby the SoC simulator 28 is formed.

[0110] Then, the file acquisition unit 26 acquires address values ​​indicating the area where the simulation data structure 320 is stored, the application program section 322, the application data section 323, and the dummy structure section 324 (S304). The file acquisition unit 26 acquires address values ​​indicating the area where the simulation data structure 320 included in the SoC simulator source file 130 compiled in the process of S302 is stored. The file acquisition unit 26 also acquires address values ​​indicating the application program section 322, the application data section 323, and the dummy structure section 324 where the application execution file 133, program variables, and dummy structures are stored. The file acquisition unit 26 stores the acquired address values ​​in the storage unit 32 in association with the area where the simulation data structure 320 is stored, the application program section 322, the application data section 323, and the dummy structure section 324, respectively.

[0111] (Debugging process executed by the debugging device according to the second embodiment) Fig. 14 is a flowchart of the debugging process executed by the debugging device 2. The debugging process shown in Fig. 14 is executed mainly by the processing unit 40 in cooperation with each element of the debugging device 2, based on a program stored in advance in the storage unit 32.

[0112] First, the symbolic debugger 21 acquires a debug command (S401). The symbolic debugger 21 acquires a debug command from the SW developer via the operation unit 13. The symbolic debugger 21 stores the acquired command in the storage unit 12.

[0113] Next, the symbolic debugger 21 provides the debug instruction acquired in the process of S401 to the debug server 22 (S402). When the debug instruction includes an instruction to monitor and control a program variable, the symbolic debugger 21 provides the debug instruction in association with an address value indicating the application data portion 323. When the debug instruction includes an instruction to monitor and control data stored in the simulation data structure 320, the symbolic debugger 21 provides the debug instruction in association with an address value indicating the dummy structure portion 324. The debug server 22 stores the provided debug instruction in the storage portion 32.

[0114] Next, the debug server 22 provides the provided debug instruction to the instruction operation unit 41 (S403). The debug server 22 judges whether the debug instruction is related to a program variable, memory data stored in a plurality of internal memory circuits such as registers of the CPU and an external memory circuit, or input / output data input / output by the processor. Specifically, the debug server 22 judges whether the debug instruction is associated with an address value indicating either the application data unit 323 or the dummy structure unit 324. When the debug server 22 judges that the debug instruction is associated with an address value indicating the application data unit 323, the debug server 22 judges that the debug instruction is related to a program variable, and rewrites the variable stored in the application execution file stored in the application program unit 322. When the debug server 22 judges that the debug instruction is associated with an address value indicating the dummy structure unit 324, the debug server 22 judges that the debug instruction is related to any of memory data stored in a plurality of internal memory circuits and an external memory circuit, or input / output data input / output by the processor, and rewrites the data held in the simulation data structure 320.

[0115] Next, the instruction operation unit 41 executes processing according to the debug instruction provided from the debug server in the processing of S403 (S404). The instruction operation unit 41 stores execution result information indicating the execution result of the processing in the data structure 320 and the application data unit 323.

[0116] Next, the debug server 22 acquires execution result information of the process from the SoC simulator 28 (S405). The debug server 22 determines whether a debug instruction is associated with an address value indicating either the application data unit 323 or the dummy structure unit 324. When the debug server 22 determines that a debug instruction is associated with an address value indicating the application data unit 323, the debug server 22 reads out program variables stored in the application data unit 323. When the debug server 22 determines that a debug instruction is associated with an address value indicating the dummy structure unit 324, the debug server 22 reads out data held in the simulation data structure 320. The debug server 22 stores the acquired execution result information in the storage unit 32.

[0117] Next, the debug server 22 provides the execution result information acquired in the process of S405 to the symbolic debugger 21 as a debug response (S406). The symbolic debugger 21 stores the provided debug response in the storage unit 32.

[0118] Then, the symbolic debugger 21 outputs the debug response provided in the process of S406 to the display unit 14 (S407). In response to the input of the debug response, the display unit 14 displays a debug response image indicating the debug response. The SW developer visually recognizes the debug response image displayed on the display unit 14.

[0119] (Functions and Effects of the Debugging Device According to the Second Embodiment) The debugging device 1 performs a simulation using an SoC model including a CPU model, thereby enabling monitoring and control of not only the CPU but also hardware modules connected to the CPU. [Explanation of symbols]

[0120] 1, 2 Debugging device 21 Symbolic Debugger 22 Debug Server 23 CPU Simulator 24, 41 Instruction operation section 25 Compiler 26 File Acquisition Section 28 SoC Simulator 120, 320 Simulation Data Structure 121, 321 CPU memory 122, 322 Application Program Section 123, 323 Application Data Section 124, 324 Data structure section

Claims

1. a hardware module model generated by compiling a hardware source file describing the operation of a hardware module including a processor having a plurality of internal storage circuits each for storing data, executing a process in response to input of data and outputting data in accordance with an execution state, and an external storage circuit connected to the processor for storing data; a storage unit for storing a software execution file generated by compiling a software source file including a plurality of program variables and describing a process including a plurality of steps to be executed by the processor; a simulator that executes a simulation of a process described in the software source file by using the hardware module model and the software execution file; a monitoring control unit that provides, in a simulation by the simulator, instructions for monitoring and controlling the software execution file, the program variables, execution state data indicating an execution state of the processor, memory data stored in the multiple internal memory circuits and the external memory circuit of the processor, and input / output data input / output by the processor; a simulator control unit that causes the simulator to execute the simulation, The simulator control unit determining whether the supervisory control instruction relates to the program variables, the execution state data, the stored data, or the input / output data; when it is determined that the monitoring and control instruction relates to any one of the execution state data, the storage data, and the input / output data, causing the simulator to execute the simulation so as to monitor and control the execution state data, the storage data, and the input / output data; providing execution result information indicating an execution result of the simulation to the monitoring control unit; The monitoring control unit outputs the execution result information. A debugging device comprising:

2. The simulator comprises: a simulation data structure indicative of the execution state data, the stored data, and the input / output data; an instruction operation unit that updates data corresponding to the simulation data structure and executes a process including the steps described in the software source file; a CPU memory for storing the software execution file, the program variables, and a dummy structure that is dummy data for the simulation data structure; 2. The debugging apparatus of claim 1, comprising:

3. the monitoring control unit provides the monitoring control instruction in association with an address value of an area in which either the program variable or the dummy structure is stored; 3. The debugging device according to claim 2, wherein said simulator control section determines whether the address value relates to said program variable, said execution state data, said storage data, or said input / output data, based on said address value.

4. the dummy structure is not updated by the simulator; the simulator control unit acquires the execution result information from the simulation data structure when the address value input together with the monitoring control instruction is associated with the dummy structure; 4. The debugging device according to claim 3.

5. the hardware module further includes a logical hardware model that is at least one of a hardware accelerator, a bus module, and an I / O circuit; the execution state data indicates an execution state of the logical hardware model in addition to an execution state of the processor; the stored data includes data stored in the logical hardware model in addition to data stored in the plurality of internal storage circuits and the external storage circuit; the input / output data includes data input / output to / from the logical hardware model in addition to data input / output to / from the processor; The simulator comprises: a simulation data structure indicative of the execution state data, the stored data, the input / output data, and an instruction operation unit that updates data corresponding to the simulation data structure and executes a process including the steps described in the software source file; a logic operation unit that updates data corresponding to the simulation data structure to execute a logic operation of the logic hardware model; a CPU memory for storing the software execution file, the program variables, and a dummy structure that is dummy data for the simulation data structure; 2. The debugging apparatus of claim 1, comprising:

6. The debugging apparatus according to claim 5 , wherein the hardware module model is declared as a global variable in the software source file.

7. a hardware module model generated by compiling a hardware source file describing the operation of a hardware module including a processor having a plurality of internal storage circuits each for storing data, executing a process in response to input of data and outputting data in accordance with an execution state, and an external storage circuit connected to the processor for storing data; a storage unit for storing a software execution file generated by compiling a software source file including a plurality of program variables and describing a process including a plurality of steps to be executed by the processor; a simulator that executes a simulation of a process described in the software source file by using the hardware module model and the software execution file; a monitoring control unit that provides, in a simulation by the simulator, instructions for monitoring and controlling the software execution file, the program variables, execution state data indicating an execution state of the processor, memory data stored in the multiple internal memory circuits and the external memory circuit of the processor, and input / output data input / output by the processor; a simulator control unit that causes the simulator to execute the simulation, determining whether the supervisory control instruction relates to the program variables, the execution state data, the stored data, or the input / output data; when it is determined that the monitoring and control instruction relates to any one of the execution state data, the storage data, and the input / output data, causing the simulator to execute the simulation so as to monitor and control the execution state data, the storage data, and the input / output data; providing execution result information indicating an execution result of the simulation to the monitoring control unit; outputting the execution result information; 13. A method for controlling a debugging device, comprising:

8. a hardware module model generated by compiling a hardware source file describing the operation of a hardware module including a processor, each of which has a plurality of internal storage circuits for storing data, which executes processing in response to input of data and outputs data in accordance with an execution state, and an external storage circuit connected to the processor and for storing data; a storage unit for storing a software execution file generated by compiling a software source file including a plurality of program variables and describing a process including a plurality of steps to be executed by the processor; a simulator that executes a simulation of a process described in the software source file by using the hardware module model and the software execution file; a monitoring control unit that provides, in a simulation by the simulator, instructions for monitoring and controlling the software execution file, the program variables, execution state data indicating an execution state of the processor, memory data stored in the multiple internal memory circuits and the external memory circuit of the processor, and input / output data input / output by the processor; a simulator control unit that causes the simulator to execute the simulation, determining whether the supervisory control instruction relates to the program variables, the execution state data, the stored data, or the input / output data; when it is determined that the monitoring and control instruction relates to any one of the execution state data, the storage data, and the input / output data, causing the simulator to execute the simulation so as to monitor and control the execution state data, the storage data, and the input / output data; providing execution result information indicating an execution result of the simulation to the monitoring control unit; outputting the execution result information; A control program for a debugging device, which causes a computer to execute a process.

Images