Power profiling system and method for correlating runtime information

[0001] This application is related to and claims priority under 35 USC §119 (e)(1) to Provisional Application Serial No. 60/369,596, (attorney docket TI-34344) “Power Profiler” filed on Apr. 4, 2002 and Provisional Application Serial No. 64/401,128, (attorney docket TI-34344PS1) “Power Profiler” filed on Aug. 5, 2002. This application is also related to co-pending applications Ser. No. XX/XXX,XXX (attorney docket TI-34344) “Method And Apparatus for Non-Obtrusive Power Profiling” and Ser. No. XX/XXX,XXX (attorney docket TI-35011) “System and Method for Power Profiling of Tasks.”

FIELD OF THE INVENTION

[0002] This invention generally relates to microprocessors, and more specifically to improvements in profiling the power consumption of a microprocessor application.

BACKGROUND OF THE INVENTION

[0003] Power is a critical constraint in the design of embedded applications. For example, in the world of portable electronics, one of the key concerns for consumers is the time they can operate their devices on battery power. Therefore, a top priority in the portable electronics industry is designing low power devices. To support this endeavor, various techniques for measuring the power consumption of these applications have been developed. Many of these techniques focus solely on the hardware components of the application and ignore the impact of the software components on the overall power consumption.

[0004] Software impacts power consumption at various design levels. At the highest level, the partitioning of application functionality between hardware and software has implications on total power consumption. The choice of algorithm and other higher-level design decisions for the software components also affect system power consumption. The choice of programming language constructs in implementing the design also affects the power cost of the software.

[0005] Some techniques, with varying levels of effectiveness, have been developed to analyze power consumption from the software perspective. For example, some estimation techniques are based on architectural level analysis of the processor. Power costs are assigned to architectural components such as datapath execution units, control units, and memory elements. Then, the power cost of a hardware module is determined by the estimated average capacitance that would switch when the module is activated based on a statistical power model. Activity factors for the modules are obtained from functional simulation over typical input streams. Power costs are assigned to individual modules, in isolation from one another, ignoring the correlations between the activities of different modules during execution of real programs.

[0006] In another technique, power analysis is done at the instruction level. In this type of analysis, power models of programs are created from a set of base costs for the instructions in the processor instruction set and the power costs of inter-instructions effects such as stalls and cache misses. These models require the generation of the base instruction costs and the inter-instruction effects on a processor-by-processor basis and their accuracy is limited by the accuracy in determining the impact of the dynamic behavior of an application.

[0007] In addition to these model-based techniques, some methods for measuring power consumption during actual execution of the embedded application at varying levels of granularity have been developed. In one method, the power consumption of a selected single range of instructions can be measured. In another, the power consumption of selected functions can be measured but the application is halted after each function is executed.

SUMMARY OF THE INVENTION

[0008] The present invention seeks to provide systems and methods for measuring the power consumption of a software unit of an embedded application in real-time and non-real-time. An illustrative method for real-time power profiling comprises instrumenting an embedded application to select software units for which power consumption information is to be collected. This power consumption information, in the form of execution data and power measurements, is collected while the application is executing and passed back to a host system without halting the execution. The execution data is correlated with the power measurement data to determine power consumption for each selected software unit. In an alternative method, the software units may be functions of a high level programming language.

[0009] Another illustrative method provides for non-real-time power profiling of a software unit of an embedded application. In this method, the embedded application is instrumented to select those software units for which power consumption information is to be collected. This power consumption information, in the form of execution data and power measurements, is collected while the application is executing. The power consumption information is received on a host system and the execution data is correlated with the power measurement data to determine the power consumption of each selected software unit. In an alternative method, the software units may be functions of a high level programming language.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Particular embodiments in accordance with the invention will now be described, by way of example only, and with reference to the accompanying drawings in which:

[0011] FIGS. <b>1</b>A-<b>1</b>C are block diagrams of systems for power profiling of embedded applications;

[0012]FIG. 2 is a block diagram of emulation support circuitry;

[0013]FIG. 3 is an embodiment of a trigger latch;

[0014]FIG. 4 illustrates modifications to a target system to support power profiling;

[0015]FIG. 5 shows a block diagram of target system appropriately modified and connected up to measure power consumption;

[0016]FIG. 6 is a power profiling flowchart;

[0017] FIGS. <b>7</b>-<b>14</b>B illustrate various displays of an embodiment of a power profiling system;

[0018] FIGS. <b>15</b>-<b>17</b>, <b>19</b>, <b>21</b>-<b>24</b>, and <b>26</b>-<b>30</b> are flowgraphs of various methods of power profiling; and

[0019]FIG. 25 illustrates the data structures created by a power profiling method.

[0020] Corresponding numerals and symbols in the different figures and tables refer to corresponding parts unless otherwise indicated.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0021] Systems and methods for improved power profiling of embedded applications are described below. These inventions provide the ability to measure the power consumption of an embedded application at varying levels of software granularity as the application is executing on the target hardware. Methods and apparatus are provided to permit such measurements in both real-time and non-real-time.

[0022] The embodiments of the systems and methods presented below are exemplary and are presented in relation to target hardware incorporating digital signal processing technology and advanced emulation technology. Details of the general construction of such digital systems are well known and may be found readily elsewhere. For example, U.S. Pat. No. 5,072,418 issued to Frederick Boutaud, et al, describes a digital signal processor (DSP) in detail, U.S. Pat. No. 5,329,471 issued to Gary Swoboda, et al, describes in detail how to test and emulate a DSP. Other embodiments using differing processor and/or emulation technology should be apparent to one skilled in the art.

[0023] FIGS. <b>1</b>A-<b>1</b>C present various embodiments of a system for power profiling of an embedded application. Each system comprises host computer <b>1000</b> connected to target system <b>1018</b> through emulation controller <b>1004</b>. Host computer <b>1000</b> provides an integrated software development environment including debug software, a compiler, and software for sending and receiving information between the software development environment and target system <b>1018</b> through emulator <b>1004</b>. Typically, emulation controller <b>1004</b> is connected to target system <b>1018</b> through a JTAG (IEEE 1149.1) test access port <b>1008</b>. The integrated software development environment also comprises power profiling software <b>1002</b>.

[0024] In FIGS. 1A and 1C, target system <b>1018</b> is comprised of at least one digital signal processor (DSP) <b>1010</b>. DSP <b>1010</b> comprises emulation circuitry providing a standard JTAG debug interface with two additional terminals or pins (interchangeably referred to as nET<b>1</b> and nET<b>2</b> or EMU<b>0</b> and EMU<b>1</b>) supporting various extended debugging capabilities. Such emulation circuitry is well known in the art and is described in detail in U.S. Pat. No. 5,828,824 issued to Gary Swoboda. These terminals may be used to export trigger signals from DSP <b>1010</b> without interfering with any other functionality of the standard JTAG debug interface. These terminals are made available for triggering a power measurement device by latch <b>1006</b> residing between JTAG port <b>1008</b> and emulation controller <b>1004</b>.

[0025] The emulation circuitry of DSP <b>1010</b> further comprises emulation components that may be programmed to generate the trigger signals. FIG. 2 presents one possible configuration of emulation components. These emulation components comprise logic that monitors activity such as event detector <b>201</b> and auxiliary event detector <b>202</b>, logic that records activity such as counters and state machines (block <b>203</b>), logic that permits pin sharing such as scan adapter <b>205</b> and pin manager <b>204</b>, logic that imports data such as RTDX <b>207</b>, logic that accelerates transmission such as local oscillator <b>209</b>, logic that exports data such as RTDX <b>207</b> and trace export <b>208</b>, logic that captures execution activity such as trace collection <b>210</b>, and logic that directs traffic such as trigger builder <b>206</b>.

[0026] In FIG. 1B, target system <b>1018</b> is comprised of at least one digital signal processor (DSP) <b>1024</b>. Circuitry connected to an I/O pin of DSP <b>1024</b> is provided to permit the use of the pin for transmitting trigger signals to a power measurement device.

