JP2013058264A - Software debugging support program, software debugging support device, and software debugging support method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To automatically provide information related to a source code necessary for software debugging.SOLUTION: When software to be verified is executed by a hardware model 112, a software debugging support device 100 generates log data 105 by associating an address of a source code of the software with execution result of each source code, and stores the generated log data 105 in a recording region. When accepting selection of arbitrary log data among the stored log data 105, a software debugging program 120 refers to the address of the source code associated with the execution result of the arbitrary log data, and retrieves a source code 132 corresponding to the arbitrary log data 105 from the software to be verified, to output the source code 132 to a GUI 130.

Description

  The present invention relates to a software debug support program, a software debug support apparatus, and a software debug support method used for software development in an embedded system.

  Conventionally, when developing an embedded system in which hardware and software are mixed, such as a CPU (Central Processing Unit) core and a SoC (System on Chip) integrated with a DSP (Digital Signal Processor) core, System level verification is performed as a system in which hardware and software are integrated.

  In order to perform such system level verification, it is necessary to complete the initial verification in a state where individual hardware and software are independent as preprocessing. However, in order to verify the software, hardware for executing the software is required. Therefore, software verification can be realized by using an HW (hardware) model described in a programming language such as C, C ++, or SystemC, and software can be developed early without waiting for the hardware verification status.

  One of the methods for early software development is an ESL (Electronic System Level) design method. ESL design techniques include technologies such as architecture search, high-level synthesis, performance estimation, power consumption estimation, early software development, and HW / SW collaborative verification. When designing embedded systems as described above, ESL design techniques can be applied to early software development.

  FIG. 22 is a block diagram illustrating a configuration example of SoC. As in the system 2200 of FIG. 22, the SoC configuration example includes, for example, a CPU and a memory, and a dedicated HW block group for performing specific processing. FIG. 23 is an explanatory diagram showing the SoC development process. As shown in FIG. 23, the HW model and ISS (instruction set simulator) operating on the ESL tool are used to verify the software before the hardware is completed.

  FIG. 24 is an explanatory diagram showing a configuration example of the software early development environment. As described above, in the SoC development process, the software that has become the executable file 102 is operated on the ISS 111 included in the ESL tool 110. Then, HW processing is performed by the HW model 112 described in various program languages, and the verification of the software is realized by virtually realizing the operation of the entire system. Further, a software debug program 120 is used for software verification. The software debug program 120 implements a debugging function by reading the software source code 101 and the execution format file 102 and acquiring execution control of the ISS 111 and CPU operation information from the ISS 111. The debug function includes breakpoint setting, continuous execution, step execution, source code display, variable / memory display, and the like. The GUI 130 displays information used for debugging, such as execution control and source code in the software debug program 120.

Here, conventional debugging support processing for realizing debugging as described above will be described. FIG. 25 is a flowchart showing the procedure of the software debugging process in the initial stage. FIG. 26 is a flowchart showing the procedure of the software debugging process after the verification has progressed. The flowchart of FIG. 25 is mainly used when many bugs are included in the initial stage of software development.

  In FIG. 25, first, a breakpoint is set at a portion where the operation of the source code is to be confirmed (step S1), and the operation of the source code is continuously executed (step S2). When a break occurs (step S3), it is stopped and the contents of each value such as source code, variable, and memory are confirmed (step S4). Then, it is determined whether or not to end debugging depending on whether or not a bug has been found and whether or not a part that seems to have a problem has passed (step S5). If debugging is not ended (step S5: No), The source code step is executed line by line (step S6), and the content confirmation process of step S4 is executed each time.

  Thereafter, when the debugging of the source code is finished (step S5: Yes), it is determined whether or not there is a program bug at the time of confirming the contents in step S4 (step S7). If it is determined in step S7 that a bug has been found (step S7: Yes), the source code is corrected and compiled (step S8), and the process returns to step S1 again to execute debugging. If it is determined in step S7 that no bug has been found (step S7: No), the series of processing ends.

  When the verification as shown in FIG. 25 progresses to a certain extent and the software operates stably, the detailed verification is performed according to the flowchart in FIG. In FIG. 26, first, an input file (test pattern) is designated by a script or the like (step S11). Then, it is continuously executed (step S12), and after completion, an expected value comparison is performed (step S13). The comparison result of step S13 is output (step S14), it is determined whether or not the processing of the number of input files has been completed (step S15), and the processing of steps S11 to S14 is performed until the processing is completed (step S15: No). Run repeatedly.

  Thereafter, when the process for the number of input files is completed (step S15: Yes), the series of processes is terminated as it is. As described above, in the debugging process after the progress of verification, manual input is not required by a script, so that a plurality of test patterns can be collectively executed by executing them at night or in the background.

  FIG. 27 is an explanatory diagram showing expected value comparison processing. The expected value comparison process performed in step S13 of FIG. 26 includes the execution result 104 generated by the ESL tool 110 from the test pattern 103 and the expected value data 272 generated by the expected value generation software 271 as shown in FIG. Is compared with the expected value comparison script 273, and the comparison result 274 is output. In step S13 of FIG. 26, the expected value comparison script 273 is executed, and the comparison result 274 is output in step S14.

  FIG. 28 is a flowchart showing the procedure of software debugging processing corresponding to the expected value comparison. If the comparison result output by the process of FIG. 27 does not match the expected value, the debugging process is performed according to the procedure shown in FIG. In FIG. 28, first, output data, register access log, and firmware are confirmed (step S21).

