Debug support in a processor chip - Patent Review 5491793

What is claimed is:

1. A single chip central processing unit (CPU) for real-time debugging connected between an external memory for storing data and instructions and an external diagnostic instrument for setting breakpoints in the CPU and obtaining a trace of instructions processed by the CPU, the CPU comprising:

a processor comprising means for processing data and instructions fetched from the external memory, means for comparing a breakpoint condition received from the external diagnostic instrument to the data and instructions being processed by the processing means, and means for notifying the external diagnostic instrument with an acknowledgement signal when the breakpoint condition matches the data and instructions;

a first bus interface unit for coupling instructions and data between the processor and the external memory before and after the breakpoint condition over a first bus connected between the first bus interface unit and the external memory; and

a second bus interface unit for coupling instructions and data between the processor and the external diagnostic instrument after the breakpoint condition has occurred and transmitting status information to the external diagnostic instrument before, during and after the breakpoint condition over a second bus connected between the second bus interface unit and the external diagnostic instrument.

2. A single chip CPU as in claim 1, wherein said first bus has a bandwidth and said second bus has a bandwidth, the bandwidth of said first bus is greater than the bandwidth of said second bus.

3. A single chip CPU as in claim 1, said first and second bus interface units operate to cause said processor to fetch the instructions and data from the external memory through said first bus before and after the breakpoint condition and fetch the instructions and data from the external diagnostic instrument through said second bus during the breakpoint condition.

4. A single chip CPU as in claim 3, wherein the breakpoint condition is a hard breakpoint trap.

5. A single chip CPU as in claim 3, further comprising means for communicating addresses of said instructions to said diagnostic instrument and means for receiving fetched instructions from said diagnostic instrument through said second bus.

6. A single chip CPU as in claim 5, further comprising means for communicating a header before an address is communicated to said diagnostic instrument.

7. A single chip CPU as in claim 6, further comprising means for communicating said header in a first time frame, means for communicating said address in at least one second time frame and means for communicating said fetched instruction in at least one third time frame.

8. A single chip CPU as in claim 7, further comprising means for communicating said header in one first time frame, means for communicating said address in four time frames and means for communicating said instruction in four time frames.

9. A single chip CPU as in claim 8, further comprising means for communicating a stopper in a time frame after said first, second and third time frames.

10. A single chip CPU as in claim 9, further comprising means for providing a high impedance between said second bus interface unit and said second bus in said time frame wherein the stopper is communicated.

11. A single chip CPU as in claim 1, further comprising:

means for setting at least one criterion for initiating a breakpoint condition;

means for comparing the criterion to a value generated during execution by the processor; and

means for transmitting the breakpoint acknowledgement signal to the external diagnostic instrument via said second bus when the criterion is satisfied.

12. A single chip CPU as in claim 11, further including means for selectively initiating a process switch when said breakpoint condition is met.

13. A single chip CPU as in claim 11, further including means for inhibiting a process switch when said breakpoint condition is not met.

14. A single chip CPU as in claim 1, wherein said second bus comprises a first set of signal lines for outputting addresses of instructions executed by said processor and a second set of signal lines for outputting status information when said instruction addresses are output.

15. A single chip CPU as in claim 14, wherein each instruction address is output in segments comprised of a most-significant segment and a plurality of additional segments.

16. A single chip CPU as in claim 14, wherein the status information indicates whether an instruction has been fetched by the processor and whether an address segment accompanying the status information is the most-significant segment.

17. A single chip CPU as in claim 14, wherein the status information indicates whether the processor is in a hold state and whether an accompanying address segment is the most-significant address segment.

18. A single chip CPU as in claim 14, wherein the status information indicates whether an instruction fetched by the processor is a next sequential instruction to a preceding instruction and whether an accompanying address segment is the most-significant address segment.

19. A single chip CPU as in claim 14, wherein the status information indicates whether a breakpoint condition has occurred, whether an instruction fetched by the processor is a next sequential instruction to a preceding instruction and whether an accompanying address segment is the most-significant address segment.