[0027] Various types of power measurement devices, e.g. oscilloscopes, multimeters, special purpose boards, etc., and means for connecting the devices to the system may be employed. In FIG. 1A, the power measurement device is oscilloscope <b>1012</b>. Oscilloscope <b>1012</b> is connected by current probe <b>1016</b> to a power measurement point on target system <b>1018</b>. It receives signals to start and stop power measurements via trigger <b>1014</b> connected to EMU<b>0</b> and EMU<b>1</b> on target system <b>1018</b> via latch <b>1006</b>. Oscilloscope <b>1012</b> is also connected to host computer <b>1000</b> via General Purpose Interface Board (GPIB) <b>1026</b> to permit collection of power measurement data. In FIG. 1B, the power measurement device is again oscilloscope <b>1012</b> but here trigger <b>1014</b> is connected to a pin of DSP <b>1024</b>. The DSP pin may be an XF pin, any general purpose I/O (GPIO) pin or any user configurable pin that can be controlled through software. The connection to host computer <b>1000</b> is also GPIB <b>1026</b>. In FIG. 1C, the power measurement device is special purpose power measurement board <b>1022</b> with the capability to capture, amplify, convert, and store power data. Measurement board <b>1022</b> is connected by current probe <b>1016</b> to a power measurement point on target system <b>1018</b>. It receives signals to start and stop power measurements via trigger <b>1014</b> connected to EMU<b>0</b> and EMU<b>1</b> on target system <b>1018</b> via latch <b>1006</b>. Measurement board <b>1022</b> is connected to host computer <b>1000</b> via parallel port interface <b>1028</b> to permit collection of power measurement data. Alternatively, measurement board <b>1022</b> may also be connected to host computer <b>1000</b> with a USB connection.

[0028]FIG. 3 illustrates an embodiment of latch <b>1006</b>. When the emulation circuitry of DSP <b>1010</b> is programmed to generate trigger signals for power measurement, a pulse on EMU<b>0</b> will cause trigger <b>1014</b> to latch and send a start indication to the connected power measurement device. A pulse on EMU<b>1</b> will clear trigger <b>1014</b> telling the connected power measurement device to terminate power data collection.

[0029] To perform power measurements, target system <b>1018</b> may need to be modified to permit connection of current probe <b>1016</b> at an appropriate power measurement point. FIG. 4 illustrates a typical modification. Wire loop <b>4000</b>, which is kept as short as possible while still accommodating the connection of current probe <b>1016</b>, is placed between the output of power supply <b>4002</b> and load <b>4004</b>. If there are any large capacitors on the output of power supply <b>4002</b>, they should be on the same side as the output of the power supply. Such capacitors filter the output of the power supply and slow down its response to increases or decreases in the current demand of load <b>4004</b>. Placing these capacitors on the input side of current probe <b>1016</b> will permit the inclusion of any additional current that such capacitors add as current demands change. FIG. 5 shows a block diagram of target system <b>1018</b> appropriately modified and connected up to measure power consumption. Additional background information regarding setting up a power profiling system such as those described in the above embodiments is provided in Texas Instruments Incorporated application report SPRA074 entitled “Target System Power Profiling Via Code Composer Studio.” This application report is available at http://www-s.ti.com/sc/techlit/spra074 and is incorporated herein by reference.

[0030] Power profiling software <b>1002</b>, in conjunction with other software executing on the host computer, provides the user interface for setting up power profiling operations and for displaying the resulting power measurement data. In the preferred embodiment, three modes of power profiling are provided: single-range real-time (SR), multifunction non-real-time (MNR), and multifunction real-time (MR).

[0031] SR profiling mode allows the user to measure the power consumed by an application while it is executing between two user-selected addresses. This profiling is done in real-time, meaning that target system <b>1018</b> is not halted between the two selected addresses. The resulting power measurement data is displayed when execution is halted. MNR and MR profiling modes permit power measurement of user-selected functions in the embedded application. In MNR profiling mode, the application is halted after power measurement data is collected for a selected function and the resulting power measurement data is displayed. In MR profiling mode, power measurement data for each selected function is collected with minimal impact while the application is executing and is displayed when the application completes execution and/or is halted.

[0032]FIG. 6 presents an exemplary flow of operation for profiling power consumption of target system <b>1018</b>. The steps of this flow of operation are used as a framework in the following text to illustrate various innovative aspects of the present inventions. This example is presented using the user interface of an integrated software development system comprising a power profiling plugin, Code Composer Studio, developed by Texas Instruments Incorporated. However, other embodiments will be apparent to one skilled in the art. Following the discussion of this exemplary flow of operation, additional details regarding the operation of each power profiling mode are presented in self-titled sections.

[0033] At step <b>6000</b>, power profiling software <b>1002</b> is invoked. FIG. 7 illustrates selecting the Power Dissipation option from the Profiler drop-down menu on the main screen to invoke a power profiling window. FIGS. 8A, 8B, and <b>8</b>C present power profiling window <b>8000</b>. The left side of power profiling window <b>8000</b> contains buttons for selecting a mode of instrumentation, displaying power measurement graphs, and selecting various options. When the Mode button is selected, menu <b>8006</b> is presented to permit the user to select the desired mode of instrumentation. When the Options button is selected, menu <b>8004</b> is presented to permit the user to do such things as modifying the settings, clearing or saving results, or saving raw data. Title bar <b>8002</b> presents the column titles for the information that power profiling software <b>1002</b> collects and displays. This information includes the selected address range or function associated with the data, the total power in milliJoules consumed during execution, including any called functions (inclusive count), the total power consumed during execution of the selected function, excluding any called functions (exclusive count), and the maximum and average power values measured within the address range/function. If status data, i.e., their on/off status, is collected for peripherals such as timers, multichannel buffered serial ports and direct memory access channels, window <b>8000</b> will also show that information.

[0034] The next step, <b>6002</b>, is to perform some general setup of the profiling software. FIG. 9 illustrates settings window <b>9000</b> which is invoked by selecting the Settings entry of menu <b>8004</b> as illustrated in FIG. 8C. Using data collection options <b>9004</b>, the user may select whether the data is to be collected in milliwatts (power) or milliAmps (current). Collecting data as milliAmps is useful when the voltage changes during execution, i.e., the application is performing dynamic voltage scaling. Using triggering options <b>9002</b>, the user may select the trigger pin to be used to trigger power measurement device <b>1012</b> or <b>1022</b> and the voltage of the power supply at the point where current is to be measured on target system <b>1018</b>. The triggering option selected must correspond to the capabilities of target system <b>1018</b>. For example, if the power system configuration is that of FIG. 1A or FIG. 1C, EMU<b>0</b>/EMU<b>1</b> may be selected as the triggering option. If the configuration is that of FIG. 1B, a DSP pin may be selected as the triggering option. The voltage entered will be multiplied with the measured current to compute power values.

[0035] At step <b>6004</b>, the power measurement device is initialized. In this embodiment, the device is oscilloscope <b>1012</b>. As FIG. 10 illustrates, scope tab <b>9002</b> of control properties window <b>9000</b> provides options for selecting the channel for collecting data from current probe <b>1016</b> and for the trigger channel of oscilloscope <b>1012</b> connected to trigger <b>1014</b>.

[0036] At step <b>6006</b>, the user may elect to enable or disable collection of peripheral status data. As FIG. 11 shows, the user may select peripherals tab <b>9004</b> of control properties window <b>9000</b> to access this option. The user may specify the number of peripherals for which status information is to be collected and information about each peripheral. Setting the number of peripherals to be 0 denotes that no peripheral information is to be collected.

[0037] In steps <b>6008</b> and <b>6010</b>, the embedded application is modified to support the mode of power profiling the user wants to use. For all three power profiling modes, a target system specific runtime support library must be added. Each runtime support library provides initialization routines for the selected triggering option and trigger functions for doing the actual triggering of the power measurement device and to do any other special processing required by the power profiling mode.

[0038] If the user wants to do SR power profiling, the beginning and end points of the range of instructions to be profiled is set at this time. FIG. 12 illustrates how the user sets this profiling range. First, the user selects the source code file of the embedded application where the profiling is to be initiated and its contents are displayed in pane <b>1200</b>. The user places the mouse on the source code line where profiling is to be started and right clicks. Popup menu <b>1202</b> is presented. The user selects the Power Profiler option from the menu and the Begin Power Profiling Range option from profiler submenu <b>1204</b>. Analogous actions are taken to set the end of the profiling range. In response to these user actions, power profiling software <b>1002</b> inserts calls to the required trigger functions provided by the runtime support library in the source code of the embedded application at the selected points.

[0039] For MNR and MR power profiling modes, a special compiler option is used to compile the embedded application. This option instructs the compiler to insert NOP instructions at the beginning and end of each function in the application. The number of NOPs inserted is target dependent and based on the calling sequence of the triggering support functions. Also, the application is linked with a special linker option that forces the required support code to be included. These special options eliminate any requirement for the application developer to alter the application source code manually to provide explicit references to the triggering support routines. If MR mode is to be used, a support library for transferring data from target system <b>1018</b> to host system <b>1000</b> must also be included in the application. For the embodiments of FIGS. <b>1</b>A-<b>1</b>C, the data transfer mechanism is industry standard RTDX.