Next, it is determined whether or not the problem part included in the verification target software has been identified (step S22). If the problem part can be identified (step S22: Yes), after the firmware is corrected, the verification target software is re-executed (step S23), and the series of processing ends. On the other hand, if the problem part cannot be identified in step S22 (step S22: No), in order to identify the problem part, a detailed investigation is performed by the conventional method (step S24), and the series of processes is terminated.

  Usually, the execution speed in the ESL environment is 1/100 or less of the execution speed in the actual machine. Therefore, when debugging is performed by the processing of FIG. 25, if a long test pattern is used, a very long processing time is required. For example, in the case of an image decoding LSI, even if the test time is 1 minute in the actual machine, the processing time in the ESL environment takes 1 hour and 40 minutes. Actually, it takes more time to debug while proceeding with processing such as breakpoint setting and step execution. Therefore, before re-execution of the firmware corrected by the processing of the flowchart as shown in FIG. 28, debugging is first performed using the output data, the register access log, and the source code. Only when no bug is found by this debugging, the debugging shown in FIG. 25 is performed (for example, see Patent Document 1 below).

  In addition, in the case of embedded software that is applied to SoC, it is necessary not only to perform arithmetic processing as in general software, but also to control the HW block outside the CPU. Such control by software is executed based on reading / writing of a register in the HW block or an interrupt notification from the HW block. Note that the register described here is a register dedicated for controlling the HW block and confirming the operation state, unlike the arithmetic register generally disposed in the CPU. Mapped to memory space.

  Here, FIG. 29 is a chart showing the configuration of the register access log, and FIG. 30 is a chart showing the configuration of the interrupt log. FIG. 31 is an explanatory diagram showing an access log / interrupt log. As shown in the chart 2900 in FIG. 29 and the chart 3000 in FIG. 30, register access and interrupt log information are very useful information for analyzing a program for debugging the embedded software. When the verification target software is executed by the HW model, register access and interrupt log information as shown in FIG. 31 can be acquired as an output result. Since the information indicates the operation of the system, a certain amount of debugging can be performed using only the information related to the log.

  As described above, when performing debugging using the log data 105 by the HW model 112, specifically, (1) processing for checking register settings and source code, and (2) interrupt operation There are two types of confirmation processing. In the confirmation process (1), it is confirmed whether the operation is correct while confirming the access value to be confirmed in the register access log and the source code of the register access and the verification target software corresponding thereto.

  On the other hand, in the confirmation process (2), the interrupt log in the log data 105 output as the execution result, the command activation register corresponding to this interrupt log, etc. are confirmed, and the sequence of the interrupt generation triggered by the activation is confirmed. Check if the flow is running correctly. At the same time, check the source code of the command activation part. In both cases, the verifier debugged while comparing the text file and the printed paper.

Japanese Patent Laid-Open No. 2001-256072

However, the debugging using the execution result by the HW model 112 as described above has been performed manually by a verifier, and thus has a problem that it takes a lot of time.

  Further, in the confirmation process (1), an operation such as visually confirming an output result or searching for a source code using a register name is required. However, even when searching for a source code portion corresponding to a log, if there are a plurality of codes accessing the same register, it cannot be specified which source code is the execution result. For example, it is not impossible to infer the corresponding part of the source code from the register access sequence log, but it is difficult for the verifier who wrote the source code of the corresponding part to identify the corresponding part from the sequence. . However, in an actual development environment, since it is common to create a piece of software by sharing it with a plurality of names, there is a problem that it is very difficult to specify a source code.

  In the case of the confirmation process (2), it is difficult to identify the source code that caused the interrupt from the log in the output result in which the interrupt order is disturbed due to a bug. For example, FIG. 32 is an explanatory diagram illustrating an example of a log related to the block A. And FIG. 33 is explanatory drawing which shows the sequence according to a log. When the verification is performed only from the log description as shown in FIG. 32, even if it is a sequence like pattern 1 or a sequence like pattern 2 in FIG. There was a problem.

  The present invention realizes a software debugging support program, a software debugging support device, and a software debugging support method that automatically provide information on source code necessary for debugging in order to solve the above-described problems caused by the prior art. Objective.

  In order to solve the above-described problems and achieve the object, the software debugging support program, the software debugging support apparatus, and the software debugging support method are executed when a software to be verified is executed by a hardware model or hardware in a computer. A process of generating log data in which the address of the source code is associated with an execution result for each source code of the software, a process of storing the generated log data in a recording area, and a process of outputting the stored log data It is a requirement to include.

  According to the software debug support program, software debug support apparatus, and software debug support method, log data in which an access log to a designated register and a source code that is an instruction source for outputting the access log are associated with each other is output. be able to.

  The software debugging support program, the software debugging support apparatus, and the software debugging support method include a source code group of verification target software and a log data group when the verification target software is executed by a hardware model or hardware. In an accessible computer, a process for receiving selection of an arbitrary register from among the registers described in the log data group and a description of an arbitrary register received from the source code group are included. It is necessary to include processing for searching for source code and processing for outputting the searched source code in association with log data in which the arbitrary register is described.

  According to this software debug support program, software debug support apparatus, and software debug support method, it is possible to automatically extract source code for executing access to a designated register and provide it to a verifier.

  According to the software debug support program, the software debug support apparatus, and the software debug support method, it is possible to support efficient debugging by automatically providing information on source code necessary for debugging. .

It is explanatory drawing which shows the outline | summary of the software debugging assistance process concerning this Embodiment. It is a block diagram which shows the hardware constitutions of a software debugging assistance apparatus. It is a block diagram which shows the structure of the software debug program in Example 1. FIG. 3 is a flowchart illustrating a procedure of software debugging support processing according to the first exemplary embodiment. It is a block diagram which shows the structure of the software debug program in Example 2. It is a block diagram which shows the structure of the HW model in Example 2. FIG. 10 is a chart illustrating a configuration of a register access log according to the second embodiment. 10 is a chart showing a configuration of an interrupt log in Embodiment 2. It is a flowchart which shows the procedure of the execution process at the time of the register access log output in a HW model. 10 is a flowchart illustrating a procedure of a source code display process of a software debug program in the second embodiment. It is a flowchart which shows the procedure of the execution process at the time of the interruption log output in a HW model. 14 is a flowchart illustrating a procedure of display processing of an interrupt-compatible register of a software debug program according to the second embodiment. It is explanatory drawing which shows the output example (the 1) of log data. It is explanatory drawing which shows the output example (the 2) of log data. It is explanatory drawing which shows the output example (the 3) of log data. It is a flowchart which shows the procedure of the software debugging process concerning this Embodiment. It is a block diagram which shows the structural example of SoC. It is a sequence diagram which shows the process of the HW model at the time of a source code display. It is explanatory drawing which shows the example of a GUI display at the time of a source code display. FIG. 10 is a sequence diagram illustrating a processing example (part 1) of the HW model when outputting an interrupt log. It is a sequence diagram which shows the process example (the 2) of the HW model at the time of interruption log output. It is a sequence diagram which shows the process example (the 3) of the HW model at the time of interruption log output. It is explanatory drawing which shows the GUI display example (the 1) at the time of interruption generation | occurrence | production by a mask / enable change. It is explanatory drawing which shows the GUI display example (the 2) at the time of the interruption generation | occurrence | production by a mask / enable change. It is explanatory drawing which shows the example of a GUI display at the time of interruption generate | occur | produced by command completion. It is explanatory drawing which shows the example of a GUI display at the time of the other interruption generation | occurrence | production. It is a block diagram which shows the structural example of SoC. It is explanatory drawing which shows the development process of SoC. It is explanatory drawing which shows the structural example of a software early development environment. It is a flowchart which shows the procedure of the software debugging process of an initial stage. It is a flowchart which shows the procedure of the software debug process after verification progress. It is explanatory drawing which shows an expected value comparison process. It is a flowchart which shows the procedure of the software debugging process according to expected value comparison. It is a graph which shows the structure of a register access log. It is a chart which shows the structure of an interruption log. It is explanatory drawing which shows an access log and an interruption log. It is explanatory drawing which shows an example of the log regarding the block A. FIG. It is explanatory drawing which shows the sequence according to a log.

  Exemplary embodiments of a software debugging support program, a software debugging support apparatus, and a software debugging support method will be described below in detail with reference to the accompanying drawings. In this software debugging support program, software debugging support apparatus, and software debugging support method, debugging is supported by automatically extracting correspondence information between designated register access and interrupt operation and source code and providing it to a verifier. be able to.