20. A single chip CPU as in claim 1, wherein the status information indicates whether a branching instruction was fetched by the processor, whether an instruction fetched by the processor is a next sequential instruction to a preceding instruction and whether an accompanying address segment is the most-significant address segment.

21. A CPU as in claim 1, wherein the breakpoint condition is a correlation between a predefined address and an address for at least one of the instructions.

22. A CPU as in claim 1, wherein the breakpoint condition is a correlation between a predefined address and an address for at least one of the data.

23. A CPU as in claim 1, wherein the breakpoint condition is a correlation between a predefined value and a value for at least one of the data.

24. In a computer system having a processor for processing instructions and a debug support unit for tracing the processing of the instructions, the processor and the debug support unit being incorporated onto an integrated circuit and being interconnected by a bus, a method for tracing in real time instructions processed by the processor using the debug support unit, comprising the steps of:

receiving an instruction address with the debug support unit for an instruction to be processed next from the processor over the bus;

outputting with the debug support unit the instruction address and a trace status block for indicating trace status information over an output bus with a width smaller in number of bits than the instruction address, the instruction address being output in more than one segment, each segment with a width smaller in number of bits than the instruction address; and

repeating the outputting step with the debug support unit until each of the segments comprising the instruction address has been output.

25. A method as in claim 24, wherein the instruction address comprises a most significant segment followed by at least one next most significant segment, the outputting step further comprising:

outputting the most significant segment; and

repeating the outputting step for each of the next most significant segments.

26. A method as in claim 25, wherein the trace status block contains a most significant segment indication representing that the segment being output in the outputting step is the most significant segment, further comprising the step of:

setting the most significant segment indication prior to the outputting step whenever a new instruction address is received in the receiving step.

27. A method as in claim 25, wherein the instruction address comprises a least significant segment and the least significant segment contains a supervisor state indication representing that the processor is in a supervisor state, further comprising the step of:

setting the supervisor state indication with the debug support unit prior to the outputting step and in response to a supervisor signal transmitted by the processor to the debug support unit indicating that the processor is in the supervisor state.

28. A method as in claim 25, wherein the least significant segment contains a trap indication representing that the processor has taken a trap, further comprising the step of:

setting the trap indication with the debug support unit prior to the outputting step and in response to a trap signal transmitted by the processor to the debug support unit indicating that the processor has taken the trap.

29. A method as in claim 24, wherein the processor has a program counter for storing an instruction address, the debug support unit having access to the program counter, and the method further comprising the step of:

storing an instruction address for an instruction to be executed next by the processor into the program counter; whereby the receiving step further comprises receiving the instruction address from the program counter.

30. A method as in claim 24, wherein the computer system has an instruction cache containing a plurality of entries for storing instructions staged from a main memory, and the processor, the debug support unit and the instruction cache being interconnected by an address bus, the method further comprising the step of:

transmitting an instruction address from the processor to the instruction cache during an instruction fetch over the address bus; whereby the receiving step further comprises receiving the instruction address from the address bus.

31. A method as in claim 30, wherein the processor, the debug support unit and the instruction cache are incorporated onto the same integrated circuit.

32. A method as in claim 24, wherein the debug support unit contains a no-hold indication representing that the processing of instructions by the processor is not to be held, the method further comprising the steps of:

clearing the no-hold indication in response to a nonassertion of a no-hold signal transmitted by the processor;

holding the processing of instructions by the processor during the outputting step and repeating step until the instruction address has been output in the outputting step in response to a non-sequential instruction signal transmitted by the processor to indicate that a next instruction is not sequential in order of processing; and

resuming the processing of instructions by the processor upon the completion of the outputting step.

33. A method as in claim 24, wherein the trace status block contains a no-branch indication representing that a next instruction is sequential in order of processing to an instruction being output in the outputting step, further comprising the step of:

