JPH1124959A - Trace information outputting method of microprocessor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To perform an output in a frequency that does not depend on the operation frequency of a processor core, to output with the number of pins as small as possible, to let the number of pins have the degree of freedom and also to perform real time trace in many cases by outputting trace information as a packet comprising a variable length bit string. SOLUTION: An outputting method of trace information outputs trace information as a packet consisting of a variable length bit string in a microprocessor that outputs trace information. It is effective at the time of debugging a monitor program itself which preferably prepares such a special trace mode as to output a trace packet even in a debug mode in order to facilitate the development of a debug tool. Because it can be finished to send one piece of trace information in a shorter time than in the conventional practice on average, the probability that overrun of trace information occurs while real time trace is performed is reduced.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method of outputting trace information for debugging a system to which a microcomputer is applied, and more particularly, to a method of outputting a trace information representing an operation state in a microprocessor. Related to the output method of trace information.

[0002]

2. Description of the Related Art In debugging an application system using a microprocessor, it is important to obtain trace information, that is, a series of information such as addresses and data during execution of a program and various other states of the processor. Especially,
It is important not to affect the operation of the microprocessor when acquiring the trace information, specifically, not to reduce the operation speed (real-time trace) by inserting an extra wait into the operation of the microprocessor. Therefore, as the operation speed of the microprocessor increases, it becomes difficult to adopt a method of connecting a trace information acquisition circuit or the like to the outside during debugging, so that the trace information is output into the microprocessor. It has been proposed to incorporate functionality. However, the configuration proposed in the past was not always satisfactory in terms of the following problems.

[0003]

Although the frequency of the core clock of the processor has been increasing, it has become difficult to increase the frequency that can be input and output to and from the outside. For this reason, as a technique for improving the performance of the processor, the inside of the processor is often operated at a high frequency, and the frequency of the input / output pins with the outside is often operated at a lower operating frequency. Therefore, if a conventional method that needs to output at the same frequency as the core clock frequency of the processor is applied to such a processor, real-time or near real-time tracing can be performed unless a large amount of weight is inserted inside the processor. Could not.

Further, even if trace information can be output at the same frequency as the frequency of the core clock of the processor,
When a processor that has been modified such as a function extension that issues two or more instructions at the same time is added to a processor family, a new status must be added or changed. As described above, the debugging tool (hardware and software) must be newly designed in each of the above cases and each time a new processor family is supported, and the tool development efficiency is low.

Furthermore, in the conventional method, the total number of pins assigned to the output of trace information is as large as four or eight for status signal pins and data signal pins, and the number of pins is fixed. There were restrictions on the number and package size.

Since a program has a certain degree of locality, the upper bits of a branch destination address at the time of an exception or a branch often do not change when compared with recently obtained address information such as a previous branch destination address. However, in the conventional method, when outputting the branch destination address,
Only the entire address or a preset number of bits is output from the lower bits. In the case of output of the entire branch destination address, even redundant (unnecessary) data is output if the upper bits do not change. Further, when a predetermined number of bits is output from the lower bits, in the case of a branch in which the upper bits change, the upper bits cannot be determined.

Accordingly, the present invention, in order to solve the above-mentioned drawbacks, enables an output at a frequency independent of the operating frequency of a processor core by an output method independent of a processor architecture, and uses a pin number as small as possible. It is an object of the present invention to provide a method of outputting trace information of a microprocessor which has a degree of freedom in the number of output pins and can perform real-time tracing in many cases.

[0008]

According to the trace information output method of the present invention, a microprocessor capable of outputting trace information outputs the trace information as a packet composed of a variable-length bit string.
The above objective has been achieved.

[0009]

【Example】

<1.1. Debug Port><1.1.1 Required Debug Port> Regarding the required debug port, JTAG (an interface standard for testing boards and ICs proposed by the Joint Test Action Group; this is well known to those skilled in the art. It is not described here any more because it is a matter of IEEE Std1149.1
-1990 (IEEE Standard Test Access Port and Boundary
-See Scan Architecture)) Use implementation as default. TCLK input TMS input TDI input TDO output

<1.1.2 Optional Debug Port> The following signals are optional. TRST L input RMODE / BKTGIO_L input / output

<1.1.3 RMODE / BKTGIO_L> This pin has two functions: BKTGIO_L and RMODE. JTAG-
In the Test-Logic-Reset controller state, this pin is R
Work as MODE. This pin acts as BKTGIO_L in other states.

<1.1.3.1 RMODE> RMODE represents a reset mode. The debug module is initialized when the TAP controller is in the Test-Logic-Reset controller state. This pin selects the initial value of the debug reset setting. Debug reset is a reset input to the processor. This effect is the same as a reset input from the target system.

[0013] Depending on the level of the RMODE input, debugging
Reset settings can be made using the JTAG Test-Logic-Reset controller s
In tate, it is initialized as follows. Low: Enable debug reset settings. The debug module is initialized so that a debug reset is required. High: Disables debug reset settings.
The debug module is initialized so that a debug reset is not required.

This signal is output from the RO on the target system.
If the boot program in M is incomplete during the early development phase, it is necessary to prevent the target system from operating unexpectedly at power up. When connected, the tool drives this signal low upon power up of the target system. The processor can remain reset even after the reset input from the target system has been released.

The chip needs a pull-up resistor so that the level of the RMODE pin is high when the tool is not connected. If RMODE is high, there should be no effect of the debug module on processor activity.

<1.1.3.2 BKTGIO_L> The RMODE / BKTGIO_L signal functions as BKTGIO_L in a controller state other than the Test-Logic-Reset controller state. Bidirectional signal BKTGIO
_L is mainly used to interrupt the processor execution by a trigger input from the external device or to trigger the external device at a specified event. This signal is disabled by a debug module reset.

When configuring this signal for output, it is driven low under the following conditions: -The processor is in debug mode. − The trace trigger condition is satisfied.

These two conditions can be individually configured to drive or not drive the signal.

Break Output As shown in FIG. 1A, this signal is driven low while the processor is in debug mode.

Trigger Output As shown in FIG. 1B, this signal is driven low (pulsed) when a hardware breakpoint condition is met.

When configuring this signal for input, the debug module operates as follows when the level of the signal changes from high to low.

Halt the processor and enter debug mode. -Generate an N-Trace trigger packet.

These two activities can be configured individually, as they occur or not.

Break input Breaks the user program execution at the falling edge of the BKTGIO_L input. If this edge is entered while in debug mode, it will be suspended until the processor returns to normal mode. (See Fig. 2 (A))

Trigger input This function is not required if the optional N-trace is not implemented. This function generates an N-trace MATCH packet on the falling edge of the BKTGIO_L input. Even if this edge is input while in the debug mode, a MATCH packet is output immediately. (See Fig. 2 (B))

<1.1.4 Initialization of debug module>
As described in the above <RMODE>, the debug module is initialized in the Test-Logic-Reset controller state. The debug module is used for debugging after initialization.
Has no effect on processor activity except for the reset function.

<1.2. Debug Function Controlled via JTAG><1.2.1 JTAG Instruction> Almost all debug functions of the debug module are controlled via JTAG. debug·
You must implement JTAG private instructions to control the module. To obtain processor identification information
JTAG option instruction IDCODE must also be implemented.

A) JTAG IDCODE must be implemented. b) Some JTAG private instructions must be implemented for debug tools.

The following may be performed. c) Instruction register lengths and bit assignments for IDCODE and JTAG private instructions may be different for each processor family.

<1.2.2 device identification register
> This mandatory device identification register is used to configure the tool with minimal user help. After power up, the tool reads this register to determine if the processor is supported. If supported, the tool configures itself according to the value of this register.

A) device identification in the processor
The register value must have some common characteristics between the same processor family.

The following may be adopted. b) There may be another register accessible via JTAG to convey details of the implementation options.

<1.2.3 Initialization of Debug Module>
This required feature is available in the Test-Logic-Reset controller state
Used to initialize a debug module without entering In this reset, the debug / reset setting is not initialized, and the previous setting is retained.

A) All debugging functions are
Must be initialized and disabled except in the case of a reset. b) Debug reset settings must not be changed.

<1.2.4 Configuration of BKTGIO_L / RMODE Signal><1.2.4.1 BKTGIO_L / RMODE Implementation Flag> This essential function is used to know whether or not the BKTGIO_L / RMODE signal is implemented.

A) The presence or absence of the BKTGIO_L / RMODE signal must be known in some way. We recommend the following: b) JTA for debugging whether this signal is present
Test data regis selected by G private instruction
It is recommended to know by the bit in ter.

The following may be performed. c) device iden instead of bits in test data register
The value of the tification register may be used to indicate this presence. The tool must have a list of IDs of all supported processors and must know which processor has the BKTGIO_L / RMODE pin.

<1.2.4.2 BKTGIO_L Signal Setting> This function, which is required when there is a BKTGIO_L signal, is used to configure the BKTGIO_L signal.