(Outline of software debugging support process)
First, software debugging support processing according to the present embodiment will be described. FIG. 1 is an explanatory diagram showing an outline of software debugging support processing according to the present embodiment. As shown in FIG. 1, in this embodiment, the software debug support apparatus 100 outputs a register access or interrupt operation log specified by the verifier (user) in association with the corresponding source code, thereby enabling the software by the verifier. Debugging can be supported.

  First, the configuration of the software debug support apparatus 100 according to the present embodiment will be described. As shown in FIG. 1, the software debug support apparatus 100 includes an ESL tool 110, a software debug program 120, and a GUI 130. The ESL tool 110 is a conventionally used design method. And when using for software early development like this software debugging assistance apparatus 100, the structure which mounted ISS111 and the HW model 112 like FIG. 1 is used.

  The ISS 111 and the HW model 112 configure a virtual SoC by reading the execution format file 102 of the verification target software. In addition, a test pattern is input as input data 103 to the HW model 112. In the HW model 112, processing according to the test pattern of the input data 103 input in accordance with the control of the ISS 111 is executed, and the execution result is output as output data 104. Further, the log data 105 corresponding to the control from the ISS 111 is output from the HW model 112.

  Further, the software debug program 120 implements a debugging function by reading the source code 101 and the execution format file 102 of the verification target software, and acquiring execution control of the ISS 111 and CPU operation information from the ISS 111. In addition to the conventional breakpoint setting, continuous execution, step execution, source code display, and variable / memory display, the debug function displays the specified register access log 131 and the corresponding source code 132 in association with each other. It has a function. Therefore, the GUI 130 displays information used for debugging, such as acceptance of execution control in the software debug program 120 and source code 132.

Next, a hardware configuration of the above-described software debug support apparatus 100 will be described. FIG. 2 is a block diagram illustrating a hardware configuration of the software debugging support apparatus. The software debug support apparatus 100 includes an ESL tool 110 and a software debug program 120 by a general-purpose computer having a hardware configuration as shown in FIG.
And the GUI 130 are realized.

  For example, in FIG. 2, the software debug support apparatus 100 includes a CPU (Central Processing Unit) 201, a ROM (Read-Only Memory) 202, a RAM (Random Access Memory) 203, a magnetic disk drive 204, and a magnetic disk 205. An optical disk drive 206, an optical disk 207, a display 208, an input I / F (Interface) 209, and a network I / F (Interface) 210. Each component is connected by a bus 220.

  Here, the CPU 201 governs overall control of the software debugging support apparatus 100. The ROM 202 stores programs such as a boot program, an ESL tool, and a software debug program. The RAM 203 is used as a work area for the CPU 201. The magnetic disk drive 204 controls reading / writing of data with respect to the magnetic disk 205 according to the control of the CPU 201. The magnetic disk 205 stores data written under the control of the magnetic disk drive 204.

  The optical disk drive 206 controls reading / writing of data with respect to the optical disk 207 according to the control of the CPU 201. The optical disk 207 stores data written under the control of the optical disk drive 206, or causes the computer to read data stored on the optical disk 207.

  The display 208 displays data such as a document, an image, and function information as well as a cursor, an icon, or a tool box. As the display 208, for example, a CRT, a TFT liquid crystal display, a plasma display, or the like can be adopted.

  An input interface (hereinafter abbreviated as “input I / F”) 209 receives an instruction from a verifier such as a keyboard and a touch panel. For example, in the case of a keyboard, keys are provided for inputting characters, numbers, various instructions, etc., and data is input. Moreover, a touch panel type input pad or a numeric keypad may be used. In the case of a mouse, the cursor is moved and a range is selected, or a window is moved and the size is changed. A trackball or a joystick may be used as long as they have the same function as a pointing device.

A network interface (hereinafter abbreviated as “network I / F”) 210 is a LAN (Local Area Network) or WAN (Wide) through a communication line.
Are connected to a network such as an area network or the Internet, and are connected to other devices via this network. The network I / F 210 serves as an internal interface with the network, and controls data input / output from an external device. As the network I / F 210, for example, a modem or a LAN adapter can be employed.

  As described above, the software debugging support apparatus 100 can realize the ESL tool 110, the software debugging program 120, and the GUI 130 using the hardware resources 201 to 210 of a general-purpose computer. For example, the ESL tool 110 and the software debug program 120 can be realized by the CPU 201, the ROM 202, and the RAM 203. The GUI 130 can be realized by the display 208 and the input I / F 209.

Also, source code (entire) 1 which is input information of the software debugging support apparatus 100
01, the execution format file 102 and the input data (test pattern) 103 may be recorded in advance on the magnetic disk 205 or the optical disk 207, or may be acquired from the outside via the network I / F 210. Further, the magnetic disk 205 and the optical disk 207 can be used as storage means for storing output data 104 and log data 105 that are output information from the debug support apparatus 100.

  In the above description, the ESL tool 110, the software debug program 120, and the GUI 130 are realized by one general-purpose computer, but each function is realized by a plurality of computers, and the network I / F 210 is used to One software debugging support system may be provided.

  Specific examples 1 and 2 for realizing the software debugging support process as described with reference to FIG. 1 will be described below. The first and second embodiments are realized by the software debugging support apparatus 100 shown in FIG. 1. However, in order to handle log data 105 having different configurations (in the case of the first embodiment, the same configuration as conventional log data), software debugging is performed. The information provided to the verifier for support also has a different configuration. Therefore, the verifier may use any one of the first and second embodiments according to the hardware environment of the debug support apparatus 100 and the verification purpose in the debugging process.