setting the no-branch indication prior to the outputting step and in response to a sequential instruction signal transmitted by the processor to indicate that a next instruction is sequential in order of processing.

34. In a computer system having a processor for processing instructions and a debug support unit for monitoring the processing of the instructions, the processor and the debug support unit being incorporated onto the same circuit and connected by a bus, the debug support unit comprising a plurality of descriptor registers for storing program values and a debug support interface for interfacing to a diagnostic instrument, a method for setting breakpoints in the processing of instructions in a computer program using a debug support unit, comprising the steps of:

loading a program value to be monitored by the debug support unit into at least one of the descriptor registers, the program value being received from the diagnostic instrument over the debug support interface;

monitoring with the debug support unit instructions processed by the processor by comparing each such instruction to the program value stored in the at least one descriptor register, each such instruction being received from the processor over the bus, a match between the instruction and the program value indicating to the debug support unit that a breakpoint has been encountered;

taking a trap if the breakpoint is indicated by performing a process switch with the processor, setting the processor into a supervisor mode and setting a debug indication in the processor for representing that the debug support unit is in use;

executing a trap routine stored in a supervisor address space which includes fetching instructions and data values for processing by the processor from the debug support unit over the bus and executing the instructions with the data values on the processor; and

returning from the trap routine by performing a process switch with the processor, setting the processor into a user mode and clearing the debug indication.

35. A method as in claim 34, wherein the debug support unit further comprises a debug control register which includes a data value mask bit for representing that the breakpoint is a mask operation, the loading step further comprising setting the data value mask bit, and the monitoring step further comprising masking each such instruction using the program value.

36. A method as in claim 34, wherein the debug support unit further comprises a debug control register which includes a data value condition bit for representing that the breakpoint is a range comparison operation, the loading step further comprising loading a pair of program values into a pair of descriptor registers, and the monitoring step further comprises comparing each such instruction to the pair of program values using the pair of descriptor registers to determine whether the instruction falls between the pair of program values.

37. A method as in claim 34, wherein the setting step further comprises a debug control register which includes a data value condition bit for representing that the breakpoint is a range comparison operation, the loading step further comprising loading a pair of program values into a pair of descriptor registers, and the monitoring step further comprising comparing each such instruction to the pair of program values using the pair of descriptor registers to determine whether the instruction falls outside the pair of program values.

38. A method as in claim 34, wherein each program value comprises an instruction address for a program instruction.

39. A method as in claim 34, wherein each program value comprises a data value address for a program data value.

40. A method as in claim 34, wherein each program value comprises a constant value.

41. A method as in claim 34, wherein the debug support unit further comprises a debug control register which includes an external break signal for representing that the breakpoint condition is to be triggered asynchronously whereby the taking and executing steps are performed immediately responsive to an activation of the external break signal.

42. A method as in claim 34, wherein the program value to be monitored is an instruction address.

43. A method as in claim 34, wherein the program value to be monitored is a data address.

44. A method as in claim 34, wherein the program value to be monitored is a data value.

Description Submit all comments and votes

FIELD OF THE INVENTION

The present invention relates in general to debug support in a single chip central processing unit (CPU) and specifically to an interface in a single chip CPU for coupling to a diagnostic instrument to facilitate debugging and tracing of transactions performed by the CPU.

BACKGROUND OF THE INVENTION

In a typical procedure of bringing up a computer, a set of diagnostic programs is first run. The diagnostic programs are typically written to test specific components of the computer and, in the event of a failure, provide error message(s) identifying or isolating the cause(s) thereof. Upon completion of the diagnostic programs, benchmark application programs may also be executed. The benchmark application programs typically comprise routines that exercise the functions expected from the computer and are run to determine whether these functions are performed correctly thereby.