[0040] Once the embedded application has been appropriately modified as described above, it is recompiled, relinked, and downloaded to target system <b>1018</b>. At step <b>6012</b>, the instrumentation mode is selected. FIG. 8B illustrates the popup menu for selecting the power measurement instrumentation mode presented when the user selects mode button <b>8002</b> in power profiling window <b>8000</b>. At this point, power profiling software <b>1002</b> performs any initialization that may be required for the selected mode. If MNR or MR profiling mode is selected at step <b>6012</b>, the embedded application is automatically instrumented by power profiling software <b>1002</b>. This instrumentation comprises replacing the NOPs inserted by the compiler at the beginning and end of each function with the calling sequences for the required trigger functions. Once the application is instrumented, the user may optionally select functions not to measure at step <b>6016</b> if MR mode is selected or at step <b>6018</b> if MNR mode is selected. Power profiling software <b>1002</b> uninstruments the functions selected at step <b>6016</b> or <b>6018</b> by replacing the inserted calling sequences with NOP instructions.

[0041] At step <b>6020</b>, the embedded application is executed. Power measurement data and other execution data is collected, correlated if necessary, and presented to the user. FIGS. 13 and 14 present examples of power measurement data collected from the execution of an embedded application instrumented for one of the multi-function power profiling modes in tabular and graphical formats, respectively.

[0042] Multi-Function Real-Time Profiling

[0043] From a high level, in an embodiment, the control flow for multi-function real-time profiling is as follows:

[0044] 1. The user prepares the embedded application for MR profiling as previously described.

[0045] 2. The user selects the MR profiling option.

[0046] 3. Power profiling software <b>1002</b> instruments each function to be profiled by replacing the compiler inserted NOPs that are located in the prologue and epilogue code of each function with calls to a profile support routine _TSPP_MRtriggerXXX (where XXX denotes the triggering option selected in step <b>6002</b>). By default, all functions that were compiled with special compiler mode are instrumented. Following the initial instrumentation, the user can remove individual functions from the list of profiled functions (i.e. select functions to be uninstrumented).

[0047] 4. The user starts execution of target system <b>1018</b> by issuing a Run command.

[0048] 5. During program execution, any call instruction that was inserted by the profiler as part of the code instrumentation will transfer control to the support routine _TSPP_MRtriggerXXX when it is executed. Each invocation of the support routine will cause steps 6-9 described below to occur.

[0049] 6. The support routine clears trigger <b>1014</b>, indicating the end of the previous power measurement.

[0050] 7. The support routine collects execution data. It determines its return address (which will be a program counter value of an instruction that is part of the function that was being profiled) in a target-dependent fashion. This return address will later be used by the profiler (in step 13) to correlate power measurements to specific functions. Once the return address is determined, the support routine will transfer this program counter value to host computer <b>1000</b> using RTDX. In addition to transferring the program counter value, other information may also be transferred. For example, the current state (on/off) of the on-chip peripherals may also be transferred.

[0051] 8. The support routine sets trigger <b>1014</b>, indicating the start of the next power measurement.

[0052] 9. The support routine returns back to the calling function to continue execution of the embedded application.

[0053] 10. While the application is executing, power profiling software <b>1002</b> will retrieve the execution data that is passed to host computer <b>1000</b> from target system <b>1018</b>. As mentioned above in step 7, this data will include program counter values and possibly other information, such as on-chip peripheral information.

[0054] 11. Either while application is executing, or when execution completes, power profiling software <b>1002</b> will retrieve power measurement data from the power measurement device. If the measurement device is oscilloscope <b>1012</b>, the set of power measurements will be retrieved when the application completes execution. If the measurement device is high-speed measurement board <b>1022</b>, the set of power measurements may be retrieved while the application is still running.

[0055] 12. When execution completes, power profiling software <b>1002</b> retrieves any remaining execution data stored in its internal buffer on target system <b>1018</b>.

[0056] 13. After retrieving the execution data (in step 10 and possibly step 12) and the power measurement data (in step 11), power profiling software <b>1002</b> correlates specific power measurements to specific functions by reconstructing the call stack from the execution data using the method described below.

[0057] 14. Power profiling software <b>1002</b> then displays the results as illustrated by FIGS. 13 and 14.

[0058]FIG. 15 presents of a flowgraph of a method for correlating power measurement data to the function that was executing at the time the measurement was taken. When the embedded application finishes execution, power profiling software <b>1002</b> has a set of power measurements, in the order they were taken, and a set of program counter values that specifies the execution order of the functions. This information is used to reconstruct the runtime call stack, and as a result, correlate a specific power measurement to the exact function that was executing when the power measurement was taken.

[0059] At step <b>1500</b>, the identity of the function associated with a program counter value is determined. At step <b>1502</b>, a test is made to determine if the program counter value corresponds to the entry or exit of the identified function. If it is an entry point, then step <b>1504</b> is executed next. Here, a check is made to determine if the call stack is empty. If it is, then step <b>1508</b> is executed and the function identifier is pushed on top of the stack. Processing of the set of program counter values then continues at step <b>1500</b> with the next program counter value. If the call stack is not empty at step <b>1504</b>, then the next power measurement in the time ordered set of power measurements is attributed to the function on top of the call stack and processing continues at step <b>1508</b>. If the program counter value is not an entry point at step <b>1502</b>, then it is an exit point. At step <b>1510</b>, the function at the top of the call stack is popped off the stack and the next power measurement in the set of power measurements is attributed to that function. Processing then continues at step <b>1500</b> with the next program counter value.

[0060] Consider the application of this correlation method to the example C program in Table 1. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="42PT" align="left" /><colspec colname="4" colwidth="77PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="4" align="center">TABLE 1</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>main ()</entry><entry>{</entry><entry>/* </entry><entry>PC1 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . . </entry><entry>/* measurement M1 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><tbody valign="top"><row><entry /><entry>func1 ()</entry><entry>;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . . </entry><entry>/* measurement M5 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry><entry>/* PC6 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="14PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry /><entry>func1 ()</entry><entry>{</entry><entry>/* PC2 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . .</entry><entry>/* measurement M2 */</entry></row><row><entry /><entry>func2 () ;</entry></row><row><entry /><entry>. . . . </entry><entry>/* measurement M4 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry><entry>/* PC5 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="14PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry /><entry>func2 ()</entry><entry>{</entry><entry>/* PC3 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . . </entry><entry>/* measurement M3 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry><entry>/* PC4 */</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0061] In this example, three functions are executed, main, func<b>1</b>, and func<b>2</b>. Assuming that all three functions are profiled, _TSPP_MRtriggerXXX is called six times. This causes six program counter values (PC1-PC6) to be transferred from the target to the host. The ordering of these program counter values corresponds to the execution order of the functions. This example also produces five separate power measurements (M1-M5). The ordering of the measurements also corresponds to the execution order of the functions. Note that there is always one more program counter value than there are power measurements. This is because no measurement is taken prior to entering the first function profiled (main in this example).