Example 1
In the first embodiment, debugging is supported by extracting the corresponding source code and providing it to the user for the specified access log and interrupt log using normal log data as described in FIG. It is configured to do.

  As described above, in this embodiment, software debug support processing is realized by the debug support device 100 described with reference to FIG. Therefore, first, the configuration of the software debug program 120 in the first embodiment will be described. FIG. 3 is a block diagram illustrating the configuration of the software debug program according to the first embodiment. As shown in FIG. 3, the source code 101, the execution format file 102, and the log data 105 are input to the software debug program 120, and the software debug program 120 includes a program group that executes the following processing.

-Log data input section: Reads register access / interrupt log from log data. Register access log display section: The register access / interrupt log read by the log data input section is displayed on the GUI.
GUI control accepting unit: accepts a GUI operation from the verifier.
Source code search unit: Searches the source code from the register name specified by the GUI control reception unit. When source code including the same register name exists at a plurality of locations at the time of search, the description locations of all the source codes are displayed on the GUI as verification candidates and can be selected.
Source code display unit: Displays the source code searched by the source code search unit.

Next, a procedure of software debugging support processing in the first embodiment will be described. FIG. 4 is a flowchart illustrating the procedure of the software debugging support process according to the first embodiment. In the flowchart of FIG. 4, when a source display instruction is input from the verifier through the GUI 130 or the like, the software debugging support process is started using this as a trigger. First, when there is a source display instruction from the GUI 130, the source code is searched with the designated register name (step S401). Since the description of the register access corresponding to the designated register name is retrieved in step S401, it is determined whether there are a plurality of retrieved register access descriptions (step S402).

  In step S402, when there are a plurality of register access descriptions (step S402: Yes), a list of candidate portions of the plurality of register access descriptions is displayed on the GUI 130 (step S403). When a selection from the verifier is received from the list of candidate parts displayed here, the source code 132 of the selected part is displayed (step S404), and the series of processes is terminated.

  On the other hand, in step S402, when there is only one retrieved register access description (step S402: No), the source code corresponding to the retrieved register access description portion is displayed (step S405), and a series of processing Exit.

  In the flowchart of FIG. 4, the verifier designates the register name, and the source code is searched from the designated register name. However, the log data to be verified may be designated from the log data list. In such a case, a register name is extracted from the selected log data. Then, the processing of the flowchart of FIG. 4 may be performed on the extracted register name.

  As described above, in the first embodiment, it is possible to display the register access log 131 and the source code 132 related to the designated register by using conventional log data as they are. Therefore, it is possible for the verifier to reduce the trouble of grasping the correspondence relationship while comparing all the source code 101 and the log data 105 as in the past. Further, as described above, since the log data 105 uses the conventional configuration as it is, the HW model 112 can also use the conventional configuration as it is without adding a new function.

(Example 2)
The second embodiment obtains more information than the case of the first embodiment as the log data 105, thereby providing more information than the first embodiment and realizing debugging support. The second embodiment is also realized by the configuration of the debug support apparatus 100 as shown in FIG. 1 as in the first embodiment. However, the configuration inside the HW model 112, the configuration inside the software debug program 120, and the HW The configuration of log data output from the model 112 is different. Therefore, the difference between each configuration and the specific contents of the debugging support process will be described below.