In running the test programs and/or the benchmark application programs, one often encounters failures that do not manifest themselves until after processing has proceeded for a substantial period of time past the failures, or failures (such as timing errors caused by unexpected capacitance in signal paths) that manifest only when the computer runs at full speed (as oppose to those that manifest in "single-cycle" which are relatively more easy to debug). When such types of failures occur, one vital debugging tool is to obtain a trace of the transactions performed by the computer. Tracing the transactions performed by the computer often means tracing the instructions it executes. From the trace, the activities of the computer during the time of a failure can be examined and from such activities the possible area of the failure can be isolated.

Tracing instructions is also useful for developing and debugging a computer software, where the trace can assist in understanding how and when problematic portions of the software are entered or exited.

Another often-used tool for debugging a computer system and/or computer software is to set breakpoints at selected addresses of the software. The breakpoints trap the flow of the software, such as whether, when and how certain portions of a software are entered and exited. From the flow, the behavior of the software can be examined.

Setting breakpoints also facilitates debugging and development of a computer or a computer software by allowing trial values to be injected at various processing stages of the software.

Tracing and trapping instructions are typically accomplished in prior art computers by a debug support circuit which is connected to the system bus--the bus that connects the CPU to the external memory and other peripheral devices. Connecting the debug support circuit to the system bus is convenient in prior art computers because it is where addresses, instructions and data of the computer flow. Moreover, by connecting the debug support circuit to the system bus, there is no need to add new input/output pins to a semiconductor chip; otherwise, the new I/O pins needed may be significant because instruction tracing requires outputting addresses whose length is normally equal to the width of the computer.

Unfortunately, providing the debug support circuit from the system bus also increases the electrical load of the system bus and interferes with the design and operation thereof. Moreover, debug support operations may be handicapped by shared use of the system bus, as they may be interfered by operations of the external memory and other peripheral devices.

Connecting the debug support circuit to the system bus is also undesirable for CPUs that use internal cache(s). In these CPUs, memory access is not performed if there is a cache hit; that is, instructions, data and addresses will not pass through the system bus when they are already present in the internal cache. If the instructions, data or addresses are accessed without passing through the system bus, they may become undetectable to the debug support device.

What is needed in view of the foregoing is a new debug support interface in a CPU whereby tracing and trapping of instructions can be achieved without using the system bus. Preferably, the new debug support interface allows tracing and trapping of instructions even when the CPU has an internal cache. Moreover, because increasing input/output pins of a semiconductor chip has an adverse effect on the cost and design thereof, it is also important that the new debug support interface does not significantly increase the number of input/output pins of the chip.

SUMMARY OF THE INVENTION

The present invention discloses a single chip central processing unit (CPU) for coupling with a external memory via a system bus to form a data processing system. The central processing unit comprises a processor having means for decoding instructions and means for executing instructions. The central processing unit also comprises a first bus for connecting the processor with the system bus to communicate instructions and data between the processor and the external memory. The central processing unit according to the present invention also comprises a second bus for connecting the processor with an external diagnostic instrument to communicate instructions and data between the processor and the diagnostic instrument.

The present invention also discloses a method in a computer of providing a trace of instructions processed by a processor. The method comprises the step of outputting data of the trace through a bus which is smaller in width than the trace data and the step of maintaining the rate of the processor substantially at its normal rate when the trace data are output.

The present invention also discloses a computer system, having a first memory, a second memory, a processor fetching instructions from a memory space, and means for mapping said memory space into said first memory during normal operations and mapping said memory space into said second memory during debug support operation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram illustrating a single chip central processing unit wherein the present invention is embodied.

FIG. 2 is a schematic diagram illustrating the interface signals between the IU and the DSU, as well as the interface signals between the DSU and the diagnostic instrument shown in FIG. 1.

FIG. 3 is a flow chart illustrating the general steps of a trace operation.

FIG. 4A-4C are a schematic diagrams showing how a complete instruction trace is provided under the preferred embodiment of the present invention.

FIG. 5 is a schematic block diagram which illustrates the components tin the debug support unit for outputting a trace of instructions.

FIG. 6 is a flow chart illustrating the general steps for setting the DSU registers.

FIG. 7 is a flow chart illustrating the general steps of a breakpoint operation.