A) If the debug module is enabled, the enable or disable, direction (input or output), and function (break and / or trigger) must be configurable in any state. b) The BKTGIO_L signal must be initialized by a debug module reset (disable, input).

<1.2.5 Configuration of N-trace><1.2.5.1 N-trace implementation flag>
Used to know if ce is implemented.

A) It must be known in some way whether the N-trace function exists.

The following is recommended. b) Determine if this signal is present by J
Test data reg selected by TAG private instruction
It is recommended to know by the bit in the ister.

The following may be performed. c) device iden instead of bits in test data register
The value of the tification register may be used to indicate this presence. The tool must have a list of IDs of all supported processors and must know which processor has the N-trace port.

<1.2.5.2 N-trace Enable / Disable> This function, which is required if N-trace is present, is used to enable or disable the N-trace function.

A) If the debug module is enabled, enable or disable must be configurable in any state. b) N-trace must be initialized (disabled) by a debug module reset.

<1.2.6 Execution Control><1.2.6.1 Debug Mode and Normal Mode>
Debug mode and normal mode are defined as follows.

Normal mode: In this mode, the processor executes a user program or is reset (including a debug reset). Debug mode: In this mode, the processor stops execution of the user program.

<1.2.6.2 Debug Reset> This essential function is used to input a processor reset signal from a debug tool (it operates in the same manner as a reset from the target system).

A) The debug reset must be able to forcibly execute and release the processor reset regardless of the state of the processor. b) This reset has the same effect as a reset from the target system. c) In the JTAG Test-Logic-Reset controller state, this setting is initialized according to the RMODE signal. RMODE requests a debug reset if low. Otherwise, no debug reset is requested and the processor will not be reset if the target system is not driving the reset input. JTAG Test-Logi
After the c-Reset controller state ends, the tool
Change the settings via. d) This setting must not be changed by debug module initialization.

<1.2.6.3 Debug Break> This essential function is used to request a break that puts the processor in the debug mode asynchronously with the execution of the user program.

A) When a break is requested, the processor must break the execution of the user program as soon as possible. b) After a break, the processor must remain in debug mode until commanded. c) Whether the request succeeded or failed must be known. d) If the break fails, the request must be cleared by debug module initialization.

<1.2.6.4 Break from Debug Reset> This essential function is used to enter the debug mode after releasing the debug reset without executing the user program.

A) When the tool releases debug reset, the processor must enter debug mode. b) To avoid unexpected effects on the target system or the processor, the processor must not access the target system memory (for instruction fetch, etc.) and transition from debug reset to debug mode Sometimes user program instructions must not be executed. c) Whether the request succeeded or failed must be known. d) If the break fails, the request must be cleared by debug module initialization.

<1.2.6.5 Resume Execution of User Program> This essential function is used to terminate the debug mode and resume execution of the user program.

A) The processor must exit debug mode on demand. b) After exiting debug mode, the processor
Execution of the user program must be resumed from the state immediately before the break (unless the tool is changing states in response to a user request, such as modifying the contents of a register). c) Whether the request succeeded or failed must be known. d) If the break fails, the request must be cleared by debug module initialization.

<1.2.6.6 Execution of User Program from User Reset Input> This essential function is used to start a user program from a reset handler synchronously with a target reset input.

A) The processor must wait for the processor reset input without executing the user program. b) After the processor reset input, the processor must start the user program as a normal operation of the processor. c) Whether the request succeeded or failed must be known. d) If the break fails, the request must be cleared by debug module initialization. e) It must be known whether a target reset input has been received. f) The mode must be cleared by debug module initialization.

<1.2.6.7 Executing User Program from Power-On> This optional function is used to start the user program from the reset handler in synchronization with the target power-on reset. Since power is turned on, almost all functions of the tool will not work until a debug reset or debug break occurs. a) The processor must wait for a power-on reset without executing the user program. b) After a power-on reset input, the processor must start the user program as a normal operation of the processor. c) The processor must respond to a debug reset or debug break. d) N-trace and hardware breakpoints
Must be configurable in normal mode before the first debug reset or debug break. e) After a debug reset or debug break, all features of the tool must be available.

<1.2.6.8 Software Breakpoint> This essential function is used to break the execution of the user program immediately before the instruction at the specified address is executed. When a processor executes a special instruction called a software breakpoint instruction, a break occurs and the processor enters a debug mode. This is achieved by replacing the instruction at the specified address with a software breakpoint instruction, so there is no limit on the number of breakpoints that can be set at one time. However, it cannot be set if the memory is not RAM.

A) Instruction replacement must be performed at least in debug mode. b) When the processor executes a software breakpoint instruction, a break must be set before executing the next instruction. c) After a break, the processor must remain in debug mode until commanded to exit. d) The address at which the software breakpoint caused the break must be known. e) The processor must be able to correctly resume program execution after replacing the software breakpoint with the first instruction. f) The length of the software breakpoint instruction must be the same as the length of the shortest instruction. g) You must know whether the break was successful or failed. h) If the break fails, the request must be cleared by debug module initialization.

The following is recommended. i) It is recommended that the debug module has the ability to replace instructions in normal mode and debug reset and debug mode. j) Software breakpoint instructions must not be published, nor should tables be reserved for debugging. k) When a break occurs, the program counter must point to the address where the software breakpoint instruction is located.

<1.2.6.9 Single-step break>
This essential function is used to execute the user program step by step (execute only one instruction at a time). When the processor exits the debug mode and shifts to the user program in the single-step mode, a break occurs after executing one instruction of the user program, and the debug mode is entered.

A) Single-step mode setting is changed in debug mode (enable / disable)
Must be possible. b) The processor must enter debug mode after executing one instruction of the user program. c) After a break, the processor must remain in debug mode until commanded to exit. d) The instruction executed during the step operation (its address and instruction count) must be known. e) The processor must be able to resume program execution properly. g) You must know whether the break was successful or failed. h) If the break fails, the pending request must be cleared by debug module initialization.

The following may be performed. i) Multiple instructions may be executed during a step operation to properly resume program execution. This can be done, for example, if the processor has a delayed branch instruction.

<1.2.6.10 Hardware Breakpoint> This function is used to break the execution of the user program by detecting a specified processor internal condition. This specification defines the following types of hardware breakpoints:

Instruction address breakpoint: The processor breaks execution of the user program before executing the instruction at the specified address. Unlike software breakpoints, these breakpoints can be set on instructions outside of RAM.
Data access breakpoint: the processor
Breaks the execution of the user program when accessing the specified address of the memory with the specified data.

Further, a hardware breakpoint can be set to an external device and an N-
Can be used to trigger / trace trace. In addition, N-trace can output addresses and data used for memory access specified by data access breakpoints.

A) The hardware breakpoint settings must be changeable regardless of whether the processor is in debug mode or normal mode. b) In normal mode, changing the settings must not affect the execution of the user program (ie,
Do not stop temporarily.) c) Each hardware breakpoint must be individually configurable. The configuration here includes whether to break, whether to output a trigger, whether to output a MATCH packet, and the like. d) After a break, the processor must remain in debug mode (if break is enabled). e) You must know which hardware breakpoint caused the break (if breaks are enabled). f) The processor must be able to correctly resume program execution (if breaks are enabled). g) You must know if the break succeeded or failed (if breaks are enabled). h) If the break fails (if breaks are enabled), the debug module initialization must clear any outstanding requests. i) Implementation options (number of channels, etc.) must be known.

<1.2.6.11 Instruction Address Breakpoint (Hardware Breakpoint)> This required function is used to stop execution of the user program before the instruction at the specified address is executed. You. Unlike software breakpoints, these breakpoints can be set on instructions outside of RAM. This is also used to detect that the instruction at the specified address has been executed (but not to break the execution of the user program).

A) This function must follow the rules described in the "Hardware Breakpoints" section. b) The processor must cause a break before executing the instruction on which the breakpoint is set (if break is enabled). c) Addresses must be specified with the smallest instruction resolution. d) The debug module must have at least one instruction address to support minimal execution control when the user program code is in ROM.
Must have breakpoints. e) Breakpoints must be set at any address where the user program code resides. f) The address at which the address breakpoint caused the break (if breaks are enabled) must be known.

The following is recommended. g) The program counter should point to the address where the breakpoint was hit.

The following is optional. e) The address comparison can have a mask function or a range function.

Address mask or range

A program is used to detect when a program exits or enters a specified address block. Thus, the mask can be made valid only for the lower address bits. The following two options are available. (1) A breakpoint is hit when the address is within the range. (2) Breakpoint hit when address is out of range.

<1.2.6.12 Data Access Breakpoint (Hardware Breakpoint)> This optional function breaks the execution of the user program when data is accessed (variable or input / output) to the specified address. Used to multiply. This function is also used when detecting data access to a specified address (but not breaking the execution of the user program). N-trace can output data used for data access specified by a data access breakpoint. This feature can be used in C-level debugging to detect access to specified variables (global or static) that reside in fixed memory locations or I / O.

