Computer Architecture · Architecture Tradeoffs

Thermal Design Power and the Throttling It Authorises

What a TDP rating specifies, why a part may exceed it briefly, how the control loop reacts to temperature and current limits, and why two parts with the same TDP perform differently.

A processor datasheet states a thermal design power figure in watts, and the figure is routinely read as a consumption number. It is not one. It is a specification of the heat a cooling solution must remove to keep the part inside its temperature limits while running a defined workload, and the processor is permitted to draw more than that figure for short intervals and less than it for long ones. The gap between the rating and the behaviour is occupied by a control loop, and the loop’s decisions explain why identical-looking parts produce different performance in different machines.

What the rating actually constrains

Three distinct limits are usually collapsed into the TDP number.

The first is the junction temperature limit, the maximum temperature the silicon itself may reach, commonly in the range of 90 to 105 °C for logic. Exceeding it does not instantly destroy the part, but it degrades reliability through electromigration and oxide wear, and at some point the timing guarantees stop holding because carrier mobility falls and interconnect resistance rises with temperature.

The second is the package and socket thermal path. Heat flows from the die through the thermal interface material, the integrated heat spreader, the socket, and the heatsink to the air. Each boundary has a thermal resistance, and the total from junction to ambient sets how many watts produce how many degrees of rise. A cooler with a junction-to-ambient resistance of 0.3 °C per watt turns 100 W into a 30 °C rise above ambient, which fits under a 100 °C limit at room temperature with margin; the same cooler at 200 W needs a 60 °C rise and leaves much less room.

The third is the voltage regulator and board current budget. A rail that supplies 1 V at 200 A is delivering 200 W through a few hundred microohms of copper and silicon, and the conduction losses and the connector ratings bound the current regardless of what the cooler can handle.

TDP is the figure that satisfies all three for a specified workload, and it is chosen so that a mainstream cooling solution can meet it. A part rated at 65 W and a part rated at 250 W may be the same die with different firmware limits, sold into different thermal environments. This is why Voltage and Frequency Domains matters: the limit is enforced by choosing an operating point, not by a hardware fuse.

Boost states spend a thermal budget that must be repaid

Modern parts define a sustained power limit and one or more short-term limits above it. The mechanism is a token bucket. The controller tracks an exponentially weighted average of power over a window of tens of seconds, and permits the part to exceed the sustained limit as long as the average stays inside it. A burst of work at the higher limit is therefore allowed, and the debt is repaid by running below the sustained limit later.

The time constants are chosen to match the thermal mass. Silicon and copper heat up quickly; a heatsink and the air around it heat up slowly. A short burst raises the junction temperature but barely moves the heatsink, so a burst limit can be much higher than the sustained limit without breaching the junction limit. A long burst heats the whole assembly, and the average is what the heatsink sees.

The consequence for benchmarking is that the result depends on the duration of the test. A workload that fits inside the burst window runs at the high operating point; the same workload run long enough settles at the sustained point. Neither number is wrong, and a single figure quoted without the duration is not a property of the part.

class PowerBudget:
    """Token bucket: credit accumulates while running below the sustained
    limit and is spent above it. Level and average are both bounded."""
    def __init__(self, sustained_w, burst_w, window_s, dt_s=0.001):
        self.limit = sustained_w
        self.burst = burst_w
        self.window = window_s
        self.dt = dt_s
        self.credit = 0.0                                  # joules in hand
        self.cap = (burst_w - sustained_w) * window_s       # window's worth

    def update(self, measured_w):
        self.credit += (self.limit - measured_w) * self.dt
        self.credit = min(self.credit, self.cap)
        self.credit = max(self.credit, 0.0)

    def allowance(self):
        return self.limit + self.credit / self.window

With an empty bucket the allowance is the sustained limit; after a long idle period the bucket fills to its cap and the allowance reaches the burst limit; sustained work above the limit drains the bucket back to zero.

The controller does not act on the model above directly. It acts on measured quantities: a current sense on the voltage regulator, a temperature diode on the die, and a digital power meter that estimates switching activity from performance counters. Each has a different latency and a different failure mode. Current sensing is fast and local; temperature is slow, because the thermal path is a low-pass filter with a time constant of seconds; counter-based estimates are workload dependent and can be gamed by code that switches a lot without doing much.

