JP5120103B2 - Debugging method and debugging program - Google Patents

Description

  The present invention relates to a technology for debugging software on a computer with respect to a system (hardware / software mixed system) realized by combining hardware including a CPU (Central Processing Unit) and software executed by the CPU.

  FIG. 15 shows an example of SoC (System on Chip). FIG. 16 shows an example of the SoC development process. As shown in FIG. 15, a hardware / software mixed system such as SoC 6 in which a CPU 1 for executing firmware, a memory 2 for storing various data, and functional blocks 3, 4, 5, etc. for implementing various peripheral functions are integrated is developed. In this case, as shown in FIG. 16, the specification determination, implementation and verification are sequentially performed for each of hardware and software (firmware executed on the CPU), and then the system is realized by combining the hardware and software. It is necessary to carry out verification (system level verification). In debugging a hardware / software mixed system, it is necessary to check the status of both the hardware and software in order to determine whether there is a problem on the hardware side or the software side when a failure occurs.

  As a method for verifying a hardware / software mixed system, a hardware / software co-verification method is known. In the hardware / software co-verification method, the operation of hardware other than the CPU is executed by a logic simulator or the like, and the operation of the CPU (software execution) is executed by an instruction set simulator (ISS: Instruction Set Simulator). The ISS, the logic simulator, and the like are connected to each other, and by reproducing data exchange between the CPU and hardware other than the CPU, the operation as a system combining the CPU and other hardware is reproduced. Hardware / software co-verification methods include a method using a logic simulator (co-simulation) and a method using a logic emulator (co-emulation).

  FIG. 17 shows an outline of co-simulation. In co-simulation, a source file is built (compiled and linked) for software executed by the CPU to generate an execution file, and then the software source file and execution file and HDL (Hardware Design Language) related to hardware other than the CPU Simulation is executed by the ISS and logic simulator with the description file as an input. For example, the co-simulation is realized by using a software development tool 12 (comprising an ISS 13 and a debugger 14) and a logic simulator 15 on the computer 11, as shown in FIG. In this case, the operation of hardware other than the CPU is executed by the logic simulator 15, the operation of the CPU is executed by the ISS 13, and the software debugging function is realized by the debugger 14 connected to the ISS 13. In such a co-simulation, since a lot of time is required for the simulation related to hardware other than the CPU, this becomes a bottleneck, and there is a problem that the execution speed becomes slow, for example, about several tens to several hundreds Hz. For example, it may take several hours to reach a breakpoint after starting simulation execution. Therefore, using co-simulation for software debugging is not practical.

