Abstract:
An integrated circuit comprising a plurality of functional blocks, each functional block being operative to cause one or more power consuming events, each power consuming event being associated with a respective weight. The integrated circuit also comprises at least one accumulation block for monitoring the functional blocks over a time window and generating a weighted count of the number of occurrences of each power consuming event within the time window; and a power calculation module for calculating a runtime power consumption estimate over the time window using the weighted count. The weighted count may comprise a sum of products of each one of the power consuming events by its respective weight. Calculating the runtime power consumption estimate may comprise averaging the weighted count over the time window to generate a dynamic power estimate, calculating a leakage power estimate over the time window, and summing the dynamic power estimate with the leakage power estimate. The integrated circuit may further comprise a power management module for adapting power consumption of the integrated circuit based on a comparison of the runtime power consumption estimate with one or more predetermined thresholds.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates generally to power management in integrated circuits (ICs) and, more specifically, to ICs incorporating components that allow real-time power monitoring and management. 
       BACKGROUND 
       [0002]    Current trends in IC chip design have ever increasing power demands. For example, desire for better performance, higher levels of integration and smaller dimensions results in higher processor frequency and increasingly complex logic with higher density and higher switching activity. This increased demand for power, has led to corresponding efforts to reduce power consumption. 
         [0003]    One approach to reducing power consumption is to reduce the operational voltage of the chip. However, as the operational voltage decreases, propagation delays through the transistors increases. Though the threshold voltage can be reduced to help maintain the required performance, decreasing the threshold voltage increases the total leakage power. Therefore, there is a limit to this approach. 
         [0004]    Another approach reduces clock speeds. This of course, similarly, limits performance. 
         [0005]    In addition, there are situations where new applications have the potential to consume higher power than the circuits on which they run were designed. If execution of a new application causes power consumption to exceed circuit limits, the system could shut down. For many applications this is simply unacceptable. 
         [0006]    As will be appreciated, accurately controlling the power consumption state of an integrated is most effective when the current power consumption can be accurately assessed. As such, new methods and circuits for estimating and adapting power consumption of IC chips in real-time are desirable. 
       SUMMARY OF EMBODIMENTS OF THE INVENTION 
       [0007]    In an aspect of the present invention, there is disclosed an integrated circuit comprising: a plurality of functional blocks, each one of the of functional blocks being operative to cause one or more power consuming events, each one of the power consuming events being associated with a respective weight; at least one accumulation block for monitoring the plurality of functional blocks over a time window and generating a weighted count of the number of occurrences of each of the power consuming events within the time window; and a power calculation module for calculating a runtime power consumption estimate over the time window using the weighted count. 
         [0008]    In a further aspect, the weighted count comprises a sum of products of each one of the power consuming events by the respective weight. 
         [0009]    In a further aspect, calculating the runtime power consumption estimate comprises averaging the weighted count over the time window to generate a dynamic power estimate, calculating a leakage power estimate over the time window, and summing the dynamic power estimate with the leakage power estimate. 
         [0010]    In a further aspect, the integrated circuit further comprises a power management module for adapting power consumption of the integrated circuit based on a comparison of the runtime power consumption estimate with one or more predetermined thresholds. 
         [0011]    In a further aspect of the present invention, there is disclosed a method for use in managing runtime power consumption of an integrated circuit, the integrated circuit comprising a plurality of functional blocks, the method comprising: monitoring a plurality of power consuming events in the integrated circuit, each of the power consuming events being associated with a respective weight; generating a weighted count of each occurrence of each of the power consuming events within a time window; and calculating a runtime power consumption estimate associated with the power consuming events over the time window using the weighted count. 
         [0012]    Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]    In the figures which illustrate embodiments of the invention by example only, 
           [0014]      FIG. 1  is a simplified block diagram of computing device including a graphics processing unit, interconnected to a display device; 
           [0015]      FIG. 2  is a simplified block diagram of the graphics processing unit of the computing device of  FIG. 1 ; 
           [0016]      FIG. 3  is a simplified block diagram of the power estimation block of the graphics processing unit of  FIG. 2 ; 
           [0017]      FIG. 4  is a simplified block diagram of an embodiment of the power estimation block of the graphics processing unit of  FIG. 2 ; 
           [0018]      FIG. 5  is a simplified block diagram of an embodiment of the graphics processing unit of  FIG. 2 ; 
           [0019]      FIG. 6  is a flow diagram showing steps performed by the graphics processing unit of  FIG. 2 ; 
           [0020]      FIG. 7  is a flow diagram showing steps performed by the graphics processing unit of  FIG. 2 . 
       
    
    
     DETAILED DESCRIPTION 
       [0021]      FIG. 1  illustrates a simplified block diagram of computing device  102  interconnected to a display device  104 . Computing device  102  includes a processor  106  which may be a general purpose processor such as a conventional central processing unit (CPU). Processor  106  may be a microprocessor that has the x86 or x86-64 processor architecture. Alternatively, processor  106  may also have the PowerPC, SPARC or other architectures. Processor  106  is interconnected to memory and peripherals, through integrated interface circuits  110  and  112 . 
         [0022]    Integrated interface circuits  110  and  112  are sometimes referred to as North Bridge and South Bridge respectively, and are used to facilitate data communication between processor  106 , peripheral devices and memory  108 . 
         [0023]    The North Bridge interface circuit  110  may interconnect processor  106  with a graphics adapter expansion card  118 , a block of system memory  108  and the South Bridge interface circuit  112 . The South Bridge interface circuit  112  in turn may interconnect lower speed peripheral devices such as a network interface card (NIC)  116 , an audio adapter  120  (i.e., a sound card) and other lower speed peripherals (not specifically illustrated). 
         [0024]    A high speed expansion bus such as the Peripheral Component Interconnect Express (PCIe) may be used to interconnect the North Bridge interface circuit  110  with processor  106 , graphics adapter expansion card  118 , memory  108  and the South Bridge interface circuit  112 . In some embodiments, the North Bridge interface circuit  110  and the South Bridge interface circuit  112  may be combined into a single circuit or ASIC on the motherboard of device  102 . 
         [0025]    A graphics processing unit (GPU)  114  forms part of graphics subsystem  118 . Graphics subsystem  118  may be formed as part of a motherboard hosting computing device  100 , or as a stand-alone graphics adapter, formed on a peripheral expansion card. GPU  114  may be an application specific integrated circuit (ASIC). GPU  114  may be connected to a number of conventional voltage regulators (VRs)  115   a - n  which supply voltage to GPU  114 . As described in more detail below, a power management module in GPU  114  may adjust the voltage provided by VRs  115   a - n  based on a comparison between a real-time power consumption estimate for GPU  114  and one or more pre-determined thresholds. 
         [0026]    A simplified block diagram of GPU  114  is shown in  FIG. 2 . As shown, GPU  114  may be formed as an integrated circuit, to include a number of functional blocks (FBs)  202   a - n , a power estimation (PE) module  210 , and a power management (PM) module  212 . 
         [0027]    Functional blocks  202   a - n  represent the various functional blocks of a conventional GPU, and may include, for example, the different modules that make up a conventional graphics pipeline. As will be appreciated, a number of different power consuming events may occur within functional blocks  202   a - n  during execution of GPU  114 . 
         [0028]    As described in more detail below, power estimation module  210  monitors power consuming events occurring within functional blocks  202   a - n  at runtime and, based on the number of occurrences of those events, calculates an estimated value for dynamic power consumption in GPU  114 . Power estimation module  210  also calculates an estimated value for leakage power in GPU  114  and, based on both the dynamic and leakage power estimates, calculates a total power consumption value for GPU  114 . Power management module  212  may take one or more actions (such as changing the frequency, the voltage and frequency, or any other pre-programmed action) to adapt power consumption in GPU  114  based on the total power consumption value calculated by power estimation module  210 . 
         [0029]    Broadly, power estimation module  210  may model the power consumption in GPU  114  according to the following equation: 
         [0000]    
       
         
           
             
               
                 
                   Power 
                   = 
                     
                    
                   
                     Dynamic_Power 
                     + 
                     Leakage_Power 
                   
                 
               
             
             
               
                 
                   = 
                     
                    
                   
                     
                       C 
                       * 
                       A 
                       * 
                       F 
                       * 
                       
                         V 
                         2 
                       
                     
                     + 
                     Leakage_Power 
                   
                 
               
             
             
               
                 
                   = 
                     
                    
                   
                     
                       Cac 
                       * 
                       F 
                       * 
                       
                         V 
                         2 
                       
                     
                     + 
                     Leakage_Power 
                   
                 
               
             
           
         
       
     
         [0030]    As will be appreciated, leakage power depends on a number of chip parameters such as the temperature, voltage, and process corner (e.g. fast, typical or slow). The dynamic power is proportional to C, A, F, and V, where C is equivalent to switching capacitance to be charged or discharged in every clock cycle, A is the activity or switching factor, F is the operational frequency of GPU  114 , and V is the operational voltage of the GPU  114 . Cac is the product of capacitance and switching activity, or C*A. 
       Dynamic Power 
       [0031]    Power estimation module  210  is more specifically illustrated in  FIG. 3 . As shown, power estimation module  210  includes an accumulation block  302 , a power calculation module  304 , and a timer  311 . 
         [0032]    As shown in  FIG. 3 , accumulation block  302  includes a weighting accumulator  312  and a weight table  314  containing a set of weights  315 . Accumulation block  302  is configured to sample one or more signals from each functional block  202   a - n . The sampled signals provide indications to accumulation block  302  of the occurrence of power consuming events within functional blocks  202   a - n.    
         [0033]    Each weight  315  in table  314  is a predetermined value representing an approximation of the power consumption associated with an event monitored by accumulation block  302 . Thus, for a given set of events monitored by accumulation block  302 , there may be an associated set of corresponding weights  315  in weight table  314 . As described in more detail below, weighting accumulator  302  uses weights  315  and the signals received from functional blocks  202   a - n  to perform a weighted accumulation of events occurring within a predefined time interval (the “monitoring window”). After the conclusion of the monitoring window, which may be signalled by an interrupt from timer  311 , power calculation module  304  reads the accumulated weight from accumulation block  302 , and uses the accumulated weight to calculate an estimate of runtime dynamic power consumption in GPU  114 . 
         [0034]    The accuracy of the dynamic power estimate depends on the number and type of signals that are sampled by power estimation module  210 . Ideally, power estimation module  210  would sample every fine grain clock gating enable signal in GPU  114 , which would provide accurate information about the activity in GPU  114 . However, this is impractical considering the total number of signals that would need to be sampled. Therefore, monitoring is preferably performed at a coarser level focusing on functional events rather than looking at every register in the design. Advantageously, this event-based approach to calculating power consumption provides a reliable estimate of dynamic power consumption in GPU  114  that is based on a relatively small number of sampled signals. 
         [0035]    Timer  311  may be a programmable timer so that the size of the monitoring window may be selectively adjusted. It will be appreciated that the size of the monitoring window may be selected in accordance with conventional design principles so as to (a) ensure GPU  114  remains within its thermal design limit, and (b) avoid the over-current protection level set by voltage regulators  115 . In some embodiments, if both small (microseconds) and long (milliseconds) sized windows are desired, timer  311  may be set to a small size, and the output of weighting accumulator  312  may be stored in local memory for many windows so that the average power over the long window may be calculated. Advantageously, this approach enables GPU  114  to adjust for fast and slow events. 
         [0036]    During accumulation, weighting accumulator  312  may perform weighting by calculating the product of each detected event with a corresponding weight  315  in weight table  314 . Thus, at the conclusion of the monitoring window, the accumulated weight (AW) in weighting accumulator  312  may be represented by the following equation: 
         [0000]        AW =(num E 0* W 0)+(num E 1 *W 1)+(num E 2* W 2)+ . . . +(num En*Wn ) 
         [0000]    Where numEx is the number of occurrences of event Ex during the monitoring window. 
         [0037]    After the conclusion of the monitoring window, power calculation module  304  reads the accumulated weight from accumulation block  302 , and uses the accumulated weight to calculate an estimate of runtime dynamic power consumption in GPU  114 . The runtime dynamic power consumption value may accordingly be calculated in accordance with the following equation: 
         [0000]      Dynamic_Power= AW*F*V   2    
         [0038]    In the embodiment shown in  FIG. 3 , accumulation block  302  includes a shadow register  313  for latching the output of weighting accumulator  312  at the conclusion of the monitoring window. Weighting accumulator  312  may be cleared immediately after its contents are latched into shadow register  313  so that it may start accumulating events in the next monitoring window. Power calculation module  304  may then read the accumulated weight value from shadow register  313 . Thus, any delays in the read operation by power calculation module  304  would not delay event monitoring performed by weighting accumulator  312 . 
         [0039]    As the size and complexity of GPU  114  increases, and the number of functional blocks  202  rises, it may not be practical (for example, due to wire congestion) to send signals from every functional block  202  in GPU  114  to one centralized accumulation block  302 . To address this issue, a hierarchical approach to monitoring power consuming events may be used, as described below. 
         [0040]      FIG. 4  shows a power estimation module  410  designed using a hierarchical approach, whereby GPU  114  is divided into multiple monitored regions  430 , with each region being monitored by a separate accumulation block  402 . In the particular embodiment of  FIG. 4 , three monitored regions  430   a ,  430   b  and  430   c  which include, respectively, functional blocks  202   a  and  202   b ,  202   c  and  202   d , and  202   e  and  202   f , are shown. The three monitored regions  430  are monitored by three accumulation blocks  402   a ,  402   b , and  402   c , respectively. Each accumulation block  402  includes a weighting accumulator and a weight table, and operates in the same manner as described above in respect of accumulation block  302 . At the conclusion of the monitoring window, the outputs of accumulation blocks  402   a,b,c  are sent to an accumulation block adder  404 , for example via point to point connections or via a bus. Adder  404  adds the outputs from accumulation blocks  402   a,b,c  and stores the resulting total accumulated weight (AW) in a register  405 . Power calculation module  304  subsequently reads the total AW from register  405  in order to calculate an estimate of runtime dynamic power consumption in GPU  114 , as described above. 
         [0041]    The interface between functional blocks  202  and power accumulation block  302 / 402  may be based on a push model whereby functional blocks  202  generate a pulse every time a monitored event occurs. To reduce the number of pulses signalled to accumulation block  302 / 402 , functional blocks  202  may be designed to generate one pulse for every Nth time each event occurs. This approach may reduce the dynamic power consumption associated with pulsing signals over the potentially long wires connecting functional blocks  202  to accumulation block  302 / 402 . Under this approach, the assigned weights  315  in table  314  may be selected to account for the fact that each pulse is indicative of N occurrences of a particular event. 
         [0042]    As noted, the accuracy of the dynamic power estimate depends on the number and type of signals that are sampled. Determining the right number of signals and events to monitor may be achieved through detailed analysis of the relation between the power consumption of the functional blocks of GPU  114  and a number of selected signals from each block. Therefore, and as explained in more detail below, a series of tests may be performed with different data toggle rates and workloads so that the power consumption of GPU  114  may then be correlated with the toggle rate of the sampled signals, and suitable weights  315  for use by accumulation block  302  may be determined. 
         [0043]    An approach for selecting a set of events (E 0 , E 1 , . . . En) to be monitored, and for determining appropriate corresponding weight values (W 0 , W 1 , . . . Wn) will now be described. Broadly, for each functional block in GPU  114  a minimum number of mutually exclusive events having significant effect on power may be selected. A number of representative applications and tests that create different toggle rates—e.g. from 0% to 100% to cover a wide range of activities—may then be executed on GPU  114  for the purpose of resolving, for each application, the following equation: 
         [0000]      (num E 0 *W 0+num E 1 *W 1+ . . . +num En*Wn )* F*V 2=Measured_Power 
         [0000]    Where numEx is the measured number of occurrences of event x, Measured_Power is the measured power consumption, and the weights Wn are unknown values to be resolved. 
         [0044]    It will be appreciated that if the above equation contains N variables, it will be necessary to generate at least N sets of measured values in order to resolve the N variables. More specifically, event occurrences and power consumption are measured as representative applications/tests are executed on GPU  114 , and at least N sets of measured values are generated in order to resolve the above equation for the set of weights Wn. While it is possible to conduct this analysis pre-silicon using power estimation tools that operate, for example, at RTL (Register Transfer Level), synthesis level, post-route, or SPICE (Simulation Program with Integrated Circuit Emphasis), post-silicon analysis in addition to or in lieu of pre-silicon analysis is desirable as it will generally provide faster and more accurate results. A drawback of post-silicon analysis however is that it does not provide information as to whether the events selected for power estimation correctly represent the power consumption of GPU  114 . In this regard, pre-silicon analysis at the functional block level may allow for refinement of the chosen set of events prior to post-silicon testing. Specifically, a number of vectors may be generated pre-silicon to mimic as closely as possible the conditions of individual functional blocks. Based on the generated vectors, the individual functional blocks are analysed pre-silicon and the above equation is resolved for each tested functional block based on an initial set of events chosen, for example, by the designers of each functional block. If the error in the resolved weights exceeds a predetermined threshold (e.g. 2-3%), the chosen set of events for the functional block may be refined and the pre-silicon test conducted again. The error may be calculated as: (numE 0 *W 0 +numE 1 *W 1 + . . . +numEn*Wn)*F*V 2 −Measured_Power=error. 
         [0045]    To achieve a higher degree of granularity during testing, each representative application may be split into multiple time windows, and a set of measured values (number of event occurrences and dynamic power consumption) may be gathered for each time window, resulting in one equation to be solved per time window. Thus, execution of a given application may result in multiple equations to be resolved—i.e. since the application is split into multiple timing windows, the application will generate multiple equations. Also, since the weights Wn are intended to work with a range of applications, it may be desirable to use measurements from many representative applications to resolve the above-noted equation. 
         [0046]    In post-silicon testing, to determine the number of occurrences of a given event E in a given time interval for a given application, all weights  315  in weight table  314  ( FIG. 3 ) may be set to zero save for the weight corresponding to the event E, which may be set for example to one. On conclusion of the time interval, the accumulated weight value in shadow register  313  of accumulation block  302  will accordingly be equal to the number of occurrences of event E. At each time interval, the accumulated weight value is stored in local memory for post-processing. Using this approach, each application will need to be run multiple times—i.e. once for each event—in order to determine all of the numEx values for the application. In the embodiment of  FIG. 4 , it may be possible to reduce the number of times a given application needs to be run in order to determine all events. Specifically, each monitored region  430  may be associated with a different subset of the set of all monitored events for GPU  114 . During testing, the output of each accumulation block  402  may be stored in local memory at the end of each monitoring time interval (i.e. bypassing adder  404 ). Thus, at each time interval each accumulation block  402  generates one numEx value for an event from its corresponding monitored region  430 . Through this process, eventually all numEx values are determined for each time interval of each application. As power consumption for each time interval is also measured during testing, the above equation can be resolved and appropriate weights calculated. 
         [0047]    In some instances, pre-silicon testing may allow for simplification of the post-silicon analysis. As will be appreciated, through conventional pre-silicon analysis the power consumption ratio between different events within a given functional block may be determined. For example, in a functional block with four types of events (E 1 , E 2 , E 3 , E 4 ), pre-silicon testing may indicate that E 1  accounts for 50%, E 2  20%, E 3  20%, and E 4  10% of the power consumption in the functional block. Thus, post-silicon analysis may be simplified to resolving a total weight for the functional block (rather than resolving individual weights for each event), and the total weight may then be apportioned amongst the four events according to the pre-determined ratios. Continuing with the foregoing example, if post-silicon analysis were to resolve the total weight for the functional block to be 1 Watt, the following weights may then be assigned to the four events: 500 mW, 200 mW, 200 mW and 100 mW. 
       Leakage Power 
       [0048]    To calculate leakage power over the monitoring window, power calculation module  304  uses a leakage table  306  which represents the variation in leakage power in relation to temperature and voltage for GPU  114 . 
         [0049]    As is known, the variation in leakage power in relation to voltage and temperature varies depending on certain physical properties (e.g. process corner) of GPU  114 . A leakage identifier indicative of the physical properties of GPU  114  is fused in the GPU in a manner known in the art. A device driver may read the leakage identifier at device start-up and, based on the identifier, load values into leakage table  306  that are specific to the physical properties of GPU  114 . 
         [0050]    GPU  114  includes a number of thermal sensors (not shown) for providing temperature readings, the outputs of which are used by power calculation module  304  together with the GPU voltage level to determine which entry from table  306  to select, and thereby determine an estimate value for leakage power for a given monitoring window. As is known, the GPU voltage level may be read for example from a voltage level register on GPU  114 . 
       Power Management 
       [0051]    Once dynamic power and leakage power are calculated, power calculation module  304  adds the two values to produce a total power consumption estimate for GPU  114 . Power management module  212  may then compare the total power estimate with one or more pre-determined thresholds—for example, upper and lower power limits for GPU  114 . The upper power limit may be the Thermal Design Limit (TDP) for GPU  114 , and it may be fused in the GPU  114 . During initialization, the fused TDP value may be read by a device driver and stored into a local register, in manners known in the art. At runtime, if the total power estimate calculated by power calculation module  304  exceeds the upper power limit, power management module  212  may take action to reduce power consumption in GPU  114 , such as by lowering the frequency/voltage of GPU  114 , power gating one or more functional blocks (e.g. a SIMD), or disabling one or more functional blocks (e.g. the scheduler may not issue any instructions to one or more SIMDs). Similarly, if the total power estimate calculated by power calculation module  304  falls below the lower power limit, power management module  212  may take action to reverse one or more of the aforementioned actions. 
         [0052]    Thus, advantageously, the ability to monitor switching activity and deterministically estimate runtime power consumption in GPU  114  enables power management module  212  to adapt power consumption in GPU  114  based on the workload to achieve low power in low activity periods and to stay within power budget in high activity periods. 
         [0053]    While power estimation module  210  may be implemented entirely in hardware, the cost in terms of area and loss of programming flexibility may be undesirable. In the embodiment shown in  FIG. 5 , a combination of hardware and software is used to implement the power estimation and power management functionality described above. As shown, a GPU  514  consists of hardware including a number of functional blocks  501   a - f , a number of accumulation blocks  502   a - c , an adder  504  with a register  505 , a timer  511 , and a microcontroller  530 . Microcontroller  530  is configured to execute software implementing a power calculation module  506  and a power management  512 . 
         [0054]    The operation of GPU  514  will now be described with reference to the flow diagrams of  FIGS. 6 and 7 . 
         [0055]    During hardware initialization, a device driver sets the weights (not shown) in accumulation blocks  502  and loads the leakage table into the local memory (not shown) of microcontroller  530  (step  602 ). If power estimation is enabled on GPU  514  (step  604 ), timer  511  is started and it begins counting the first monitoring window (step  608 ). Accumulation blocks  502  perform weighted accumulation (step  610 ) until timer  511  generates an interrupt (step  612 ) signalling conclusion of the monitoring window. At the conclusion of the monitoring window, the accumulated values from accumulation blocks  502  are latched into respective shadow registers (step  614 ). Immediately after step  614 , timer  511  may be re-started (step  608 ) to begin counting the next monitoring window. Adder  504  subsequently sums the accumulated values from accumulation blocks  502  and stores the resulting aggregate value in register  505  (step  616 ). 
         [0056]    On the software side, when microcontroller  530  receives an interrupt from timer  511  (step  702 ), power calculation module  506  reads the aggregate value from register  505  (step  704 ) and averages the aggregate value over the monitoring window to calculate a dynamic power consumption estimate (step  706 ). Power calculation module  506  then reads the temperature and voltage level of GPU  514  to obtain the appropriate leakage power value from the leakage table (step  708 ). Power calculation module  506  then sums the dynamic power consumption estimate and leakage power value to generate a total power consumption value (step  710 ), and clears the timer interrupt (step  712 ). Power management module  512  may then compare the total power consumption value to pre-determined thresholds and perform any power management actions as may be required (step  714 ). 
         [0057]    Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.