A) This function must follow the rules described in the "Hardware Breakpoints" section. b) If the processor has separate I / O space,
There must be a switch to select memory space or input / output space for comparison. c) The processor must break (if breaks are enabled) by accessing the memory or I / O where the breakpoint is set. d) Addresses must be specified at least for the smallest data resolution. e) The access type must be selectable between read and / or write. f) Breakpoints must be set at any address that the user program accesses for data manipulation.

The following is optional. g) The address comparison can have a mask function or a range function. h) Data comparison can be performed. i) The data comparison can have a mask function or a range function. j) In addition to memory and I / O, other resource types may be specified.

An address mask or range program is used to detect access to memory or I / O locations inside or outside the specified address block. For example, this feature breaks execution of the user program when an illegal block of memory is accessed, or uses N-trace to trace data access to specified I / O blocks. . Thus, the mask can be made valid only for the lower consecutive address bits. The following two options are available. (1) A breakpoint is hit when the address is within the range. (2) Breakpoint hit when address is out of range.

Data comparison Used to detect access to specified data. For example, this function stops execution of the user program or triggers N-trace when the contents of the specified variable reaches the specified value.

Data Mask or Range Used to detect when data access to a memory or input / output is within a set range or matches a particular pattern. For example, this feature
Trigger N-trace when the specified bit of the specified variable reaches the specified value. For this reason, the mask must be able to be individually specified for each bit. 2 below
Two options are available. (1) A breakpoint is hit when the address is within the range.
(2) Breakpoint hit when address is out of range.

Resource Type Used to detect access to processor resources other than memory or input / output. Possible processor resources are on-chip cache, on-chip TLB, and registers (including coprocessor registers).

<1.2.6.13 Debug mode flag>
This required function is used to determine if the processor is in debug mode or normal mode. By using this, the tool
Detects that a break has taken place, or
It is possible to know whether a debugging function that is not allowed in the mode can be executed.

A) This flag must indicate whether the processor is in debug mode or normal mode. b) This flag must be accessible whether the processor is in debug mode or normal mode.

<1.2.6.14 Break Cause Flag> This essential function is used to check the cause of a break.
The tool performs necessary post-processing after the break depending on the cause of the break.

A) This flag must be updated each time a break is executed. b) This flag must be accessible in debug mode. c) If a break was requested by more than one break cause, all causes must be indicated.

<1.2.7 Processor Status><1.2.7.1 Processor Status Flag> This required function is used to check the current processor status. By using this, the tool
It is possible to avoid sending a command that fails with certain processor status, or to know the cause of the failure if the request for a debug function is denied. It is also used to communicate the current processor status to the user.

A) This flag must be updated each time the processor status changes. b) This flag must be accessible whether the processor is in debug mode or normal mode. c) The debug function shall indicate all processor statuses that fail.

The following is recommended. d) Only one processor status can be indicated with the following priority.

<1.2.7.2 Bus Hung-Up Address> This optional function is used to check the address when the bus cycle hangs up because there is no ready response.

<1.2.8 Memory and Input / Output Access> The memory or input / output access function from the tool side has three requirements. • Normal access to memory or I / O in debug mode (required) • Quick access to memory or I / O (optional) • High-speed program download to memory (optional)

<1.2.8.1 Normal Access to Memory or I / O in Debug Mode> This essential function is used to access memory or I / O in debug mode. Tools include variables (including local variables)
And input and output can be displayed and modified. this is,
It can also be used when setting or removing software breakpoints.

A) To use variable read / write and software breakpoint setting / removal, memory or I / O must be accessible. b) Must be accessible to any memory or I / O at addresses accessible by the processor. c) It must know whether the access has been completed and whether it has succeeded or failed. d) If the access is to raise an exception (eg, a bus error), the exception must not be raised,
You must know that the access is aborted and why. e) If access is not completed, the impact must be minimized. For example, if the bus cycle hangs due to no response (infinite wait), the tool must be able to abort the bus cycle. f) If access fails, it must be initialized by debug module initialization. g) Even if the processor has a privileged mode and a user mode, it must be able to access memory and I / O regardless of the mode.

The following may be performed. h) Does not need to be accessible during normal mode or processor reset (including debug reset).

<1.2.8.2 Quick Access to Memory or I / O> This optional function is used for quick access to memory or I / O. Its primary purpose is to allow a user to monitor global or static variables, or inputs and outputs, without interfering with the execution of the user program.

A) Access to memory or I / O must not halt the execution of the user program, or only a very short time when halt execution of the user program. b) Memory or I / O accesses must be made regardless of whether the processor is in debug mode or normal mode. c) It must know whether the access has been completed and whether it has succeeded or failed. d) The user program must be able to access memory or I / O at any address accessed for data manipulation. e) If the access is to raise an exception (eg, a bus error), the exception must not be raised,
You must know that the access is aborted and why. f) If access is not completed, the impact must be minimized. For example, if the bus cycle hangs up (infinite wait) due to no response, the bus cycle must be able to be aborted. g) If the access fails, it must be initialized by debug module initialization. h) Even if the processor has a privileged mode and a user mode, it must be able to access memory and I / O regardless of the mode.

The following may be performed. i) It is not necessary to be able to perform quick access at processor reset (including debug reset). j) It may not be possible to support only read access.

The following is recommended. k) It is recommended that the access method be the same as normal access.

<1.2.8.3 High-speed Program Download to Memory> This optional function is used to download a user program to the memory.

A) Writing to a memory block must be fast. b) Write to any memory at the address where the user program resides. c) It must know whether the access has been completed and whether it has succeeded or failed. d) If the access is to raise an exception (eg, a bus error), the exception must not be raised,
You must know that the access is aborted and why. e) If access is not completed, the impact must be minimized. For example, if a bus cycle hangs (infinite wait) due to no response, the tool must be able to abort the bus cycle. f) If the access fails, it must be initialized by debug module initialization. g) Even if the processor has a privileged mode and a user mode, it must be able to access the memory regardless of the mode.

The following may be performed. h) It is not necessary to be able to perform fast downloads in normal mode or on processor reset (including debug reset).

The following is recommended. i) It is recommended that the access method be the same as normal access.

<1.2.8.4 Register Access> This essential function is used to access a register in the debug mode. Tools can display and modify registers.

A) All processor registers used by the user program must be accessible in debug mode. b) You must know whether the access was successful or failed. c) If the access fails, the request must be cleared by debug module initialization. d) Changes to registers that control some functions that are also active in debug mode must take effect immediately (eg, on-chip peripheral registers). e) Even if the processor has a privileged mode and a user mode, it must be able to access the registers regardless of the mode.

The following may be performed. f) Read-only registers need not be writable.
The write-only register may not be readable.

<1.3. Standard mounting method><1.3.1 JTAG debug instruction> IDCODE of JTAG optional instruction
Must be implemented. IDCODE device identification
register

The following instructions are also defined as JTAG private instructions for debugging. DM_SYSTEM Select debug module system register. DM_CONTROL Select debug module control register. DM_RADDR Selects debug module resource access address register. DM_RDATA Selects debug module resource access data register.

Test dat selected by JTAG private instruction
The details of a register will be described below.

<1.3.2 IDCODE Register> FIG. 3 shows the configuration of this register.

A function debug_module_exist () indicating whether the device has a debug module and a function pr indicating a processor family ID code for each manufacturer
There is ocessor_family_id (). The debug tool can determine these by using functions provided by the manufacturer. For example, if the tool supports a processor family with a part number of 0x123? (Where? Indicates that the digit in the digit is anything)
If the version of the MSB indicates whether the device has a debug module, these functions are written in C-style as follows: processor_family_id (part_no, version) = (part_no &
0xfff0); debug_module_exist (part_no, version) = pr
ocessor_family_id (part_no) == 0x1230 && (version &
0x8);

<1.3.3 Debug Module System Register> DINIT Initializes the debug module (R / W). 1: Reset (initialize) the debug module. 0: Release reset of debug module. Test-Logic-Reset controller state defaults to 1.

BKTGIO BKTGIO_L / RMODE signal mounting (R) 1: mounted. 0: Not implemented.

BKTGIODIR Direction of BKTGIO_L (R / W) 1: Input 0: Output Default is 1 when the debug module is initialized.

BKTGIOBEN BKTGIO_L Break Enable (R / W) 1: Drives a trigger at the time of processor break, or enables triggering of the processor at the time of BKTGIO_L input. 0: Disabled 0 by default when the debug module is initialized
become.

BKTGIOTEN BKTGIO_L trigger enable (R / W) 1: Trigger drive at N-Trace trigger, or BK
Enable to trigger N-Trace on TGIO_L input. 0: Disabled 0 by default when the debug module is initialized
become.

NTRACE N-trace implementation (R) 1: implemented. 0: Not implemented.

NTRACEEN N-trace enable (R / W) 1: Enable 0: Disable 0 when the debug module is initialized
become.

