HOME       UP       PREV       |ENDOFPACK|

Example 3 - Static and Dynamic Power Tradeoff


Sweetspot shift in DVFS approach for higher leakage on a real-time task.
# Trade off of Archilies and Tortoise for increasingly leaky technology.
# For a hard-realtime computation we known the number of clock cycles needed but should we do them quickly and halt (Archilies) or slowly and finish just in time (Tortoise).
# For a higher leakage technology, switching off as much as possible tends to become preferable to running at low supply voltage.

# Unfold=1 is baseline design. Unfold=3 uses three times more silicon. 
static_dynamic_tradeoff <- function(clock_freq, leakage, unfold, xx)
{
  op_count <- 1e5; 
  execution_time = op_count / clock_freq / (unfold ^ 0.75);   // Model: Pollack-like unfold benefit.
  vdd <- 1 + 0.5 * (clock_freq/100e6);                        // Model: Higher supply needed for higher clock.
  static_power <- leakage * vdd ^ 0.9 * unfold * 0.4;         // Model: Leakage resistance slightly increasing with Vdd.
  static_energy <- static_power * execution_time;             // Integrate static power
  dynamic_energy <- op_count * vdd ^ 2.0 / 0.5 * 1e-9;        // Use CV^2/2 for dynamic 
}

For the 90nm technology, there was low static leakage and considerable scope for DVFS. With the smaller geometries performance can be traded off for greater leakage. Transistor dopant levels (and hence leakage) can be adjusted in regions or globally. We will want a low leakage, large slow transistor for power gating but may choose higher leakage transistors for logic since these will either be faster or can be run off a lower Vdd, hence reducing dynamic power.

The simple R plot illustrates the shift in operating frequency sweet spot (minimal total power) with higher leakage transistors. We considered leakage of 0.05 and 0.3 (arbitrary units). With low leakage it is best to compute slowly and finish just in time. With high leakage it is best to compute more quickly and then turn off for longer.


18: (C) 2012-16, DJ Greaves, University of Cambridge, Computer Laboratory.