Patent Application
20060048011
The present invention relates to systems for diagnosing problems in microprocessor computing systems. Specifically, a system which provides performance profiling through the cooperation of debug hardware and a performance monitor of a microprocessor system is disclosed.
Microprocessor systems are used in applications where specific software modules are executed having real-time performance constraints that are timing critical. For example, in a cellular telephone application that has voice recognition capabilities, the audio must be saved and processed in sufficient time to keep up with human speech patterns. In applications such as a hard disk controller, the magnetic head must be tracked reliably in real-time to prevent damage to the disk being written with data. Application software which is subject to these real-time system constraints can be verified in either a simulation or emulation of the application software. This requires a time consuming and costly approach to recreate a model of the system, including all real world variables that may be encountered when the application is executed. Further, because of the cost constraints, the model may have limited throughput lessening the value of this approach to validating the system against real-time constraints.
Many microprocessing systems include performance monitors which can measure events identified through starting and end points of code being executed under test. This requires that the application source code be invasively modified to include the starting and end points for the monitor to begin and end analysis of code being executed. Further, it is generally difficult to filter performance monitor data unless the region within which the events are counted is precisely defined.
As an additional technique for verifying performance against real-time constraints, a trace port may be added to the microprocessor system which provides a method to analyze software execution through an external logic analyzer or other digital tool. The additional equipment and software necessary to post process any data recovered through the trace port provides an additional cost which is objectionable.
U.S. Pat. No. 5,774,724 describes a type of system which is used to monitor the performance of a computing system with improved granularity. The earlier patent describes the use of a single break point register where both a start and stop break point instruction address are inserted to define a useful address range for monitoring software execution. The system break point register includes a start break point, and when an interrupt occurs when the start address has been detected in the instruction address register, the interrupt handler reprograms the break point register with a stop address. The interrupt occurs during execution of the code being counted by the performance monitor hardware thereby polluting the performance results of the executed code. A code module may also have multiple entry points that a single start break point register cannot detect, and events may not be counted since the code region being monitored may not have entered at the start address. Further, the code module may have multiple exit points that a single stop point register cannot detect. This would result in an over counting of events since the counting continues until the module is re-entered and exits through the identified stop break point address. The use of interrupts also reduces computational bandwidth for the application and is otherwise invasive. Additionally, the system must alter the source code of the application which is then recompiled into the code image.
Because of these and other disadvantages, the present invention has been provided which makes use of the existing debug hardware and performance monitor, and which does not require the use of interrupts and the interrupt handler.
A method and apparatus are disclosed which provides for performance monitoring during execution of a microprocessor program. An interface is provided between on board debug hardware and an on board performance monitor for selecting events which occur during execution of the program defining a beginning and end to a monitoring interval. The processor on board performance monitor is enabled and disabled by an enable and disable signal produced at the beginning and end of the monitoring interval.
In accordance with a preferred embodiment of the invention, the interface includes a programmable performance monitor debug register which identifies a plurality of events which occur during program execution. Each of the debug hardware detected events is supplied to first and second multiplexers. When these events occur, a first and second multiplexer are enabled by the performance monitor debug register to generate the enable and disable signal.
Referring now to
The microprocessor system of
The function of the performance monitor is to monitor and count pre-selected events such as processor clocks, cache misses, instructions dispatched to a particular execution unit, instruction per cycle time of execution, etc. The performance monitor permits a real-time evaluation of software code during execution and facilitates increased system performance by enabling the design of more efficient processors and software. The typical performance monitor 32 includes counter registers which can be used to time events or count events produced during program execution.
In accordance with a preferred embodiment of the invention, an interface 33 is provided between the debug hardware 34 and performance monitor 32 as shown more particularly in
As shown in TABLE 1, the start addresses 19:23 can hold up-to five bits which can identify a debug event which marks the beginning of a performance monitoring interval of a program being executed by the microprocessor system. The performance monitor is enabled by a start signal when one of the events defined in locations 19:23 is detected by the debug hardware. These events may include execution of a particular instruction address IACI, IAC2, IAC3 or IAC4. A similar register, the Debug Control Hardware Register DCHR, in the debug hardware is programmed to control a comparison operation between the instruction address register for the instruction to be executed and a selected instruction address. As will be evident from the description of the debug hardware, the selected instruction address can be programmed in the debug hardware for each of IACI, IAC2, IAC3 or IAC4 which identifies the selected instruction address to the debug hardware.
Other events identified in Table 1 which may initiate monitoring include data being read or being written (DAC1R, DAC1W, etc.), the execution of a trap instruction (Trap), an interrupt (Intrp) and a branch taken (BT). The selected address for defining the debug event is programmed in a data register of the debug hardware by the user.
The PMDBCR register further includes a stop event identified in addresses 27:31 marking the end of the monitored portion of the program execution which generates a stop signal for the performance monitor. These also include up-to four instruction addresses (IAC1-IAC4), data addresses (DAC1-DAC2, both written and read), Trap, interrupt (Intrp) and a branch taken (BT). The contents of the performance monitor debug control register of Table 1 are exemplary only. Other events identifying the execution sequence to be monitored may be identified in the PMDBCR register as a start event, and a stop event.
An enable and disable signal is provided by each of multiplexers 36 and 37 when the defined start and stop event is encountered by the debug hardware to provide start/stop signals for the performance monitor.
The conventional on board debug hardware is illustrated in schematic form in
The selection of some debug events, such as an instruction which is being executed IAC1, and IAC2, or data being read or written to, DAC1, DAC2, require the selected data or address to be programmed in the debug hardware. If the IAC1 bit in location 14 is set, an instruction address is programmed into register 55. The system program counter PC is monitored, and when the selected instruction is executed, compare logic 56 associated with register 55 issues debug event 1. When the bit in location 15 of DHCR 51 is set to 1, a second selected instruction IAC2, whose address is programmed into register 57, is monitored. When the compare logic 58 associated with register 57 indicates that the system PC has produced the selected instruction address, debug event 2 is generated.
Each of these two debug events require the programmer to enter an address of the particular instruction IAC1 and IAC2 to be monitored into registers 55, 57. When the processor executes the identified instruction, debug event 1 or debug event 2 is produced from compare logic 56 and 58 associated with each of the registers 55 and 57.
The debug hardware control register (DHBCR) 51 and programming of the debug hardware is described more particularly in Chapter 8 of the “PowerPC PPC403 GB Embedded Controller User's Manual,” which is published by the International Business Machines Corporation. As set forth in the foregoing user's manual, still other events may be defined by the debug control register 51 for monitoring events which occur during execution of a program by the microprocessor system.
Table 2 is an example of how the debug hardware is programmed to monitor a common subroutine instruction sequence. The debug event for starting monitoring is a beginning IAC1 address of 1020, and an ending IAC2 address 1221. A programming step for setting the contents of the PMDCR is shown so that the appropriate data is entered in locations 19-23 and 27-31 to identify a beginning instruction address and an ending instruction address. Similarly, the debug DHCR register 41 and the respective IAC1, IAC 2 registers 55 and 57 are programmed with the instructions MTSPR
WHERE:
In this scenario, the debug hardware will provide an output from the compare logic 56 and 58 when the appropriate instruction has been fetched for execution by the program being monitored.
It should be noted that if execution of a program leaves the subroutine, the interval continues until execution returns and the IAC2 instruction is executed.
The preferred embodiment of the invention permits the debug hardware to interface with the performance monitor using the existing debug hardware as well as the exiting performance monitor. The foregoing is non-invasive, in that no extra instructions needs to be placed in the application source code, nor does any interrupt handling become necessary to begin monitoring any particular range of events.
The foregoing description of the invention illustrates and describes the present invention. Additionally, the disclosure shows and describes only the preferred embodiments of the invention in the context of a performance profiling of microprocessor systems using debug hardware and performance monitor, but, as mentioned above, it is to be understood that the invention is capable of use in various other combinations, modifications, and environments and is capable of changes or modifications within the scope of the inventive concept as expressed herein, commensurate with the above teachings and/or the skill or knowledge of the relevant art. The embodiments described hereinabove are further intended to explain best modes known of practicing the invention and to enable others skilled in the art to utilize the invention in such, or other, embodiments and with the various modifications required by the particular applications or uses of the invention. Accordingly, the description is not intended to limit the invention to the form or application disclosed herein. Also, it is intended that the appended claims be construed to include alternative embodiments.
