KR20010067341A - Intelligent power management for distributed processing systems - Google Patents

Abstract

A distributed processing system 10 is disclosed that includes an MPU 12, a number of processing modules, such as a DSP 14, and a coprocessor / DMA channel 16. Power management software and execution tasks associated with profiles 36 for the various processing modules are used to construct scenarios that meet certain power goals, such as providing optimal operation in package thermal constraints or using minimal energy. Actual activity related to the task is monitored during operation to ensure compatibility with the purpose. The assignment of tasks changes to operations to adapt to changes in environmental conditions and changes in task lists.

Description

INTELLIGENT POWER MANAGEMENT FOR DISTRIBUTED PROCESSING SYSTEMS

The present invention relates generally to integrated circuits, and more particularly to managing power in a processor.

For many years, the processor design focus, including the design for microprocessor units (MPUs), co-processors, and digital signal processors (DSPs), has been to increase the speed and functionality of the processor. In recent years, power consumption has become a serious concern. Importantly, maintaining low power consumption was considered important and central to the design, without seriously reducing speed and functional advantages. Power consumption has become an important issue in many applications because many systems, such as smart phones, cellular phones, personal digital assistants (PDAs), and handheld computers run on relatively small batteries. Because it becomes. Since it is inconvenient to recharge the battery in a short time, it is hoped to maximize the battery life of these systems.

Recently, approaches towards minimizing power consumption have included static power management, ie, designing circuits that use less power. In this case, a functional action has been taken to reduce the clock speed during the idle period, or to stop the circuit.

While these changes are important, it is important to continually improve power management, especially in systems where size, ie battery size, is critical for the convenient use of the device.

In addition to saving total power, the ability to dissipate heat from integrated circuits in complex processing environments can be a factor. Integrated circuits will be designed to dissipate a certain amount of heat. If tasks require multiple systems on an integrated circuit to draw a high level of current, the circuit may overheat and cause the system to fail.

In the future, applications executed by integrated circuits will become more complex, with multiple processors (hereafter "distributed processing systems") containing MPUs, DSPs, coprocessors, and DMA channels in a single integrated circuit. It will be easy to include treatment. The DSP will be deployed to support multiple and concurrent applications, and none of these applications will be provided on a particular DSP platform, but will be loaded from a global network such as the Internet. Thus, the task, which can handle the distributed processing system without overheating, will become inactive.

Therefore, a method and apparatus for managing power in a circuit emerge as a necessary issue without seriously affecting its performance.

The present invention provides a method and apparatus for controlling task execution in a processor comprising a plurality of processing modules. Consumption information is calculated based on a probability value for the action associated with the task. Thereafter, the task for the processing module is executed in accordance with the consumption information.

The present invention provides many advantages over the prior art. First, it provides complete dynamic power management. As the tasks executed in the processing system change, the power management software can build a new scenario to ensure that the threshold has not been exceeded. In addition, as external conditions change, such as battery voltage drops, power management software can re-evaluate such conditions and change scenarios as needed. Second, power management software is evident for the various tasks it controls. Thus, even if a particular task does not provide any power management, the power management software is responsible for executing the task in a manner consistent with the power capability of the processing system. Third, the overall operation of the power management software can be used for different hardware platforms, different hardware and tasks coordinated by changing the profile used in power calculations.

1 is a block diagram of a distributed processing system.

2 is a software hierarchy diagram of a distributed processing system.

3 illustrates an example of the power management of a distributed processing system.

4A and 4B are flow charts showing a preferred embodiment of the operation of the power management software of FIG.

5 is a block diagram of the building system scenario of FIG.

6 is a motion estimation block diagram of FIG.

7 is a power calculation block diagram of FIG.

8 is a block diagram of the operation measurement and monitor of FIG.

9 is a block diagram illustrating a distributed processing system having an operation counter.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention is best understood with reference to FIGS. 1 to 9 of the accompanying drawings, in which like elements are assigned like reference numerals.

1 is a schematic block diagram of a general distributed processing system 10 including an MPU 12, one or more DSPs 14, and one or more DMA channels or coprocessors (collectively referred to as DMA / coprocessors 16). to be. In this embodiment, the MPU 12 includes a core 18 and a cache 20. The DSP 14 includes a processing core 22 and a local memory 24 (in a practical embodiment, a separate instruction / data memory or an integral instruction / data memory may be used). Memory interface 26 couples shared memory 28 to one or more of MPU 12, DSP 14, or DMA / coprocessor 16. Each processor (MPU 12, DSP 14) can operate fully automatic under its operating system (OS) or real time operating system (RTOS) within the actual distributed processing system, and the MPU 12 You can manage a global OS that manages shared resources and memory environments.