<Configuration of software debug program>
First, a software debug program according to the second embodiment will be described. FIG. 5 is a block diagram illustrating the configuration of the software debug program according to the second embodiment. As shown in FIG. 5, the software debug program 120 includes a register access log display unit, a source code display unit, a source line acquisition unit, a GUI control reception unit, a log data input unit, and a log data search unit. As described above, compared to the first embodiment, a source line acquisition unit is added, and a log data search unit is added instead of the source code search unit.

  The source code 101 and the execution format file 102 input to the software debug program 120 are the same information as in the first embodiment. In addition, as described above, the log data 105 is generated by the HW model 112 according to the log data 105 of the first embodiment (the conventional log data shown in FIGS. Log data 105 having a configuration different from that of the same configuration is output, and this log data 105 is input. The log data 105 output process by the HW model 112 will be described later.

Next, a description will be given of the point that the processing different from that of the first embodiment is performed for each functional unit of the above-described software debug program. The source line acquisition unit stores the register access log and interrupt log displayed by the register access log display unit. When a source code display instruction is received from the verifier, the instruction code associated with the log data 105 is referenced to obtain the corresponding number of source code lines. Therefore, the source code display unit displays the source code 132 corresponding to the designated number of lines. Since the correspondence information between the address and the number of lines of the source code 132 is included in the execution format file 102 input to the HW model 112, the HW model 112 causes the log data 105 associated with the instruction address to be output. (It will be described in detail in the configuration of the HW model 112). The log data search unit performs a process of searching the log data 105 with the interrupt name designated by the verifier.

<Configuration of HW model>
Next, the configuration of the HW model applied to the software debugging support apparatus 100 according to the second embodiment will be described. FIG. 6 is a block diagram illustrating the configuration of the HW model in the second embodiment. As shown in FIG. 6, the HW model 112 of the ESL tool 110 of the debugging support apparatus 100 according to the second embodiment has a configuration including a new function in order to output the log data 105 including information for debugging. Yes.

  More specifically, in the HW model 112 of FIG. 6, in addition to the conventional HW function unit 600, a register access log output unit 601, an interrupt log output unit 602, an instruction address acquisition unit 603, and a stack memory read unit 604 and a return address acquisition unit 605.

  The register access log output unit 601 newly outputs information for debugging in addition to the conventional log (“conventional log” means the log data described with reference to FIG. 29). The interrupt log output unit 602 newly outputs debugging information in addition to the conventional interrupt log (“conventional interrupt log” means the log data described with reference to FIG. 30). The instruction address acquisition unit 603 acquires the instruction address (program counter value) of the program at the time when the register access occurs. The instruction address is acquired using a PC acquisition function prepared as an API (Application Program Interface) of the ISS 111.

  The stack memory reading unit 604 performs processing for reading the contents of the stack memory from the ISS 111. This reading of the stack memory is also realized by using a memory reading function prepared as an API. The return address acquisition unit 605 performs processing for acquiring a return address indicating a caller function from the contents of the read stack memory.

<Log structure>
Next, the configurations of the register access log and the interrupt log in the second embodiment will be described. As described with reference to FIG. 6, new functional units 601 to 605 are added to the HW model 112 of the second embodiment. Therefore, the HW model 112 outputs log data 105 having a configuration in which information for debugging is newly added to the conventional log and the conventional interrupt log described with reference to FIGS.

FIG. 7 is a chart showing the configuration of the register access log in the second embodiment, and FIG. 8 is a chart showing the configuration of the interrupt log in the second embodiment. In the second embodiment, the log data related to the register access has a configuration in which an interrupt ID, an instruction address, and a return address are added to the configuration of the conventional log data as shown in a chart 700 of FIG. Further, as shown in a chart 800 of FIG. 8, an interrupt type and an interrupt ID are added to the configuration of the conventional log data. The interrupt ID added here is an ID assigned to associate the interrupt with the command activation register that causes the interrupt. In the present embodiment, the following four types of information are used as interrupt types.

-Command completion: COM_END
・ Enable change: ENABLE
・ Others: OTHER
・ Factor change: MASKED

  As described above, the HW model 112 according to the second embodiment is configured to generate new log data 105 in which debug information is associated with conventional log data. Therefore, the output procedure of the log data 105 when the HW model 112 performs various execution processes and the software debug support process using the output log data 105 will be described below.

<HW model execution processing (when register access log is output)>
First, the procedure of the execution process at the time of register access log output in the HW model 112 will be described. FIG. 9 is a flowchart showing a procedure of execution processing at the time of register access log output in the HW model. In FIG. 9, first, it is determined whether or not a register access has occurred in the program being executed (step S901). Here, it waits until register access occurs (step S901: No loop). When register access occurs (step S901: Yes), the instruction address executed when the register access occurs is acquired by the instruction address acquisition unit 603 ( Step S902).

  Next, the stack memory is read out by the stack memory reading unit 604 (step S903), the return address acquisition unit 605 analyzes the contents of the stack memory read out at step S903, and holds the value if there is a return address ( Step S904). Then, in addition to the execution result of the program, the instruction address acquired in step S902 and the return address acquired in step S904 are output as log data 105 (step S905). Thereafter, the hardware configuration is executed in accordance with the executed program (step S906), and a series of processing ends.

  As described above, when the register access is executed, the HW model 112 acquires the instruction address of the source code instructing the execution of the register access, and the log data 105 associated with the instruction address is generated and stored. Further, when there is a return address in the executed register access, the return address is also acquired, and log data 105 associated with the return address is generated and accumulated.

<Source code display processing>
Next, software debugging support processing using the log data 105 including various addresses as debugging information as described above will be described. Specifically, the verifier's software debugging is supported by displaying the source code for the log designated from the log data 105 by the software debugging program 120.

  FIG. 10 is a flowchart illustrating a procedure of source code display processing of the software debug program according to the second embodiment. The flowchart of FIG. 10 shows processing when the verifier issues an instruction to display the source code 132 corresponding to register access using the GUI.

In FIG. 10, it is first determined whether or not a GUI input from the verifier has been received (step S1001). Here, it waits until it is determined that the GUI input is accepted (step S1001: No loop), and when the GUI input is accepted (step S1001: Yes).
Then, the process proceeds to a process for confirming whether the received GUI input is a source display instruction or a caller function display instruction.

  First, it is determined whether or not the received GUI input is a source display instruction (step S1002). Here, when the received GUI input is a source display instruction (step S1002: Yes), the instruction address of the designated access portion is acquired to perform source display (step S1003), and further, the instruction address is supported. The source line number to be acquired is acquired (step S1004). Then, the source code is displayed with reference to the acquired source line number (step S1005), and the series of processes is terminated.

  On the other hand, if it is not a source display instruction in step S1002 (step S1002: No), it is determined as a caller display instruction, and it is determined whether there is a return address (step S1006). If it is determined that there is a return address (step S1006: Yes), the return address is acquired (step S1007), and the source line number corresponding to the return address is acquired (step S1008). Then, the source code is displayed with reference to the acquired source line number (step S1009), and the series of processes is terminated. In the source code display process of step S1005 and step S1009 described above, the source code of the display target portion is displayed on the GUI 130. If it is determined in step S1006 that there is no return address (step S1006: No), the series of processing ends.

  Thus, using the register access log output in advance by the HW model 112 of the software debug support apparatus 100, the software debug program 120 generates the source code 132 corresponding to the instruction address and return address from which the register access is executed. Extract automatically. The extracted source code 132 is displayed as information associated with the register access log 131 by the GUI 130, and is provided as information for software debugging by the verifier.

<HW model execution process (when interrupt log is output)>
Next, output of an interrupt log when an interrupt is generated by the execution process of the HW model 112 will be described. FIG. 11 is a flowchart showing a procedure of execution processing at the time of interrupt log output in the HW model. Interrupt processing is performed when a register write occurs when the register is (a) a command activation register, (b) an interrupt mask / enable register, or (c) any other register. Therefore, after register write confirms any one of the above (a) to (c), processing corresponding to each case is performed.

  In the flowchart of FIG. 11, it is first determined whether or not a register write has occurred (step S1101). Here, the process waits until register write occurs (step S1101: No loop). When register write occurs (step S1101: Yes), next, in step S1101, whether or not the written register is an activation register. Is determined (step S1102).

In step S1102, if the written register is the activation register (step S1102: Yes), it is determined that the above-mentioned case (a) is present. Therefore, first, an interrupt ID is assigned (step S1103), an access log is output (step S1104), and HW processing is executed (step S1105). Then, after executing the HW process in step S1105, it is determined whether or not an interrupt occurs (step S1106). If it is determined that an interrupt occurs (step S1106: Yes), the interrupt is executed (step S1107). ). Then, a log of the interrupt process executed in step 1107 is output (step S1108), and the series of processes is terminated. Step S110
When it is determined that no interruption occurs after the execution of the HW process No. 5 (step S1106: No), the series of processes is terminated as it is.

  On the other hand, if it is determined in step S1102 that the written register is not a start register (step S1102: No), it is determined that the above-described cases (a) and (c) are present. Therefore, this time, it is determined whether or not the written register is a mask / enable register (step S1109). Here, if the accessed register is one of the mask / enable registers (step S1109: Yes), it is determined that the case is (A). Therefore, the access log of the mask / enable register is output (step S1110), and it is further determined whether or not an interrupt occurs (step S1111).

  If it is determined in step S1111 that an interrupt will occur (step S1111: Yes), the interrupt process is executed as it is (step S1112). Then, a log of the interrupt process executed in step 1112 is output (step S1113), and the series of processes is terminated. If it is determined in step S1111 that no interrupt occurs (step S1111: No), the series of processing ends.

  In step S1109, if the accessed register is neither a mask / enable register (step S1109: No), it is determined that the case is (c). Therefore, the accessed register outputs an access log as another register that does not correspond to either the activation register or the mask / enable register (step S1114), and the series of processing ends.