FIG. 18 shows an outline of co-emulation. In the co-simulation, the operation of hardware other than the CPU is executed by the logic simulator, whereas in the co-emulation, the operation of hardware other than the CPU is executed by the logic emulator. For example, the co-emulation is realized using an emulator control tool 22 (comprising an ISS 23 and a debugger 24) on the computer 21 and a logic emulator 25 connected to the computer 21, as shown in FIG. In such co-emulation, in addition to the ISS execution speed being slower than the logic emulator execution speed (1 MHz), the computer equipped with the ISS and the logic emulator are physically separate devices, Due to the presence of an interface portion for connecting the two, the execution speed is significantly reduced. For this reason, there is a problem that the execution speed becomes slow, for example, about several tens of kHz, compared to the case where the entire hardware including the CPU is mapped to the emulator and operated as a single emulator.
JP 2002-366602 A

  For both co-simulation and co-emulation, the execution speed was very slow, and it was difficult to perform software debugging in a short time.

  An object of the present invention is to perform software debugging for a hardware / software mixed system in a short time.

  In one aspect of the present invention, the first to third steps are performed when debugging software on a computer for a system realized by combining hardware including a CPU and software executed by the CPU. In the first step, a waveform data file generated by system simulation, a CPU definition file defining CPU components, a software source file, and a software execution file are input. In the second step, time information and CPU internal operation information are acquired based on the waveform data file and the CPU definition file, and the software execution state of the CPU is reproduced. In the third step, debug information is displayed based on time information, CPU internal operation information, software source file, and software execution file.

  Software debugging can be performed in a short time for a hardware / software mixed system. As a result, it can greatly contribute to shortening the development period of the hardware / software mixed system.

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

  FIG. 1 shows an embodiment of the present invention. FIG. 2 shows an example of the CPU definition file. FIG. 3 shows details of the software debug unit. FIG. 4 shows an example of a debug API (Application Program Interface). FIG. 5 shows an example of the waveform information acquisition API.

  In one embodiment of the present invention, as shown in FIG. 1, a source file 110 is built (compiled) by a compiler / linker 200 on a computer 100 for software executed by a CPU in the SoC before debugging the SoC. And link) to generate an execution file 120 (binary file). At this time, the source file 110 is built with a debug option so that additional information for debugging (information indicating the correspondence between instruction addresses and source code lines, etc.) is included in the execution file 120.

  Next, the HDL description file 130 of the entire SoC (including the CPU) is mapped to the emulator 300, and the execution file 120 is loaded into the memory in the emulator 300, and then the emulator 300 is emulated to execute the waveform data file. 140 is generated. The waveform data file 140 includes information such as signal names, signal values, and times of internal signals of hardware including the CPU. The waveform data file 140 has a VCD (Value Change Dump) file defined by Verilog-HDL.

  Thereafter, a hardware debugging function (internal signal waveform display) and a software debugging function (initialization, breakpoint setting, continuous execution, step execution, source code display, variable value display, etc. realized by the debug program 400 on the computer 100 SoC debugging is performed using memory data display or the like. As a result, hardware and software can be debugged simultaneously as in the case of using co-simulation or co-emulation.

  The debug program 400 receives a source file 110, an execution file 120, a waveform data file 140, and a CPU definition file 150 as input, and includes a GUI (Graphical User Interface) such as a debug control unit 160, a debug information output unit 170, and a waveform information output unit 180. Debug function is realized by linking with. For example, the debug program 400 implements a software debug unit 410 that implements a software debug function, a waveform information acquisition unit 420 that obtains information such as time and signal values from the waveform data file 140, and a waveform display function (hardware debug function). The waveform information display unit 430 and the like are implemented.

  The source file 110 is used for displaying source code, and the execution file 120 is used for displaying source code and variable values. The waveform data file 140 is used at the time of waveform display, and is used at the time of acquiring information related to the internal operation of the CPU in order to realize a software debugging function. The CPU definition file 150 is used when acquiring information related to the internal operation of the CPU from the waveform data file 140. For example, as shown in FIG. 2, the CPU definition file 150 includes basic components of the CPU (clock, reset, program counter, stack pointer, frame pointer, status register, instruction memory, data memory, general-purpose register, etc.) It includes information on the signal name of the corresponding internal signal. The debug control unit 160 also performs various processes for realizing the software debugging function (initialization process, breakpoint setting process, continuous execution process, step execution process, source code display process, variable value display process, memory data display process, etc. Etc.) is used when entering commands. The debug information output unit 170 is used when displaying debug information (source code, variable value, memory data, etc.). The waveform information output unit 180 is used when displaying waveform information.

  For example, as shown in FIG. 3, the software debug unit 410 includes a debug processing unit 411 and a debug information acquisition unit 416. The debug processing unit 411 uses the debug API to acquire necessary information from the debug information acquisition unit 416 to realize functions such as source code display, variable value display, and memory data display, and also to the debug information acquisition unit 416. Issue necessary instructions to implement functions such as initialization, breakpoint setting, continuous execution and step execution. For example, the debug processing unit 411 includes an initialization control unit 412 for realizing an initialization function, an execution control unit 413 for realizing a continuous execution function and a step execution function, and break control for realizing a breakpoint setting function. A debug information display unit 415 for realizing a unit 414, a source code display function, a variable value display function, and a memory data display function.

  The debug information acquisition unit 416 acquires the time and the value of the component (internal signal) of the CPU from the waveform information acquisition unit 420 (waveform data file 140) using the waveform information acquisition API based on the CPU definition file 150. Since the CPU definition file 150 is used when acquiring information from the waveform information acquisition unit 420 (waveform data file 140), it is easy to change the contents of the CPU definition file 150 even when the CPU type is changed. It becomes possible to cope with. When co-simulation or co-emulation is used, an ISS is required, and therefore hardware and software cannot be debugged simultaneously if the ISS is not provided by the CPU vendor.

  For example, the debug information acquisition unit 416 communicates with the waveform information acquisition unit 420 using the waveform information acquisition API, and the debug information acquisition unit 417 and the debug processing unit 411 using the debug API. A debug information processing unit 418 that performs transmission / reception of information, an information holding unit 419 that holds a time, the number of clock cycles, a value of a program counter (PC), a value of a breakpoint, and the like are included. Note that the number of clock cycles held by the information holding unit 419 indicates what cycle the time held by the information holding unit 419 corresponds to from the simulation start time in the waveform data file 140. In the information holding unit 419, a value obtained by dividing the held time by the time of one cycle of the clock signal in the CPU calculated in advance based on the waveform data file 140 is held as the number of clock cycles.

  In the debug information acquisition unit 416, the time, the number of clock cycles, and the value of the program counter are held, so that it is possible to specify which part of the software is being executed at a certain time. Therefore, the debug information acquisition unit 416 supplies information related to the internal operation of the CPU to the debug processing unit 411 based on the time, the number of clock cycles, and the value of the program counter, so that the software is not actually executed. Regardless, it becomes possible to respond to the debug processing unit 411 so that the CPU is operating in a pseudo manner.

  As types of debug APIs, for example, as shown in FIG. 4, initialization API, breakpoint setting API, continuous execution API, step execution API, PC read API, memory read API, break occurrence notification API, and execution stop Notification API and the like. In the initialization API, the debug processing unit 411 holds the software execution start position information (the occurrence time of the falling edge of the reset signal in the CPU and the value of the program counter in the CPU corresponding to the time) in the debug information acquisition unit 416. Used when making The breakpoint setting API is used when the debug processing unit 416 causes the debug information acquisition unit 416 to hold a specified breakpoint value. The continuous execution API is used when the debug processing unit 411 causes the debug information acquisition unit 416 to advance the value of the program counter to a breakpoint value, a value after the specified number of steps, or a value corresponding to the end of the software. The The step execution API is used when the debug processing unit 411 causes the debug information acquisition unit 416 to advance the value of the program counter to a value after one step. The PC read API is used when the debug processing unit 411 acquires the value of the program counter in the CPU from the debug information acquisition unit 416. The memory read API is used when the debug processing unit 411 acquires data at a specified address of the memory in the CPU from the debug information acquisition unit 416. The break occurrence notification API is used when the debug information acquisition unit 416 notifies the debug processing unit 411 of the occurrence of a break (a match between the program counter value and the breakpoint value). The execution stop notification API is used when the debug information acquisition unit 416 notifies the debug processing unit 411 of execution stop (end of processing for updating the value of the program counter).

  Examples of the waveform information acquisition API include a signal value acquisition API and a signal change position acquisition API as shown in FIG. The signal value acquisition API is used when the debug information acquisition unit 416 acquires the value of the specified time from the waveform information acquisition unit 420 regarding the signal with the specified signal name. The signal change position acquisition API includes a time at which a specified edge (rising edge, falling edge, or both edges) is first generated after a specified time with respect to a signal having a specified signal name by the debug information acquiring unit 416 and a signal value (change) at that time. This is used when the later signal value is acquired from the waveform information acquisition unit 420.

  Here, various processes (initialization processing, breakpoint setting processing, continuous execution processing, step execution processing, source code display processing, variable value display processing, memory data display processing, and waveform display processing) for realizing the debug function explain.

  FIG. 6 shows the initialization process. FIG. 6A shows the data flow during the initialization process, and FIG. 6B shows the operation during the initialization process. When an initialization command is input via the debug control unit 160 (GUI), the debug processing unit 411 issues an initialization instruction to the debug information acquisition unit 416. Accordingly, the debug information acquisition unit 416 receives the reset release position information (the generation time of the falling edge of the reset signal in the CPU and the CPU corresponding to the time from the waveform data file 140 via the waveform information acquisition unit 420). Of the program counter) is acquired (step S11). The debug information acquisition unit 416 holds the time acquired from the waveform data file 140 and the value of the program counter (step S12). Thereby, the software execution state of the CPU reproduced by the debug information acquisition unit 416 is set to the state at the start of software execution.

  FIG. 7 shows a breakpoint setting process. FIG. 7A shows the data flow during the breakpoint setting process, and FIG. 7B shows the operation during the breakpoint setting process. When a breakpoint setting command (including a breakpoint value) is input via the debug control unit 160 (GUI), the debug processing unit 411 issues a breakpoint setting instruction to the debug information acquisition unit 416. Accordingly, the debug information acquisition unit 416 holds the breakpoint value supplied from the debug processing unit 411 (step S21). A plurality of values can be set for the breakpoint.

  FIG. 8 shows the continuous execution process. FIG. 8A shows the data flow during the continuous execution process, and FIG. 8B shows the operation during the continuous execution process. When a continuous execution command (including the number of steps) is input via the debug control unit 160 (GUI), the debug processing unit 411 issues a continuous execution instruction to the debug information acquisition unit 416. Along with this, the debug information acquisition unit 416 receives the PC change position information (the time when the value of the program counter changes next and the value after the change of the program counter) from the waveform data file 140 via the waveform information acquisition unit 420. Obtain (step S31). The debug information acquisition unit 416 holds the time acquired from the waveform data file 140 and the value of the program counter (step S32). Thereafter, the debug information acquisition unit 416 determines whether or not the held program counter value matches the breakpoint value (step S33). When the debug information acquisition unit 416 determines that the value of the program counter does not match the value of the breakpoint, the software execution state of the CPU is assumed to advance by one step each time the value of the program counter changes. Is determined to have reached the state after the specified number of steps (the number of steps supplied from the debug processing unit 411) (step S34). If the debug information acquisition unit 416 determines that the software execution state of the CPU has not progressed to the state after the specified number of steps, whether or not the value of the held program counter matches the value corresponding to the end of the software. Is determined (step S35). If the debug information acquisition unit 416 determines that the value of the program counter does not match the value corresponding to the end of the software, the debug information acquisition unit 416 performs the processing from step S31 onward. If the debug information acquisition unit 416 determines in step S33 that the value of the program counter matches the value of the breakpoint, the debug information acquisition unit 416 sends a break occurrence notification (including the value of the program counter) to the debug processing unit 411. Issued, and when it is determined in step S34 that the software execution state of the CPU has progressed to the state after the specified number of steps, or when it is determined in step S35 that the value of the program counter matches the value corresponding to the end of the software Is issued to the debug processing unit 411 (including the value of the program counter) (step S36). At the same time, the debug information acquisition unit 416 issues a waveform display instruction to the waveform information display unit 430. Thus, the software execution state of the CPU reproduced by the debug information acquisition unit 416 is advanced to any of the state at the time of the break occurrence, the state after the designated number of steps, or the state at the end of the software execution.

  FIG. 9 shows the step execution process. FIG. 9A shows the data flow during the step execution process, and FIG. 9B shows the operation during the step execution process. When a step execution command is input via the debug control unit 160 (GUI), the debug processing unit 411 issues a step execution instruction to the debug information acquisition unit 416. Along with this, the debug information acquisition unit 416 receives the PC change position information (the time when the value of the program counter changes next and the value after the change of the program counter) from the waveform data file 140 via the waveform information acquisition unit 420. Obtain (step S41). The debug information acquisition unit 416 holds the time acquired from the waveform data file 140 and the value of the program counter (step S42). Thereafter, the debug information acquisition unit 416 determines whether or not the held program counter value matches the breakpoint value (step S43). Next, the debug information acquisition unit 416 determines whether or not the value of the held program counter matches the value corresponding to the end of the software (step S44). If the debug information acquisition unit 416 determines in step S43 that the value of the program counter matches the value of the breakpoint, the debug information acquisition unit 416 notifies the debug processing unit 411 of the occurrence of a break (including the value of the program counter). When it is determined that the value of the program counter does not match the value of the breakpoint in step S43, an execution stop notification (including the value of the program counter) is issued to the debug processing unit 411 (step S45). ). At the same time, the debug information acquisition unit 416 issues a waveform display instruction to the waveform information display unit 430. As a result, the CPU software execution state reproduced by the debug information acquisition unit 416 is advanced to the state after one step.

  FIG. 10 shows source code display processing. FIG. 10A shows the flow of data during the source code display process, and FIG. 10B shows the operation during the source code display process. When a break occurrence notification or an execution stop notification is issued from the debug information acquisition unit 416 to the debug processing unit 411 (when the continuous execution process or the step execution process ends), the debug processing unit 411 uses the debug information acquisition unit 416. The value of the held program counter is acquired (step S51). Next, the debug processing unit 411 uses the additional information for debugging (information indicating the correspondence relationship between the instruction address and the source code line) in the execution file 120 to set the value of the program counter acquired from the debug information acquisition unit 416. A corresponding source code line is specified (step S52). The debug processing unit 411 acquires the source code from the source file 110 for the source code line specified based on the debug additional information in the execution file 120 (step S53), and the acquired source code is output to the debug information output unit 170. (GUI) is displayed (step S54). The debug processing unit 411 acquires the time and the number of clock cycles in addition to the value of the program counter held in the debug information acquisition unit 416, and the value of the program counter, the time and the number of clock cycles in addition to the source code. It is also possible to display on the debug information output unit 170 (GUI).

  FIG. 11 shows variable value display processing. FIG. 11A shows the data flow during the variable value display process, and FIG. 11B shows the operation during the variable value display process. When a variable value display command (including a variable name) is input in advance via the debug control unit 160 (GUI), a break occurrence notification or execution stop notification is sent from the debug information acquisition unit 416 to the debug processing unit 411. Is issued, the debug processing unit 411 uses the additional information for debugging in the execution file 120 to identify the address and type of the variable of the specified variable name (step S61). Next, the debug processing unit 411 determines whether or not the variable type is a global variable (step S62). If the debug processing unit 411 determines that the type of the variable is a global variable, the corresponding address of the memory in the CPU (specified in step S61) from the waveform data file 140 via the waveform information acquisition unit 420 and the debug information acquisition unit 416. Data) is acquired as a variable value (step S63), and the acquired variable value is displayed on the debug information output unit 170 (GUI) (step S64). Further, when the debug processing unit 411 determines that the variable type is not a global variable (the variable type is a local variable), the debug processing unit 411 receives the waveform information from the waveform data file 140 via the waveform information acquisition unit 420 and the debug information acquisition unit 416. The stack frame data of the execution target function stored in the memory in the CPU is acquired (step S65), and it is determined whether or not the acquired stack frame data includes a variable with the specified variable name (step S66). If the debug processing unit 411 determines that the variable having the specified variable name is included in the stack frame data, the debug processing unit 411 extracts the value of the variable from the stack frame data (step S67), and uses the extracted variable value as the debug information output unit. 170 (GUI) is displayed (step S68). Note that if the debug processing unit 411 determines that the variable of the specified variable name is not included in the stack frame data, nothing is displayed on the debug information output unit 170 (GUI).

  FIG. 12 shows the memory data display process. FIG. 12A shows the data flow during the memory data display process, and FIG. 12B shows the operation during the memory data display process. When a memory data display command (including an address) is input in advance via the debug control unit 160 (GUI), a break occurrence notification or an execution stop notification is sent from the debug information acquisition unit 416 to the debug information processing unit 411. Is issued, the debug processing unit 411 acquires the data of the specified address (specified address range) of the memory in the CPU from the waveform data file 140 via the waveform information acquisition unit 420 and the debug information acquisition unit 416 (step S71) The acquired memory data is displayed on the debug information output unit 170 (GUI) (step S72).

  FIG. 13 shows the waveform display process. FIG. 13A shows the flow of data during the waveform display process, and FIG. 13B shows the operation during the waveform display process. When a waveform display instruction (including time) is issued from the debug information acquisition unit 416 to the waveform information display unit 430 (when the continuous execution process or the step execution process ends), the waveform information display unit 430 acquires the debug information. The time held by the unit 416 is acquired (step S81). Then, the waveform information display unit 430 acquires the waveform information corresponding to the specified time (the time supplied from the debug information acquisition unit 416) from the waveform data file 140 via the waveform information acquisition unit 420 (Step S82). The obtained waveform information is displayed on the waveform information output unit 180 (GUI) (step S83). Thereby, it is possible to synchronize the display of waveform information and the display of debug information (source code, variable values, memory data, etc.).

  Next, a case where software debugging is performed using a debugging function realized by the various processes as described above will be described.

  FIG. 14 shows an example of a processing flow of software debugging. First, when a software developer inputs an initialization command via the debug control unit 160 (GUI), the debug information acquisition unit 416 performs software execution start position information (time and program counter information acquired from the waveform data file 140). Value) is held (step S101). Next, when the software developer inputs a breakpoint setting command via the debug control unit 160 (GUI), the debug information acquisition unit 416 holds the breakpoint value (step S102). Thereafter, the software developer inputs a continuous execution command via the debug control unit 160 (GUI) until the value of the program counter held in the debug information acquisition unit 416 matches the value of the breakpoint. The process of acquiring the PC change position information (time and program counter value) and updating the time and program counter value is repeated (step S103). When the stored program counter value matches the breakpoint value in the debug information acquisition unit 416, a break occurrence notification is issued from the debug information acquisition unit 416 to the debug processing unit 411 (step S104). Along with this, debug information (such as source code corresponding to the value of the program counter) is displayed on the debug information output unit 170 (GUI) (step S105). Then, the software developer performs a software failure analysis based on the debug information displayed on the debug information output unit 170 (GUI), and determines whether or not to end the debugging (step S106). When the software developer determines that the debugging is not finished (continues the debugging), the software developer inputs a step execution command via the debug control unit 160 (GUI), so that the debug information acquisition unit 416 The held time and the value of the program counter are updated, and the software execution state of the CPU is advanced one step in a pseudo manner (step S107). Along with this, the debug information displayed on the debug information output unit 170 (GUI) is updated. Then, when the software developer can identify the software defect, the software developer determines that the debugging is finished, and corrects the source code of the source file 110 (step S108).

  In the embodiment of the present invention as described above, since the software debugging function is realized by acquiring information related to the internal operation of the CPU from the waveform data file without using the ISS, the hardware simulation is simultaneously performed. There is no need. Therefore, the execution speed can be significantly improved as compared with the case where co-emulation is used (co-emulation: about several tens of kHz, one embodiment of the present invention: about several hundred kHz). Thereby, software debugging can be performed in a short time. As a result, it can greatly contribute to shortening the development period of the hardware / software mixed system.

