JP2004021751A - Debug system, debug program, and debug program storage medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable the constitution of a device with minimized test system and terminal number in a debug device for a plurality of processor cores, and the high-speed execution thereof. <P>SOLUTION: Each of a plurality of processor cores 106 and 107 of an LSI 108 is debugged by debuggers 102 and 103 having input and output function of debugging command, which are operated on a computer system 101. This system has a shared memory 104 accessible from each of the debuggers 102 and 103. Only when the shared memory 104 is referred to acquire a hard access right by the content of the shared memory 104 before issuing a command for transmitting a debug command from an optional debugger to the LSI, a hard access is started. When the other debugger issues the command, also, it is determined by the content of the shared memory 104, and the hard access is performed only when the access right is acquired. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a debugging device that supports hardware evaluation and software debugging of a target system using a microprocessor, and more particularly, to a debugging device in a system in which the target system includes a plurality of processor cores.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, in developing a target system of a microprocessor, a debugging device has been used for evaluating the system and software. Further, in recent years, as the use of system LSIs has progressed, the number of processor cores having an on-chip debug circuit has increased, and a debug device using the debug circuit has become common. Among them, when debugging a system LSI composed of a plurality of processor cores, system verification between processor cores and software debugging are important issues.
[0003]
Until now, multiple processor cores have been controlled by serial ports such as JTAG, and the test system is connected to multiple sets of serial port output terminals according to the number of processor cores to be debugged. The debug system was configured with only cores.
[0004]
A test system usually has a command input function and an execution result output function on a computer system having an input / output function, and commands from the computer system control data transmitted to and received from a debug circuit of a microprocessor. It is exchanged via the control unit. FIG. 19 shows an example of the configuration. The LSI 209 is composed of two processor cores, CORE (A) 207 and CORE (B) 208, each of which has a terminal output by a serial port, and has a control unit (A) 205 and a control unit (B), respectively. 206. The control unit is connected to a debugger (A) 203 and a debugger (B) 204 on the computer systems PC (A) 201 and PC (B) 202, respectively.
[0005]
As another system, a plurality of processor cores are connected by a set of serial ports, and output terminals of the plurality of processor cores are connected to a server application on a computer system and a plurality of debugger applications for a debug target core via a control unit. Starts up and there is something that constitutes a debugging device. FIG. 20 shows an example of the configuration. An LSI 309 is composed of a CORE (A) 307 and a CORE (B) 308, each of which is connected by a serial chain such as a JTAG system. The LSI 309 has a terminal output of one set of serial ports, and is connected to a control unit 306. You. The control unit 306 is connected to a master computer system PC (A) 301, and the server application 305 transmits and receives data to and from the control unit 306 on the computer system PC (A) 301. The server application 305 can be accessed from a debugger (A) 303 started on the computer system PC (A) 301 or a debugger (B) 304 on a remote computer system PC (B) 302 connected to a network.
[0006]
[Problems to be solved by the invention]
However, in order to debug the plurality of processor cores 207 and 208, the debugging device in the conventional example of FIG. 19 has a plurality of sets of computer systems 201 and 202 and control units 205 and 206 corresponding to the processor cores 207 and 208. Is required. Although the problem may be small when the number of processor cores is small, it is difficult to construct an environment for debugging an LSI including a large number of processor cores. Furthermore, with the miniaturization of LSIs, the chip area limitation due to the number of terminals has become a major issue, and since it is necessary to output debugging terminals for the processor cores to be debugged individually from the LSI 309, the chip area is large. This leads to a problem that the cost of the chip is further increased.
[0007]
The debug device in the conventional example of FIG. 20 does not require a plurality of sets of debug systems or output terminals from an LSI as in the conventional example of FIG. 19, but the debuggers 303 and 304 and the processor core 307, Since the exchange of data with the server 308 is performed via the server application 305, there is a problem that the response speed of the debugger becomes slow. Further, when debugging is performed on a plurality of processor cores, there is another problem that a plurality of computer systems corresponding to the debug are required.
[0008]
SUMMARY OF THE INVENTION An object of the present invention is to solve the above-mentioned conventional problems, and an object of the present invention is to realize a multi-processor core debug environment which can be configured with a minimum test system and the number of terminals and can be executed at high speed. .
[0009]
[Means for Solving the Problems]
In order to achieve the above object, according to the present invention, a system for debugging a plurality of processor cores of an LSI using a debugger having a command input / output function that operates on a computer system is provided. A shared memory that is accessible, and only when a hard access right is acquired by referring to the shared memory before issuing a command for sending a debug instruction from any debugger to the LSI, and by referring to the contents of the shared memory In the meantime, the hard access is started. During that time, even if another debugger issues a command, it is determined based on the contents of the shared memory, and if the access right cannot be acquired, the hard access is not performed. As a result, debugging of a plurality of processor cores can be performed at high speed without using a server application as in the related art.
[0010]
Therefore, when issuing a command from a plurality of arbitrary debuggers, the debugging device according to the present invention refers to the contents in the shared memory and acquires the hard access right or acquires the hard access based on the contents. An arbitration unit is provided for avoiding the failure.
[0011]
According to this configuration, when debugging a plurality of processor cores, a single computer system can activate a plurality of debuggers for each processor core to perform high-speed debugging. Further, it is possible to debug a plurality of processor cores with a minimum system of one computer system and one control unit. Further, even when a new debugger is added to the debug device, it is only necessary to add an access processing unit to the shared memory, so that the number of steps required for the debugger is reduced.
[0012]
Further, it is preferable that the debugging device of the present invention includes a transmission debugger name storage unit that stores the name of the debugger in the shared memory when an arbitrary debugger acquires the hard access right.
[0013]
According to this configuration, the debugger whose access right cannot be acquired can refer to the transmission debugger name storage unit to confirm what the debugger is currently performing hard access. Also, every time a command is issued to the processor core to be debugged, it is necessary to send information on which processor core should be bypassed to multiple serially connected processor cores. Then, when the same debugger as before tries to access, there is no need to send bypass information, so that it is possible to execute the command at higher speed.
[0014]
Furthermore, the debug device of the present invention preferably includes a command storage unit that can store a command when one debugger wants to issue a command to the other debugger when two debuggers are running. .
[0015]
According to this configuration, it is possible to perform a command operation from one debugger to the other debugger. For example, it is possible to perform operations such as execution and forced break from any debugger to another debugger.
[0016]
Further, when two or more debuggers are activated and one debugger wants to issue a command for a specific debugger, the debugger of the present invention can store the name of the debugger that is the command receiving destination. Preferably, a receiving debugger name storage is provided.
[0017]
According to this configuration, a command operation can be performed from one debugger to a specific debugger. For example, it is possible to perform operations such as execution and forced break from an arbitrary debugger to a specific debugger.
[0018]
Further, the debug device of the present invention preferably includes a command result storage unit for storing a result of executing the command.
According to this configuration, the result of operating a command from one debugger to a specific debugger can be referred to from the other debugger. For example, an arbitrary debugger can refer to or change the memory contents of a specific debugger.
[0019]
Further, it is preferable that the debugging device of the present invention includes a priority arbitration unit that executes the command with priority.
According to this configuration, it is possible to execute a command in response to a command request having a high priority in real time, and it is possible to perform efficient debugging.
[0020]
Further, the debug device of the present invention preferably includes, in the shared memory, a control unit information storage unit in which any debugger stores register information common to a plurality of debuggers of the control unit.
[0021]
That is, conventionally, regarding a register used by a plurality of debuggers of the control unit, if an arbitrary debugger needs to refer to the register and clear its value immediately, only the referred debugger can read the register. I could not get the information. However, according to this configuration, the debugger that refers to the register contents stores the common register information in the control unit information storage unit in the shared memory, so that other debuggers can refer to the register information. Become.
[0022]
In order to achieve the above object, a debug program according to the present invention reads a command and determines whether or not the command is a hard access command, and determines whether or not a hard access right can be acquired. Referencing the memory contents of the arbitration unit of the shared memory to perform the operation, changing the memory contents of the arbitration unit when the hard access right can be acquired, executing the command, and completing the command execution. And a step of referring to the memory content of the arbitration unit and changing the content again in order to relinquish the access right of the arbitration unit.
[0023]
By causing the computer system to execute the debug program, a debug device according to the present invention can be realized.
In the present invention, in the step of referring to the arbitration unit, in addition to the process of accessing the arbitration unit, when the debug program acquires the hard access right, the name of the debugger that acquired the hard access right in the transmission debugger name storage unit Setting, a step of referring to the transmission debugger name storage when the hard access right cannot be acquired, and a step of clearing the transmission debugger name storage when the hard access right is abandoned. Preferably, it is executed by a computer system.
[0024]
Further, in the present invention, when the number of activated debuggers is two, in addition to the process of accessing the arbitration unit when one of the debuggers is activated, a command is executed from one debugger to the other debugger. A step of determining whether or not to perform the setting; a step of storing the command in the command storage unit when it is determined that the command setting is to be performed; a step of looping until the memory content of the command storage unit is cleared; If the data is set in the command storage unit of the shared memory at regular intervals, and the other debugger is determined if the data is set in the command storage unit. To execute the command, and to clear the contents of the command storage when the command ends. And flop, it is preferable command storage unit in which to execute the processing including the steps of passing the loop when it is cleared in the computer system.
[0025]
Further, in the present invention, when the number of activated debuggers is two or more, in addition to the process of accessing the arbitration unit and the process of accessing the command setting unit, when the number of activated debuggers is two or more, the debug program sends a command from an arbitrary debugger to a specific debugger. In order to issue, the step of storing the name of the specific debugger that executes the command in the receiving debugger name storage unit, and whether the data set in the receiving debugger name in the shared memory is its own debugger name or not A step of executing a command in the command storage unit when the receiving debugger determines that the two match, and a step of clearing the receiving debugger storage when abandoning the hard access right to the computer system. It is preferable that the program be executed.
[0026]
Furthermore, in the present invention, in addition to the process of accessing the arbitration unit, the process of accessing the command setting unit, and the process of accessing the received debugger name storage unit, the debug program executes command execution from an arbitrary debugger to a specific debugger. Executing the command in the command storage unit to store the command result in the command result storage unit, storing the command result in the command result storage unit, and referring to the command result storage unit from an arbitrary debugger. Clearing the command storage when relinquishing the right.
[0027]
Further, in the present invention, in addition to the process of accessing the arbitration unit, the debug program refers to the priority arbitration unit for the purpose of determining whether or not priority execution is possible in order to execute the command preferentially; Preferably, the method includes a step of setting priority execution in the priority arbitration unit when the priority arbitration unit can be executed, and a step of clearing priority execution of the priority arbitration unit when ending the priority execution.
[0028]
A debug program storage medium according to the present invention is characterized by recording at least one of the above debug programs.
Further, the debugging device of the present invention sets, for each of a plurality of debuggers, ID information setting for defining an instruction register (IR) and a data register (DR) of a processor core connected before and after a plurality of processor cores to be debugged serially connected. It is preferable to provide a part.
[0029]
That is, in the prior art, each debugger has dealt with the connection information of a plurality of processor cores that are uniquely serially connected. However, according to this configuration, the ID information definition unit stores the IR of the processor core connected before and after the IR and DR. By simply setting the DR and DR, it is possible to issue an instruction to the processor core to be debugged simply by changing the ID information setting section, regardless of what connection is generally added later.
[0030]
Further, according to the present invention, it is preferable to include an ID information storage unit of the control unit that stores the ID information, and an automatic code generation unit for generating transmission codes for a plurality of processor cores.
[0031]
According to this configuration, conventionally, debug instructions are generated for each of a plurality of processors by each debugger and transmitted via the control unit. However, if only debug instructions for the processor core to be debugged are transmitted, the control unit By automatically generating an instruction code for a serially connected processor core connected to a target system from the ID information and transmitting the code to the target system, a debug instruction can be transmitted as in the related art. In addition, with the configuration of the debugging device, it is not necessary to transmit the ID information and the instruction code other than the target processor core every time the communication between the computer system and the control unit is performed, so that a high-speed debugging response can be realized.
[0032]
In the debugging device of the present invention, it is preferable that the control unit includes a monitor instruction storage unit.
That is, in the conventional method, a monitor code is input from a host computer system through a serial port one instruction at a time. However, the response speed of the entire debugger is reduced due to the transfer speed of the host interface. there were. For example, a group of monitor code instructions sent when a debugger breaks is always the same. Therefore, in the present invention, by setting the instruction group sent immediately after the break in the monitor instruction storage unit of the control unit, the exchange of the instruction immediately after the break becomes a transfer between the control unit and the processor. Can be suppressed, and instructions can be executed at high speed.
[0033]
Also, according to the invention, it is preferred that the multiple debuggers operate on only one computer system.
According to this configuration, it is possible to construct a debugging environment with a minimum test system. That is, if there is only a space-saving and lightweight computer system such as a notebook personal computer and a control unit, the target system can be debugged.
[0034]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
A debugging device according to an embodiment of the present invention provides a target system in which an LSI includes a plurality of processor cores, each of which is serially connected, and only one set of debugging output terminals is output from the LSI. It is assumed that the core is a system that operates on a computer system and is debugged by a debugger having a command input / output function for debugging. In addition, the debugger includes a program execution, stop (break), step execution function, data, register, and stack reference or change functions for debugging a program operating on the target system. I do.
[0035]
FIG. 1 is a block diagram illustrating a schematic configuration of a debugging device according to an embodiment of the present invention. In this debugging device, the debugger (A) 102 and the debugger (B) 103 are activated on the computer system 101, and the shared memory 104 is created. Commands from the debugger (A) 102 and the debugger (B) 103 are sent to the LSI 108 via the control unit 105. In the LSI 108, a processor core (A) 106 to be debugged by the debugger (A) 102 and a processor core (B) 107 to be debugged by the debugger (B) 103 are connected by a serial chain. The debugging terminal is output. Since there is only one set of debugging terminals, only one of the plurality of debuggers 102 and 103 running on the computer system 101 can make hard access to the LSI 108 via the control unit 105. Only one debugger.
[0036]
FIG. 9 is a flowchart illustrating a method of accessing an arbitrary shared memory 104 by an arbitrary debugger when the arbitration unit 401 exists inside the shared memory 104 as shown in FIG.
[0037]
First, in the command input step S101, the debuggers 102 and 103 input a command (in the following description, for simplicity, "step" is simply abbreviated to "S"). In S102, it is checked whether or not the command input in S101 is a command accompanied by hard access (hard access command). If the determination result in S102 is YES, in the next S103, the arbitration unit 401 of the shared memory 104 in FIG. 2 is accessed, and the state of the arbitration flag in the arbitration unit 401 is determined. If the arbitration flag is ON and it is determined that another debugger is in the hard access state, the process returns to S101. If it is determined that the arbitration flag is OFF and none of the other debuggers is in the hard access state, the value of the arbitration flag is set to ON in S104. As a result, the hard access command is permitted, and in the next S105, the hard access is started. When the execution of the command is completed, the state of the arbitration flag is determined in S106. If the arbitration flag is ON, the arbitration flag is set OFF in S107, and a hard access termination procedure is performed. In step S102, if the command input in step S101 is a command not accompanied by hard access, that is, if the command is not a hard access command, the command is directly executed in step S105, and if the arbitration flag is OFF in step S106, the command is directly executed. Perform the hard access termination procedure. By repeating the above operation, it is possible to debug an LSI having a plurality of processor cores.
[0038]
FIG. 10 is a flowchart illustrating a method of accessing a shared memory by an arbitrary debugger when the arbitration unit 501 and the transmission debugger name storage unit 502 exist inside the shared memory 104 as shown in FIG.
[0039]
First, the debugger inputs a command in a command input step S201. In S202, it is checked whether the command input in S201 is a hard access command. If the determination result in S202 is YES, in the next S203, the shared memory is accessed, and the state of the arbitration flag in the shared memory is determined. If the arbitration flag is ON in S203, it indicates that another debugger is executing a hard access instruction. Therefore, in step S205, referring to the transmission debugger name storage unit 502 in the shared memory to check which debugger is performing hard access, the process returns to step S201. If it is determined in S203 that the arbitration flag is OFF and none of the other debuggers is in the hard access state, the value of the arbitration flag is set to ON in S204. In the next step S206, the debugger that has started the hard access stores its own debugger name in the transmission debugger name storage unit 502 of FIG. In the next step S207, since the hard access command is permitted, the hard access is started. When the execution of the command is completed, the state of the arbitration flag is determined in S208. If the arbitration flag is ON, the arbitration flag is set OFF in S209, the transmission debugger name is cleared in S210, and a hard access termination procedure is performed. In S202, if the command input in S201 is a command not accompanied by hard access, that is, if the command is not a hard access command, the command is executed as it is in S207, and if the arbitration flag is OFF in S208, the command is Perform the hard access termination procedure.
[0040]
As described above, the name of the debugger for which the access right has been acquired is stored in the transmission debugger name storage unit 502. Therefore, in a case where the access right cannot be obtained while a plurality of debuggers are running, which debugger accesses the Can be referred from the debugger side that cannot acquire the access right.
[0041]
FIG. 11 is a flowchart illustrating a method of accessing a shared memory by an arbitrary debugger when the arbitration unit 601 and the command storage unit 602 exist inside the shared memory 104 as in FIG.
[0042]
Here, it is assumed that only two debuggers are activated to perform debugging. First, in a command input step S301, it is confirmed whether or not the debugger is in a command input start state. When the command input is started, it is checked in S302 whether the command input in S301 is a hard access command. If the determination result in S302 is YES, in the next S303, access to the shared memory is performed, and the state of the arbitration flag in the shared memory is determined. If it is determined that the arbitration flag is OFF and the other debugger is not in the hard access state, the value of the arbitration flag is set to ON in S304. If the arbitration flag is ON in S303, the process returns to S301.
[0043]
In the next step S305, it is determined whether or not the debugger attempting to acquire the access right issues a command to the other debugger. If a command is to be issued, the command is stored in the command storage unit 602 in FIG. The next step S307 is a step of judging whether or not the command set in the command storage section 602 has been cleared. When the command is executed by the other debugger, the command storage unit 602 is cleared, and the process proceeds to the next step, S308. In step S308, the execution of the above command terminates the hard access. Therefore, it is determined whether the arbitration flag is ON. If the arbitration flag is ON, the arbitration flag is set to OFF in step S309, and the hard access termination procedure is performed. Take. If the arbitration flag is OFF in S308, the procedure for terminating the hard access is immediately taken.
[0044]
When the command input is not started in the step of S301, it is determined that the command is stored in the step S310, in which it is determined at a certain period whether or not data is stored in the command storage unit 602 inside the shared memory 104. If it has, the command is issued in step S311 and the command is executed. If it is determined that no command is stored, the process returns to S301. In the next step S312, it is determined whether or not there is data in the command storage unit 602. If data remains, the command setting unit 602 is cleared in the next step S313, and the process proceeds to S307. Perform the hard access termination procedure. If no data remains in S312, the process immediately proceeds to S307.
[0045]
If the input command is not a hard access command in S302, or if the debugger trying to acquire the access right does not issue a command to the other debugger in S305, the command is issued in S311.
[0046]
By setting a command in the command storage unit 602 in this manner, a command can be transmitted from one debugger to the other debugger only when two debuggers are running. Forcibly perform an execution operation or an end operation on the debugger.
[0047]
FIG. 12 is a flowchart showing a method for an arbitrary debugger to access the shared memory when the arbitration unit 701, the command storage unit 702, and the received debugger name storage unit 703 exist in the shared memory 104 as shown in FIG. is there.
[0048]
Here, it is assumed that two or more debuggers are activated to perform debugging. First, in a command input step S401, it is checked whether or not the debugger is in a command input start state. When the command input is started, it is checked in S402 whether the command input in S401 is a hard access command. If the determination result in S402 is YES, in the next S403, the shared memory 104 is accessed, and the state of the arbitration flag in the shared memory is determined. If it is determined that the arbitration flag is OFF and none of the other debuggers is in the hard access state, the value of the arbitration flag is set to ON in S404. If the arbitration flag is ON in S403, the process returns to S401.
[0049]
In the next step S405, it is determined whether or not the debugger trying to acquire the access right issues a command to another debugger. If a command is issued, the name of the debugger that receives the command is stored in the received debugger name storage unit 703 in FIG. 5 in S406. Next, in S407, the command name to be executed is set in the command storage unit 702. The next step S408 is a step of judging whether or not the command set in the command storage section 702 has been cleared, and is checked until the command is cleared. When a command is executed by another debugger, the command storage unit 702 is cleared, and the process proceeds to the next step, S409. In step S409, since the hard access has been completed, it is determined whether the arbitration flag is ON. If the arbitration flag is ON, the arbitration flag is set to OFF in step S410, and a procedure for terminating the hard access is performed. If the arbitration flag is OFF in S409, the procedure for terminating the hard access is immediately taken.
[0050]
When the command input is not started in S401, in step S411, it is determined at a certain period whether or not the debugger name of the own device is stored in the receiving debugger name storage unit 703 inside the shared memory 104. If it is determined that the debugger name is stored, a command is issued in step S412, and the command is executed. Next, when the execution of the command is completed, if the reception debugger name is set in S413, the contents of the reception debugger storage unit 703 are cleared in S414. If a command is stored in the command storage unit 702 in step S415, the contents of the command storage unit 702 are cleared in step S416, and the process advances to step S408 to perform a hard access termination procedure. If the own debugger name is not stored in S411, the process returns to S401. If the receiving debugger name has not been set in S413, the process immediately proceeds to S415. If it is determined in step S415 that no command is stored in the command storage unit 702, the process immediately proceeds to step S408.
[0051]
By setting a command in the command storage unit 702 in this way, a command can be transmitted from a certain debugger to another specific debugger. And an end operation can be performed.
[0052]
FIG. 13 shows that an arbitrary debugger accesses the shared memory when the arbitration unit 801, the command storage unit 802, the received debugger name storage unit 803, and the command result storage unit 804 exist in the shared memory 104 as shown in FIG. 5 is a flowchart illustrating a method.
[0053]
Here, in the command input step S501, it is confirmed whether or not the debugger is in a command input start state. If the command input is started, it is checked in S502 whether the command input in S501 is a hard access command. If the determination result in S502 is YES, in the next S503, the shared memory 104 is accessed, and the state of the arbitration flag in the shared memory is determined. If it is determined that the arbitration flag is OFF and none of the other debuggers is in the hard access state, the value of the arbitration flag is set to ON in S504. If the arbitration flag is ON in S503, the process returns to S501.
[0054]
In the next step S505, it is determined whether the debugger trying to acquire the access right issues a command to the other debugger. If a command is issued, the name of the debugger that receives the command is stored in the received debugger name storage unit 803 in FIG. 6 in S506. Next, in S507, the command name to be executed is set in the command storage unit 802. The next step S508 is a step of determining whether or not the command set in the command storage unit 802 has been cleared. When the command is executed by the other debugger, the command storage unit 802 is cleared, and the process proceeds to the next step.
[0055]
That is, since the hard access has been completed as described above, in the next step S509, it is determined with reference to the command result storage unit 804 of FIG. If there is, the command result is referred to in S510. After the reference, in S511, the data in the command result storage unit 804 is cleared. In the next S512, it is determined whether or not the arbitration flag is ON. If the arbitration flag is ON, the arbitration flag is set to OFF in S513, and a hard access termination procedure is performed. If there is no command result data in S509, S512 is executed. If the arbitration flag is OFF in S512, a hard access termination procedure is immediately taken.
[0056]
If the command input is not started in S501, in step S514, it is determined at a certain period whether or not the debugger name is stored in the reception debugger name storage unit 803 in the shared memory 104. If it is determined that the debugger name is stored, a command is issued in the next step S515, and the command is executed. Next, when the command execution is completed, it is determined in S516 whether or not the execution result is stored in the command result storage unit 804 in FIG. 6, and if it is determined that the execution result is stored, the command result is stored in S517.
[0057]
Next, if the reception debugger name has been set in S518, the contents of the reception debugger storage unit 803 are cleared in S519. If a command is stored in the command storage unit 802 in step S520, the contents of the command storage unit 802 are cleared in step S521, and the process advances to step S508 to perform a hard access termination procedure. If the own debugger name is not stored in S514, the process returns to S501. In S516, if the execution result is not stored in the command result storage unit 804 of FIG. 6, the process immediately proceeds to S518. If the receiving debugger name is not set in the receiving debugger name storage unit 803 in S518, the process immediately proceeds to S520. Further, in step S520, if no command is stored in the command storage unit 802, the process immediately proceeds to step S508.
[0058]
By setting a command in the command storage unit 802 in this manner, a command can be transmitted from one debugger to another specific debugger, and the execution result of the command can be referred to from the transmitted debugger. For example, the contents of a certain memory can be referred to and changed by a certain debugger from the own debugger. It is also possible to refer to the contents after the step execution.
[0059]
FIG. 14 is a flowchart illustrating a method in which an arbitrary debugger accesses the shared memory when the arbitration unit 901 and the priority arbitration unit 902 exist in the shared memory 104 as in FIG.
[0060]
Here, the debugger inputs a command in the command input step S601. In the next step S602, the shared memory 104 is accessed, and the state of the priority flag in the shared memory 104 is determined. If it is determined that the priority flag is OFF and that no other debugger is executing priority, the shared memory is accessed in S603, and the state of the arbitration flag in the shared memory is determined. If the arbitration flag is OFF and it is determined that none of the other debuggers is in the hard access state, the value of the arbitration flag is set to ON in S604. When the priority flag is ON in S602 and when the arbitration flag is ON in S603, the process returns to S601.
[0061]
In the next step S605, it is determined whether or not to execute the command input with priority. If the command is to be executed with priority, the priority flag is set to ON in the priority arbitration unit 902 in FIG. 7 in S606, and the command is executed in S607. If the command input is not preferentially executed in S605, the command is immediately executed in S607. When the execution of the command is completed, it is determined in S608 whether or not the command is to be executed again preferentially. If the command is to be executed preferentially, the execution of the command input is repeated in S609, and in S607, every time this command is executed, S608 is executed. It is determined whether or not to execute preferentially.
[0062]
When the priority execution is completed, it is determined in S610 whether or not the setting of the priority flag is ON. If the setting is ON, the priority flag is turned OFF in S611. In addition, it is determined whether or not the arbitration flag is ON in S612, and if it is ON, the arbitration flag is turned OFF in S613 and a hard access termination procedure is performed. If the setting of the priority flag is OFF in S610, the process immediately proceeds to S612. If the arbitration flag is OFF in S612, a procedure for terminating the hard access is immediately performed. By setting the priority arbitration unit 902 in this way, it is possible to preferentially execute a command.
[0063]
FIG. 15 is a flowchart showing a method of accessing a shared memory by an arbitrary debugger when the arbitration unit 1001 and the control unit information storage unit 1002 exist inside the shared memory 104 as shown in FIG.
[0064]
Here, the debugger inputs a command in the command input step S701. Next, in S702, it is determined whether or not data is stored in the control unit information storage unit 1002 in the shared memory 104. If it is stored, the process ends after referring to the control unit information in S703.
[0065]
If data is not stored in the control unit information storage unit 1002 in S702, it is checked in S704 whether the command input in S701 is a hard access command. If the determination result in S704 is YES, in the next S705, the shared memory 104 is accessed, and the state of the arbitration flag in the arbitration unit 1001 in the shared memory 104 is determined. If it is determined that the arbitration flag is OFF and none of the other debuggers is in the hard access state, the value of the arbitration flag is set to ON in S706. As a result, the hard access command is permitted, and in the next step S707, the hard access is started. In S704, if the command input in S701 is not a hard access command, the process immediately proceeds to S707, and if the arbitration flag is ON in S705, the process returns to S701.
[0066]
When the completion of the command issuance in S707 is confirmed, it is determined in S708 whether register information common to a plurality of debuggers of the control unit is stored. If it is determined in step S708 that the common register information is stored, the common register information is stored in the control unit information storage unit 1002 in FIG. 8 in step S709. In the next step S710, it is determined whether or not the arbitration flag is ON. If the arbitration flag is ON, the arbitration flag is set to OFF in S711, and a hard access termination procedure is performed. If the register information is not stored in S708, the process immediately proceeds to S710, and if the arbitration flag is OFF in S710, a procedure for terminating the hard access is immediately performed.
[0067]
In this way, even if any debugger refers to the common register information in the control unit and needs to clear it, by storing the register information in the control unit information storage section of the shared memory, other debuggers can be used. However, that information can be referred to.
[0068]
Next, referring to FIG. 16, for each of the plurality of debuggers, the IR (instruction register) and DR (instruction register) of the processor cores connected before and after the processor core to be debugged among the plurality of serially connected processor cores will be described. A description will be given of a case where a data register is defined and used.
[0069]
A plurality of processor cores are serially connected as an interface for debugging. Usually, a debugging function is realized by an interface called a JTAG interface. Here, the case where the JTAG is used will be described. Before and after the core to be debugged, another processor core is serially scan-chain connected. Therefore, in order to access a specific core, it is necessary to bypass the processor cores before and after the particular core.
[0070]
Conventionally, an arbitrary debugger directly holds connection information of a processor core before and after a processor core to be debugged. Therefore, when the order of connection is changed or when a new processor core is added, it is necessary to modify the debugger again.
[0071]
On the other hand, in FIG. 16, the ID information setting unit 2004 is set in the debugger 2001. In the ID information setting unit 2004, the number of register bits of IR and DR connected before and after the core to be debugged is set. That is, here, it is assumed that the processor A2014, the processor B2015, and the processor C2016 of the LSI 2013 are serially connected by the JTAG interface. Processor A 2014 has an IR bit length of 6 and a DR bit length of 1, processor B 2015 has an IR bit length of 4 and a DR bit length of 6, and processor C 2016 has an IR bit length of 3 and a DR bit length of 3. The bit length is 1. Then, assuming that the debugger 2001 debugs the processor B 2015, the IR information and the DR connected before and after the processor B 2015 are set in the ID information setting unit 2004. That is, 6 which is the IR bit length of the processor A2014 is set in the IR-IN 2005 of the TDI which is the input side of the JTAG. In addition, since the DR is bypassed, 1 which is the DR bit length of the processor A 2014 is set in the DR-IN 2007. Next, 3 which is the IR bit length of the processor C 2016 is set in the IR-OUT 2006 of the TDO serving as the output side of the processor B 2015. Since DR is bypassed, 1 which is the DR bit length of the processor C 2016 is set in DR-OUT 2008.
[0072]
In the debugger 2001, these contents in the ID information setting unit 2004 are stored in the ID information storage unit 2003, and further transmitted from the ID information transmission unit 2002 to the control unit 2009. Then, the ID information is received by the ID information receiving unit 2012 of the control unit 2009, and the received ID information is stored in the ID information storage unit 2011. In order to perform serial transmission including the processor core to be bypassed to the LSI 2013, the code automatic generation unit 2010 generates a code to be transmitted to the LSI 2013 based on the IR and DR information for bypass received by the ID information reception unit 2012. Generate. Then, by transmitting the code generated in this manner to the LSI 2013, an instruction code for the processor B 2015 to be debugged can be transmitted, and the result can be obtained.
[0073]
Therefore, by simply setting the IR and DR register bits connected before and after the debug target processor B 2015 in the ID information setting unit 2004 of the debugger 2001, the ID information setting unit 2004 can be used regardless of any general connection added later. An instruction for the processor B 2015 to be debugged can be issued only by making a change.
[0074]
Also, by setting the ID information only once in the control unit 2009 and generating the instruction code by the automatic instruction code generation unit 2010 in the control unit 2009, the data transmission between the computer system and the control unit 2009 is a debug target. It is only necessary to transmit IR and DR data to the processor, so that the amount of transmission data can be reduced. Therefore, it can be executed at higher speed.
[0075]
With reference to FIG. 17, a description will be given of a debugging device that sends monitor instructions transmitted from a debugger all at once. To obtain debug information, an instruction is transmitted from the debugger to the LSI via the control unit. Regarding the instruction, for example, the instruction sent to the LSI immediately after the break is always the same instruction sequence. The instruction sequence is set as batch instruction data of the debugger 3001. Next, at the time of activation or the like, the monitor command in the monitor command storage unit 3003 is transmitted to the control unit 3004 only once by the monitor command transmission unit 3002. The monitor command is received by the monitor command receiving unit 3005 of the control unit 3004, and is stored in the monitor command storage unit 3007. Next, when the processor core to be debugged breaks, data in the monitor instruction storage unit 3007 is transmitted from the monitor instruction transmission unit 3006 to the LSI 3008. The LSI 3008 includes a processor A 3009, a processor B 3010, and a processor C 3011.
[0076]
That is, conventionally, it has been necessary to input a monitor code from the host computer system one instruction at a time through the serial port. However, according to this debug device, the exchange of instructions immediately after a break involves the transfer between the control unit and the processor. Therefore, the amount of transfer between host interfaces can be suppressed, and instructions can be executed at high speed.
[0077]
Hereinafter, a detailed processing example of a typical command operation will be described based on the flowcharts shown in FIGS. 9 to 15. The requests 1) to 4) shown in FIG. 18 will be described with reference to the flow chart showing an example of analysis. It is assumed that processor cores A, B, and C exist in the target system, and the debuggers A, B, and C corresponding to the processor cores are activated on one computer system. At that time, first, a case where the debugger C is in the RUN state and the debugger A issues a forced break to the debugger C will be described.
[0078]
First, the debugger A inputs a forced break command in S401 of FIG. On the other hand, in step S402, it is determined whether the forced break command is a hard access command. Since the command is a hard access command, the content of the arbitration flag of the arbitration unit is determined in the next step S403. Here, assuming that the arbitration flag is OFF, the arbitration flag is set ON to acquire the arbitration right in S404. Next, in S405, it is determined whether or not the command is for another debugger. Since the command is for the debugger C, "C" is input to the receiving debugger name storage unit 703 in FIG. 5 as a receiving debugger in S406. In step S407, the “forced break command” is stored in the command storage unit 702. Next, in S408, the process waits in a loop until the contents of the command storage unit 702 are cleared. At this time, since the debugger C has not input a command in S401, it checks the data in the received debugger name storage unit 703 at a fixed time period in S411, determines “C” written from the debugger A, and sends it to itself. The command is recognized. The debugger C issues a forced break command in S412, and the debugger C performs a forced break. Next, since the received debugger name is stored as “C” in S413, the received debugger name storage unit 703 is cleared in S414. Next, since the "forced break command" is stored in the command storage unit 702 in S415, the command storage unit 702 is cleared in S416. Thereafter, since the debugger A has been waiting for the command storage unit 702 to be cleared in the loop processing, it is confirmed that the command storage unit 702 has been cleared in S416, and the process proceeds to S409. In S409, it is checked whether or not the arbitration flag is ON. Since the arbitration flag is ON, the arbitration flag is set to OFF, and the request of 1) is completed. By the above processing, the request of 1) can be realized.
[0079]
Next, 2) a case where the debugger A issues a hard access command but cannot obtain an access right will be described.
First, in the flowchart of FIG. 9, a hard access command is input from the debugger A in S101. In S102, it is determined that the command is a hard access command. Next, in S103, it is determined whether or not the arbitration flag is ON. If the arbitration flag is ON, the debugger B or the debugger B other than the debugger A has already been determined. It can be seen that the debugger C has issued a hard access command. In this case, the process returns to S101, and the command is input again. In this flowchart, if the access right cannot be obtained, the flow returns to the command input. However, the arbitration unit is accessed for a certain period of time to obtain the access right, and a loop process is performed until the access right can be obtained. Processing such as waiting at the terminal can be considered.
[0080]
Further, when the debugger A cannot acquire the access right in 2), it can be confirmed that the debugger B or the debugger C has the access right, but it is possible to know which one has the access right. Can not. Therefore, when the debugger B or the debugger C acquires the access right, the name of the debugger having acquired the access right is stored in the transmission debugger name setting unit 502 in FIG. At this time, first, a command is input from S201, and it is determined that the command is a hard access command in S202. Since the arbitration flag is OFF in S203, the arbitration right is acquired and the arbitration flag is set to ON in S204. Next, in step S206, the transmission debugger name is set in the transmission debugger name storage unit 502, and a command is issued in step S207. Next, in S208, it is confirmed whether or not the arbitration flag is ON. Since the arbitration flag is ON, the arbitration flag is turned OFF in S209, and the transmission debugger name is cleared in S210.
[0081]
As described above, since the debugger A issues a hard access command until the arbitration flag is turned OFF in S209 and the transmission debugger name is cleared in S210, the arbitration flag is determined to be ON in S203, and in S205, the transmission debugger is determined in S206. By referring to the set debugger name, it is possible to determine whether the debugger currently having the access right is the debugger B or the debugger C. The above processing makes it possible to fulfill the requirement 2).
[0082]
Next, 3) a case where the debugger A repeats step execution and memory dump preferentially will be described.
In the flowchart of FIG. 14, a step execution command is input from the debugger A in S601. In the next step S602, it is determined whether or not the priority flag of the priority arbitration unit 902 in FIG. 7 is ON. Since the priority flag is OFF, it is determined in the next step S603 whether the arbitration flag is ON. I do. Here, if it is determined that the arbitration flag is OFF and that no access has been made from another debugger, the arbitration flag is set to ON in S604. Next, since the debugger A prefers to execute the command preferentially, it is determined that the command is a priority command in S605, and the priority flag of the priority arbitration unit is set to ON in S606. In step S607, the input step execution command is executed, and in step S608, it is determined whether to repeat the priority execution. Here, since the debugger A repeats the step execution and the memory dump, the command is input again in S609. In this case, the memory dump command is input. This memory dump command is executed in S607, and in S608, it is determined again whether or not to repeat the priority execution. After repeating this, when ending the priority execution in S607, the state of the priority flag is confirmed to be ON in S610, and the priority flag is set to OFF in S611. In step S612, the state of the arbitration flag is confirmed to be ON, the arbitration flag is set to OFF, and the hard access ends. With the above processing, the request of 3) can be realized.
[0083]
Next, 4) the case where the debugger A refers to the memory contents of the debugger B will be described.
In the flowchart of FIG. 13, first, in step S501, the debugger A starts inputting a command. In step S502, it is determined whether the command is a hard access command. In step S503, it is determined whether the arbitration flag is ON. If the arbitration flag is OFF, the arbitration flag is set to ON in step S504. In step S505, a command issuance to another debugger is selected. In step S506, a debugger name to which a command is to be issued is set in the received debugger name storage unit 803 of FIG. 6, and in step S507, the command storage unit 802 is set. In this case, in order to issue a command for referring to the memory contents to the debugger B, “B” is written in the received debugger name storage unit 803 and a dump command is written in the command storage unit 802. Next, in S508, a loop process is performed until the data in the command storage unit 802 is cleared. Further, at this time, the debugger B does not input a command in S501, so that the process of checking the received debugger name storage unit 803 in S514 is repeated for a fixed time to confirm whether or not the debugger name is its own debugger name. After the debugger A writes "B" in S506, the debugger B confirms it in S514 and executes the dump command in S515. When the execution is completed, it is determined in S516 whether or not the command result is to be written to the command result storage unit 804, and in S517, the result of the dump command is written. Since there is a setting of the reception debugger in S518, the data is cleared in S519. Since there is data in the command storage unit in S520, the command storage unit is cleared in S521. At this time, since the debugger A has performed the loop processing in S508, the command storage unit 802 is cleared in S521, and the process proceeds to S509. In step S509, the command execution result of the debugger B can be referred from the debugger A by referring to the command result storage unit 804 for the result of the dump command executed by the debugger B. Next, it is confirmed in S512 that the arbitration flag is ON, and the arbitration flag is set OFF in S513. In step S510, the data in the command result storage unit 804 is confirmed. In step S511, the data in the command result storage unit 804 is cleared, and the command execution process ends. The above processing makes it possible to fulfill the requirement 4).
[0084]
【The invention's effect】
As described above, according to the present invention, a debugging device can be configured with a minimum test system and a minimum number of terminals. Therefore, if there is one computer system and one control unit, it is possible to debug a target system including a plurality of processor cores, and thus it is possible to perform debugging regardless of a location such as a field test of the target system. Further, debugging of a plurality of processor cores can be performed at high speed without using a server application as in the related art. In addition, debugging can be performed in cooperation with a plurality of debuggers, and system verification and software debugging between a plurality of processors can be efficiently performed.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of a debugging device including a shared memory according to an embodiment of the present invention.
FIG. 2 is a configuration diagram of a shared memory including an arbitration unit according to the embodiment of the present invention;
FIG. 3 is a configuration diagram of a shared memory including a transmission debugger name storage unit according to the embodiment of the present invention;
FIG. 4 is a configuration diagram of a shared memory including a command storage unit according to the embodiment of this invention;
FIG. 5 is a configuration diagram of a shared memory including a reception debugger name storage unit according to the embodiment of the present invention;
FIG. 6 is a configuration diagram of a shared memory including a command result storage unit according to the embodiment of this invention;
FIG. 7 is a configuration diagram of a shared memory including a priority arbitration unit according to the embodiment of the present invention;
FIG. 8 is a configuration diagram of a shared memory including a control unit information storage unit according to the embodiment of the present invention.
FIG. 9 is a flowchart illustrating an arbitration method according to an embodiment of the present invention.
FIG. 10 is a flowchart showing a method of using a transmission debugger name storage according to the embodiment of the present invention;
FIG. 11 is a flowchart illustrating a method of using the command storage unit according to the embodiment of this invention.
FIG. 12 is a flowchart illustrating a method of using the reception debugger name storage according to the embodiment of this invention;
FIG. 13 is a flowchart illustrating a method of using the command result storage unit according to the embodiment of this invention.
FIG. 14 is a flowchart showing a method of using the priority arbitration unit according to the embodiment of the present invention;
FIG. 15 is a flowchart showing a method of using the control unit information storage unit according to the embodiment of the present invention.
FIG. 16 is a configuration diagram of a debugging device including an ID information setting unit and an automatic code generation unit of a control unit according to an embodiment of the present invention.
FIG. 17 is a configuration diagram of a debugging device including a monitor instruction transmitting / receiving unit according to an embodiment of the present invention.
FIG. 18 is a diagram illustrating an example of a command for indicating an execution example of the debugging device according to the embodiment of this invention;
FIG. 19 is a configuration diagram of a conventional debugging device.
FIG. 20 is a configuration diagram of another conventional debugging device.
[Explanation of symbols]
101 Computer System
102 Debugger (A)
103 Debugger (B)
104 Shared memory
105 control unit
106 processor core (A)
107 processor core (B)
108 LSI

