Low power Design Strategies

Daniele Folegnani

Talk outline

• Why Low Power is Important

• Power Consumption in CMOS Circuits

• New Trends for Future Microprocessors

• Low Power Strategies

• Power Consumption Evaluation of a Superscalar Processor

• An Architectural Technique to Reduce the Power Consumption of the Issue Logic

• Conclusions

Why Low Power is Important

High performance microprocessors

PowerPC704 consumes 85 Watt

Alpha 21364 consumes 100 Watt

Problems involved: thermal runaway, gate dielectric, junction fatigue, electromigration diffusion, electrical parameters shift, silicon interconnections fatigue, package related failure.

THE FUNCTIONALITY AND THE CLOCK SPEED CAN BE LIMITED

Thermal and Power dissipation costs

0

10

20

30

40

50

60

0 10 20 30 40 50 60

Watt

To

tal

dis

sip

ati

on c

ost

CPU

1$/1W

Low performance processors

• High demand of portable devices ( mobile phones, laptops, smart cards,

videogames, etc ) >>> 95% of production !!!

• Extensive use of multimedia features

Problems involved: >>> Battery life !!!

Energy battery will not grow drastically in the near future due to technology and safety reasons ( today´s batteries has the same energy of a grenade !!! )

• One of the market point is: hours of use and hours of standby

• Need of techniques to improve energy efficiency without penalizing performance

Power Consumption in CMOS Circuits

• Static • Theoretically 0, in practice leakage and threshold currents exist in transistors

• Dynamic• Transients ( the linear zone )

• Capacitance switching THE MOST IMPORTANT FACTOR

fCVP 2

2

1

New Trends for Future Microprocessors

0

0,5

1

1,5

2

2,5

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5

microarch complexity

Power

Perf

Moore´s Law doubling transistors every 18 months

Power is proportional to DIE AREA and FREQUENCY

• In the same technology a new architecture has 2-3X in Die Area

• Changing technology implies 2X frequency

SCALING TECHNOLOGY ...

• Decreasing voltage ( 0.7 scaling factor )

• Decreasing of die area ( 0.5 scaling factor )

• Increasing C per unit area 43% !!!

This implies that the power density increase of 40% every generation !!!

Temperature is a function of power density and determinates the type of cooling system needed.

VARIABLES

• PEAK POWER ( worst case )

Today´s packages can sustain a power dissipation over 100W for up to 100msec >>> cheaper package if peaks are reduced

• ENERGY SPENT ( for a workload )

More correlated to battery life

Low Power Strategies

• OS level : PARTITIONING, POWER DOWN

• Software level : REGULARITY, LOCALITY, CONCURRENCY

( Compiler technology for low power, instruction scheduling )

• Architecture level : PIPELINING, REDUNDANCY, DATA ENCODING

( ISA, architectural design, memory hierarchy, HW extensions, etc )

• Circuit/logic level : LOGIC STYLES, TRANSISTOR SIZING, ENERGY RECOVERY

( Logic families, conditional clocking, adiabatic circuits, asynchronous design )

• Technology level : Threshold reduction, multi-threshold devices, etc

Power Consumption Estimation

0

5

10

15

20

25

30

Arch RTL Circuit Layout

Levels of abstraction

Err

or

est

ima

tio

n

power consumption

Due to the relative high error rate in the architectural estimation ( no vision of the total area, circuit types, technology, block activity, etc )

IMPORTANT DESIGN DECISIONS MUST BE DONE AT

ARCHITECTURAL LEVEL

• Accurate power evaluation is done at late design phases

• Needs of good feedback between all the design phases

- Correlation between power estimation from low level to high level

TRY TO IMPROVE ACCURACY AT HIGH LEVELTRY TO IMPROVE ACCURACY AT HIGH LEVEL

- Critical path based power consumption analysis

( CIRCUIT TYPES, TECHNOLOGY, ACTIVITY FACTOR )

- Thermal images based correlation analysis

( HOTTEST SPOTS LOCATION, COOLEST SPOTS LOCATION, TEMPERATURE DIFFERENCES, TEMPERATURE

DISTRIBUTION )

Architectural Power Evaluation

[ G.Cai, Intel ]

• Architectural design partition

• Power consumption evaluation at block level