<Interrupt-compatible register display processing>
Next, a procedure of display processing of the activation register corresponding to the interrupt will be described using the log data 105 output from the HW model 112 by the processing of FIG. FIG. 12 is a flowchart illustrating the display processing procedure of the interrupt-compatible register of the software debug program according to the second embodiment. Here, when the verifier gives an instruction to display an interrupt cause through the GUI 130, the software debug program 120 has (A) an interrupt due to a change in mask / enable and (B) a normal interrupt due to completion of a command. (C) It is confirmed which of the other interrupts, and display processing corresponding to each interrupt type is performed.

  In the flowchart of FIG. 12, it is first determined whether or not an interrupt cause display instruction has been received from the verifier (step S1201). Here, the process waits until an interrupt cause display instruction is accepted (step S1201: No loop). When an interrupt cause display instruction is accepted (step S1201: Yes), whether or not the cause of the interrupt is due to a mask / enable change is determined. Is determined (step S1202). In step S1202, the cause of the interrupt occurrence is determined by referring to the interrupt type in the information included in the log data 105.

  In step S1202, if the cause of the interrupt is (A) mask / enable change (step S1202: Yes), first, the interrupt factor is acquired from the log data 105 (step S1203), and the log is searched with the acquired interrupt factor. (Step S1204). Then, the interrupt factor change portion at the closest position before the time when the interrupt occurs is searched for, and the interrupt ID is acquired (step S1205). Thereafter, the log data 105 is searched with the interrupt ID acquired in step S1205 (step S1206), the corresponding register access is specified, displayed on the GUI 130 (step S1207), and the series of processing is terminated.

  On the other hand, if the cause of the interruption is not (A) in step S1202 (step S1202: No), it is further determined whether or not (B) a normal interruption due to command completion (step S1208). If it is an interrupt (step S1208: Yes), the ID is acquired from the interrupt log (step S1209), the log is searched with the ID (step S1210), the corresponding register access is identified and displayed on the GUI. (Step S1211), a series of processing ends.

  If the interrupt is not (B) in step 1208 (step S1208: No), (C) it is determined that the interrupt is other than that. Therefore, only a message indicating that there is no activation register corresponding to the interrupt in the GUI 130 is displayed (step S1212), and the series of processing ends.

<Output example of log data>
Here, FIGS. 13A to 13C are explanatory diagrams illustrating output examples of log data. FIG. 13A is log data 105 output in the case of (A) described above. Specifically, an interrupt is generated by writing to the enable register, and the interrupt is invalidated by writing to the interrupt enable register in the second row. The processing of the HW model 112 is started by writing to the command activation register on the third line (activation register ID: 0x324).

  Furthermore, on the 10th line, the value of the interrupt factor register changes upon completion of the command, and an interrupt state is entered. At this time, since the interrupt is invalid, no interrupt actually occurs. In the log data 105, 0x324 corresponding to the ID of the activation register is recorded. Also, the interrupt is enabled by writing to the interrupt enable register on the 12th row. As a result, on the 13th line, an interrupt that has been in the interrupt state on the 10th line is generated. Here, the interrupt ID is not recorded because an interrupt is generated by changing the enable register.

  Next, FIG. 13B is log data 105 output in the case of (B) described above. An interrupt occurs when the start command is completed. Further, FIG. 13C is the log data 105 output in the case of (C) described above. In the case of (C), an interrupt (error or the like) that occurs regardless of the start / mask / enable register is indicated (for example, an interrupt due to an error that is not related to the start / mask / enable register as in the ninth line). ). As described above, in the case of the interrupt of (C), the interrupt ID is not recorded because there is no corresponding ID.

  As described above, when an interrupt is generated by the HW model 112 of the software debugging support apparatus 100, the access to the activation register corresponding to the interrupt is displayed according to the type of the interrupt, and is provided as information for software debugging by the verifier. The If the cause of the interruption is not known, a message indicating that can be output.

(Debugging process procedure)
Next, the procedure of debugging processing according to this embodiment will be described. FIG. 14 is a flowchart illustrating a procedure of debugging processing according to the present embodiment. As described above, in the present embodiment, the source code corresponding to the location specified by performing the debug support process by the software debug program 120 is displayed. The verifier checks the verification portion from the displayed source code and corrects the source code as appropriate.

The debugging process will be described. In the flowchart of FIG. 14, first, a plurality of test patterns are continuously executed by batch processing (step S1401). Then, it is determined whether or not the comparison result between the execution result and the expected value is correct (step S1402). Here, when it is determined that the comparison result is correct (step S1402: Yes), the bug is not included in the source code, and thus the series of processing is ended as it is.

  On the other hand, if it is determined in step S1402 that the comparison result is not correct (step S1402: No), the source code of the access log and interrupt log is confirmed again by the debug support process (step S1403). Then, it is determined whether or not the problematic part has been identified by the source code checking process in step 1403 (step S1404). If the problem part can be identified (step S1404: Yes), the problem part firmware is corrected (step S1405), the process returns to step S1401, and the batch process is executed again.

  In step S1404, if the problem part cannot be identified (step S1404: No), the source code is investigated in detail using a conventional method to identify the problem (step S1406), and the process proceeds to step S1405. As described above, the software debugging support apparatus 100 can improve the verification accuracy by repeating the software debugging process after the source code correction.

As described above, the following functions are realized in the second embodiment. Therefore, it is possible to automatically provide the verifier with information on the source code necessary for debugging, and the farm development period can be shortened.
-Register log / interrupt log display with debugger-Correspondence display between register access and source-Cause of interrupt (register access log) for specified interrupt processing in log data-Source code of specified start register access part display

(Display example)
Next, the case where the verifier displays the source code corresponding to the register access and the case where the activation register corresponding to the interrupt is displayed using the software debugging support apparatus 100 according to the second embodiment will be described with specific examples. To do.