Claims (20)

An LSI is configured by a target system in which each of the processor cores is serially connected and only one set of terminals is output, and the LSI is configured by a plurality of processor cores;
When debugging the plurality of processor cores on a computer system, it is configured to exchange information between the computer system and a target system via a control unit,
A debugger having an input / output function of a command for debugging, corresponding to the processor core to be debugged, is configured to perform the debugging,
A shared memory that is accessible from a plurality of debuggers corresponding to the processor core to be debugged and stores information for causing each debugger to acquire a hard access right to the corresponding processor core; Debug device. The shared memory refers to the content of the shared memory before issuing a command to a corresponding processor core from any of the plurality of debuggers, and determines whether to issue the command based on the memory content. The debugging device according to claim 1, further comprising an arbitration unit that determines the condition. 3. The debugging device according to claim 2, wherein the shared memory includes, in addition to the arbitration unit, a transmission debugger name storage unit for storing a debugger name for transmitting a command when acquiring a hard access right. 3. The shared memory further includes a command storage unit for issuing a command from one debugger and causing the other debugger to execute the command when the number of activated debuggers is two, in addition to the arbitration unit. Debug device as described. The shared memory includes, in addition to the arbitration unit, a command storage unit for issuing a command from one debugger and causing another debugger to execute the command when the number of activated debuggers is two or more, and a debugger for executing the command. 3. The debugging device according to claim 2, further comprising a receiving debugger name storage unit for storing a name. 6. The debugging device according to claim 5, wherein the shared memory includes a command result storage unit that stores a result of executing the command, in addition to the arbitration unit, the command storage unit, and the reception debugger name storage unit. 3. The debugging device according to claim 2, wherein the shared memory includes, in addition to the arbitration unit, a priority arbitration unit for giving priority to execution of the command. 3. The debugging device according to claim 2, wherein the shared memory includes, in addition to the arbitration unit, a control unit information storage unit that stores information of registers common to a plurality of debuggers of the control unit. 9. A debug program for performing debugging in the debug device according to any one of claims 1 to 8, wherein a command is read to determine whether the command is a hard access command. Accessing the arbitration unit of the shared memory to determine whether or not the right can be acquired, and referring to the contents thereof; and changing the contents of the arbitration unit when the hard access right can be acquired, Causing a computer system to execute a process including a step of executing a command and a step of referring to the content of the arbitration unit and changing the content again in order to relinquish the access right when the command execution is completed. A debugging program characterized by the following. Setting the name of the debugger that has acquired the hard access right in the transmission debugger name storage unit of the shared memory when acquiring the hard access right with reference to the arbitration unit; and And causing the computer system to execute a process including a step of referring to the transmission debugger name storage unit and a step of clearing the transmission debugger name storage unit when the acquired hard access right is abandoned. The debug program according to claim 9, wherein When the number of activated debuggers is two, in order to execute a command from one debugger to the other debugger, a step of determining whether or not to set a command in a command storage unit of the shared memory; Storing a command in the command storage unit when it is determined to be performed; performing a loop process until the memory content of the command storage unit is cleared; and A step of confirming whether data is set or not at regular intervals; a step of executing the command with the other debugger when data is set in the command storage unit; and Clearing the contents of the command storage; and Claim 9, wherein the debugging program, characterized in that in which to execute the processing including the steps of passing the flop processing in a computer system. When the number of activated debuggers is two or more, in order to issue a command from a given debugger to a particular debugger, the name of the particular debugger executing the command is stored in the received debugger name storage of the shared memory. Determining at regular intervals whether or not the data set in the receiving debugger name storage is its own debugger name; and Executing the command in the command storage unit of the shared memory when it is determined that the received debugger name is stored, and clearing the reception debugger name storage unit when relinquishing the hard access right. 10. The debugging program according to claim 9, which is executed by a system. Executes a command from a given debugger to a specific debugger and stores the command result in the command result storage section of the shared memory after the step of executing the command in the command storage section of the shared memory to store the result And a step of referring to the command result storage unit from an arbitrary debugger, and a step of clearing the command storage unit when relinquishing the hard access right. The debug program according to claim 9, wherein: Referring to a priority arbitration unit of the shared memory to determine whether it is possible to execute the command with priority; and setting priority execution to the priority arbitration unit when the command can be executed with priority 10. The computer system according to claim 9, further comprising the step of: executing a process of executing the priority execution and a step of clearing the priority execution set in the priority arbitration unit when terminating the priority execution. Debug program. Determining whether there is data in the control unit information storage unit of the shared memory; referring to the information in the control unit information storage unit if there is information; and executing the hard access command if there is no information. Issuing the hard access command, determining whether or not information is stored in a register assignment common to each processor of the control unit after issuing the hard access command; and 10. The computer-readable storage medium according to claim 9, further comprising: causing a computer system to execute a process including a step of storing the register information. A debug program storage medium on which the debug program according to any one of claims 9 to 15 is recorded. An LSI is configured by a target system in which each of the processor cores is serially connected and only one set of terminals is output, and the LSI is configured by a plurality of processor cores;
In order to debug the plurality of processor cores on a computer system, a plurality of debuggers corresponding to the processor to be debugged and having an input / output function of a command for debugging are configured to perform the debugging,
An ID information setting unit for setting, for each of the plurality of debuggers, the number of bits of an instruction register and a data register of another processor core connected before and after the serially connected plurality of processor cores to be debugged; A debug device comprising: an ID information storage unit that stores ID information set by a setting unit. The system is configured to exchange information between a computer system and a target system via a control unit, wherein the control unit transmits an ID transmitted from the ID information storage unit to the control unit by an ID information transmission unit of a plurality of debuggers. An ID information receiving unit for receiving information; an ID information storage unit for storing the received ID information; and an instruction for sending to the plurality of processors based on the ID information stored in the ID information storage unit. 18. The debugging device according to claim 17, further comprising an automatic code generation unit for automatically generating the code. An LSI is configured by a target system in which each of the processor cores is serially connected and only one set of terminals is output, and the LSI is configured by a plurality of processor cores;
When debugging the plurality of processor cores on a computer system, it is configured to exchange information between the computer system and a target system via a control unit,
A plurality of debuggers having an input / output function of a command for debugging, corresponding to the processor core to be debugged, are configured to perform the debugging,
The debugging device, wherein the control unit is configured to cause the processor core to execute a command issued by a plurality of debuggers, and further includes a monitor instruction storage unit that stores a monitor instruction transmitted from the debugger. 20. The debugging apparatus according to claim 1, wherein the plurality of debuggers are configured to operate on only one computer system. .

Images