The response is a ladder, not a switch

When a limit is approached, the controller has a sequence of increasingly severe actions. The order matters because each step costs performance and the cheapest sufficient step should be taken first.

Reducing the clock frequency at constant voltage lowers dynamic power linearly, but it also lowers the voltage the circuit needs to run at that frequency, so the usual action is a combined operating point change, called DVFS. A step from 3.0 GHz at 1.0 V to 2.4 GHz at 0.9 V reduces dynamic power by roughly $(2.4/3.0) \times (0.9/1.0)^2$, about 0.65, while reducing performance by 20 percent. That is the favourable direction of the trade.

Reducing voltage alone at constant frequency is not possible, because the timing paths were signed off at a particular voltage and lowering it produces errors rather than slower operation.

Throttling by inserting idle cycles, sometimes called duty cycling, lowers average power without changing the operating point. It is cruder than DVFS and used when the operating point cannot change quickly enough, or when the voltage regulator cannot follow.

Dropping to a much lower operating point, or gating whole cores, is the last resort before the controller shuts the part down. Shutdown is not a graceful state: the operating system sees it as a thermal event and must stop scheduling work on the part, which is why the controller aims to keep the junction temperature a few degrees below the limit at all times rather than oscillating around it.

The ladder has hysteresis built into every rung. A controller that responds to the instantaneous temperature will oscillate, because the thermal path delays the effect of every decision by seconds. Typical implementations act on filtered temperature and on the rate of change, and step down aggressively and step up slowly, because overshoot on the way up is what triggers the emergency actions.

Why two machines with the same rating differ

A part rated at 65 W in a thin laptop and the same part rated at 65 W in a workstation with a large heatsink are not equivalent. The laptop’s thermal resistance is higher, so the sustained operating point that keeps the junction under its limit is lower, and the burst window that fits inside the heatsink’s time constant is shorter. The rating describes the design point, not the trajectory.

Ambient temperature shifts the whole curve. A part that holds its maximum operating point at 20 °C ambient has less headroom at 35 °C, because the same junction limit is reached with a smaller rise. Datacenter operators care about this enough that inlet temperature is a first-class design parameter and is bounded by standards rather than left to facilities.

Silicon variation adds a per-part term. Two dies from the same wafer have different leakage and different speed at the same voltage. The part with higher leakage reaches its power limit at a lower frequency, and the part with lower leakage can be sold at a higher rating or run at a higher operating point. This is why the same model number can be built from dies with different voltage-frequency curves, and why overclocking headroom varies between individual parts.

Workload shape is the largest term of all. A workload that is memory bound spends much of its time waiting, so its switching activity and therefore its power are low, and the controller never intervenes. A workload that is dense in vector arithmetic switches every lane every cycle and hits the power limit almost immediately. The same part therefore delivers very different performance on different code, and the architecture that maximises performance per watt for one may be poor for the other. That asymmetry is the subject of Heterogeneous Cores, where the response is to build two kinds of core and schedule to whichever fits.

Limits of the model

TDP says nothing about transient power. A part can draw a current spike far above its average for microseconds while the regulator’s output capacitance supplies the charge, and those spikes stress the delivery network even when the thermal average is fine. Datacenter operators measure the maximum sustained draw and the maximum transient separately, because the second determines how many parts can share a power supply.

The rating also assumes a workload. The defined workload behind a TDP figure is chosen by the vendor and is generally not the worst case, so a code that exercises every unit simultaneously can exceed the rating indefinitely, at which point the controller throttles and the delivered performance falls below what the rating implied. That is the gap between a thermal specification and a performance specification, and no single number closes it.

References

  1. Advanced Configuration and Power Interface (ACPI) Specification — UEFI Forum
  2. Computer Architecture: A Quantitative Approach — John L. Hennessy and David A. Patterson, Morgan Kaufmann
  3. The Future of Microprocessors — Shekhar Borkar and Andrew A. Chien, Communications of the ACM, 2011