[0062] Table 2 presents the initial state of the call stack and the sets of program counter values and power measurements for the example of Table 1. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 2</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>&lt;empty&gt;</entry></row><row><entry /><entry>Program Counter Value Set</entry><entry>PC1, PC2, PC3, PC4, PC5, PC6</entry></row><row><entry /><entry>Power Measurement Set</entry><entry>M1, M2, M3, M4, M5</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0063] First, the identity of the function associated with PC1, in this case main, is determined. PC1 corresponds to the entry point for main, so step <b>1504</b> is executed. The call stack is initially empty so step <b>1506</b> is skipped and no power measurement is consumed. The function main is pushed onto the call stack. Table 3 illustrates the state of the call stack and the measurement sets after the processing of PC1. <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 3</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>main</entry></row><row><entry /><entry>Program Counter Value Set</entry><entry>PC2, PC3, PC4, PC5, PC6</entry></row><row><entry /><entry>Power Measurement Set</entry><entry>M1, M2, M3, M4 M5</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0064] Resuming the method at step <b>1500</b>, the function associated with PC2, func<b>1</b>, is determined. PC2 corresponds to the entry point for func<b>2</b> (step <b>1502</b>), so processing proceeds to step <b>1504</b>. The call stack is not empty, so power measurement M1 is attributed to the function on top of the call stack, main, at step <b>1506</b>. Func<b>1</b> is then pushed on top of the call stack at step <b>1508</b>. Table 4 illustrates the state of the call stack and the measurement sets after the processing of PC2. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="105PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 4</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>func1, main</entry></row><row><entry /><entry>Program Counter Value Set</entry><entry>PC3, PC4, PC5, PC6</entry></row><row><entry /><entry>Power Measurement Set</entry><entry>M2, M3, M4 M5</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0065] At step <b>1500</b>, func<b>2</b> is found to be the function associated with PC3. Again, PC3 is an entry point and the call stack is not empty, so power measurement M2 is attributed to the function at the top of the stack, func<b>1</b>. Func<b>2</b> is then pushed onto the stack. Table 5 illustrates the state of the call stack and the measurement sets after the processing of PC3. <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="105PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 5</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>func2, func1, main</entry></row><row><entry /><entry>Program Counter Value Set</entry><entry>PC4, PC5, PC6</entry></row><row><entry /><entry>Power Measurement Set</entry><entry>M3, M4, M5</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0066] Resuming at step <b>1500</b>, PC4 is determined to be associated with func<b>2</b>. At step <b>1502</b>, it is found to be an exit point rather than an entry point, so step <b>1510</b> is executed. The function identifier at the top of the stack, func<b>2</b>, is popped and the power measurement M3 is attributed to it. Table 6 illustrates the state of the call stack and the measurement sets after the processing of PC4. <tables id="TABLE-US-00006" num="6"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 6</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>func1, main</entry></row><row><entry /><entry>Program Counter Value Set</entry><entry>PC5, PC6</entry></row><row><entry /><entry>Power Measurement Set</entry><entry>M4, M5</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0067] Returning to step <b>1500</b>, PC5 is now processed. PC5 corresponds to the exit point for func<b>1</b>, so again step <b>1510</b> is executed. The function identifier at the top of the stack, func<b>1</b>, is popped and power measurement M4 is attributed to it. Table 7 illustrates the state of the call stack and the measurement sets after the processing of PC5. <tables id="TABLE-US-00007" num="7"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="63PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 7</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>main</entry></row><row><entry /><entry>Program Counter Value Set</entry><entry>PC6</entry></row><row><entry /><entry>Power Measurement Set</entry><entry>M5</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0068] Returning to step <b>1500</b>, PC6 is now processed. PC6 corresponds to the exit point for main, so again step <b>1510</b> is executed. The function identifier at the top of the stack, main, is popped and power measurement M5 is attributed to it. Table 8 illustrates the state of the call stack and the measurement sets after the processing of PC6. <tables id="TABLE-US-00008" num="8"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="70PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 8</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>&lt;empty&gt;</entry></row><row><entry /><entry>Program Counter Value Set</entry><entry>&lt;empty&gt;</entry></row><row><entry /><entry>Power Measurement Set</entry><entry>&lt;empty&gt;</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0069] Multi-Function Non-Real-Time Profiling

[0070] From a high level, in an embodiment, the control flow for multi-function non real-time profiling is as follows:

[0071] 1. The user prepares the embedded application for MNR profiling as previously described.

[0072] 2. The user selects the MNR profiling option.

[0073] 3. Power profiling software <b>1002</b> instruments each function that will be profiled. That is, the power profiler replaces the compiler inserted NOPs that are located in the prologue and epilogue code of each function with calls to the profile support routine TSPP_MNRtriggerXXX. Following the initial instrumentation, the user can remove individual functions from the list of profiled functions (i.e. select functions to be uninstrumented). As part of the instrumentation, power profiling software <b>1002</b> sets a breakpoint at the address specified by the symbol _TSPP_MNRstopXXX.

[0074] 4. The user starts execution of target system <b>1018</b>.

[0075] 5. During program execution, any call that was inserted as part of the code instrumentation will transfer control to the support routine _TSPP_MNRtriggerXXX when it is executed. Each invocation of the support routine will cause steps 6-12 described below to occur.

[0076] 6. The support routine clears trigger <b>1014</b>, indicating the end of the previous power measurement.

[0077] 7. The support routine hits the breakpoint, which was set in step 3, at the address specified by the symbol _TSPP_MNRstopXXX. At this point execution is halted.

[0078] 8. The power profiler reads the power measurement from the measurement device and attributes the measurement to the correct function using a correlation method. If peripheral status is also being gathered, profiling software <b>1002</b> reads the status of the peripherals from the target and updates the function's peripheral usage information.

[0079] 9. Power profiling software <b>1002</b> then updates the results displayed in Pane <b>8000</b>.

[0080] 10. Power profiling software <b>1002</b> then restarts execution of the embedded application.

[0081] 11. The support routine restarts and sets trigger <b>1014</b>, indicating the start of the next measurement.

[0082] 12. Execution of the support routine returns back to the calling function.

[0083] 13. Execution continues until the next profile point is encountered, and the control flow repeats at step 5.

[0084]FIG. 16 presents of a flowgraph of a method for correlating the current power measurement to the currently executing function when in multi-function non-real-time mode. When the embedded application is halted at the _TSPP_MNRstopXXX breakpoint, power profiling software <b>1002</b> correlates the most recent power measurement to the function that was executing when the measurement was taken To accomplish this, it maintains a version of the runtime call stack and updates this stack each time the breakpoint is encountered.

[0085] To build the call stack, power profiling software <b>1002</b> determines what function called _TSPP_MNRtriggerXXX, and whether the call was made from the function's entry point or just prior to the function's exit point. At step <b>1600</b>, the identity of the function calling the trigger function is determined based on the return address of trigger function. At step <b>1602</b>, a test is made to determine if the return address corresponds to the entry or exit of the identified function. If it is an entry point, then step <b>1604</b> is executed next. Here, a check is made to determine if the call stack is empty. If it is, then step <b>1608</b> is executed and the function identifier is pushed on top of the stack. The method then terminates. If the call stack is not empty at step <b>1604</b>, then the current power measurement is attributed to the function on top of the call stack and processing continues at step <b>1608</b>, where the current function identifier is pushed on the call stack. If the return address is not an entry point at step <b>1602</b>, then it is an exit point. At step <b>1610</b>, the function at the top of the call stack is popped off the stack and the current power measurement is attributed to that function. The method then terminates.

[0086] Consider the application of this correlation method to the example C program in Table 9. <tables id="TABLE-US-00009" num="9"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="42PT" align="left" /><colspec colname="4" colwidth="77PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="4" align="center">TABLE 1</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>main ()</entry><entry>{</entry><entry>/* </entry><entry>RA1 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . . </entry><entry>/* measurement M1 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><tbody valign="top"><row><entry /><entry>func1 ()</entry><entry>;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . . </entry><entry>/* measurement M5 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry><entry>/* RA6 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="14PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry /><entry>func1 ()</entry><entry>{</entry><entry>/* RA2 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . .</entry><entry>/* measurement M2 */</entry></row><row><entry /><entry>func2 () ;</entry></row><row><entry /><entry>. . . . </entry><entry>/* measurement M4 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry><entry>/* RA5 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="14PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry /><entry>func2 ()</entry><entry>{</entry><entry>/* RA3 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry /><entry>. . . . </entry><entry>/* measurement M3 */</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry><entry>/* RA4 */</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0087] In this example, three functions are executed, main, func<b>1</b>, and func<b>2</b>. Assuming that all three functions are profiled, _TSPP_MNRtriggerXXX is called six times and six breakpoints occur. There will be six return address (RA1-RA6) and five power measurements (M1-M5) to be correlated. Table 10 presents the initial state of the call stack prior to the execution of the example of Table 9. <tables id="TABLE-US-00010" num="10"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="84PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 10</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>&lt;empty&gt;</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0088] When function main is executed, TSPP_MNRtriggerXXX is called and the first breakpoint occurs. First, at step <b>1600</b>, the identity of the function associated with RA1, in this case main, is determined. RA1 corresponds to the entry point for main, so step <b>1604</b> is executed The call stack is initially empty so step <b>1606</b> is skipped. The function main is pushed onto the call stack. Execution of the application is then resumed. Table 11 illustrates the state of the call stack after the processing of RA1. <tables id="TABLE-US-00011" num="11"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 11</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>main</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0089] At the next breakpoint, the function associated with RA2, func<b>1</b>, is determined at step <b>1600</b>. RA2 corresponds to the entry point for func<b>2</b> (step <b>1602</b>), so processing proceeds to step <b>1604</b>. The call stack is not empty, so the current power measurement M1 is attributed to the function on top of the call stack, main, at step <b>1606</b>. Func<b>1</b> is then pushed on top of the call stack at step <b>1608</b>. Execution of the application is then resumed. Table 12 illustrates the state of the call stack and the measurement sets after the processing of PC2. <tables id="TABLE-US-00012" num="12"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 12</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>func1, main</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0090] At the next breakpoint, func<b>2</b> is found to be the function associated with RA3. Again, RA3 is an entry point and the call stack is not empty, so the current power measurement M2 is attributed to the function at the top of the stack, func<b>1</b>. Func<b>2</b> is then pushed onto the stack. Execution of the application is then resumed. Table 13 illustrates the state of the call stack and the measurement sets after the processing of PC3. <tables id="TABLE-US-00013" num="13"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 13</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>func2, func1, main</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0091] At the next breakpoint, RA4 is determined to be associated with func<b>2</b>. At step <b>1602</b>, it is found to be an exit point rather than an entry point, so step <b>1610</b> is executed. The function identifier at the top of the stack, func<b>2</b>, is popped and the current power measurement M3 is attributed to it. Execution of the application is then resumed. Table 14 illustrates the state of the call stack and the measurement sets after the processing of RA4. <tables id="TABLE-US-00014" num="14"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 14</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>func1, main</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0092] At the next breakpoint, RA5 is processed. RA5 corresponds to the exit point for func<b>1</b>, so again step <b>1610</b> is executed. The function identifier at the top of the stack, func<b>1</b>, is popped and current power measurement M4 is attributed to it. Execution of the application is then resumed. Table 15 illustrates the state of the call stack and the measurement sets after the processing of RA5. <tables id="TABLE-US-00015" num="15"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE 15</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>main</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0093] At the final breakpoint, RA6 is processed. RA6 corresponds to the exit point for main, so again step <b>1610</b> is executed. The function identifier at the top of the stack, main, is popped and current power measurement M5 is attributed to it. Execution of the application is then resumed. Table 16 illustrates the state of the call stack and the measurement sets after the processing of RA6. <tables id="TABLE-US-00016" num="16"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="84PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="2" align="center">TABLE16 </entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Call Stack</entry><entry>&lt;empty&gt;</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0094] Single Range Profiling