2 shows a software layer diagram for a distributed processing system 10. As shown in Fig. 1, MPU 12 executes an OS, and DSP 14 executes an RTOS. Distributed application layer 32 includes JAVA, C ++, and other applications, as well as power management tasks 38 utilizing profiling data 36 and global task scheduler 40. Middleware software layer 42 communicates between OS layer 30 and applications within distributed application layer 32.

1 and 2, the operation of the distributed processing system 10 is described. The distributed processing system 10 may execute various tasks. Typical applications for distributed processing system 10 are smartphone applications where distributed processing system 10 handles wireless communications, video / audio decompression, and user interfaces (ie, LCD updates, keyboard decode). In this application, different systems included in distributed processing system 10 will execute various tasks of different priorities. Typically, the OS performs task scheduling of different tasks on the various systems involved.

The present invention integrates energy consumption as a standard in scheduling tasks. In this embodiment, the power management application 38 and profile 36 from the distributed application layer 32 are used to construct a system scenario based on the likelihood value to execute the task list. If the scenario does not conform to a predetermined standard, ie if the power consumption is too large, a new scenario is created. After an acceptable scenario has been configured, the OS layer monitors hardware activity to verify that the predicted activity in the scenario is correct.

Standards for acceptable task scheduling scenarios may vary depending on the nature of the device. An important standard in mobile devices is minimum energy consumption. As mentioned above, as electronic communication devices become miniaturized, miniaturization of batteries becomes more important than energy consumption. In many cases during the operation of the device, it is possible to lower the operating mode of the task in order to reduce power, especially when the battery is at a low level. For example, if the refresh rate of the LCD is reduced, image quality may be degraded but power consumption may be reduced. There is also a method of reducing the MIP (millions of instructions per second) of the distributed processing system 10 to reduce power, but there is a problem that the performance is reduced. Power management software 38 may analyze various scenarios using various combinations of degraded performance to reach acceptable device operation.

Another purpose of power management may be to find the best MIP or lowest energy for a given power limit setup.

3A and 3B illustrate an example of using the power management application 38 to prevent the distributed processing system 10 from exceeding an average power consumption limit. In FIG. 3A, DSP 14, DMA 16, and MPU 12 execute multiple tasks simultaneously. At time t1, the average power dissipation of the three embedded systems exceeds the average limit imposed on distributed processing system 10. 3B illustrates a scenario in which the same task is executed, but the MPU task is delayed until after the DMA and DSP tasks are considered to maintain an acceptable power dissipation profile.

4A is a flowchart describing the operation of the first embodiment of the power management task 38. In block 50, the power management task is called by the global scheduler 40 and executed by either the MPU 12 or the DSP 14, and the scheduler evaluates the application being entered in accordance with the associated priority and exclusion rules. Split into tasks. Task list 52 may include, for example, audio / video decoding, display control, keyboard control, character recognition, and the like. In step 54, task list 52 is evaluated against task model file 56 and allowed degradation file 58. The task model file 56 has already generated a file for assigning a different model to each task in the task list. Each model is a collection of data, which can be derived empirically or by computer-aided software design techniques and includes latency limits, priorities, data flow, initial energy estimates at reference processor speeds, impact of degradation, and MIP and time. Defines the characteristics of the associated task, such as the execution profile of a given processor as a function. The degeneration list 58 describes the various degenerations that can be used in creating the scenario.

Whenever a task list is modified (i.e., a new task is created or a task is deleted) or when a real-time event occurs, based on task list 52 and task model file 56 at step 54, the scenario Is built. This scenario provides priority information that assigns various tasks to the module to set the priority at which the tasks run. Scenario energy estimate 59 at the reference speed may be calculated from the estimate of the task. The task can be degraded if necessary or desired, i.e., replaced with the mode of the task using less resources instead of the full version of the task. From this scenario, an activity estimate is generated at block 60. Activity estimates include the task activity profile 62 (from profiling data 36 of distributed application layer 32) and the hardware architecture model 64 (from profiling data 36 of distributed application layer 32). Use to generate probabilistic values for the hardware activities that will be obtained from the scenario. The hypothetical value includes the wait / execution computation share (effective MHz) of each module, access to cache and memory, I / O toggle rate and DMA flow request and data amount. Using a period T coinciding with the thermal time constant, the average that can be compared to the thermal package model, from the average activity (especially the effective processor speed) derived from the energy estimate 59 and step 60 at the reference processor speed The power dissipation can be calculated. If the power value exceeds any of the thresholds described in the package thermal model 72, the scenario is rejected at decision block 74. In this case, a new scenario is established at block 54, and steps 60, 66 and 70 are repeated. Otherwise, run the task list using the scenario.