Regarding the above embodiment, the following additional notes are disclosed.
(Appendix 1)
A debugging method for debugging the software on a computer for a system realized by combining hardware including a CPU and software executed by the CPU,
A first step of inputting a waveform data file generated by simulation of the system, a CPU definition file defining the components of the CPU, a source file of the software, and an execution file of the software;
A second step of acquiring time information and CPU internal operation information based on the waveform data file and the CPU definition file, and reproducing the software execution state of the CPU;
And a third step of displaying debug information based on the time information, the CPU internal operation information, the software source file, and the software execution file.
(Appendix 2)
In the debugging method described in Appendix 1,
The second step includes
Continuous execution step of advancing the software execution state of the CPU to a desired state by repeating the process of updating the time information and the CPU internal operation information to information when the value of the program counter in the CPU next changes When,
A step execution step of updating the software execution state of the CPU to the next state by updating the time information and the CPU internal operation information to information when the value of the program counter in the CPU changes next. A debugging method characterized by that.
(Appendix 3)
In the debugging method described in Appendix 2,
In the second step, a break occurs when the value of the program counter in the CPU included in the CPU internal operation information coincides with a preset break point value during the execution of the continuous execution step. A debugging method comprising a break step of notifying and terminating the continuous execution step.
(Appendix 4)
In the debugging method according to any one of appendix 1 to appendix 3,
The debugging method according to claim 3, wherein the third step includes a source code display step of displaying a source code of the software corresponding to a value of a program counter in the CPU included in the CPU internal operation information.
(Appendix 5)
In the debugging method according to any one of appendix 1 to appendix 4,
The debugging method according to claim 3, wherein the third step includes a variable value display step of displaying a value of a designated variable of the software included in the CPU internal operation information.
(Appendix 6)
In the debugging method according to any one of appendix 1 to appendix 5,
The debugging method according to claim 3, wherein the third step includes a memory data display step of displaying data at a specified address of a memory in the CPU included in the CPU internal operation information.
(Appendix 7)
In the debugging method according to any one of appendix 1 to appendix 6,
A debugging method comprising: a fourth step of displaying waveform information based on the time information and the waveform data file.
(Appendix 8)
A computer for debugging the software of a system realized by combining hardware including a CPU and software executed by the CPU,
A first step of inputting a waveform data file generated by simulation of the system, a CPU definition file defining the components of the CPU, a source file of the software, and an execution file of the software;
A second step of acquiring time information and CPU internal operation information based on the waveform data file and the CPU definition file and reproducing the software execution state of the CPU;
And a third step of displaying debug information based on the time information, the CPU internal operation information, the software source file, and the software execution file.

  Although the present invention has been described in detail above, the above-described embodiment is merely an example of the present invention, and the present invention is not limited to this. Obviously, modifications can be made without departing from the scope of the present invention.