[0095] From a high level, the control flow for multi-function non real-time profiling is as follows:

[0096] 1. The user prepares the embedded application for SR profiling as previously described.

[0097] 2. The user selects the SR profiling option.

[0098] 3. The user starts execution of target system <b>1018</b>.

[0099] 4. When execution is completed, power profiling software <b>1002</b> reads the power measurements from the measurement device (oscilloscope <b>1012</b> or measurement board <b>1022</b>) and reads the peripheral information if it has been requested.

[0100] Power profiling software <b>1002</b> then displays the results in Pane <b>8000</b>.

[0101] The user can choose a special form of single range profiling that supports multiple executions of the embedded application. In this case, power profiling software <b>1002</b> will execute the application multiple times without user intervention. The final results are the average power consumption for all the executions.

[0102] To use this form of profiling, the user tells power profiling software <b>1002</b> how many times the application is to be executed when SR mode is selected. When performing multiple executions, power profiling software <b>1002</b> initiates each execution.

[0103]FIG. 17 illustrates an alternate, unobtrusive method of single range power profiling for target systems comprised of DSPs such as DSP <b>1010</b> of FIGS. 1A and 1C. As previously discussed, DSP <b>1010</b> comprises emulation components that may be programmed to generate the trigger signals and emulation circuitry providing a standard JTAG debug interface with two additional terminals or pins EMU<b>0</b> and EMU<b>1</b>, supporting various extended debugging capabilities. No instrumentation of the application is required. Instead, when the user selects the beginning and end points of the range of instructions to be profiled, power profiling software <b>1002</b> causes the required emulation components to be programmed to monitor the address bus for the selected start address and end address (step <b>1700</b>). As shown in steps <b>1702</b>-<b>1706</b>, when the start address is detected, a trigger signal is sent on EMU<b>0</b> to start power measurement. And, as illustrated in the sequence of steps <b>1702</b>, <b>1704</b>, <b>1708</b>, when the end address is detected, a trigger signal is sent on EMU<b>1</b> to terminate power measurement.

[0104]FIG. 18 illustrates the operation of latch <b>1006</b> during single range power profiling. At start point <b>1800</b>, EMU<b>0</b> is pulsed to indicate the execution of the instruction at the selected start address of the range. This 15 ns pulse causes the trigger signal to latch, sending a signal via trigger <b>1014</b> to the attached power measurement device. The trigger signal remains high, as indicated by trigger width <b>1804</b>, until the execution of the instruction at the selected end address of the range Then, at end point <b>1802</b>, EMU<b>1</b> is pulsed to clear the trigger signal. The 15 ns for the pulse width of the EMU pin pulse is representative of three clock cycles on a 200 MHZ DSP. The 10 ns for the delay in the latch is dependent on the source voltage to latch <b>1006</b>, assumed here to be three volts.

[0105] In addition to the above described methods for measuring the power consumption of discrete software units such as address ranges or functions of an embedded application, methods have been developed for measuring the power consumption of the software tasks performed during execution.

[0106] Task-Level Real-Time Profiling

[0107] Task-level real-time profiling (TR) allows measurement of the power consumption of each task executed in an embedded application. This includes both statically and dynamically created tasks. FIG. 21 presents a flowgraph of a method for task-level real-time power profiling of an embedded application. At step <b>2100</b>, the embedded application is instrumented to permit power profiling of all tasks that will be executed when the application is run. In an embodiment such as that of FIGS. <b>1</b>A-<b>1</b>C, this instrumentation consists of linking in profile support code tailored to target hardware <b>1018</b> and trigger <b>1014</b> be used on host computer <b>1000</b>, downloading the application to target hardware <b>1018</b>, and selecting the TR profiling mode in power profiling software <b>1002</b>. Power profiling software <b>1002</b> replaces the current address of the task switch hook function provided by the operating system of the embedded application with the address of a trigger function _TSPP_switchfxn_XXX_tr. This causes the trigger function to be executed each time there is a task context switch while the embedded application is executing.

[0108] Task hook functions are well known to those skilled in the art. Such hook functions are provided by an operating system to permit an application to specify functions to be called whenever the state of a task changes, such as when a task is created, deleted, exited, or when a context switch occurs. One implementation of such hook functions is described in more detail in Section 2.25 of “TMS320C6000 DSP/BIOS Application Programming Interface (API) Reference Guide”. This section is incorporated herein by reference as background material. The entire document is available at http://www-s.ti.com/sc/psheets/spru403d/spru403d.pdf.

[0109] More specifically, in an embodiment, when replacing the task switch hook function, power profiling software <b>1002</b> performs the following steps:

[0110] 1. Determines the address of the function that the application may have specified as the task switch hook function by reading the value of the variable referred to by the symbol _KNL_tswitchfxn.

[0111] 2. If the user specified hook function is NULL, the value 0 is written into the variable referred to by the symbol _TSPP_switchfxn_user_hook. Otherwise, the address of the application hook function is written into the variable referred to by _TSPP_switchfxn_user_hook.

[0112] 3. Writes the address of the trigger function _TSPP_switchfxn_XXX_tr into the variable referred to by the symbol _KNL_tswitchfxn.

[0113] These steps preserve the address of any application specified task switch hook function so that it may be executed after the trigger support function is executed.

[0114] After the embedded application is instrumented for TR profiling, the user starts execution. During this execution, steps <b>2102</b>-<b>2104</b> of the method are performed. Any task context switch that occurs transfers control to the trigger function _TSPP_switchfxn_XXX_tr. Each invocation of the trigger function causes the following steps to occur:

[0115] 1. The trigger function clears trigger <b>1014</b>, indicating the end of the previous measurement. This causes a power measurement to be captured on the power measurement device.

[0116] 2. The trigger function determines the task handle for the new task, which will begin executing when the context switch has completed. Once the handle is determined, the trigger function initiates transfer of the handle to the host computer <b>1000</b>. In addition to the task handle, other information, such as the current state (on/off) of the on-chip peripherals, may also be collected for transfer.

[0117] 3. The trigger function sets trigger <b>1014</b>, indicating the start of the next measurement.

[0118] 4. The trigger function calls the application's original hook function that was overridden if such function was present. The address of the original hook function is stored in the variable _TSPP_switchfxn_user_hook. If the value of this variable is 0, this indicates that there was no user hook function. Note that the user hook function is called after trigger <b>1014</b> is set. Therefore, the power consumed by the user hook function is measured and will be attributed to the new task.

[0119] 5. Execution of the support routine returns back to the caller to continue execution of the application.

[0120] As indicated by step <b>2106</b>, the task handles are transferred to the host computer while the application is executing. The actual method for retrieving the task handles and other data depends on the transfer method used by target system <b>1018</b>. For an embodiment, the transfer method is RTDX.

[0121] Either while the application is executing, or when execution completes, power profiling software <b>1002</b> retrieves power measurement data from the measurement device. If the measurement device is oscilloscope <b>1012</b>, the set of power measurements is retrieved when the application completes execution. If the measurement device is high-speed measurement board <b>1022</b>, the power measurement data may be retrieved while the application is still running.

