Title of Invention: Shared Power Rail Peak Current Manager Abstract: Various embodiments include a shared power rail monitoring circuit included in integrated circuits configured to manage worst case power on a shared power rail within the integrated circuit. Various embodiments include circuit components configured to determine allocated currents for each processing block or subsystem core on the shared power rail based on operating parameters of each processing block or subsystem core, and set a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail. The operating parameters may be voltage or voltage mode, temperature and operating frequency of each processing block or subsystem core. Detailed Description: BACKGROUND Modern integrated circuit products integrate numerous computational and other types of processors or “cores” combined into integrated systems. Integrating multiple processors and subsystems within a single integrated circuit or package saves real estate in devices using such components, and reduce cost and power demands. In some designs, multiple processing blocks or subsystem cores may share a power rail to enable more compact designs and reduce the number of power control circuits. However, doing so complicates the problem of ensuring that the shared power rail is not subject to power demands that exceed the capacity of the power rail. SUMMARY Various aspects of the present disclosure include methods of setting worst case power limits for managing dynamic currents on shared power rails based on multiple operating factors and states within an integrated circuit. Various aspects include Various aspects include a shared power rail monitoring circuit within an integrated circuit that may include one or more data registers within the integrated circuit configured to receive operating parameters of one or more processing blocks or subsystem cores coupled to a shared power rail, and a controller coupled to the one or more data registers and configured with executable instructions to determine allocated currents for one or more processing blocks or subsystem cores on the shared power rail based on operating parameters of each processing block or subsystem core, and set a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for one or more processing blocks or subsystem cores on the shared power rail. In some aspects the controller may be further configured with executable instructions to determine allocated currents for one or more processing blocks or subsystem cores on the shared power rail based on operating parameters of each processing block or subsystem core by determining allocated currents using a set of lookup tables correlated to operating parameters of each processing block or subsystem. In some aspects the controller may be further configured with executable instructions to compare a total of allocated currents for all processing blocks or subsystem cores on the shared power rail to a current limit of the shared power rail, and the controller may be further configured to set a mitigation level for one or more processing blocks or subsystem cores on the shared power rail by setting a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the comparison of the allocated currents to the current limit of the shared power rail. In some aspects the operating parameters received on the one or more data registers may include voltage or voltage mode, temperature and operating frequency of each processing block or subsystem core coupled to a shared power rail, and the controller may be configured with executable instructions to determine allocated currents for each processing block or subsystem core on the shared power rail based on voltage or voltage mode, temperature and operating frequency of each processing block or subsystem core. Some aspects may further include a set of leakage current and dynamic current lookup tables for each processing block or subsystem core coupled to a shared power rail, in which each leakage current table stores an allocated leakage current indexed to a voltage or voltage mode and a temperature for the respective processing block or subsystem core, and each dynamic current lookup table stores an allocated leakage current indexed to a voltage or voltage mode and a frequency of the respective processing block or subsystem core, and a rail current summing circuit configured to receive allocated leakage and dynamic currents from the lookup tables and output to the controller a total allocated current for processing blocks or subsystem cores coupled to the shared power rail. In such aspects, the controller may be coupled to the set of leakage current and dynamic current lookup tables for each processing block or subsystem core coupled to a shared power rail, and to the rail current summing circuit. In such aspects, the controller may be configured with a policy module configured to determine allocated currents for each processing block or subsystem core on the shared power rail based on operating parameters of each processing block or subsystem core by receiving voltage or voltage setting, temperature and frequency data from the processing blocks or subsystem cores, using the voltage or voltage setting, temperature and frequency data as indices in lookup tables to determine a leakage current and a dynamic current of each processing block or subsystem core on the shared power rail and summing the determined leakage and dynamic currents to determine allocated current for each processing block or subsystem core on the shared power rail, and adding the allocated currents for all processing blocks or subsystem cores on the shared power rail. In such aspects, the controller may be configured to set a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail by comparing a sum of the allocated currents for all processing blocks or subsystem cores on the shared power rail to a limit of the shared power rail, applying a policy to a result of the comparison to determine a mitigation level for one or more of the processing blocks or subsystem cores on the shared power rail, and communicating each determined mitigation level to a local level monitor module within a respective processing block or subsystem core. In some aspects the controller may configured to set the mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail by determining whether a total of the determined allocated currents of the processing blocks or subsystem cores exceeds a current limit of the shared power rail, incrementing a power mitigation level for one or more processing blocks or subsystem cores on the shared power rail in response to determining that the total of the determined allocated currents of the processing blocks or subsystem cores exceeds the current limit of the shared power rail, determining whether the total of the determined allocated currents of the processing blocks or subsystem cores is less than a hysteresis amount less than the current limit, decrementing a power mitigation level for one or more processing blocks or subsystem cores on the shared power rail in response to determining that the total of the determined allocated currents of the processing blocks or subsystem cores is less than a hysteresis amount less than the current limit, and delaying a period of time associated with the power mitigation level before again determining whether the total of the determined allocated currents of the processing blocks or subsystem cores exceeds a current limit of the shared power rail. Some aspects may include methods of managing, by a shared power rail monitoring circuit, power demand on a shared power rail within an integrated circuit. Such aspects may include determining allocated currents for each processing block or subsystem core on the shared power rail based on operating parameters of each processing block or subsystem core, and setting a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail. In some aspects, determining allocated currents for one or more processing blocks or subsystem cores on the shared power rail based on operating parameters of each processing block or subsystem core may include determining allocated currents using a set of lookup tables correlated to operating parameters of each processing block or subsystem. Some aspects may further include comparing a total of allocated currents for all processing blocks or subsystem cores on the shared power rail to a current limit of the shared power rail, in which setting a mitigation level for one or more processing blocks or subsystem cores on the shared power rail may include setting a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the comparison of the allocated currents to the current limit of the shared power rail. Some aspects may further include receiving a current measurement of a processing block or subsystem core by the shared power rail monitoring circuit, in which comparing the total of allocated currents for all processing blocks or subsystem cores on the shared power rail to a current limit of the shared power rail may include comparing a total of measured and allocated currents for all processing blocks or subsystem cores on the shared power rail to the current limit of the shared power rail, and setting the mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the comparison of the allocated currents to the current limit of the shared power rail may include setting the mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the comparison of the measured and allocated currents to the current limit of the shared power rail. In some aspects, determining allocated currents for each processing block or subsystem core on the shared power rail based on operating parameters of each processing block or subsystem core may include receiving voltage or voltage setting, temperature and frequency data from the processing blocks or subsystem cores, using the voltage or voltage setting, temperature and frequency data as indices in lookup tables to determine leakage current and dynamic current of each processing block or subsystem core on the shared power rail, adding leakage currents and dynamic currents for all processing blocks or subsystem cores on the shared power rail, and providing the sum of leakage currents and dynamic currents for all processing blocks or subsystem cores on the shared power rail to a policy module of the shared power rail monitoring circuit. In some aspects, setting a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail may include applying a policy, by the policy module of the shared power rail monitoring circuit, to the sum of leakage currents and/or dynamic currents for processing blocks or subsystem cores on the shared power rail to determine a mitigation level for each processing block or subsystem core on the shared power rail, and communicating each determined level to a local level monitor module within a respective processing block or subsystem core. In some aspects using the voltage or voltage setting, temperature and frequency data as indices in lookup tables to determine leakage current and dynamic current of each processing block or subsystem core on the shared power rail may include for each processing block or subsystem core using the voltage or voltage setting and temperature of the processing block or subsystem core as indices to perform a look up in a leakage lookup table for that processing block or subsystem core to determine the leakage current for the processing block or subsystem core, and using the voltage or voltage setting and frequency of the processing block or subsystem core as indices to perform a look up in a dynamic current lookup table for that processing block or subsystem core to determine the dynamic current for the processing block or subsystem core. In some aspects adding leakage currents and dynamic currents for all processing blocks or subsystem cores on the shared power rail may include adding the leakage current and the dynamic current for each processing block or subsystem core to determine a total allocated current for each processing block or subsystem core, providing the sum of leakage currents and dynamic currents for all processing blocks or subsystem cores on the shared power rail to the policy module of the shared power rail monitoring circuit may include providing the total allocated current for each processing block or subsystem core to the policy module of the shared power rail monitoring circuit, and setting a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail may include applying a policy, by the policy module of the shared power rail monitoring circuit, to the sum of leakage currents and/or dynamic currents for all processing blocks or subsystem cores and each determined allocated current for the processing blocks or subsystem cores the on the shared power rail to determine a mitigation level for each processing block or subsystem core on the shared power rail, and communicating each determined level to a local level monitor module within a respective processing block or subsystem core. Some aspects may further include determining an operating mode of the integrating circuit, in which setting a mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail may include setting the mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined operating mode and the determined allocated currents for each processing block or subsystem core on the shared power rail. In some aspects setting the mitigation level for one or more processing blocks or subsystem cores on the shared power rail based at least in part on the determined allocated currents for each processing block or subsystem core on the shared power rail may include determining whether a total of the determined allocated currents of the processing blocks or subsystem cores exceeds a current limit of the shared power rail, incrementing a power mitigation level for one or more processing blocks or subsystem cores on the shared power rail in response to determining that the total of the determined allocated currents of the processing blocks or subsystem cores exceeds the current limit of the shared power rail, determining whether the total of the determined allocated currents of the processing blocks or subsystem cores is less than a hysteresis amount less than the current limit, decrementing a power mitigation level for one or more processing blocks or subsystem cores on the shared power rail in response to determining that the total of the determined allocated currents of the processing blocks or subsystem cores is less than a hysteresis amount less than the current limit, and delaying a period of time associated with the power mitigation level before again determining whether the total of the determined allocated currents of the processing blocks or subsystem cores exceeds a current limit of the shared power rail. Further aspects may include an integrated circuit device having a shared power rail management circuit configured to perform one or more operations of the methods summarized above. Further aspects include a shared power rail management circuit having means for performing functions of the methods summarized above. Further aspects include a system on chip for use in a wireless device that includes an integrated circuit device having a shared power rail management circuit configured to perform one or more operations of the methods summarized above. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary aspects of the claims, and together with the general description given above and the detailed description given below, serve to explain the features of the claims. FIG. 1 is a component block diagram illustrating a computing system of two systems-on-chip that may be configured to implement a shared power rail management circuit in accordance with various embodiments. FIG. 2 is a circuit block diagram of a portion of an integrated circuit that includes a shared power rail monitor configured to implement a first approach for monitoring current on a shared power rail. FIG. 3 is a graph illustrating power draws from a shared power rail by two processing blocks with power managed by the first approach for monitoring current on a shared power rail. FIG. 4 is a circuit block diagram of a portion of an integrated circuit that includes a shared power rail monitor circuit for ensuring current on a shared power rail remains within limits according to various embodiments. FIG. 5 is a state diagram illustrating operating states of a shared power rail monitor circuit monitoring current on a shared power rail according to various embodiments. FIGS. 6A and 6B are examples of lookup tables for determining allocated current of a processing block or subsystem core based upon its operating states of voltage state, temperature and frequency in accordance with various embodiments. FIG. 7 is an example table identifying different mitigation levels that may be set by a shared power rail monitor circuit according to various embodiments. FIGS. 8A, 8B, 9A, 9B, 10 and 11 are process flow diagrams illustrating methods that may be implemented within a shared power rail monitor circuit for ensuring current on a shared power rail remains within limits according to various embodiments. FIG. 12 is a component block diagram of a wireless device suitable for implementing dynamic thermal management for enhancing thermal performance in 5G enabled devices in accordance with various aspects of the present disclosure. DETAILED DESCRIPTION Various aspects will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims. In many modern integrated circuit products, multiple processing cores, processing blocks, processor cores within various subsystems are combined into a system implemented on a single integrated circuit or chip, which are frequently referred to as a system-on-chip (SOC). Larger scale integration of multiple functionalities may be integrated within the same packaging including multiple chips, which are sometimes referred to as a system-in-package (SIP). Integrating multiple functionalities and processors and subsystem components in a single SOC reduces the physical area and volume of the electronics use in products, reduces power demands (and thus extends battery life), and reduces overall costs of the components. In some SOC designs, multiple processing blocks or subsystem cores are connected to and receive power from a common power rail, referred to herein as a shared power rail. Designing an SOC so multiple subsystem cores draw power from the same power rail simplifies the design and reduces the number of power rail management modules or circuits required in the SOC. Thus, the shared power rail architecture increases the density of functional cores on the SOC, reduces complexity, and thereby reduce costs. However, integrating multiple processing blocks or subsystem cores on a shared power rail complicates the problem of ensuring that the power rail is not subject to power demands that exceed the capacity of the power rail. This is because independent processing blocks or subsystem cores will exhibit independent power demands on the shared power rail as their respective processes and functionalities turn on and off, and experience different loadings. For example, when the graphics processor is executing a graphics rendering process, a camera or DSP may not be operating, and thus the demand on the power rail will be driven by the graphics processor. However, if another processing block or subsystem begins a processing operation or executing a new thread, that processing block/subsystem core would draw power from the shared power rail. If many processing blocks or subsystem cores connected to the shared power rail were to execute at significant processing rates (e.g., at a maximum current draw) simultaneously, the shared power rail could experience a current that exceeds its limits. To address this problem, the shared power rail may be sized to accommodate the worst case power draw of all connected blocks/cores, or circuitry may be included in SOCs to ensure rail power or current limits are not exceeded. One approach to ensuring rail power or current limits are not exceeded involves including a power monitoring circuitry within the SOC that receives measurements of the current drawn by certain connected processing blocks or subsystem cores, and implements restrictions or mitigation actions on processing blocks or subsystem cores so that the total current on the shared power rail does not exceed its limits Mitigation actions that may be imposed on processing blocks or subsystem cores include operating at lower frequency or voltage, and could include suspending some operations if necessary. Factors affecting the power demand by a processing block or subsystem core include the level of activity involved in processing a computational thread, the frequency at which the core is operating, the voltage or voltage regime in which the core is operating, the temperature of that core, and the fabrication process variability of silicon. Current drawn by processing blocks or subsystem cores connected to the shared power rail may be measured (e.g., by a current sensor), all measured currents of processing blocks or subsystem cores may be summed to determine a total current draw, and the total current compared to a limit for the shared power rail. If the shared power rail current limit is exceeded, signals may be sent to a local limits management (LLM) module within one or more processing blocks or subsystem cores to impose a mitigation level to reduce current demand. As explained in more detail herein, this process of ensuring the measured currents of processing blocks or subsystem cores remains below a limit works well, but suffers from a need to provide a safety margin because not all processing blocks or subsystem cores include a power or current monitoring sensor providing power/current data to the power monitoring circuitry. Therefore, power mitigation actions imposed on core activities need to be implemented at a total current level that is less than the total capacity of the shared power rail in order to provide a sufficient safety margin to account for processing blocks or subsystem cores that are not directly monitored. Thus, the full capacity of the shared power rail is not utilized. Various embodiments provide methods and circuitry for better managing power on a shared power rail by determining the leakage and dynamic current demands of processing blocks or subsystem cores based upon their operating parameters and knowledge of how those operating parameters effect the total current that may be drawn from the shared power rail. The total current that may be drawn from the shared power rail by a given processing block or subsystem core includes leakage current and/or dynamic current. The term “leakage current” refers to the amount of current drawn by a processing block or subsystem core based on temperature and voltage even in an idle state. The term “dynamic current” refers to the current drawn from the shared power rail that varies depending upon the activity level of each processing block or subsystem core. In some processing blocks or subsystem cores the leakage current may dominate, depending on the type of circuitry and processing activity. In processing blocks or subsystem cores with high activity (e.g., processing load), the dynamic current may dominate. The leakage current draw and dynamic current draw of each processing block or subsystem core under different operating conditions/activity can be determined through design analysis, simulation and/or testing, and correlated to particular operating parameters, with the results stored in lookup tables or reflected in parametric relationships. The operating parameters may include the voltage, temperature and frequency of the processing blocks or subsystem cores. Knowing these operating parameters, a controller can estimate the leakage and/or dynamic currents of each processing block or subsystem core. By estimating the total current draw that needs to be accounted for or allocated to each processing block or subsystem core based upon known operating parameters, various embodiments provide mechanisms that can better account for the worst-case and most likely demands on the shared power rail. By doing so, safety margins imposed on the operating limits of the shared power rail may be significantly reduced or eliminated. Additionally, there is less need for power manage and measuring circuitry in each processing block or subsystem core. The term “system on chip” (SOC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and/or processors integrated on a single substrate. A single SOC may contain circuitry for digital, analog, mixed-signal, and radio-frequency functions. A single SOC may also include any number of general purpose and/or specialized processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, Flash, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). SOCs may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices. The term “processing block” is used herein to refer generally to a portion of an SOC that functions together to process data to provide a particular functionality. Processing blocks may include one or more programmable processors executing software or firmware instructions, dedicated circuitry (i.e., “hardware”) that performs the data processing, or a combination of a one or more programmable processors and dedicated circuitry. Examples of processing blocks include digital signal processors, memory controllers, cache memories, logic register banks, digital signal processors, hardened algorithm processors, network infrastructure for data flow control, read-only memory (ROM), random-access memory (RAM), interface protocol controllers, etc. The term “subsystem core” is used herein to refer generally to a portion of an SOC that functions as a subsystem and includes at least one processor core. Examples of subsystem cores include central processor units (CPUs), graphic processing units (GPUs), modem processors, audio digital signal processor (DSPs), sensor DSPs, double data rate (DDR) memory, camera/video/display processors, etc. The term “system in a package” (SIP) may be used herein to refer to a single module or package that contains multiple resources, computational units, cores and/or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, the SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unifying substrate. A SIP may also include multiple independent SOCs coupled together via high speed communication circuitry and packaged in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high speed communications and the sharing of memory and resources. Various embodiments take advantage of the fact that the leakage current and dynamic or dynamic current of a processing block or subsystem core can be predicted using a limited number of operating properties parameters, particularly, voltage temperature and operating frequency. Knowing these operating parameters, leakage and dynamic current demands of a given processing block or subsystem core can be determined using simulations, prototype and production testing, and design algorithms. For example, simulations of a design of a given processing block or subsystem core can be used to determine most likely power leakage and dynamic current demands at each of a variety of operating conditions (i.e., various combinations of voltage, temperature and frequency). The determinations of allocated current can be made for each processing block or subsystem core present in the SOC design. This enables the determinations to account for differences in the physical designed and operating characteristics of each circuit or chip. These determinations may then be recorded in lookup tables that may be stored in non-volatile memory within the SOC. A shared rail monitoring subsystem may then use the same operating parameters (e.g., voltage, temperature and frequency) that were used in filling in the table data as look up indices. Such lookup tables may be loaded in memory at the time of manufacture or loaded or updated in a later provisioning operation. Storing leakage or current lookup tables for each processing block or subsystem core within the SOC enables a shared power rail monitoring circuit to accurately predict the dynamic current draw that is likely or possible under the current operating conditions for each processing block or subsystem core on the shared power rail using just a few operating parameters, such as voltage, temperature and operating frequency. In some embodiments, rather than using a look up table, the same information may be implemented within predictive algorithms that can be executed using similar operating characteristics (e.g., voltage, temperature and frequency) to obtain an allocated current for the respective processing block or subsystem core. The operating temperature of each processing block or subsystem core may be obtained by temperature sensors implemented in each core's circuitry that communicate temperature data via any of a variety of data communication circuits, such as a systemwide data bus. Temperature information may be received from the systemwide data bus by a shared rail monitoring circuit within the SOC. Voltage levels or voltage regimes of each core are known to the system and be communicated via a shared data bus. The voltage or voltage regime information may be received from the systemwide data bus by the shared rail monitoring circuitry. Operating frequency data can be written to a common system register (CSR) within the shared rail monitoring circuitry by software executing within each of processing block or subsystem core. Thus, the information needed to determine allocated currents for each processing block or subsystem core can be obtained through shared data buses and resources and then used to in a lookup table process (or in an algorithm) by the shared rail monitoring circuitry within the SOC. The allocated currents for all processing blocks or subsystem cores on the same shared power rail may be added together in a summing circuit of the shared rail monitoring circuitry to determine an aggregate current that could be imposed (e.g., in a worst-case situation) on the shared power rail if mitigation actions are not taken in at least some processing blocks or subsystem cores. The shared rail monitoring circuitry may then compare the total of all allocated currents to one or more limits of the shared power rail. If the shared rail monitoring circuitry determines that the total allocated current draw that could be imposed on the shared power rail exceeds a limit, the shared rail monitoring circuitry may determine one or more mitigation actions that should be taken to reduce the total allocated current draw to within the limit. If the shared rail monitoring circuitry determines that the total allocated current draw that could be imposed on the a shared power rail is less than the limit by a sufficient amount, referred to herein as a hysteresis amount, the shared rail monitoring circuitry may change the mitigation level imposed on some processing blocks or subsystem cores to enable operation at higher power (e.g., at a higher operating frequency and/or voltage) to improve their performance. The hysteresis amount may serve to prevent oscillation between two or more different performance levels with one level causing the other level to cross a threshold and revert back, a situation that could impact the user experience. In various embodiments, the shared rail monitoring circuitry may include a policy circuit or module configured to determine the level of mitigation actions to set for individual processing blocks or subsystem cores to address an over-limit or under-limit current draw situation consistent with various design targets and user operating modes. Decisions from such a policy module may then be communicated to local limit manager circuits (“LLM” in the figures) in each processing block or subsystem core that is to implement a particular mitigation level. The local limit manager is a circuit or controller that can control the operating point of its processing block or subsystem core. The local limit manager can take actions to maintain its core within the mitigation level set by the shared rail monitoring circuitry. When all processing blocks or subsystem cores operate in this manner to remain within mitigation levels set by the share power rail monitoring circuitry, the overall demand on the shared power rail will not exceed limits while permitting processing blocks or subsystem cores to operate at an appropriate power level consistent with current operations or processes of the SOC. Mitigation actions may be taken at the processing block or subsystem core level by its local limit manager. Specifically, each local limit manager may compare the operating state of its core (e.g., current, voltage, frequency or other operational parameter defined by a mitigation level) to the operating state limit(s) defined by the mitigation level set by the shared rail monitoring circuitry (e.g., the policies circuit or module). If the core is exceeding the operating state limit(s) defined by the mitigation level set by the shared rail monitoring circuitry, then the local limit manager may take an action to cause the core to comply with mitigation level. Thus, if the total of allocated currents of processing blocks or subsystem cores connected to the shared power rail exceeds the total current limit of the shared rail and the operating state of a particular processing block or subsystem core exceeds its local limit as defined by a set mitigation level, then the local limit manager will take an action that will reduce the current draw by a processing block or core. Similarly, if the total of allocated currents of all processing blocks or subsystem cores is less than a limit on the shared power rail, the shared rail monitoring circuit may set the mitigation level of individual processing blocks or cores at a lower level of mitigation (such as permitting high-frequency operations), thereby enabling individual processing blocks or subsystem cores to operate in modes with greater power consumption when operating conditions permit. The processes of monitoring operating temperature, voltage and frequency of processing blocks or cores may be performed continuously, thereby enabling the shared rail monitoring circuit to account for and manage dynamic changes occurring within cores connected to the shared power rail. For example, if a particular subsystem core initiates an operation, function or computational thread that would benefit from a higher operating frequency (i.e., clock frequency), the new operating frequency may be written to the condition and status register (CSR in the figures), thereby enabling the shared rail monitoring circuit to update the current allocated to that particular subsystem core, and update the mitigation levels of processing blocks or subsystem cores if necessary to maintain the shared power rail within operating limits. Various embodiments improve the performance of integrated systems that include multiple processing blocks or subsystem cores powered by a shared power rail on a single chip (i.e., an SOC) or within an integrated package (i.e., an SIP) by limiting power demands on the shared rail while enabling full use of the power capacity of the shared rail, such as by enabling processing blocks or subsystem cores to operate at greater power levels when operating conditions (e.g., temperature) permit. For example, the current allocated to one or more processing blocks or subsystem cores may be increased as the operating temperatures of processing blocks or subsystem cores within an SOC decline (e.g., may happen when a user equipment is operating in cold conditions), because the leakage current of processing blocks or subsystem cores decreases with decreasing temperature. The term “multicore processor” may be used herein to refer to a single integrated circuit (IC) chip or chip package that contains two or more independent processing cores (e.g., CPU core, internet protocol (IP) core, graphics processing block (GPU) core, etc.) configured to read and execute program instructions. A SOC may include multiple multicore processors, and each processor in an SOC may be referred to as a core. The term “multiprocessor” may be used herein to refer to a system or device that includes two or more processing blocks configured to read and execute program instructions. The various aspects may be implemented in a number of single processor and multiprocessor computer systems, including a system-on-chip (SOC) or system in a package (SIP). As an example, FIG. 1 illustrates components of an example SOC 100 architecture that may implement various embodiments. The example SIP 100 illustrated in FIG. 1 an SOC 102, a temperature sensor 105, a clock 106, and a voltage regulator 108. In some aspects, the SOC 102 may operate as central processing block (CPU) of a computing device, such as a wireless device, that carries out the instructions of software application programs by performing the arithmetic, logical, control and input/output (I/O) operations specified by the instructions. In the example illustrated in FIG. 1, the SOC 102 includes a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor 216, one or more coprocessors 218 (e.g., vector co-processor) connected to one or more of the processors, memory 120, custom circuitry 122, system components and resources 124, an interconnection/bus module 126, one or more temperature sensors 130, a thermal management unit 132, and a thermal power envelope (TPE) component 134. One or more of the modem processor 212, graphics processor 214, application processor 216, and coprocessors 218 may be connected to and receive power from a shared power rail 104. The thermal power envelope (TPE) component 134 may be configured to generate, manage, compare and/or evaluate one or more TPE values. The thermal management unit 132 may be configured to monitor and manage the wireless devices surface/skin temperatures and/or the ongoing consumption of power by the active components that generate thermal energy in the wireless device. Each processor 110, 112, 114, 116, 118 may include one or more cores, and each processor/core may perform operations independent of the other processors/cores. For example, the SOC 102 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS 10). In addition, any or all of the processors 110, 112, 114, 116, 118, 152, 160 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.). The SOC 102 may include various system components, resources and custom circuitry for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources 124 of the SOC 102 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support the processors and software clients running on a wireless device. The system components and resources 124 and/or custom circuitry 122 may also include circuitry to interface with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, etc. The SOC 102 may further include an input/output module (not illustrated) for communicating with resources external to the SOC, such as a clock 106 and a voltage regulator 108. Resources external to the SOC (e.g., clock 106, voltage regulator 108) may be shared by two or more of the internal SOC processors/cores. In addition to the SOC 102 discussed above, the various embodiments may be implemented in a wide variety of integrated computing systems, which may include a single processor, multiple processors, multicore processors, or any combination thereof in addition to a variety of processing blocks and subsystem cores. FIG. 2 is a circuit block diagram 200 illustrating portions of a large-scale integrated circuit, such as the SOC 102 illustrated in FIG. 1, including a shared rail monitor circuit 204 that interacts with processing blocks or subsystem cores on the SOC to manage power draw on a shared power rail (e.g., 104) based primarily on measurements of current or power in some processing blocks or subsystem cores. With reference to FIGS. 1-2, typical SOCs (e.g., 102) include a number of different processing blocks or subsystem cores (e.g., 110-118). In many designs, several such processing blocks or subsystem cores may be powered by a shared power rail. In order to ensure that total current demands on the shared power rail do not exceed a current limit, the shared rail monitoring circuit 204 may receive current measurements from processing blocks or subsystem cores and compare the sum of measured currents to limits, which may be set for individual blocks/cores, and initiate mitigation actions when limits are exceeded. In the example illustrated in FIG. 2, a shared rail monitor circuit 204 may include a register for receiving power control information 224, receiver blocks (Rx) 228, 230 for receiving measured current values, a summing circuit 232 configured to add the current values from the measured current receiver blocks 228 230, and a core control module 226 configured to receive inputs from the power control register 224 and summing circuit 232, and output mitigation levels to processing blocks or subsystem cores on the shared power rail. FIG. 2 illustrates two processing blocks coupled to the shared rail monitor circuit 204 in the form of a digital signal processor (DSP) 206 and a neural net processor unit (NPU) 208. Each of the DSP 206 and NPU 208 includes a local limits manager (LLM) 240, 250 that receives mitigation level information from the core control module 226 and conveys this information to a mitigation module 242, 252 that is configured to implement a current level mitigation setting based on the mitigation level set by the shared rail monitor circuit 204. Some processing blocks or subsystem cores may include power or current measuring elements. In the illustrated example, the DSP 206 includes a current monitoring circuit 236 that measures the current drawn by the DSP and provides measurement data to the local limits manager (LLM) 240 and to a receiver block 230 in the shared rail monitor circuit 204. Also, the NPU 208 is shown including a digital power meter (DPM) 248 that provides power measurement data to a register (RX) 228 in the shared rail monitor circuit 204. While FIG. 2 shows single examples of various circuit modules, there may be more than one of each type of circuit module within an SOC. Similarly, the example NPU 208 includes a digital power monitor (DPM) circuit 248 configured to provide power measurement data to the local limits manager (LLM) 250 and to a receiver block 228 in the shared rail monitor circuit 204. The shared rail monitor 204 may receive information regarding power demands, temperatures and voltages of the SOC from power monitoring (PM) circuits 218, temperature monitoring (TM) circuits 210 that are configured to receive temperature information from temperature sensors throughout the SOC die, and voltage monitor circuits (VM) 212 that are configured to receive information regarding the voltage regulators within the SOC. The temperature monitoring (TM) circuits 210 outputs temperature data to other modules, including power controllers (PC) 214, resource controllers (RC) 216, and various data communication modules 220. The power controller 214 may be configured to maintain information regarding the power condition of various subsystems within the SOC. The resource controller 216 may be configured to maintain information regarding the activity of various resources within the SOC. The power controller 214 and resource controller 216 may output information regarding the operating conditions and states of various processing blocks within the SOC to the power control receiver block 224 within the shared rail monitoring circuit 204. In addition to receiving data from the temperature sensor controller 210 and voltage regulator monitor 212, the central broadcast module 220 may receive power state information from the power monitor (PM) circuit (PM) 218. The central broadcast module 220 may output on a shared data bus information regarding the operating state (e.g., power, temperature and voltage) of various components of the SOC. This information may be used by the local limits manager 240, 250 and digital power managers 248 of various processing blocks or subsystem cores (e.g., 206, 208). Thus, as illustrated in FIG. 2, the shared rail monitor circuit 204 issues power mitigation settings from the core controller 226 based on actual measurements of current and power of various processing blocks or subsystem cores. While controlling current and power demands of processing blocks or subsystem cores based on actual measurements functions to protect shared power rails from exceeding power current limits, this approach provides margin in the limit settings to account for processing blocks or subsystem cores for which the power or current draws are not measured. This is illustrated in FIG. 3, which is a graph showing current drawn by a DSP (e.g., 206) and an NPU (e.g., 208) sharing a common power rail when managed by a power rail monitoring circuit (e.g., 204) that relies solely on measurements of currents by some but not all processing blocks or subsystem cores on the shared power rail. With reference to FIGS. 1-3, to ensure that the total current capacity of the shared power rail 302 (illustrated as being 8 amps (A)) is not exceeded, a rail monitor current limit 308 may be established at a current value less than the theoretical limit to account for current drawn by processing blocks or subsystem cores that do not include current sensors reporting current demand to the power rail monitoring circuit (e.g., 204). To ensure that the rail monitor current limit 308 is not exceeded by operating two or more processing blocks or subsystem cores on the shared power rail, throttle set points may be established for each processing block or subsystem core. For example, a throttle set point 304 may be set for the NPU and a throttle set point 306 may be set for the DSP, the sum of which is equal to the rail monitor current limit 308. Thus, if both the NPU and the DSP are operating at a respective throttle set point (304, 306), the total power drawn by these two processing blocks will not exceed the rail monitor current limit 308. FIG. 3 illustrates how a power rail monitoring circuit (e.g., 204) that depends on measured current values of processing blocks or subsystem cores may impose performance limits on the blocks/cores on the same shared power rail. For example, while the NPU is deenergized or inactive and thus is not drawing significant current, as illustrated in duration 320, the DSP may be permitted to draw as much current (shown as line 312) as it may consume up to the rail monitor current limit 308. Once the DSP current reaches the rail monitor rate 308, the total measured current of the two processing blocks coupled to the shared power rail will equal the rail monitor current limit 308, and therefore the power rail monitoring circuit will send signals to the local limits management modules in the two processing blocks, which will impose limits on the DSP so that its current draw does not exceed the rail monitor current limit 308 during duration 322. When the NPU begins processing, and thus drawing current (shown as line 310), power rail monitoring circuit will begin to send signals to the local limits management modules in the two processing blocks, which will impose limitations on the NPU so that the sum of the currents drawn by the DSP (312) and the NPU (310), which is shown as line 314, does not exceed the rail monitor current limit 308. Thus, during the duration 324, mitigation settings imposed by local limits management modules in response to signals received from the shared power rail monitoring circuit will result in the DSP reducing current draw commensurate with the increase in the current draw by the NPU until the NPU reaches the NPU throttle set point 304, and the DSP reaches the DSP throttle set point 306. While both the DSP and NPU are operating at their respective throttle set points during duration 326, the total current draw of the two
{'application_number': '<application-reference appl-type="utility">\n<document-id>\n<country>US</country>\n<doc-number>16683403</doc-number>\n<date>20191114</date>\n</document-id>\n</application-reference>', 'publication_number': '<publication-reference>\n<document-id>\n<country>US</country>\n<doc-number>20210149476</doc-number>\n<kind>A1</kind>\n<date>20210520</date>\n</document-id>\n</publication-reference>', 'source_file': './application/2021/ipa210520.xml', 'source_data': 'USPTO-Application'}