<1.3.4 Debug Control Register> RESET Debug Reset (R / W) 1: Requests a debug reset. 0: Release debug reset. Test-Logic-Reset controller s if RMODE exists
Tate follows the RMODE level as default. RMODE
Test-Logic-Reset controller stat if does not exist
e defaults to 0.

BREAK Break request (R / W) Write 1: Command requesting break Write 0: No operation Read 1: Command not completed (Break is still requested). Read 0: Break completed. This bit is cleared when the break has completed. As default at debug module initialization
Becomes 0.

EXIT Exit from debug mode (R / W) Write 1: Command to leave debug mode Write 0: No operation Read 1: Command not completed (still in debug mode). Read 0: Command completed. This bit is cleared when the command completes, even if a break occurs immediately after exiting to normal mode. -To avoid escaping again. − To detect a new break when the tool cannot detect normal mode due to the debug mode flag. Defaults to 0 when the debug module is initialized.

Mask the user reset in the MRST debug mode (R / W). 1: Ignore (mask) the target reset input in debug mode. 0: Accept target reset input in debug mode. Defaults to 0 when the debug module is initialized.

MNMI User NMI mask (R / W) 1: NMI generation is suppressed. 0: Does not suppress the occurrence of NMI. Assume NMI is the edge detection input. An unprocessed NMI occurs when a bit is cleared. Defaults to 0 when the debug module is initialized.

MINT User interrupt mask (R / W) 1: User interrupt input is ignored. 0: Accept user interrupt input. Defaults to 0 when the debug module is initialized.

STEP Single step break (R /
W) 1: Single step break (single step break)
Mode). 0: Disable single-step break. Defaults to 0 when the debug module is initialized.

DBM Indicates the debug mode or normal mode (R). 1: Debug mode 0: Normal mode

BRKCAUSE Break cause (R). It consists of a number of bits. One bit is assigned for each break cause, and the corresponding bit is set when the break occurs. If a break is caused by more than one break cause, more than one bit is set. Bit assignment is defined as follows. Bit 0: external break bit 1: single step bit 2: software breakpoint bit 3: BREAK bit 4: break from RESET bit 5: instruction address breakpoint bit 6: data access breakpoint

CPUSTAT Processor status (R). The processor status is coded as follows:

ACTFLG_CLK Processor clock active flag (R / W). The ACTFLG_CLK bit indicates clock activity. The debug tool can detect that the clock is not being supplied from the target system board to the processor. Write 1: No operation Write 0: Clear the active status flag. Read 1: Clock is active. Read 0: Clock is inactive. This flag is set when there is some activity on the clock. This flag is cleared when the debug tool writes a 0 to this bit.

ACTFLG_BUS Bus cycle active state flag (R / W). The ACTFLG / BUS bit indicates bus activity. Write 1: No operation Write 0: Clear the active status flag. Read 1: Bus cycle is active. Read 0: No bus cycle has been performed since flag was cleared. This flag is set when there is some activity on the bus. This flag is cleared only when debugging
This is when the tool writes 1 to this bit.

<1.3.5 Resource Access> The following resources can be similarly accessed. − User memory − User registers − Debug registers (such as hardware breakpoints)

The following registers are used to access user resources. DM_RADDR Selects debug module resource access address register. DM_RDATA Selects debug module resource access data register.

DM_RADDR consists of the following bits. ADDR Address of resource to be accessed RW Read / write ADDRINC Address increment TYPE Type of resource to be accessed (memory, input / output, register, etc.) ASID Address space ID (process ID) MMUE MMU enable / disable CACHEE Cache enable / disable Able OPSIZE Operation size

DM_RDATA consists of the following bits. DATA Data to be read / written START / BUSY Starts processor resource access. Cleared when access is made. ABORT / ERR Cancel current access. Set when an error occurs during access.

The resource access can be performed using the following sequence. Read access 1) Set the following parameters in the register. ADDR Set the memory address (user memory) or register number (user register or debug register) to be read. Set to 1 for RW read access. TYPE Set the type of resource (user memory, user register, or debug register). ASID (when accessing user memory) Set the process ID if the processor has an MMU. MMUE (when accessing user memory) If the processor has an MMU, select whether access should be through the MMU. CACHEE (when accessing user memory) If the processor has a cache, select whether the access should be through the cache. OPSIZE Set the operation size from 8 bits, 16 bits, 32 bits, etc. ADDRINC Set address increment when accessing a block of memory or registers. 2) Set START / BUSY to 1 to start access. 3) Wait until START / BUSY is cleared to 0. ABORT / ERR
Indicates whether the access has been completed normally. ABORT / ERR -------- 0 Access completed normally. DATA contains the data retrieved by the access. 1 Access terminated with an error. If START / BUSY is not cleared for a long time, access may hang. In this case, ABORT / ERR should be set to 1 to stop the access. 4) Set START / BUSY to 1 and continue accessing the next location.

Write access 1) Set the following parameters in the register. ADDR Set the memory address (user memory) or register number (user register or debug register) to be written. RW Cleared to 0 for write access. TYPE Set the type of resource (user memory, user register, or debug register). ASID (when accessing user memory) Set the process ID if the processor has an MMU. MMUE (when accessing user memory) If the processor has an MMU, select whether access should be through the MMU. CACHEE (when accessing user memory) If the processor has a cache, select whether the access should be via the cache. OPSIZE Set the operation size from 8 bits, 16 bits, 32 bits, etc. ADDRINC Set address increment when accessing a block of memory or registers. DATA Set the data to be written. 2) Set START / BUSY to 1 to start access. 3) Wait until START / BUSY is cleared to 0. ABORT / ERR
Indicates whether the access has been completed normally. ABORT / ERR --------- 0 Access completed normally. 1 Access terminated with an error. If START / BUSY is not cleared for a long time, access may hang. In this case, ABORT / ERR should be set to 1 to stop the access. 4) Set START / BUSY to 1 and continue accessing the next location.

<1.3.5.1 The processor has a cache and
If MMU is equipped> Processor is cache and M
If equipped with MU, user memory access should be through cache and MMU. You need to be able to choose between enabling or disabling each of the cache and MMU.
You also need to be able to invalidate certain entries in the cache. Usually, a user specifies a logical address.
When using the MMU, the user should specify both the logical address and the address space ID (process ID).

Normal Access To maintain consistency between the data cache and main memory, the cache must be enabled. If the tool changes the contents of memory in the instruction cache, it should invalidate the corresponding entry in the instruction cache. Setting a software breakpoint is a good example. Conversely, the MMU must be disabled to avoid a TLB miss. The user interface or debugger must be able to translate logical addresses to physical addresses using the symbol information stored in the object module. Certain debuggers can leave the MMU on to access memory through the current settings of the MMU.

Quick Access To maintain consistency between the data cache and main memory, the cache must be enabled. Conversely, the MMU must be disabled to avoid a TLB miss. The user interface or debugger must be able to translate logical addresses to physical addresses using the symbol information stored in the object module.

The fast download cache must be disabled and invalidated. The program must be loaded into main memory. The user interface or debugger must be able to translate logical addresses to physical addresses using the symbol information stored in the object module.

3.6 Instruction Address Breakpoint A hardware breakpoint is a “resource access”
Should be accessed through the scheme. At least one instruction address breakpoint is required. Instruction address breakpoints are mainly RO
Used as a breakpoint when M-based (thus, software breakpoints cannot be used). Instruction address breakpoints are also used when triggering a trace. When the conditions are met, the actions are "break", "trigger",
It must be selectable from "both" and "none".

<1.3.6.1 Instruction Address Breakpoint Register> The following registers are used to set an instruction address breakpoint.

[0140]

IBAn Instruction address break address register n Stores the address of an instruction address breakpoint. The condition is satisfied when the instruction stored at the specified address is executed. The instruction address resolution is
Must be the minimum length of an instruction.

IBCn instruction address break control register n BE break enable. Abort the user program when the condition is met. The instruction stored at the specified address must not be executed. Outputs a trigger for BKTGIO_L when the TE trigger enable condition is satisfied. A trigger is output even if a break occurs. N-tr
If ace is implemented, additional bits are required to specify the conditions for outputting N-trace packets.

Address Mask The following register is added for the address mask.

IBAMn Instruction address break address mask register Bit mask for IBAn. If a bit in this register is 1, the corresponding bit in IBAn is not compared. Not all bits need to be masked. In such a case,
The lower bits should be masked. In addition, one mask
It is acceptable to mask multiple bits with bits. Examples of this are mask bits every four bits,
There are a mask bit for the lower 16 bits and a mask bit for the lower 24 bits. It is also acceptable to specify how many bits (of the LSB) are masked in binary.

The following bits are added to IBCn. IBCn Instruction address break control register INV 0-Breakpoint hit when condition is met. 1-Breakpoint is hit when condition is not met.

Address Range When comparing addresses by "range", the following registers are used instead of IBA. IBALn instruction address break address low register IBAHn instruction address break address high register Address matches if address is in range of IBALn or IBAHn (both boundaries, including IBALn and IBAHn) .