During operation of the task defined by the scenario, the OS and the RTOS use the counter 78 included in the hardware to track the activity by their respective modules in the block 76. The actual activity in the module of the distribution processing system 10 may vary from the activity estimated at block 60. The data from the hardware counters are monitored based on period T to generate the measured activity values. These measured activity values are used at block 66 to calculate the energy value during this period and the average power value at block 66 as described above and compare it with the package thermal model of block 72. If the measured values exceed the threshold, a new scenario is established at block 54. By continuously monitoring the measured activity values, the scenario can be dynamically modified to remain within defined limits or to adjust to changing environmental conditions.

The total energy consumption of the chip

Where f is the frequency, V _dd is the supply voltage, and α is the stochastic (or measured, see discussion section related to block 76 of this calculation) activity. In other words, Is the energy corresponding to the unique hardware module characterized by the equivalent consuming capacitance Cpd, and the counter value is E is the sum of all energy for all modules in the distributed processing system consumed within T. Average system power consumption W = E / T. In a preferred embodiment, the measured probabilistic energy consumption is calculated and the average power consumption is derived from the energy consumption during period T. In most cases, energy consumption information will be more readily available. However, it would also be possible to calculate power consumption from the measured stochastic power consumption.

4B is a flowchart describing the operation of the second embodiment of the power management task 38. The flow of FIG. 4B is the same as that of FIG. 41, but instead of selecting one new scenario, when eliciting the scenario construction algorithm in step 50 (new task, task deletion, real-time event), n different performance constraints are met. Scenarios can be precomputed and stored in steps 54 and 55 in advance to reduce the number of operations and provide fast adaptation in a dynamic loop if the power calculated in the tracking loop is the current scenario rejection in block 74. It is different.

5-8 illustrate the operation of the various blocks of FIG. 3 in more detail. The build system block 54 is shown in FIG. 5. In this block, a task list 52, a mother tree model 56, and a list 58 of possible task degradations are used to generate the scenario. The task list depends on which task is executed in the distributed processing system 10. In the example of FIG. 5, three tasks; MPEG4 decode, wireless modem data reception and keyboard event monitor are shown. In actual practice, tasks come from quite a few sources. The mission model describes the conditions and potential constraints that must be considered in defining the scenario, such as the impact of data constraints, initial energy prediction, and performance degradation. The output of the build system scenario block is scenario 80, which links various tasks with the module and gives priority to each task. In the example shown in FIG. 5, for example, the MPEG4 decode task has priority 16 and the wireless modem task has priority 4.

Scenarios built at block 54 may be based on various considerations. For example, scenarios can be built based on providing package thermal constraints for maximum performance. Alternatively, scenarios may be based on using the lowest possible energy. The optimal scenario is changeable during the operation of the device; For example, with a fully charged battery, the device can operate at the maximum performance level. Because power in the battery was reduced below the preset level, the device was operable at the lowest possible power level to maintain operation.

The scenario from block 54 is used by the activity prediction block 60 shown in FIG. This block performs probability estimation for various parameters that affect power usage in distributed processing system 10. Probabilistic activity prediction is generated in collaboration with the mission activity profile 62 and the model 64 of the hardware architecture. The task activity profile includes information about occurrences for data access (load / store) and other memory, code profiles such as branches or loops used for the task, and cycles per instruction for instructions in the task. Hardware architecture model 64 describes the impact of task activity profile 62 on system latency that will allow calculation of estimated hardware activity (such as processor operation / latency distribution). This model provides the characteristics of the hardware on which the test will be implemented, such as the size of the cache, the width of the various buses, the number of I / O pins, whether the cache is write through or write back, Consider the type of memory used (dynamic, static, flash, etc.) and the clock speed used by the module. Typically, the model may consist of a collection of curves that indicate MPU and DSP effective frequency changes with different parameters such as data cacheable / non-cacheable, read / write access share, number of cycles per instruction, and the like. In the embodiment illustrated in FIG. 6, values for the effective frequency, number of memory accesses, I / O toggle rate and DMA flow of each module are calculated. Other factors that affect power are also calculated.

Power calculation block 66 is shown in FIG. 8. In this block, the possible activity from block 60 or the measured activity from block 76 is used to calculate the power values for the various energy value periods T. The power value is calculated in relation to the hardware power profile inherent in the hardware design of the distribution processing system 10. The hardware profile may include Cpd, logic design style (D flip-flop, latch, gate clock, etc.), supply voltage and capacitive load on the output for each module. Power calculations can be made for integrated modules or external memory or other external devices.

Activity measurement and monitoring block 76 is shown in FIG. 8. Counters are implemented by the distributed processing system 10 to ensure cache misses, translation lookaside buffer (TLB) misses, non-cacheable memory access, latency, read / write requests for different resources, memory overhead, and temperature. Measures activity on various modules, etc. Activity measuring and monitoring block 76 outputs the value of the effective frequency of each module, the number of memory accesses, the I / O toggle rate and the DMA flow. In certain implementations, other values may also be measured. The output of this block is sent to the power calculation block 66.