It is a figure which shows one Embodiment of this invention. It is a figure which shows an example of a CPU definition file. It is a figure which shows the detail of a software debug part. It is a figure which shows an example of debug API. It is a figure which shows an example of waveform information acquisition API. It is a figure which shows the initialization process. It is a figure which shows a breakpoint setting process. It is a figure which shows a continuous execution process. It is a figure which shows a step execution process. It is a figure which shows a source code display process. It is a figure which shows a variable value display process. It is a figure which shows a memory data display process. It is a figure which shows a waveform display process. It is a figure which shows an example of the processing flow of software debugging. It is a figure which shows an example of SoC. It is a figure which shows an example of a SoC development process. It is a figure which shows the outline | summary of co-simulation. It is a figure which shows the outline | summary of co-emulation.

Explanation of symbols

100. Computer; 110 Source file; 120 Executable file; 130 HDL description file; 140 Waveform data file; 150 CPU definition file; 160 Debug control unit; 170 Debug information output unit; 200: Compiler / Linker; 300 ... Emulator; 400 ... Debug Program; 410 ... Software Debugging Unit; 411 ... Debug Processing Unit; 412 ... Initialization Control Unit; Debug information display section; 416 Debug information acquisition section; 417 Waveform information processing section; 418 Debug information processing section; 419 Information storage section; 420 Waveform information acquisition section; 430 Waveform information display section