The following bits are added to IBCn. IBCn Instruction address break control register INV 0-Breakpoint hit when condition is met. 1-Breakpoint is hit when condition is not met.

<1.3.6.2 Action of Breakpoint> BE
If the (Break Enable) bit is set, the break must occur before the instruction at the specified address is executed. The program counter should point to that instruction. In that case, the tool resets the instruction breakpoint and causes the user program to execute from the current program counter. The user program must be able to resume work. Special attention should be paid to breakpoints in branch delay slots or overrun break status (where a break occurs after an instruction is executed). A break must not occur if the instruction has not been executed. Examples include branches, exceptions, and breaks on previous instructions.

<1.3.6.3 Processor is Cache and MMU
If> is provided, the set address must be logical. Address space ID as well as logical address
There should be a way to specify too. The address space ID is
It is specified in the following bits of IBCn. ASID Address space ID ASIDM 1-ASID is masked.

1.3.7 Data Access Breakpoints Hardware breakpoints should be accessible through a "resource access" scheme. Hardware breakpoints are used to halt a user program when the user program accesses a specified address containing specified data. The access type, such as read or write, should also be specified. Hardware breakpoints are also used when triggering a trace. When the condition is met, the action is "break", "trigger", "both",
Must be selectable from "None".

<1.3.7.1 Data Access Breakpoint Register> The following registers are used to set a data access breakpoint. DBAn data access break address register n The condition is satisfied when the specified address is accessed. DBDn Data Access Break Data Register n A condition is met when the data read or written equals the specified data. DBCn data access break control register n MEM memory condition is satisfied only in memory access cycle. IO I / O access conditions are satisfied only in I / O access cycles. DBE Data Comparator Byte Enable The bit length is equal to the number of bytes in the processor data word. Each bit corresponds to a byte enable of the processor. When these bits are set, the data condition will not be met unless the processor has enabled the corresponding data byte. Break enable at BEA address match Breaks the user program when the address condition is satisfied. Break enable at BED data match Breaks the user program when the data condition is satisfied. If both the BEA and BED bits are set, a break is required when both conditions are met. If both are cleared, a break is requested regardless of the result of the comparator. BERD read access break condition is satisfied only in read cycle. BEWR Write Access Break condition is satisfied only in the write cycle. BE
If both the RD and BEWR bits are set, a break is requested regardless of the access type. If both are cleared, no break is required. Trigger enable at TEA address match Outputs trigger for BKTGIO_L when address condition is satisfied. A trigger is output even when a break occurs. Trigger enable when TED data matches Outputs a trigger for BKTGIO_L when data conditions are satisfied. A trigger is output even when a break occurs. If both TEA and TED bits are set, a trigger will be output when both conditions are met. If both are cleared, a trigger is output regardless of the result of the comparator. TERD Read Access Trigger condition is satisfied only in a read cycle. TEWR Write Access Trigger condition is satisfied only in a write cycle. TERD
If both the bit and the TEWR bit are set, a trigger is output regardless of the access type. If both are cleared, no trigger is output. If N-trace is implemented, additional bits are required to specify the conditions for outputting N-trace packets.

Address Mask The following register is added for the address mask. DBAMn Data access break address mask register Bit mask for DBAn. If a bit in this register is 1, the corresponding bit in DBAn is not compared. Not all bits need to be masked. In such a case,
The lower bits should be masked. In addition, one mask
It is acceptable to mask multiple bits with bits. Examples of this are mask bits every four bits,
There are a mask bit for the lower 16 bits and a mask bit for the lower 24 bits. It is also acceptable to specify how many bits (of the LSB) are masked in binary. DBCn Data Access Break Control Register AINV 0-Breakpoint is hit when condition is met. 1-Breakpoint is hit when condition is not met.

Address Range When comparing addresses by "range", the following registers are used instead of the DBA. DBALn Data Access Break Address Low Register DBAHn Data Access Break Address High Register If the address is in the range of DBALn or DBAHn (both boundaries, including DBALn and DBAHn), the address is Match. The following bits are added to DBCn: DBCn Data Access Break Control Register AINV 0-Breakpoint is hit when condition is met. 1-Breakpoint is hit when condition is not met.

Data Mask The following register is added for the data mask. DBDMn Data access break data mask register Bit mask for DBDn. If a bit in this register is 1, the corresponding bit in DBDn is not compared. DBDn
You need to mask every single bit of. The following bits are added to DBC: DBCn Data Access Break Control Register DINV 0-Breakpoint hit when condition is met. 1-Breakpoint is hit when condition is not met.

<1.3.7.2 Action of Breakpoint> After a break, the tool resets the data access breakpoint and causes the user program to execute from the current program counter. The user program must be able to resume work. There may be a time interval between the time the instruction causing the data access cycle to be executed is executed and the time the actual break occurs. Instructions may be executed during this time interval.

<1.3.7.3 Processor is Cache and MMU
If> is provided, the set address must be logical. Address space ID as well as logical address
There should be a way to specify too. The address space ID is
It is specified in the following bits of DBCn. ASID Address space ID ASIDM 1-ASID is masked.

<1.4. Level 2 standard> If the level 1 standard is not applicable, the following specifications should be followed. <1.4.1 Monitor> When it is difficult to directly access user resources such as registers, memory, and caches through JTAG, an alternative is to execute a monitor program. If you use a monitor, select one of the options listed below.

<1.4.1.1 When Monitor Program is Executed for Several Words of Internal Buffer> Two JTAG instructions should be added. In one instruction, MON_INST, MO
N_DATAACC and MON_INSTEXEC are accessed. In the other instruction, MON_DATA is accessed. MON_INST Monitor Instruction Register The processor fetches instructions from this register when in debug mode. MON_DATA Monitor Data Register In debug mode, if the MON_DATAACC bit is set to 1, the processor accesses data in this register during load / store instructions. MON_DATAACC is 0
Is cleared to the normal user
Access memory. MON_DATAACC Monitor Data Access Flag While the processor is in debug mode, a load / store instruction accesses MON_DATA or
Indicates whether to access memory. MON_INSTEXEC Execute monitor program Writing 1 to this bit causes the processor to fetch and execute instructions from the MON_INST register. This bit should be cleared when the processor has finished executing the instruction. Writing 0 is ignored.

<1.4.1.2 When Monitor Program is Arranged in Dedicated Monitor Memory> When the monitor is arranged on the ROM, a register for data access is required. Alternatively, a portion of the user RAM must be used for monitoring. When placing the monitor on RAM,
There must be the ability to download monitors.

<1.4.1.3 Loading Monitor Program>
If the monitor cannot be loaded during a processor reset, there must be a function that prevents the monitor from running after the first break after reset.

<1.4.1.4 Return to User Program> When using the monitor program, unlike the level 1 standard, instead of writing 1 to the EXIT bit, a special instruction (return instruction) is used. User
You can return to the program. In this case, RUNFLAG to determine whether the user program is running
Bits should be provided (instead of EXIT). RUNFLAG Used to determine if the user program has been executed. Set when the user program is executed. Cleared by writing 0. Writing 1 is ignored. The debugging tool is
Clear this bit before returning to normal mode.
When RUNFLAG is set, the cause of the break is checked by reading BRKCAUSE.

<1.4.2 Quick Access> If it is difficult to insert a quick access mechanism inside the MMU, there are two methods. In other words, this mechanism
And between the cache and the cache (method 2) or outside the cache (method 3). Quick access is provided by a DMA-like mechanism. Static variables or I / O can be accessed with minimal impact of this mechanism on user programs. Code download is also faster. A DMA-like mechanism can be connected to the processor bus at one of the three locations (1)-(3) in FIG.

<1.4.2.1 Method (1)> Method (1) is strongly recommended. There are some limitations when using method (2) or (3).

<1.4.2.2 Method (2)> When the memory is accessed by quick access, it is impossible to refer to the current MMU setting.

<1.4.2.3 Method (3)> High-speed download is performed immediately after reset in the debug mode (the cache is also reset). Therefore, method (3)
Is useful for downloading code. However, the following restrictions apply. If the cache is a write-back cache, the contents of the main memory and the contents of the cache may be different. Therefore, reading from the write-back cache area by quick access is not supported. If cache snooping is not supported and any data is written to main memory, the contents of the cache will be different from main memory. Therefore, if snooping is not supported, writing to the cache area cannot be supported. Normal memory access (not quick access) is done in debug mode. The tools are
A write back can be performed during a write cycle, or an entry can be invalidated during a read cycle. Therefore, the above-mentioned problem is solved.

<1.4.2.4 When Quick Access Is Not Supported> All memory accesses are performed by the monitor. Therefore, neither quick access nor fast download is supported.

The following describes the N-trace section. <2.1. Trace Port> FIG. 5 shows the signals of the trace port. TRCCLK Output Clock for trace output TRCEND Output Indicates the end bit of trace data. TRCDATA [n-1: 0] Output Trace data output