[0122] When execution of the application is complete, the power measurement data is correlated with the collected task handles at step <b>2108</b> to attribute specific power measurements to specific tasks. When the application finishes execution (or execution is manually halted), power profiling software <b>1002</b> has a set of power measurements in the order they were taken, and a set of task handles that specify the execution order of the tasks. The ordering of the set of task handles and the set of power measurements is such that there is a one-to-one correspondence between the respective elements of the sets. This is possible because the first call to the profile support routine occurs before any measurement is taken. The support routine initiates the transfer of the task handle of the task that will start executing when the task switch is complete (i.e. the handle for the new task). It does not transfer the handle of the task that was executing when the switch occurred (i.e. the old task handle). On all subsequent context switches, the power measurement that has just been taken corresponds to the old task. This task is the same task whose handle was transferred in the previous task switch. In other words, the new task in the nth context switch is also the old task in the nth+1 context switch.

[0123] Using this information, a specific power measurement may be correlated to the exact task that was executing when the power measurement was taken. FIG. 22 illustrates one such method for correlating power measurements with the appropriate tasks. For each task handle in the set of task handles, the steps <b>2200</b> and <b>2202</b> are executed. At step <b>2200</b>, the task associated with the task handle is identified and at step <b>2202</b>, the next power measurement in the ordered set of power measurements is attributed to that task. For example, if an application has tasks T<b>1</b>, T<b>2</b>, T<b>3</b>, and T<b>4</b> whose execution order is: T<b>4</b>, T<b>3</b>, T<b>2</b>, T<b>1</b>, T<b>4</b>, T<b>3</b>, T<b>2</b>, T<b>1</b>, the set of task handles and the set of power measurements will be TH<b>4</b> , TH<b>3</b>, TH<b>2</b>, TH<b>1</b>, TH<b>4</b>, TH<b>3</b>, TH<b>2</b>, TH<b>1</b> and M1, M2, M3, M4, M5, M6, M7, M8 respectively. When the method is applied, measurement M1 is attributed to T<b>4</b>, M2 is attributed to T<b>3</b>, etc. Note that TH<b>1</b> is the task handle for T<b>1</b>, TH<b>2</b> is the task handle for TH<b>2</b>, etc.

[0124] In an implementation of the above method, power profiling software <b>1002</b> maintains a hash table of pointers to ProfileTask objects. The keys to this hash table are based on the task handles. For each task handle, the hash table is checked to see if this particular task handle has already been encountered. If it has not, a new ProfileTask object is created. The task associated with the task handle is identified by looking it up in the symbol table created when the embedded application was created and the task name is stored in the ProfileTask object. The next power measurement in the set of power measurement is also stored in the ProfileTask object. If the task handle has already been encountered, the ProfileTask object associated with the task handle is updated with the next power measurement in the set of power measurements.

[0125] The method of FIG. 21 is limited in that it cannot distinguish among tasks that are created with duplicate task handles. Such duplication only occurs when an application is allocating tasks dynamically. FIG. 23 presents an enhanced version of this method that overcomes this limitation. In this enhanced method, step <b>2100</b> includes further instrumentation of the embedded application. In addition to replacing the task switch hook function with a trigger support function, the task create hook function is also replaced with a profile support function that will be called each time a new task is created. This support function will cause the task handle of a newly created task to be captured as illustrated by added step <b>2110</b>. The task handles for the created tasks are transmitted to host computer <b>1000</b> at step <b>2106</b>. Because there are now task handles being captured at task creation and at each context switch, there must be a way to distinguish between the two modes of capture for purposes of correlating the power measurements with the task handles. One possible means of distinguishing is to provide an identifying header when the task handles are transferred to host computer <b>1000</b>.

[0126]FIG. 24 illustrates a correlation method for power profiling software <b>1002</b> using the enhanced TR profiling method of FIG. 23. The steps of this method are executed for each task handle of the set of task handles. At step <b>2400</b>, a check is made to determine if the next task handle was captured at task creation or at task execution. If it was captured at task creation, step <b>2402</b> is executed. A new ProfileTask object is created and added to an array that contains all ProfileTask objects created during the correlation process. At the end of the correlation process, this array will contain one ProfileTask object for each task executed in the embedded application. At step <b>2404</b>, a check is made to determine if the task handle is already in the hash table. If it is, then a new dynamically allocated task was created during execution that has the same task handle as a previous dynamically allocated task. The hash table entry associated with the task handle is replaced with the new ProfileTask object at step <b>2406</b>. If the task handle is not already in the hash table, then a new entry is created with the new ProfileTask object at step <b>2408</b>. Processing of the set of task handles then continues at step <b>2400</b>.

[0127] If the check at step <b>2400</b> determines that the task handle was not captured at task creation, then it was captured at task execution and step <b>2410</b> is executed. At step <b>2410</b>, the ProfileTask object for the task handle is located in the hash table. And, at step <b>2412</b>, the next power measurement in the set of power measurements is attributed to the task represented by that ProfileTask object. Processing of the set of task handles then continues at step <b>2400</b>.

[0128] For example, consider an embedded application having tasks T<b>1</b>, T<b>2</b>, T<b>3</b>, T<b>4</b>, and T<b>5</b> where T<b>3</b> and T<b>5</b> are dynamically allocated tasks. Assume that the task execution order is: T<b>4</b>, T<b>3</b>, T<b>2</b>, T<b>1</b>, T<b>5</b>, T<b>4</b>, T<b>2</b>, T<b>1</b> and that T<b>3</b> and T<b>5</b> are given the same task handle, TH<b>3</b>, when they are created. The set of task handles and the set of power measurements will be THc<b>4</b>, THc<b>2</b>, THc<b>1</b>, TH<b>4</b>, THc<b>3</b>, TH<b>3</b>, TH<b>2</b>, TH<b>1</b>, THc<b>3</b>, TH<b>3</b>, TH<b>4</b>, TH<b>2</b>, TH<b>1</b> and M1, M2, M3, M4, M5, M6, M7, M8 respectively THcx indicates a task handle captured when the associated task Tx is created and THx indicates a task handle captured when the associated task Tx is executed.

[0129]FIG. 25 illustrates the state of the hash table and the array after the correlation method has been applied. At step <b>2400</b>, THc<b>4</b> is recognized as being a task handle captured when T<b>4</b> was created. A new ProfileTask object, PTO<b>1</b>, is created and added to array <b>2520</b> as entry <b>2510</b> at step <b>2402</b>. At step <b>2404</b>, THc<b>4</b> is found not to be in hash table <b>2500</b> so a new entry, <b>2502</b>, is created for it. Note that this entry points to PTO<b>1</b>. THc<b>2</b> and THc<b>1</b> are then processed in turn in the same manner as THc<b>4</b>, with new ProfileTask objects, PTO<b>2</b> and PTO<b>3</b>, respectively, being created for each and added to array <b>2520</b> as entries <b>2512</b> and <b>2514</b>, respectively. Each is found not to be in hash table <b>2500</b> and new entries <b>2508</b> and <b>2504</b>, respectively, are created for them. Resuming at step <b>2400</b>, TH<b>4</b> is found not be a task creation handle, so step <b>2410</b> is executed. Its ProfileTask object, PTO<b>1</b> is located and power measurement M1 is attributed to the associated task. Resuming at step <b>2400</b>, THc<b>3</b> is found to be a task creation handle. A new ProfileTask object, PTO<b>4</b>, is created and added to array <b>2520</b> as entry <b>2516</b> and a new hash table entry, <b>2506</b>, is created for it. As dotted arrow <b>2522</b> indicates, hash table entry <b>2506</b> currently points to PTO<b>4</b>. TH<b>3</b> is then processed in a similar fashion to TH<b>4</b>, with power measurement M2 being attributed to the task associated with TH<b>3</b>. TH<b>2</b> and TH<b>1</b> are then processed with power measurements M3 and M4 attributed to the tasks associated with TH<b>2</b> and TH<b>1</b>, respectively. Subsequently, at step <b>2400</b>, THc<b>3</b> is processed. It is determined to be a task creation handle and a new ProfileTask object, PTO<b>5</b>, is created and added to array <b>2520</b> as entry <b>2518</b> at step <b>2402</b>. At step <b>2404</b>, it is determined that a hash table entry, <b>2506</b>, already exists for THc<b>3</b>. So, step <b>2406</b> is executed and hash table entry <b>2506</b> is updated with a pointer to PTO<b>5</b>. Processing resumes at step <b>2400</b>, where TH<b>3</b> is determined to be a task execution handle. At step <b>2510</b>, its ProfileTask object, PTO<b>5</b> is located and at step <b>2512</b>, power measurement M5 is attributed to the associated task. TH<b>4</b>, TH<b>2</b>, and TH<b>1</b> are subsequently processed, with each being found to be a task execution handle and power measurements M6, M7, and M8 being appropriately and respectively attributed to the associated tasks.

[0130] Task-Level Non-Real-Time Profiling