Claims (5)

A debugging method for debugging the software on a computer for a system realized by combining hardware including a CPU and software executed by the CPU,
A first step of inputting a waveform data file generated by simulation of the system, a CPU definition file defining the components of the CPU, a source file of the software, and an execution file of the software;
A second step of acquiring time information and CPU internal operation information based on the waveform data file and the CPU definition file, and reproducing the software execution state of the CPU;
And a third step of displaying debug information based on the time information, the CPU internal operation information, the software source file, and the software execution file. The debugging method according to claim 1,
The second step includes
Continuous execution step of advancing the software execution state of the CPU to a desired state by repeating the process of updating the time information and the CPU internal operation information to information when the value of the program counter in the CPU next changes When,
A step execution step of updating the software execution state of the CPU to the next state by updating the time information and the CPU internal operation information to information when the value of the program counter in the CPU changes next. A debugging method characterized by that. The debugging method according to claim 2, wherein
In the second step, a break occurs when the value of the program counter in the CPU included in the CPU internal operation information coincides with a preset break point value during the execution of the continuous execution step. A debugging method comprising a break step of notifying and terminating the continuous execution step. In the debugging method of any one of Claims 1-3,
The debugging method according to claim 3, wherein the third step includes a source code display step of displaying a source code of the software corresponding to a value of a program counter in the CPU included in the CPU internal operation information. A computer for debugging the software of a system realized by combining hardware including a CPU and software executed by the CPU,
A first step of inputting a waveform data file generated by simulation of the system, a CPU definition file defining the components of the CPU, a source file of the software, and an execution file of the software;
A second step of acquiring time information and CPU internal operation information based on the waveform data file and the CPU definition file and reproducing the software execution state of the CPU;
And a third step of displaying debug information based on the time information, the CPU internal operation information, the software source file, and the software execution file.

Images