- Power density of blocks ( SPICE simulation, statistical input set,

technology and circuit types definition )

- Activity of blocks and sub-blocks ( running benchmarks )

- Area ( feedback from VLSI design, circuits and technology defined )

• TRY DO DEFINE SCALING FACTORS THAT ALLOW TO REMAP THE ARCHITECTURAL POWER SIMULATOR WHEN TECHNOLOGY, AREA AND CIRCUIT TYPES CHANGE

• TRY TO REDUCE THE ERROR ESTIMATION AT HIGH LEVEL

POW OUT ORDER

• Technology assumed: CMOS 0.18 micron

• 5 types of circuit logic ( static, dynamic, SRAM, clock distribution, PLA )

• 32 architectural blocks and area associated

• blocks built with custom design

• two types of power density ( active and inactive power density )

kkk kkkk kj IPDAiaAPDAiaiP 1

iPEi jj

Power Consumption Evaluation of a Superscalar Processor

Architectural parameters:

• 4 instr. fetch, issue and commit

• 128 entries instruction queue size

• I-Cache 128Kbytes, direct mapped, 32 byte line, 1 cycle hit, 3 cycle miss

• D-Cache 128Kbytes, 4 way set ass, 32 byte line, 1 cycle hit, 3 cycle miss

• UL2-Cache,1024Kbytes, 4 way set ass, 64 byte line, 3 cycle hit

• Combined predictor of 1K entries with Gshare with 1K 2-bit counters, 8 bit global history and bimodal pred. of 2K entries with 2-bit counters

• 4 intALU, 4fpALU, 1int mul/div, 1 fp mul/div

• Out of order issue, oldest ready first selection policy

applu swim tomcatv wave su2cor hydro4 Avg (%)inst dec 340,952 336,48 351,133 341,916 344,195 349,875 2,751BTB 143,346 119,679 195,688 149,563 156,424 187,337 1,269TLB 63,492 53,009 86,676 66,246 69,284 82,977 0,562IL1 677,202 565,397 924,48 706,574 738,986 855,03 5,955DL1 621,026 518,495 847,79 647,961 677,684 811,613 5,497UL2 1353,916 1130,387 1848,292 1412,638 1477,439 1769,421 11,986rename table 1627,983 1672,283 1725,565 1668,854 1724,716 1738,017 13,539instr queue 3124,82 3136,195 3282,977 3160,858 3170,821 3269,56 25,201ROB 3429,455 3445,777 3394,513 3489,683 3221,504 3348,813 27,099int FU 111,612 109,172 110,205 112,288 103,285 108,362 0,873fp FU 147,722 144,934 145,859 148,617 136,701 143,42 1,156I/O logic 244,201 203,884 333,371 254,793 266,481 319,145 2,161Other 189,273 180,103 214,89 192,667 200,816 242,276 1,951Total 12075,833 11615,795 13461,439 12352,658 12288,336 13225,846 100

perl li m88ksim vortex compress gcc Avg (%)inst dec 345,874 334,607 355,221 346,63 333,885 349,317 2,761BTB 164,525 114,926 107,751 169,376 108,817 109,063 1,045TLB 72,873 50,904 47,726 75,021 48,198 84,184 0,511IL1 777,26 542,941 509,046 800,174 514,082 897,905 5,456DL1 712,783 497,902 466,819 733,796 471,437 823,42 5,004UL2 1490,043 1040,843 1017,726 1412,638 1477,439 1795,162 11,117rename table 1812,117 1879,014 1742,077 1999,771 1027,793 1773,833 13,819instr queue 3351,535 3420,231 3214,888 3645,328 3106,252 2906,202 26,524ROB 3247,036 3227,355 3315,514 3558,173 3225,669 3499,98 27,104int FU 105,166 100,344 104,111 114,311 103,075 109,19 0,859fp FU 139,19 132,808 137,794 151,294 136,423 144,517 1,136I/O logic 280,028 195,786 183,564 288,545 185,38 323,788 1,967Other 267,57 227,973 178,148 364,64 403,729 549,925 2,697Total 12766,783 11360,385 11360,385 13659,697 11142,179 13366,486 100

An Architectural Technique to Reduce the Power Consumption of the Issue Logic

• IQ + ROB responsible of about 53% of power consumption• Cache hierarchy is not the most important power consumption factor in