The larger “n”, the lower the possibility of overflow. The bit length of each trace packet is variable. The TRCEND signal indicates when the debug module has finished outputting trace packets from the TRCDATA pin. This means that there is always some packet on TRCDATA. When there is no other trace data to output, the packet may be an empty packet called "NOP". As shown in FIG.
Two or more pins may be assigned to TRCDATA.

<2.2. To minimize trace packet bit length> The size of each trace packet should be as small as possible. Bits that can be interpolated in any way should be omitted. Since the first few bits can determine the type of the packet and the end of the packet can be known by TRCEND, some subsequent bits of each packet can be removed.

Although the following two methods are effective, they are used because they are simple and easy to implement. a) Suppress trailing bits that are all zero. b) Suppress subsequent bits that have the same value as the previous packet. Use (b) for TPC packets and (a) for other packets (packets will be defined later).

Example of (a) As shown in FIG. 6A, it is possible to delete the last three bits of the 8-bit packet “1, 0, 0, 1, 1, 0, 0, 0”. it can. When TRCDATA has 2 bits, only the last 2 bits can be deleted as shown in FIG.

Example of (b) As shown in FIG. 7A, assume that a "packet Y" of a 34-bit packet is to be output, and that a previous packet of the same type is "packet X". , There is no need to output the bit after the indicator (vertical bar symbol “|”) in the figure. Note that the last bit of TRCDATA [1] is "1" and not "0".

In this example, the first four bits (0, 1, 0,
0) indicates the type of the packet. Even if the packet exactly matches the packet before of the same type ("Packet X" is the same as "Packet Y"), the first four bits should be output. However, also in this case, the last two bits of this packet can be deleted by applying the method (1). Eventually, only the first two bits need to be output, as shown in FIG.

<2.3. Trace packet definition> Abbreviation code ------------------------ NSEQ <seq #> 1, <seq #> TPC <program_counter> 0,1, 0,0, <program_counter> TPCM 0,1,0,1 EXP <exp_id> 0,1,1,0, <exp_id> LSEQ 0,1,1,1 MATCH <match_info> 0,0,1,1 <match_info> DATA <type>, <data> 0,0,1,0, <type>, <data> OVF 0,0,0,1 NOP 0

<2.3.1 Non-sequential execution> Abbreviation NSEQ <seq #> Code 1, <seq #>

This packet is output when a branch or exception occurs.

<Seq #> is the program counter increment during which instructions are executed sequentially from the previous occurrence of this event or LSEQ (Long Sequential Execution) to the current occurrence of this event. The unit of <seq #> should be the minimum number of program counter increments. <seq #> is output from the least significant bit (LSB) in binary format. It is not necessary to output the upper bits of zero.

[0178] The bits to which "^" is added in the above example need not be output.

This packet (and LSEQ packet)
Since the program counter distance between the destination address of the previous branch and the source address of the current branch is indicated, the following should be noted.

When the processor skips instructions but does not change the program flow, the skipped instructions should be counted. One example is when the branch likely instruction of the MIPS R3000 series processor is not selected. -Conversely, instructions in branch delay slots must not be counted. By disassembling the branch instruction,
It can be determined whether such an instruction has been executed.

<2.3.2 Branch destination PC> Symbol TPC <program_counter> Code 0,1,0,0, <program_counter>

<Program_counter> is output from the least significant bit (LSB) in a binary format. It is not necessary to output the same upper bits as the previous branch destination PC. It is not necessary to output the part of the bits that are always fixed (for example, bits 1 and 0 of the MIPS R3000 series processor program counter). If the processor has an MMU (memory management unit), <program_counter> should be a logical address. Examples are given in the table below.

[0183]

[Table 1] Previous target <program_counter> <program_counter> Code --------- -------- ------------------- --------------- bfc00000 bfc00328 0100010100110000000000001111111101 ^^^^^^^^^^^^^^^^^^^^^^ bfc00328 bfc00208 0100010000010000000000001111111101 ^^^^^^^ ^^^^^^^^^^^^^^^^ bfc00208 00000000 0100000000000000000000000000000000 (Note) Bits with ^ below need not be output

This packet is output in the following situation. This packet is NSE when indirect jump is selected
Should be output after the Q packet. The definition of the indirect jump instruction in this document is an instruction for executing a branch or a jump, and the branch destination address cannot be decoded from its instruction code. For example, a register indirect jump (such as "jr $ 31" on a MIPS R3000 series processor)
And returns from subroutines (such as "rts" on Motorola CPU32 processors). -When an exception or event occurs that causes the program counter to change non-sequentially, this packet should be output after the EXP packet. -If the internal N-trace buffer is empty when a direct jump is performed, this packet should be output.
This is because disassembly can only start from a TPC packet. The state stored between the first line of the trace list and the first TPC packet in the trace list cannot be disassembled. N-trace is
All bits of the register where the <program_counter> of the previous TPC packet is stored should be cleared (to zero).

If there is more than one TRCDATA pin, a meaningful value (not zero) should be output for the extra bits. For example, if there are two TRCDATA pins, "0101000001" for the second branch in the above code example
(Not "0101000000") is output.

<2.3.3 Exception> Abbreviation EXP <exp_id> Code 0,1,1,0, <exp_id>

This packet is output when an exception or special event occurs in the processor.

<Exp_id> indicates the type of exception or event. The bit assignment of <exp_id> depends on the processor family. <exp_id> is output from the least significant bit (LSB) in binary format. If all the upper bits are zero, there is no need to output those bits.

[0189] This packet is output after the NSEQ packet when the processor generates an exception. If the address of the exception handler is not known from <exp_id>, a TPC packet should be output after the EXP packet. Examples of events may be an interrupt, a process ID change, a bus release, a sleep mode entry, and the like.

<2.3.4 Trigger and / or Hardware Breakpoint Match> Abbreviation MATCH <match_info> Code 0,0,1,1, <match_info>

This packet is output when an event specified by the user, such as an on-chip hardware breakpoint hit or an external trigger input, occurs. The bit assignment of <match_info> depends on the processor family. <match_info> should contain information indicating the type of event and the channel number (if the event is a hardware breakpoint). <Match_info> may include additional information indicating details of the event. MATCH packets are used to trigger debug tools that capture N-trace packets, so that MATCH packets must not be lost while the trace buffer overflows. An example of <match_info> is shown below.

<2.3.4.1 Example of <match_info >><match_inf
The first two bits of o> indicate the type of event. Subsequent bits depend on this type. <bptype> Event type ------- ----------- 0,0 External trigger input 0,1 Instruction address breakpoint 1,0 Data access breakpoint 1,1 Reservation

External trigger input Symbol MATCH Extrg code 0,0,1,1,0,0

Instruction address breakpoint Abbreviation MATCH Exec, <bplist> Code 0,0,1,1,0,1, <bplist>

<Bplist> indicates which channel of the instruction address breakpoint has been hit. <bplist>
Has the same number of bits as the number of instruction address breakpoints. Hitting breakpoint channel "n" sets bit "n" of <bplist>. Two
If more than one bit is set, it means that more than one condition has been met at the same time.

Data access breakpoint Abbreviation MATCH Acc, <bplist>, <rw>, [1, <addr>] Code 0,0,1,1,1,0, <bplist>, <rw>, [ 1, <addr>]

<Bplist> indicates which channel of the data access breakpoint has been hit. <bplis
t> has the same number of bits as the number of data access breakpoints. Hitting breakpoint channel "n" sets bit "n" of <bplist>. If more than one bit is set, it means that more than one condition was met at the same time. <rw> is 1
It is a bit length and indicates the access type of the access cycle. <rw> ---- -------------- 1 Read cycle 0 Write cycle

When a data access breakpoint is set using an address mask, the address cannot be determined from the channel of the breakpoint. In this case, additional information, that is, the address (<addr>) of the data access cycle, is useful for determining the exact address. <addr> is output when the address output enable bit “MAOE” of the data access breakpoint is set.
Generally, an address mask is used to mask the lower bits of an address rather than the upper bits. To minimize the bit length of the packet, <addr> should be an address that is the logical OR of the address mask. <addr> = <data access address>&<address mask reg
When the bits of ister><address mask register> are set, the comparator does not compare the corresponding <data access address> bits. The complete address can be obtained from the value of the masked address and the breakpoint channel number. When a number of data access breakpoints are hit and enabled to output an address, the address is masked using the address mask with the lowest break channel number. A DATA packet can follow to indicate the data used in the access cycle.

<2.3.5 Data Access Output> Abbreviation DATA <type>, <data> Code 0,0,1,0, <type>, <data>

This packet is used to output a data access cycle when a preset condition is satisfied. <type> indicates what type of data is output. The bit length and the meaning of the value depend on the processor family. <data> is data of a data access cycle. The bit length is variable.

When a data access breakpoint is hit and the data output bit is enabled,
A DATA packet should be output following the MATCH packet. If the upper bits are zero, there is no need to output them. An example of <type> and <data> is shown below.