9 shows an example of a distribution processing system 10 using power / energy management software. In this example, distributed processing system 10 includes MPU 12, execution OS, and two DSPs 14 (called DSP1 14a and DSP2 14b, respectively). Each module executes a monitor test 82 which monitors the values of various activity counters 78 throughout the distribution processing system 10. Various monitor tests retrieve data from the associated activity counter 78 to pass information to the DSP 14a and calculate power values based on the measurement activity. Power management tests, such as power calculation test 84 and monitor test 82, can be run in conjunction with other application tests.

In the preferred embodiment, the power management test 38 and profile 36 are implemented as JAVA class packages in a JAVA real-time environment.

The present invention provides significant advantages over the prior art. First, it provides complete dynamic power management. As tests run on distributed processing system 10 change, power management establishes new scenarios to ensure that thresholds are not exceeded. In addition, as environmental conditions, such as battery voltage drop, change, the power management software can review the conditions and change the scenarios if necessary. For example, if the battery voltage (power supply voltage) drops to the point where Vdd cannot be maintained at nominal value, a low frequency can be set that allows the distribution processing system 10 to operate at a lower Vdd. We can build a new scenario that takes into account low frequencies. In some cases, there may be more drops to compensate for the low frequencies. However, it can normally provide lower frequencies for continuous device operation despite insufficient supply voltage. Also, in situations where lower frequencies can be tolerated, the device can operate at lower Vdd (which enables the use of switch mode power supplies) to conserve power during periods of relatively low activity.

Power management software is transparent to tasks under control. Thus, even if a particular task does not provide any power management, the power management software executes the task in a manner suitable for the power performance of the distributed processing system 10. The overall operation of the power management software can be used on other hardware platforms that are adapted by changing the profile 36.

Although the detailed description of the invention has been made in connection with specific embodiments, various modifications as well as alternative embodiments will be possible to those skilled in the art. Accordingly, the invention includes all modifications and alternative embodiments falling within the scope of the claims.

Claims (22)

A method for controlling execution of a task in a processor having a plurality of processing modules, the method comprising: Calculating consumption information based on a probability value for activities associated with the task; Executing the task on the plurality of processing modules in response to the consumption information Task execution control method comprising a. The method of claim 1, Monitoring actual activity occurrences in the processing module; And And modifying the execution of the task based on the monitoring step. The method according to claim 1 or 2, The executing step includes executing the task on the plurality of processing modules in response to the consumption information to provide maximum performance within a range of thermal constraints associated with the processing system. How to control task execution. The method according to claim 1 or 2, And said executing step comprises executing said task on said plurality of processing modules in response to said consumption information to execute said task while consuming as little energy as possible. The method according to claim 1 or 2, The calculating step, Generating a task assignment scenario; Predicting the activity for a task assignment scenario; And Computing a consumption associated with the activity. The method of claim 5, Generating the task assignment scenario includes receiving a task list describing a task to be executed and a task model describing the task. The method of claim 6, The task model includes initial prediction for each task. The method of claim 7, wherein The task model further comprises priority constraints associated with the task. The method of claim 8, And the task model includes information regarding possible degradation associated with one or more tasks in the task list. The method of claim 5, And said calculating step includes calculating an energy expenditure associated with said activity. The method of claim 5, And said calculating step includes calculating a power consumption associated with said activity. In the processing device, One or more processing modules for executing the plurality of tasks, The processing subsystem Calculating consumption information based on a probability value for the activity associated with the annoying task; And Executing a power management function for controlling execution of the task on the processing module in response to the consumption information. Processing device, characterized in that. The method of claim 12, Further includes a counter for measuring the occurrence of the activity, The power management function, Monitor the counter; And modifying the execution of the task based on the value in the counter. The method according to claim 12 or 13, The power management function controls execution of a task on the processing module in response to the consumption information to provide maximum performance within a thermal limit associated with the processing system. The method according to claim 12 or 13, The power management function controls execution of a task on the processing module in response to the consumption information to perform the task while consuming the lowest energy possible. The method according to claim 12 or 13, The power management function, Create a task assignment scenario; Predict the activity for the task assignment scenario; And calculate consumption information by calculating consumption associated with the activity. The method of claim 16, And the power management function generates a task assignment scenario by receiving a task list describing the task to be executed and a task model describing the task. The method of claim 17, And the task model includes initial prediction for each task. The method of claim 18, The task model further comprises a preferential constraint associated with the task. The method of claim 19, And the task model includes information about possible degeneration associated with one or more tasks in the task list. The method of claim 16, And the power management function calculates energy consumption by calculating energy consumption associated with the activity. The method of claim 16, And the power management function calculates consumption by calculating power consumption associated with the activity.