superscalar paradigm• Power consumption is almost independent to the instruction mix

TRENDS IN SUPERSCALAR

• Increasing issue width• Increasing size of instruction window is more than linear respect IW• Area of IQ grows more than linear respect the number of entries

IQ power contribution may grow in the future

Every cycle the wakeup logic broadcast the result tags through the result buses to all the entries and each entry compares them with their to find a match

THE ISSUE ENGINE SPEND EVERY CYCLE A LARGE AMOUNT OF POWER ONYL FOR CHECKING IF SOME INSTRUCTIONS ARE

AVAILABLE FOR EXECUTION

ConsideringConsidering

• Periods of execution with high parallelism, just a subpart of the IQ may satisfy the IW

• Periods of execution with poor parallelism, some parts of the IQ may not provide any useful instruction ready to execute

The issue engine is very power inefficient

Issue in the window

0

10.000

20.000

30.000

40.000

50.000

60.000

70.000

80.000

90.000

100.000

APPLU HYDRO SU2COR SWIM TOMCATV WAVE5

SpecFP

Per

cent

age 1 part

2 part

3 part

4 part

Issue in the window

0

10.000

20.000

30.000

40.000

50.000

60.000

70.000

80.000

90.000

100.000

COMPRESS GCC LI M88KSIM PERL VORTEX

SpecINT

Per

cent

age 1 part

2 part

3 part

4 part

Commit in the window

0

10.000

20.000

30.000

40.000

50.000

60.000

70.000

80.000

90.000

100.000

APPLU HYDRO SU2COR SWIM TOMCATV WAVE5

SpecFP

Per

cent

age 1 part

2 part

3 part

4 part

Commit in the window

0

10.000

20.000

30.000

40.000

50.000

60.000

70.000

80.000

90.000

100.000

COMPRESS GCC LI M88KSIM PERL VORTEX

SpecINT

Per

cent

age 1 part

2 part

3 part

4 part

Dynamically Resizing the Instruction Queue

• We propose a run-time mechanism that adapt the size of IQ based on its contribution on IPC

• We avoid the wake-up function in the parts that are temporally disabled

• Resize decision are commit based

IQ implemented as a circular FIFO with head and tail pointers, no collapsing

What we do is ...

Partition the queue in 16 parts of 8 entries

Define a new pointer for the queue, called the limit pointer

• At start time has the same value of the head pointer and is update as the head pointer

• When a resize decision is done an offset ( one portion ) is added/subtracted from it

• The zone between the head and the limit pointer is the disabled zone ( no wake-up )

• If the tail grows more than the limit, we allow the correct wake-up and we stop the insertion until the limit reach the tail

Heuristic to reduce size

• Collect statistics about the instructions committed in the youngest portion of the queue

every quantum time ( 1000 cycles ).

We propose to insert a bit in each ROB entry that will be set at dispatch time if the physical position of the instruction in IQ is in the current youngest part

• The resize decision is threshold-based >>> 0.025 of IPC in the current portion

• No limit to cut

Heuristic to increase size

• Blind >>> grow of one portion every 5 quantum time at lets the cut approach decide if

the decision was correct or not ( time of high parallelism or not )

Results

0

500

1.000

1.500

2.000

2.500

3.000

3.500

Applu

Swim

Tomca

tv

Wave

Su2co

r

Hydro

Perl Li

M88

ksim

Vorte

x

Compress

Gcc Avg

IPC

128

dynamic

64

% PowSav % TPowSav Avg entriesApplu 62.907 16.276 47.5Swim 30.000 8.100 89.6Tomcatv 58.613 14.291 52.9Wave 41.989 10.721 74.2Su2cor 61.821 15.946 48.9Hydro 66.129 16.339 43.3Perl 55.379 14.517 57.1Li 59.847 17.383 51.4M88ksim 65.890 18.620 43.6Vortex 61.084 16.278 49.8Compress 65.658 18.287 43.9Gcc 60.243 13.088 50.9Avg 57.463 14.987 54.4

Conclusions

• Power consumption is a new constraint in the design of computer systems like cost and performance

• The problem must be attacked from different levels of abstraction

• Power decision must be done at early steps of the design

• There is a need of power estimation models and tools, specially at architectural level

Q&A ?