<Structure of SoC>
First, the configuration of SoC will be described. FIG. 15 is a block diagram illustrating a configuration example of SoC. The following display examples show block diagrams of SoC examples used by the verification target software to explain the examples by the SoC 1500 in FIG. In the SoC 1500, block A, block B, and block C are controlled from the firmware on the CPU.

<When displaying source code>
Next, a display example when displaying source code will be described. Here, the processing of the HW model at the time of displaying the source code will be described first, and then a display example on the GUI will be described.

HW Model Sequence FIG. 16 is a sequence diagram showing processing of the HW model when displaying source code. FIG. 16 shows processing when accessing a normal register (not a command activation register). First, when a register access by the ISS (firm) 111 occurs, the HW model 112 acquires an instruction address (step S1601). In step S1601, the HW model 112 requests the ISS 111 to output an instruction address. In response to this request, an instruction address is transmitted from the ISS 111, whereby the HW model 11
2 can obtain the instruction address.

  Subsequently, the HW model 112 reads the contents of the stack memory from the ISS 111 with reference to the acquired instruction address (step S1602). Similar to step S1601, the processing in step S1602 is also realized by requesting reading of the stack memory from the HW model 112 to the ISS 111. The HW model 112 extracts the return address from the stack memory read in step S1602 (step S1603), outputs a register access log to which the instruction address and the return address are added (step S1604), and finally the actual hardware processing Is executed (step S1605).

GUI Display Example Next, a GUI display example when displaying source code will be described. FIG. 17 is an explanatory diagram illustrating a display example of a GUI when displaying source code. FIG. 13-1 described above is a register access log at this time. As shown in FIG. 17, a plurality of windows are displayed when the source code is displayed. Then, for example, the register access / interrupt log is displayed in the upper window 1701, and the source code is displayed in the lower window 1702. In the display example of FIG. 17, by designating writing of the register access log to the BLOCK_A__IRQ_CLEAR register and clicking the source code display button B, the source code line “write_reg (BLOCK_A__IRQ_CLEAR, int_clear) corresponding to the register access is displayed on the source code display screen. ); ”Is displayed.

  As an operation of the software debug program 120, when writing to the BLOCK_A__IRQ_CLEAR register at time 536465 of the register access log, a source code line corresponding to the instruction address 0xB588 is obtained from the debug information in the execution format file. Then, the source code of the number of lines is displayed in the source display window. Further, when the caller function display button C in the source code window is clicked, the software debug program 120 displays the source code of the caller function.

<When an interrupt occurs>
Next, a display example when an interrupt occurs will be described. Here, first, the processing of the HW model when an interrupt occurs will be described, and then a display example on the GUI will be described.

HW Model Sequence FIGS. 18A to 18C are sequence diagrams illustrating a processing example of the HW model at the time of interrupt log output. FIG. 18A shows a sequence when an interrupt of the command activation register (a) occurs in the HW model 112. As shown in FIG. 18A, when writing to the command activation register from the ISS 111 occurs, the HW model 112 is assigned an interrupt ID 0x324 (step S1811). Then, a register access log including the interrupt ID is output (step S1812).

  Thereafter, a timer setting is performed in order to realize the passage of time in the HW model 112 (step S1813), and the data is transmitted to the ISS 111. In response to the timer setting, the ISS 111 generates a timer event after a specified cycle has elapsed. It is assumed that timer setting and timer event generation are provided in the API of ISS 111.

  When the HW model 112 receives a timer event from the ISS 111, it executes a hardware process (step S1814), thereafter generates an interrupt (step S1815), and outputs the interrupt log of the interrupt ID 0x324 as the log data 105 (step S1816). ).

  Next, FIG. 18-2 is a sequence diagram illustrating a processing example (part 2) of the HW model at the time of interrupt log output. The sequence when the interrupt of the interrupt mask / enable register (a) occurs in the HW model 112 is shown. As shown in FIG. 18-2, when writing to the command activation register from the ISS 111 occurs, the hardware processing is executed in the HW model 112 (step S1821). Then, the interrupt factor changes with the completion of the process of step S1821 (step S1822).

  When the interrupt enable register is enabled by the ISS 111, the HW model 112 further enables the interrupt by writing the mask / enable register from the ISS 111 (step S1823). Then, after outputting the register access log (step S1824), the HW model 112 checks the value of the enable register and the value of the interrupt factor register to check whether or not to generate an interrupt (step S1825). In the example of FIG. 18-2, since an interrupt state has been entered in advance, an interrupt is generated (step S1826), and an interrupt log is output (step S1827). In this case, no interrupt ID is recorded because there is no corresponding activation register.

  Also, in the sequence of FIG. 18-3, the procedure of the HW model 112 when writing to a register other than the command activation / interrupt mask / interrupt enable register other than the interrupt as shown in FIG. Show. As shown in FIG. 18-3, in response to register writing (other than activation / mask / enable) from the ISS 111, the HW model 112 outputs a register access log (step S1831). In the process of step S1831, the HW model 112 does not generate an interrupt log because the interrupt process itself has not occurred.

-GUI display example [When interrupt occurs due to mask / enable change]
Next, an example of GUI display when an interrupt occurs due to a mask / enable change will be described. 19A and 19B are explanatory diagrams illustrating GUI display examples when an interrupt is generated due to a mask / enable change. FIG. 19A is a log example corresponding to the interrupt due to the enable change in FIG.

  After accepting the designation of the interrupt to be verified by the verifier from the register access, when the interrupt cause display button A is clicked, the corresponding interrupt factor change log and activation register write are displayed. The software debug program 120 first checks the interrupt type of the specified interrupt log. At this time, since the interrupt type is enabled (ENABLE), the log of the forward direction is searched with the value “BLOCK_A_INT_DEC_DONE” of the interrupt factor, and the interrupt factor is the same with the factor change (MASKED) at the nearest position. Search for logs. In the display example, the closest position is found on the 10th line, and the interrupt ID (0x324) is determined at that time. Thereafter, the log is searched with ID0x324, and the write access to the corresponding BLOCK_A_DEC_START register is displayed. The interrupt factor is also displayed.

  Further, FIG. 19-2 shows the case where the interrupt due to the enable change in FIG. 14A is similar to FIG. 19A, but the log of the interrupt factor change portion is not displayed on the GUI (by the verifier). The interrupt cause display button A was not clicked). At this time, the processing of the software debug program 120 is the same as that in FIG.