[0131] Task-level non-real-time profiling (TNR) permits measurement of power consumption for all tasks, whether statically or dynamically allocated, that are executed in an embedded application. The primary difference between TNR profiling and TR profiling is that the target system is halted at each task context switch and the power consumption display is updated. FIG. 26 presents a flowgraph of a method for task-level non-real-time power profiling of an embedded application. At step <b>2600</b>, the embedded application is instrumented to permit power profiling of all tasks that will be executed when the application is run. In an embodiment such as that of FIGS. <b>1</b>A-<b>1</b>C, this instrumentation consists of linking in profiling support code tailored to target hardware <b>1018</b> and trigger <b>1014</b> be used on host computer <b>1000</b>, downloading the application to target hardware <b>1018</b>, and selecting the TNR profiling mode in power profiling software <b>1002</b>. Power profiling software <b>1002</b> replaces the current address of the task switch hook function provided by the operating system of the embedded application with the address of the trigger function _TSPP_switchfxn_XXX_tnr. This will cause the trigger function to be called each time there is a task context switch while the embedded application is executing. Power profiling software <b>1002</b> also sets a breakpoint at the address specified by the symbol _TSPP_switchfxn_halt_XXX_tnr.

[0132] More specifically, in an embodiment, when replacing the task switch hook function, power profiling software <b>1002</b> performs the following steps:

[0133] 1. Determines the address of the function that the application may have specified as the task switch hook function by reading the value of the variable referred to by the symbol _KNL_tswitchfxn.

[0134] 2. If the user specified hook function is NULL, the value 0 is written into the variable referred to by the symbol _TSPP_switchfxn_user_hook. Otherwise, the address of the application hook function is written into the variable referred to by _TSPP_switchfxn_user_hook.

[0135] 3. Writes the address of the trigger function _TSPP_switchfxn_XXX_tnr into the variable referred to by the symbol _KNL_tswitchfxn.

[0136] These steps preserve the address of any application specified task switch hook function so that it may be executed after the trigger function is executed.

[0137] After the embedded application is instrumented for TNR profiling, the user starts execution. During this execution, steps <b>2602</b>-<b>2608</b> of the method are performed at each context switch (step <b>2610</b>). Any task context switch that occurs transfers control to the trigger function _TSPP_switchfxn_XXX_tnr. Each invocation of the trigger function will cause the following steps to occur:

[0138] 1. The support routine clears trigger <b>1014</b>, indicating the end of the previous measurement. This causes a power measurement to be captured on the power measurement device.

[0139] 2. The trigger routine determines the task handle for the new task, which will begin executing when the context switch has completed. The trigger routine saves the task handle for the new task into the profiler support variable _TSPP_newtskhandle.

[0140] 3. The trigger routine hits the breakpoint, which was set during instrumentation, at the address specified by the symbol _TSPP_switchfxn_halt_XXX_tnr. At this point execution is halted.

[0141] 4. Power profiling software <b>1002</b> reads the task handle of the new task from the variable _TSPP_newtskhandle. If this is the first encounter of the task specified by _TSPP_newtskhandle, the information for this task to the internal structures maintained for correlating power measurements to tasks.

[0142] 5. Power profiling software <b>1002</b> reads the power measurement from the power measurement device and attributes the power usage to the task that was executing before the task switch occurred using a correlation method. If peripheral status is also being gathered, the profiler will read the status of the peripherals from the target and update the task's peripheral usage information.

[0143] 6. The display of profiling data is updated and execution of the embedded application is resumed.

[0144] 7. The trigger routine restarts and sets trigger <b>1014</b>, indicating the start of the next power measurement.

[0145] 8. The trigger function calls the application's original hook function that was overridden if such function was present. The address of the original hook function is stored in the variable _TSPP_switchfxn_user_hook. If the value of this variable is 0, this indicates that there was no user hook function. Note that the user hook function is called after trigger <b>1014</b> is set. Therefore, the power consumed by the user hook function is measured and will be attributed to the new task.

[0146] 9. Execution of the support routine returns back to the caller to continue execution of the application.

[0147] When the embedded application is halted at the _TSPP_switchfxn_halt_XXX_tnr breakpoint, power profiling software <b>1002</b> correlates the most recent power measurement to the task that was executing when the measurement was taken. FIG. 27 illustrates one method for correlating power measurements with the appropriate tasks. At step <b>2700</b>, the current power measurement is attributed to the currently executing task by updating the entry for that task in the task handle data structure maintained by power profiling software <b>1002</b>. In an embodiment, power profiling software <b>1002</b> knows which task is currently executing because it maintains a variable containing the task handle of the currently executed task. If the task handle received by power profiling software <b>1002</b> is a new one (step <b>2702</b>), i.e., this is the first time the task will be executed, the task associated with the new task handle is identified and at step <b>2704</b>, an entry for the new task handle is created in the task handle data structure. And, in an embodiment, the variable tracking the currently executing task is updated to contain the new task handle.

[0148] For example, if an application has tasks T<b>1</b>, T<b>2</b>, T<b>3</b>, and T<b>4</b> whose execution order is: T<b>4</b>, T<b>3</b>, T<b>2</b>, T<b>1</b>, T<b>4</b>, T<b>3</b>, T<b>2</b>, T<b>1</b>, the task handles and power measurements received by host computer <b>1000</b> during execution of the application will be TH<b>4</b>, TH<b>3</b>, TH<b>2</b>, TH<b>1</b>, TH<b>4</b>, TH<b>3</b>, TH<b>2</b>, TH<b>1</b> and M1, M2, M3, M4, M5, M6, M7, M8 respectively. When the method is applied at the first breakpoint in the first context switch, an entry for TH<b>4</b> will be created in the task handle data structure as this is the first execution of T<b>4</b>. No power measurement will be attributed as no task has yet been executed. At the next context switch, power measurement M1 is attributed to T<b>4</b> and an entry for TH<b>3</b> is created in the task handle data structure. At the next context switch, M2 is attributed to T<b>3</b> and an entry for TH<b>2</b> is created in the task handle data structure, etc. Note that TH<b>1</b> is the task handle for T<b>1</b>, TH<b>2</b> is the task handle for TH<b>2</b>, etc.

[0149]FIG. 28 presents a flowgraph of an implementation of the above method. In this implementation, power profiling software <b>1002</b> maintains a hash table of pointers to ProfileTask objects that are created for each new task handle. The keys to this hash table are based on the task handles. To determine if a received task handle is a new one (step <b>2800</b>), the hash table is checked to see if this particular task handle has already been encountered. If it has not, a new ProfileTask object is created (step <b>2802</b>). The task associated with the task handle is identified by looking it up in the symbol table created when the embedded application was created and the task name is stored in the ProfileTask object. A new entry in the hash table is added with the new ProfileTask object at step <b>2804</b>. After processing the new task handle or if no new task handle was received, step <b>2806</b> is executed. If a task is currently executing, the hash table entry of the ProfileTask object for that task is located (step <b>2808</b>) and the current power measurement is attributed to the task by storing it in the ProfileTask object.

[0150] The method of FIG. 26 is limited in that it does not distinguish among tasks that are created with duplicate task handles. Such duplication only occurs when an application is allocating tasks dynamically. FIG. 29 presents an enhanced version of the method that overcomes this limitation. In this method, step <b>2600</b> includes further instrumentation of the embedded application. In addition to replacing the task switch hook function with a trigger support function, the task create hook function is also replaced with a task creation support function that is called each time a new task is created and a breakpoint is set in this support function. This support function will cause the task handle of a newly created task to be captured and received by host computer <b>1000</b> each time this breakpoint is hit during execution of the embedded application as illustrated by added steps <b>2612</b>-<b>2616</b> The task handles for the created tasks are received by host computer <b>1000</b> at step <b>2614</b> and used to update the task handle data structure. Because there are now task handles being captured at task creation and at each context switch, there must be a way to distinguish between the two modes of capture for purposes of correlating the power measurements with the task handles. One possible means of distinguishing is to provide an identifying header when the task handles are transferred to host computer <b>1000</b>.

[0151]FIG. 30 illustrates a correlation method for power profiling software <b>1002</b> using the enhanced TNR profiling method of FIG. 29. The steps of this method are executed for each time the breakpoints in the two profile support functions are detected. At step <b>3000</b>, a check is made to determine if the next task handle was captured at task creation or at task execution. If it was captured at task creation, step <b>3002</b> is executed. A new ProfileTask object is created and added to an array that contains all ProfileTask objects created during execution of the embedded application. When execution is complete, this array will contain one ProfileTask object for each task executed in the embedded application. At step <b>3004</b>, a check is made to determine if the task handle is already in the hash table. If it is, then a new dynamically allocated task was created during execution that has the same task handle as a previous dynamically allocated task. The hash table entry associated with the task handle is replaced with the new ProfileTask object at step <b>3006</b>. If the task handle is not already in the hash table, then a new entry is created with the new ProfileTask object at step <b>3008</b>.