FIG. 8 is a schematic block diagram illustrating means for detecting a breakpoint.

FIG. 9 is a schematic diagram illustrating the interface within the DSU for communicating with the diagnostic instrument.

FIG. 10 is a block diagram illustrating how memory spaces are mapped to the diagnostic instrument memory during a break.

FIG. 11 is a schematic block diagram of a debug support unit embodying the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a schematic block diagram illustrating a single chip central processing unit (CPU) 100 wherein the present invention is embodied. The CPU 100 has an architecture generally described in "The SPARC.TM. Architecture Manual, Version 8", Sun Microsystems, Inc Jan. 30, 1991, which is incorporated herein by reference. The CPU 100 is a 32-bit wide processing unit. Accordingly, the basic format of its instructions, its data and addresses and its components such as busses, arithmetic and logic unit and registers are 32 bits wide. It is noted, however, that the width is specifically mentioned herein to facilitate discussion and understanding of the preferred embodiment and is not intended to limit the applicability of the present invention.

Like to a conventional computer, CPU 100 fetches instructions and data from an external memory 125. The fetched instructions are processed by an Integer Unit (IU) 110 located within the CPU 100. The term "Integer Unit" is used herein to conform with the terminology set forth by the SPARC Architecture and is not intended as limitation of the applicability of the present invention. The IU 110 generally possesses facilities normally found in conventional computers, such as instruction sequence logic, a program counter, etc.

The CPU 100 is connected to the external memory 125 via a 32-bit wide conventional bus 126, commonly referred to as a system bus. Besides the external memory 125, the system bus 126 also connects the CPU 100 to other peripheral devices, such as disks, monitors, keyboard, mouses, etc. (not shown). The CPU 100 is connected to the system bus 126 through a bus interface unit (BIU) 120. BIU 120 operates to control and buffer signals passing between the CPU 100 and the external memory 125, and between the CPU 100 and other peripheral devices.

According to the preferred embodiment, CPU 100 can directly address up to one terabyte (10.sup.12) of memory, organized into 256 address spaces of 4 gigabytes (10.sup.9) each. These address spaces may or may not overlap in physical memory, depending on the particular system design.

In accordance with the SPARC architecture, a memory access involves an 8-bit Address Space Identifier (ASI) as well as a 32-bit address. The ASI selects one of the address spaces, and the address selects a 32-bit word within that space. The assignment of the address spaces is listed in Table 1.

It is noted from Table 1 that ASI 0.times.9 (hereinafter, "0.times." is used to designate that the number that follows is an hexadecimal number; for example, 0.times.9 means a hexadecimal value of "9") is reserved for storing instructions to be executed by the CPU 100 in supervisor mode and ASI 0.times.B is reserved for storing data to be executed by the CPU 100 in supervisor mode.

FIG. 1 also shows a clock control logic 160 which supplies clock and other control signals needed for the operation of various components within the computer 100. Description of the clock control logic 160 is deemed unnecessary as it is not needed for the understanding and use of the present invention and because the design of the clock control logic 160 is so dependent on the particular design of a CPU.

Similar to a conventional computer, CPU 100 has logic for supporting interrupts, including those initiated externally such as by the peripheral devices, and those caused by executions of instructions. The later interrupts are also called "traps".

Interrupts and traps can be enabled and disabled in CPU 100 as in conventional computers. When enabled, interrupts and traps cause control of the CPU 100 to be transferred (i.e. a process switch) to a service routine. In accordance with the SPARC architecture, control of the CPU 100 is transferred to an address generated by a trap base register (TBR). One field of the TBR contains the base address of a trap dispatch table. Normally, an 8-bit trap type number serves as an offset into this table. Unlike other traps, however, pointers to breakpoint trap routines are not generated from the TBR; rather, they are set to start at 0.times.00000ff0.