<2.3.5.1 Examples of <type> and <data >><type><type> represents a byte enable signal of the processor. On 32-bit processors, <type> has a bit length of 4
Bits (BE [3: 0]). <type> is output from byte enable 0 (BE [0]). <data> The bit length of <data> depends on the operation size of the data access cycle. For example, for a byte access cycle, the length would be 8 bits. <data> is output from the largest bit (LSB) in binary format.

<2.3.6 Overflow> Abbreviation OVF code 0,0,0,1

When the on-chip trace buffer overflows, input to the buffer is suspended until all packets in the buffer have been output. OVF packets should follow the last remaining packet in the trace buffer. If the condition of MATCH packet output is satisfied while the input is interrupted due to overflow, the MATCH packet should still be output after the OVF packet. MATCH packets are used to detect user-specified events and must not be lost. Other packets occurring during the overflow may be lost.

<2.3.7 Long sequential execution> Abbreviation LSEQ code 0,1,1,1

This packet is provided to limit the number of bits of the NSEQ code counter. This packet is output when the maximum number of sequential instructions have been executed. Such a maximum is not specified in this specification and may be dependent on the processor family.

<2.3.8 No data to output> Abbreviation NOP code 0

This packet is output when there is no other data to be output.

<2.3.9 Small Packet> As a matter of course, two sets of buffers are required to implement the N-trace specification. One of them stores the "type" of the event. This is called a "main buffer". The other stores "data" such as <program_counter>, <exp_id>, and <data>. This is called a "data buffer". The bit width of the “data buffer” is longer than the bit width of the “main buffer”. The depth of the "data buffer" is smaller than the depth of the "main buffer". Therefore, when the "data buffer" is full, it is likely that the "main buffer" is not yet full. If so, the "data" of the event can be omitted and the "type" of the event still output. EXP packet without <exp_id> MATCH packet without <addr> DATA packet without <data> and <type>

[0210] In the TPC packet, another packet must be defined. Abbreviation TPCM code 0,1,0,1

<2.4. Trace Modes> There should be various optional trace modes to make the most efficient use of the limited trace pins and buffers.

<2.4.1 Real-time / Non-real-time
Trace> In real-time trace mode, the processor executes the user program without any restrictions from N-trace. When the on-chip N-Trace buffer overflows, an OVF packet is generated. In exceptional cases, certain trace information required for correct tracing may be lost.

In the non-real-time trace mode,
The processor pipeline stops before the on-chip N-Trace buffer overflows. This ensures a complete trace, but slows down the execution of the user program on the processor.

<2.4.2 TPC Packet> The TPC packet should be selectively output according to the type of branch. TP
There are four levels to output C packets.

Level 0: TPC suppression At this level, no TPC packet is output. This is useful when only a data access trace is needed.

Level 1: TPC at exception and indirect jump
A TPC packet is output when a packet exception or indirect jump occurs. This is a normal mode. Very close to a complete program flow trace.

Level 2: TPC packet at the time of special instruction At this level, a TPC packet is always generated at the time of a special instruction. This mode is particularly useful when the special instruction is an "inter-function" jump. For example, in this category
Should include Jump-and-link and Return instructions. This allows program flow to be traced at the function level (such as function call history).

Level 3: TPC packet at the time of exception and jump A TPC packet is output when any exception or any jump occurs. At this level, the trace is always correct, since the program counter can be rebuilt without having to disassemble the direct jump. Levels 0 and 2 allow the program to break if the program code is corrupted due to a system crash.
The counter cannot be rebuilt.

<2.4.3 Other Packets> The EXP, NSEQ, and LSEQ packets should be selectively enabled or disabled. This corresponds to level 3 or level 0 of the TPC packet.

<2.5. Debug register> Debug
Registers control N-trace settings. The debug registers are accessed by an N-wire "resource access" scheme. Accessing this register must not affect the execution of the user program of the processor.

<2.5.1 N-trace System Register> TRC
The SYS debug register is used to control N-Trace.

TRCSYS (N-Trace System Register) ID N-Trace implementation ID (R) Identifies processor family dependent options. NDATAPIN N-Trace pin configuration (R) Number of TRCDATA pins OVF N-Trace overflow status (R / W) This bit is set when the trace buffer overflows. TGIN N-Trace input status (R / W) This bit is set when an external trigger is detected. RESET Reset N-Trace (W). Reset N-Trace. If this bit is set, N-Trace is initialized and no trace packet is generated (NOP packet is output). At the time of N-Trace reset,
The buffer and MO1 (MATCH packet output once) status are cleared. The previous <program_counter> value is used to shorten the next TPC packet, but this value should be initialized. All trace settings can be changed at N-Trace reset. When this bit is cleared, a trace packet should be generated in response to processor activity. CLKDIV Clock frequency trace (W) Change TRCCLK frequency. This bit sets this frequency
Used to adapt to N-Trace analyzer. This is selected by dividing the core clock frequency. MODE Trace of mode configuration (W) bit 0 Real-time trace or non-real-time trace bit 2, 1 Select TPC packet output level. Bit 3 suppresses EXP packets. Bit 4 Suppress NSEQ and LSEQ packets.

<2.5.2 Hardware Breakpoint Register> A debug register related to a hardware breakpoint is used to specify conditions for outputting a MATCH packet and a DATA packet. The following registers should be prepared for each hardware breakpoint channel.

<2.5.2.1 Instruction Address Breakpoint> IBA Instruction Address Breakpoint Address Register IBAM Instruction Address Breakpoint Address Mask Register IBC Instruction Address Breakpoint Control Register INV Comparator Inverter Invert the result. The condition is satisfied when the instruction address does not match the IBA and IBAM registers. ME MATCH packet enable Outputs a MATCH packet on N-trace when the conditions are met. MO1 MATCH packet output once After N-trace reset, output MATCH packet only once when condition occurs for the first time.

<2.5.2.2 Data Access Breakpoint> DBA Data Access Breakpoint Address Register DBAM Data Access Breakpoint Address Mask Register DBD Data Access Breakpoint Data Register
Register DBDM data access breakpoint data
Mask register DBC Data access breakpoint control register AINV Address comparator inversion Inverts the result of the address comparator. The condition is met when the access address does not match the DBA and DBAM registers. DINV Data comparator inversion Inverts the result of the data comparator. Access data
The condition is met when the DBD and DBDM registers do not match. DBE Data Comparator Byte Enable The bit length is equal to the number of bytes in the data word of the processor. Each bit corresponds to a byte enable of the processor. When this bit is set, the data condition is not met if the processor has not enabled the corresponding data byte. Enable MATCH packet when MEA address matches Outputs a MATCH packet on N-trace when the conditions are met. Enable MATCH packet when MED data matches. Outputs a MATCH packet on N-trace when the conditions are met. If both the MEA and MED bits are set, a MATCH packet is output when both conditions are met. If both are cleared, a MATCH packet is output regardless of the result of the comparator. The MERD read access condition is satisfied only in a read cycle. The MEWR write access condition can only be met in a write cycle. If both MERD and MEWR bits are set, a MATCH packet is output regardless of the access type. If both are cleared, no MATCH packet is output. MO1 MATCH packet output once After N-trace reset, output MATCH packet only once when condition occurs for the first time. MAOE MATCH packet address output enable Adds access address information to the MATCH packet. If the AINV bit is enabled, <addr> must not be the value masked in the DBAM register. <addr> should be just an access address. Enable DATA packet when DEA address matches Outputs DATA packet on N-trace when address condition is satisfied. Enable DATA packet when DED data match Outputs a DATA packet on N-trace when the conditions are met. If both the DEA and DED bits are set, a DATA packet is output when both conditions are met. If both are cleared, a DATA packet is output regardless of the result of the comparator. The DERD read access condition is satisfied only in a read cycle. The DEWR write access condition can only be met in a write cycle. If both the DERD and DEWR bits are set, a DATA packet is output regardless of the access type. If both are cleared, no DATA packet is output.

<2.6. Using Trace Packets><2.6.1 Trace of Program Counter Flow> NS
The branch history can be traced using the EQ packet, LSEQ packet, TPC packet, and EXP packet. The user can select a branch history level from the following. − Branch from one function to another (function flow) − all branches (full program counter flow)

<2.6.1.1 Function Flow> Function call history tracing is performed by capturing a TPC packet and an EXP packet. TPC output mode should be set to level 2.

If the <program_counter> of the TPC packet is the input address of a function, it indicates that the function is called. Also, the <program_counte> of the previous TPC packet
Since r> is within the address range of the caller, the caller can be determined by the previous TPC packet.

<2.6.1.2 Full Program Counter
Flow> Full program counter flow trace is NSEQ packet, LSEQ packet, TPC packet, EXP
This is done by capturing packets. TPC output mode should be set to level 1.

Reconstruction of Program Counter The program counter can be reconstructed by knowing where the branch is taken (the position of the branch instruction) and where the branch destination of the branch is (the branch destination address). In this protocol, the rebuilding of the program counter can only be started from a TPC packet.