[0152] If the check at step <b>3000</b> determines that the task handle was not captured at task creation, then it was captured at task execution and step <b>3010</b> is executed. The ProfileTask object for the task handle of the currently executing task is located in the hash table. And, at step <b>3012</b>, the current power measurement is attributed to that task by updating the ProfileTask object.

[0153] For example, consider an embedded application having tasks T<b>1</b>, T<b>2</b>, T<b>3</b>, T<b>4</b>, and T<b>5</b> where T<b>3</b> and T<b>5</b> are dynamically allocated tasks. Assume that the task execution order is: T<b>4</b>, T<b>3</b>, T<b>2</b>, T<b>1</b>, T<b>5</b>, T<b>4</b>, T<b>2</b>, T<b>1</b> and that T<b>3</b> and T<b>5</b> are given the same task handle, TH<b>3</b>, when they are created The task handles and power measurements received by host computer <b>1000</b> will be THc<b>4</b>, THc<b>2</b>, THc<b>1</b>, TH<b>4</b>, THc<b>3</b>, TH<b>3</b>, TH<b>2</b>, TH<b>1</b>, THc<b>3</b>, TH<b>3</b>, TH<b>4</b>, TH<b>2</b>, TH<b>1</b> and M1, M2, M3, M4, M5, M6, M7, M8 respectively. THcx indicates a task handle captured when the associated task Tx is created and THx indicates a task handle captured when the associated task Tx is executed.

[0154]FIG. 25 illustrates the state of the hash table and the array after the execution of the embedded application is complete. At step <b>3000</b>, THc<b>4</b> is recognized as being a task handle captured when T<b>4</b> was created. A new ProfileTask object, PTO<b>1</b>, is created and added to array <b>2520</b> as entry <b>2510</b> at step <b>3002</b>. At step <b>3004</b>, Thc<b>4</b> is found not to be in hash table <b>2500</b> so a new entry, <b>2502</b>, is created for it. Note that this entry points to PTO<b>1</b>. THc<b>2</b> and THc<b>1</b> are then processed in turn in the same manner as THc<b>4</b>, with new ProfileTask objects, PTO<b>2</b> and PTO<b>3</b>, respectively, being created for each and added to array <b>2520</b> as entries <b>2512</b> and <b>2514</b>, respectively. Each is found not to be in hash table <b>2500</b> and new entries <b>2508</b> and <b>2504</b>, respectively, are created for them. At the next context switch, at step <b>3000</b>, TH<b>4</b> is found not be a task creation handle, so step <b>3010</b> is executed. Its ProfileTask object, PTO<b>1</b> is located and the current power measurement M1 is attributed to the associated task. Subsequently, T<b>3</b> is created in the embedded application. At step <b>3000</b>, THc<b>3</b> is found to be a task creation handle. A new ProfileTask object, PTO<b>4</b>, is created and added to array <b>2520</b> as entry <b>2516</b> and a new hash table entry, <b>2506</b>, is created for it. As dotted arrow <b>2522</b> indicates, hash table entry <b>2506</b> currently points to PTO<b>4</b>. At the next context switch, TH<b>3</b> is processed in a similar fashion to TH<b>4</b>, with power measurement M2 being attributed to the task associated with TH<b>3</b>. TH<b>2</b>, and TH<b>1</b> are subsequently processed with power measurements M3 and M4 attributed to the tasks associated with TH<b>2</b> and TH<b>1</b>, respectively. Subsequently, at step <b>3000</b>, THc<b>3</b> is processed. It is determined to be a task creation handle and a new ProfileTask object, PTO<b>5</b>, is created and added to array <b>2520</b> as entry <b>2518</b> at step <b>3002</b>. At step <b>3004</b>, it is determined that a hash table entry, <b>2506</b>, already exists for THc<b>3</b>. So, step <b>3006</b> is executed and hash table entry <b>2506</b> is updated with a pointer to PTO<b>5</b>. At the next context switch, at step <b>3000</b>, T<b>3</b> is determined to be a task execution handle. At step <b>2510</b>, its ProfileTask object, PTO<b>5</b>, is located and at step <b>3012</b>, the current power measurement M5 is attributed to T<b>5</b>. TH<b>4</b>, TH<b>2</b>, and TH<b>1</b> are subsequently processed, with each being found to be a task execution handle and the current power measurements M6, M7, and M8 being appropriately and respectively attributed to the associated tasks.

[0155]FIG. 19 presents a method to lessen the obtrusiveness of the SR, MNR, MR, TNR, and TR profiling modes previously described. When a DSP pin is used to trigger the power measurement device, as in the profiling system of FIG. 1B, code must be present in the profile support routines to set and clear the pin to trigger the power measurement device. The amount of code required depends on which pin is used. However, in the configurations of FIGS. 1A and 1C permitting the use of EMU<b>0</b> and EMU<b>1</b> for triggering the measurement device, no additional code in the profile support routines is required. Instead, power profiling software <b>1002</b> programs the required emulation components to monitor the address bus for a start address and an end address in the profile support routine inserted when the application is instrumented (step <b>1900</b>). As shown in steps <b>1902</b>, <b>1904</b>, <b>1908</b>, when the end address is detected, a trigger signal is sent on EMU<b>0</b> to start power measurement. And, as illustrated in the sequence of steps <b>1902</b>, <b>1904</b>, <b>1906</b>, when the start address is detected, a trigger signal is sent on EMU<b>1</b> to terminate power measurement.

[0156] In SR mode, latch <b>1006</b> operates as discussed previously for the unobtrusive method of single range power profiling. FIG. 20 illustrates the operation of latch <b>1006</b> during MNR or MR power profiling. When the instruction at the start address of the profile support routine is executed, EMU<b>1</b> is pulsed at point <b>2000</b> to clear the trigger signal. The trigger signal remains low, as indicated by trigger width <b>2006</b>, until the execution of the instruction at the end address of the profile support routine. Then, at end point <b>2002</b>, EMU<b>0</b> is pulsed. This 15 ns pulse causes the trigger signal to latch, sending a signal via trigger <b>1014</b> to the attached power measurement device. The trigger signal remains high, as indicated by trigger width <b>2008</b>, until the next execution of the instruction at the start address of the profile support routine, i.e. when the next function to be profiled is executed.

[0157] In other embodiments of the above methods and systems for power profiling, the power measurement data collected is refined to permit more accurate profiling of power consumption, both for target systems that perform dynamic voltage scaling and those that do not. In power profiling systems such as those depicted in FIGS. <b>1</b>A-<b>1</b>C, if power measurement devices <b>1012</b> and <b>1022</b> have only one input means, such as a channel on an oscilloscope, then the power measurement data captured is generally a current measurement. Since power P is actually calculated by the formula P=V*I where V is voltage and I is current, the voltage value must be provided some other way. As illustrated above in FIG. 9, one approach is to ask the user of the system to specify a value for V. This specified voltage value is then used as a constant in the ensuing power calculations.

[0158] However, it is unlikely that voltage is actually a constant while an application is executing. Typically, voltage will fluctuate between plus or minus 5-10%. And, if the target hardware supports dynamic voltage scaling, the application may deliberately cause voltage changes. If power measurement devices <b>1012</b> and <b>1022</b> have a second input means, both voltage and current values may be captured by providing both a current probe and a voltage probe. The power measurement data collected as the application is executing then comprises both actual voltage and actual current values, thus providing a more accurate measurement of power consumption.

[0159] While the above inventions have been described with reference to illustrative embodiments, these descriptions should not be construed in a limiting sense. Various other embodiments of the invention will be apparent to persons skilled in the art upon reference to this description. For example, the methods for measuring the power consumption of functions are clearly applicable to any analogous software unit in a high level programming language. The task level power profiling methods may be used in applications where portions of the application are dynamically linked and loaded. Also, the basic triggering scheme, the capturing of power and execution data, and the correlation methods may be readily extended to measure power consumption of applications executing on target hardware comprising multiple processors. Some example scenarios include: 1) a configuration in which a single power supply feeds multiple processors and the aggregate power measurement is taken from all the processors; 2) a configuration in which a single power supply feeds multiple processors where each processor is connected to a separate power measurement device; 3) a configuration with a multi-core chip in which each core on the chip has a separate power supply and the inter-processor interconnect is passive routing; and 4) a configuration with a multi-core chip in which each core on the chip has a separate power supply and the inter-processor interconnect comprises an active logic interconnect that is also separately powered. It is therefore contemplated that the appended claims will cover any such modifications of the embodiments as fall within the true scope and spirit of the invention.