Similar to a conventional computer, CPU 100 is provided with means for saving the state of the CPU 100 when an interrupt or trap occurs before entering a service routine. Similar to a conventional computer, it also has means for restoring the CPU 100 to the interrupted state upon return from the service routine.

To reduce access time of instructions/data, CPU 100 employs an hierarchical memory architecture. Under such memory architecture, instructions and data from the external memory 125 are first staged respectively into an 32-bit wide instruction cache 150 and a 32-bit wide data cache 151, both of which are internal to the chip. When the IU 110 needs to fetch memory items such as instructions and data, a check is made to see if they have already been staged to the caches 150, 151. If a copy of the required memory item is already present in the caches (that is, if there is a "cache hit"), the copy in the caches 150, 151 is accessed by the IU 110 and access to the external memory 125 is not made. In other words, if there exists a copy of the data or instructions in the caches 150, 151, no address and access signals are output by the CPU 100 to the system bus 126.

The BIU 120, the IU 110 and the caches 150, 151 are coupled by an internal bus 155 which comprises a signal path for carrying instruction (also called instruction.sub.-- data under the SPARC convention) 155a, a signal path for carrying addresses of instructions (also called instruction.sub.-- addresses under the SPARC convention) 155b, a signal path for carrying addresses of data (also called data.sub.-- addresses under the SPARC convention) 155c, a signal path for carrying data (also called data.sub.-- data under the SPARC convention) 155d and a signal path for carrying control signals 155e.

In accordance with the present invention, CPU 100 also comprises a debug support bus (EMU.sub.-- BUS) 140 for connecting to a diagnostic instrument 145. The availability of EMU.sub.-- BUS 140 allows the diagnostic instrument 145 to set breakpoints in the CPU 100 as well as to obtain a complete trace of instructions processed by the CPU 100.

The EMU.sub.-- BUS 140 occupies ten input/output pins in the CPU chip. The signals assigned to these ten pins are shown schematically in FIG. 2 and their functions are listed in Table 2. The EMU.sub.-- BUS 140 is connected to the CPU 100 via a debug support unit (DSU) 130. The DSU 130 has a plurality of registers, including six on-chip breakpoint descriptor registers. Two of these descriptor registers are provided for setting breakpoints on instruction addresses, two are provided for setting breakpoints on data addresses and two are provided for setting breakpoints on data values. DSU 130 is also provided with a debug control register for controlling a debug operation and a DSU status register for reporting status of a debug operation. Definitions of the various bits in the DSU control register are listed in Table 3. Definitions of the various bits in the DSU status register are listed in Table 4.

The DSU breakpoint descriptor registers, DSU control register and DSU status register are memory mapped to ASI 0.times.1 and their respective addresses are listed in Table 5.

With reference to FIG. 2, a plurality of signals are provided between the DSU 130 and the IU 110, including those signals listed in Table 6.

One important debugging tool provided under the preferred embodiment of the present invention is the ability to trace a sequence of instructions executed by the CPU 100. The instructions are traced by their respective addresses, which can be obtained either from the internal bus of the addresses sent by the IU 110 to the internal cache 150 during an instruction fetch, or from the program counter (PC) of the CPU 100.

To be effective for debugging, it is preferable for a trace to contain all or almost all of the instruction addresses. It is also preferably that trace be performed with minimal intrusion to the operation of the CPU 100 (for example, slowing it down).

It is recalled that CPU 100 uses a 32-bit wide address to access instructions. However, it is also recalled that in order to minimize the number of I/O pins on the chip, only ten input/output pins are provided for the EMU.sub.-- BUS 140. Of these 10 pins, eight pins are assigned for communicating data/addresses/instructions between the CPU 100 and the diagnostic instrument 145. Therefore, even if all these eight pins are used, at least four cycles are required to output one address. However, the highest throughput of the CPU 100 is one instruction per cycle. If the throughput of the CPU 100 is to be maintained during a trace operation, the trace would omit at least three addresses for every address output (i.e. the trace is incomplete). However, a trace with such a gap may not be effective for debugging purposes because important information may have left out