[When an interrupt occurs due to command completion]
Next, an example of GUI display when an interrupt occurs due to command completion will be described. FIG.
These are explanatory drawings showing a GUI display example when an interrupt occurs due to command completion. FIG. 20 shows a display when a completion interrupt corresponding to the activation command (B) in FIG. 14 occurs.

  As shown in FIG. 20, when the interrupt cause display button A is clicked, the corresponding start register writing is displayed. At this time, the software debug program 120 searches the interrupt log with the interrupt ID 0x324 of the interrupt log. It then displays the corresponding write access to the “BLOCK_A__DEC_START” register at time 525650. Further, when the source code display button B is clicked, the source code of the part written to the BLOCK_A__DEC_START register is displayed.

[When other interrupts occur]
Finally, a GUI display example when an interrupt occurs due to a factor other than the mask / enable change and command completion described above will be described. FIG. 21 is an explanatory diagram showing a GUI display example when another interrupt occurs. The display example of the window 2100 in FIG. 21 is a display example in the case of an interrupt (such as an error) that occurs regardless of (C) the start / mask / enable register described in FIG.

  As described above, in the case of an interrupt log generated by a factor other than mask / enable change and command completion, a specific register is not associated. Therefore, when the interrupt cause display button A is clicked, a message “no interrupt cause activation register” is displayed as shown in FIG. At this time, the software debug program 120 first confirms the interrupt type with reference to the log data 105 for the specified interrupt log. Since the interrupt type is OTHER (others), the software debug program 120 operates to display on the GUI 130 with no corresponding activation register.

  As described above, in this embodiment, it is possible to automatically extract the source code for executing access to the designated register using the conventional log data and provide it to the verifier (Example 1). In addition, new log data associated with debugging data can be generated to automatically provide information on source code necessary for debugging (second embodiment).

  The software debugging support method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer. Further, this program may be a medium that can be distributed via a network such as the Internet.

  The following additional notes are disclosed with respect to the embodiment described above.

(Appendix 1) Computer
When the software to be verified is executed by a hardware model or hardware, generating means for generating log data in which address information of the source code is associated with an execution result for each source code of the software,
Storage means for storing the log data generated by the generating means in a recording area;
Output means for outputting log data stored in the recording area by the storage means;
Software debugging support program characterized by functioning as

(Supplementary note 2)
Accepting means for accepting selection of arbitrary log data among the log data accumulated in the recording area by the accumulation means;
Search means for searching source code corresponding to address information associated with an execution result of arbitrary log data received by the receiving means from the verification target software;
Function as
The software debug support program according to appendix 1, wherein the output means outputs the source code searched by the search means in association with the arbitrary log data.

(Additional remark 3) The said production | generation means produces | generates the log data which linked | related at least one of the instruction address and the return address of the said source code with the execution result for every source code of the said software as address information. The software debugging support program according to 2.

(Supplementary Note 4) When the interrupt process is generated by the software, the generation unit generates log data including an interrupt ID representing the interrupt process and type information of the interrupt process. The software debugging support program according to any one of to 3.

(Additional remark 5) When the log data containing the information regarding interruption is selected by the reception means, the search means uses the interruption ID included in the log data and the type information of the interruption processing to Search for the register that caused the processing,
The software debug support program according to appendix 4, wherein the output means outputs log data including information on the interrupt in association with the register searched by the search means.

(Appendix 6) A computer capable of accessing a source code group of verification target software and a log data group when the verification target software is executed by a hardware model or hardware,
Accepting means for accepting selection of an arbitrary register from among the registers described in the log data group;
Search means for searching a source code including a description of an arbitrary register accepted by the accepting means from the source code group,
Output means for outputting the source code searched by the search means in association with log data in which the arbitrary register is described;
Software debugging support program characterized by functioning as

(Supplementary note 7) When a plurality of source codes including the description of the arbitrary register are searched by the search means, the output means outputs a list of the searched source codes, and the receiving means When the selection of an arbitrary source code from the list is accepted, the arbitrary source code is output in association with the log data in which the arbitrary register is described. Debug support program.

(Supplementary note 8)
When the accepting unit accepts selection of arbitrary log data in the log data group, the receiving unit functions as an extracting unit that extracts a register description from the arbitrary log data;
The software debug support program according to appendix 1 or 2, wherein the search means searches the source code group for a source code including a description of a register extracted by the extraction means.

(Supplementary Note 9) When the software to be verified is executed by a hardware model or hardware, a generation unit that generates log data in which address information of the source code is associated with an execution result for each source code of the software,
Storage means for storing log data generated by the generation means in a recording area;
Output means for outputting log data accumulated in the recording area by the accumulation means;
A software debugging support apparatus comprising:

(Supplementary note 10)
When the software to be verified is executed by a hardware model or hardware, a generation process for generating log data in which address information of the source code is associated with an execution result for each source code of the software,
An accumulation step of accumulating log data generated by the generation step in a recording area;
An output step of outputting log data accumulated in the recording area by the accumulation step;
A software debugging support method comprising:

100 Software debugging support device 101 Source code (whole)
102 Executable file 103 Input data (test pattern)
104 Output data (execution result)
105 Log data 110 ESL tool 111 ISS
112 HW model 120 Software debug program 130 GUI
131 Register access log 132 Source code (log corresponding part)

Claims (3)

A computer capable of accessing a source code group of verification target software and a log data group when the verification target software is executed by a hardware model or hardware;
Accepting means for accepting selection of an arbitrary register from among the registers described in the log data group;
Search means for searching a source code including a description of the arbitrary register received by the receiving means from the source code group,
Output means for outputting the source code searched by the search means in association with log data in which the arbitrary register is described;
Software debugging support program characterized by functioning as A software debugging support apparatus capable of accessing a source code group of verification target software and a log data group when the verification target software is executed by a hardware model or hardware,
Accepting means for accepting selection of an arbitrary register from among the registers described in the log data group;
Search means for searching a source code including a description of the arbitrary register received by the receiving means from the source code group;
Output means for outputting the source code searched by the search means in association with log data in which the arbitrary register is described;
A software debugging support apparatus comprising: A computer capable of accessing a source code group of verification target software and a log data group when the verification target software is executed by a hardware model or hardware,
An accepting step of accepting selection of an arbitrary register from among the registers described in the log data group;
A search step for searching a source code including a description of the arbitrary register received by the receiving step from the source code group;
An output step of outputting the source code searched by the search step in association with log data in which the arbitrary register is described;
A software debugging support method comprising:

Images