The following shows how the program flow is reconstructed. 1) Search for the first TPC packet. 2) Search for NSEQ packets towards the end of the trace list. If an NSEQ <seq #> packet is found, a jump or branch has occurred there. The jump or branch instruction is located at the previous branch destination address.
You can find out by adding <seq #>. 3) If a TPC packet follows, a new branch destination address can be known from this packet. Otherwise, the branch destination address can be decoded by disassembling the jump or branch instruction. 4) Repeat from (2) to (4).

Example of Full Program Counter Flow Trace Output Here, a MIPS R3000 series processor is used as an example.

[0233]

[Table 2] Before the head of this list:-TPC register contains '000028b4'-On-chip trace buffer is empty-Instructions '000028b4' to '000028dc' sequentially + --- TRCEND | +-TRCDATA | | 0 1 (1) NSEQ: 00000009 000028d8: (1,2) bne $ 14, $ 0, 0x000028b4 0 1 000028dc: nop 0 0 000028b4: addu $ 25, $ 4 , $ 0 0 0 000028b8: addiu $ 4, $ 4, 0x0001 1 1 000028bc: addu $ 24, $ 5, $ 0 0 0 (2) TPC: 000028b4 (0 bit) 000028c0: addiu $ 5, $ 5, 0x0001 0 1 000028c4: lb $ 15, 0x0000 ($ 24) 0 0 000028c8: nop 1 0 000028cc: sb $ 15, 0x0000 ($ 25) 1 0 (3) NOP 000028d0: lb $ 14, 0x0000 ($ 5) 1 0 NOP 000028d4: nop 1 0 NOP 000028d8: bne $ 14, $ 0, 0x000028b4 1 0 NOP 000028dc: nop 1 0 NOP 000028e0: sb $ 0, 0x0000 ($ 4) 1 0 NOP 000028e4: addu $ 2, $ 3, $ 0 (Continued in Table 3)

[0234]

[Table 3] [Table 3 (first half)] 0 1 (4) NSEQ: 0000000d 000028e8: (4,5) jr $ 31 0 1 000028ec: nop 0 0 000020cc: lui $ 10, 0x0000 0 1 000020d0: addiu $ 10, $ 10, 0x48c0 1 1 000020d4: addiu $ 11, $ 10, 0x065c 1 0 (5) TPC: 000020cc (10bit) 000020d8: ori $ 8, $ 0, 0x000a 0 1 000020dc: sw $ 8, 0x0000 ($ 11) 0 0 000020e0: ori $ 19, $ 0, 0x000a 0 0 000020e4: ori $ 18, $ 0, 0x0001 0 1 000020e8: (6) j 0x000022a4 0 1 000020ec: nop 0 0 000022a4: slt $ 14, $ 19, $ 18 0 0 000022a8: (7) beq $ 14, $ 0, 0x000020f0

[Table 4] [Table 3 (second half)] 0 1 000022ac: nop 0 1 000020f0: (8) jal 0x000024b4 0 0 000020f4: nop 0 0 000024b4: ori $ 8, $ 0, 0x0041 0 0 000024b8: sb $ 8, 0x8021 ($ 28 ) 1 0 000024bc: sw $ 0, 0x8024 ($ 28) 0 1 (6) NSEQ: 00000007 000024c0: (9,10) jr $ 31 0 1 000024c4: nop 0 1 000020f8: jal 0x00002484 1 1 000020fc: nop 0 1 (7) NSEQ: 00000001 00002484: lb $ 25, 0x8021 ($ 28) 1 1 00002488: nop 1 1 (8) NSEQ: 00000000 0000248c: xori $ 24, $ 25, 0x0041 0 1 (9) NSEQ: 00000003 00002490: sltiu $ 3, $ 24, 0x0001 0 1 00002494: lw $ 15, 0x8024 ($ 28) 1 1 00002498: nop 0 0 (10) TPC: 000020f8 (4 bit) 0000249c: or $ 15, $ 15, $ 3 0 1 000024a0: sw $ 15, 0x8024 ($ 28) 0 0 000024a4: ori $ 8, $ 0, 0x0042 0 0 000024a8: sb $ 8, 0x8020 ($ 28) 0 1 000024ac: jr $ 31 0 1 000024b0: nop 0 1 00002100: ori $ 8, $ 0, 0x0002 1 1 00002104: sw $ 8, 0x0060 ($ 29)

(1) Before the branch at the top of the list, 9
Two instructions (000028b4 through 00088d4) are being executed sequentially (ie, a jump is made from a certain position to 000028b4, and no branch is taken to 000028b4 thereafter).
Therefore, an “NSEQ 9” code is output. (2) Since the on-chip trace buffer is empty, the branch destination address of the branch is output. The branch destination address is the same as before, so that only "0100" is output (no bit for the program counter). (3) N because the on-chip trace buffer becomes empty
OP is output. (4) The branch destination address of the indirect jump is output. (5) The lower 10 bits different from the previous TPC are output. (6) A jump is performed while the TPC is output in (5). The output of code "NSEQ7" is delayed until the output of (5) is completed. (7) A branch is taken, but the "NSEQ1" output is also delayed. (8) Jump and Link are performed, but “NSEQ0” output is also delayed. (9) Jump Register is performed, but “NSEQ3” output is also delayed. (10) In the case of Jump Register, since it is an indirect jump,
TPC is output even when the trace buffer is not empty. This is the peak of buffer usage in this list (4 packets are buffered).

<2.6.2 Detection of User-Specified Event> When a user-specified event is detected, a MATCH packet is output.

<2.6.2.1 Trigger of N-trace Analyzer at Event> The MATCH packet is Nt for capturing the packet.
Used to trigger the race analyzer. An analyzer can capture processor activity before and after a particular event by detecting a MATCH packet. To ignore the second event and subsequent events, MO1 (output a MATCH packet only on the first occurrence of the event) should be enabled.

<2.6.2.2 Detection of Event Occurrence> MATCH
Another use of packets is to detect the occurrence of an event. MATCH packets can also be used for: -Mixed with the program counter trace. -Access address-Count some events. − Measure the interval between events.

Mixing with Program Counter Flow Trace When tracing a MATCH packet with a program counter flow packet, the processor can determine the instruction address range that caused the event. The accuracy of the address range depends on what level of branch information is being traced (full program counter flow or function flow). This is particularly useful when using data access as events. For example, when tracing is performed using a function flow, the previous TPC packet indicates a function that performs data access.

Access Address When a data access breakpoint is specified using an address mask, the masked address bits are not known from the breakpoint channel number (<bplist>). Address (<addr>) in the MATCH packet at the time of data access, as in the example of the MATCH packet specification
Can be added. This is useful when you need to know the exact address.

Counting Some Events By counting MATCH packets, a specified event can be counted.

Measurement of Event Interval The interval between one MATCH packet and another packet can be measured. Due to the buffering, a time delay occurs from the occurrence of the event to the corresponding MATCH packet. If other packets are not buffered, the delay should be minimized and fixed, so other packets should be suppressed to make the interval more accurate.

<2.6.3 Data Access Cycle Trace> A processor data access cycle can be traced using a MATCH packet and a DATA packet. Trace buffer depth and TR
Due to the limited CDATA pin count, it is not possible to output every data access cycle.
To selectively output data access cycles,
Use data access breakpoints. In the example packet specification, a MATCH packet is used to indicate that a data access cycle has been performed, its access type and address. DATA packets are
Used to indicate access size and data.

<2.7. N-trace operation in debug mode> When the processor is in debug mode, trace packets must not be generated by processor activity. In debug mode, NOP packets should be output continuously.

<2.7.1 Transition to Debug Mode> If the cause of a debug exception is an external trigger input or a hardware breakpoint, a MATCH packet and a DATA packet should be output according to the packet enable bit. . NS when a debug exception occurs
Should output EQ and EXP packets. Other packets remaining in the trace buffer should be output before these NSEQ and EXP packets.

<2.7.2 Transition to Normal Mode> When the processor ends the debug mode, TPC indicating the instruction address at which the execution of the user program is resumed
A packet should be generated.

<2.7.3 For Tool Debugging>
This is useful when debugging a monitor program itself for which it is desirable to prepare a special trace mode for outputting a trace packet even in the debug mode in order to facilitate development of a debug tool.

[Brief description of the drawings]

FIG. 1 is a timing chart illustrating a break output and a trigger output.

FIG. 2 is a timing chart illustrating a break input and a trigger input.

FIG. 3 is a diagram showing a configuration of an IDCODE register.

FIG. 4 is a diagram illustrating a position where a quick access mechanism can be inserted.

FIG. 5 is a timing chart showing trace port signals.

FIG. 6 is a view for explaining a method of shortening a trace packet bit length.

FIG. 7 is a view for explaining a method of shortening a trace packet bit length.

FIG. 8 is a view for explaining a method of reducing a bit length of a trace packet.

Claims (1)

[Claims] 1. A microprocessor capable of outputting trace information, wherein the trace information is output as a packet composed of a variable-length bit string.