Power optimization

Power optimization

 Power management : determining how system resources are scheduled/used to control power consumption.

 OS can manage for power just as it manages for time.

 OS reduces power by shutting down units.

 May have partial shutdown modes.

Power management and performance

 Power management and performance are often at odds.

 Entering power-down mode consumes  energy  time  Leaving power-down mode consumes  energy  time

Simple power management policies

 Request-driven : power up once request is received. Adds delay to response.

 Predictive shutdown : try to predict how long you have before next request.

 May start up in advance of request in anticipation of a new request.

 If you predict wrong, you will incur additional delay while starting up.

Probabilistic shutdown

 Assume service requests are probabilistic.

 Optimize expected values:  power consumption  response time  Simple probabilistic: shut down after time T on , turn back on after waiting for T off .

Advanced Configuration and Power Interface

    Conceived by Intel, Microsoft, and Toshiba (the promoters) An “ interface ” specification  ACPI/OSPM replaces APM, MPS, and PnP BIOS Spec Allow OS-directed Power Management (OSPM) Defines     Hardware registers - implemented in chipset silicon BIOS interfaces  Configuration tables   Interpreted executable function interface (Control Methods) Motherboard device enumeration and configuration System and device power states ACPI Thermal Model

Advanced Configuration and Power Interface

 ACPI : open standard for power management services.

applications OS kernel device drivers ACPI BIOS Hardware platform power management

ACPI global power states

   G3: mechanical off G2(S5): soft off G1: sleeping state     S1: low wake-up latency with no loss of context S2: low latency with loss of CPU/cache state S3: low latency with loss of all state except memory S4: lowest-power state with all devices off  G0: working state

Global Power States

ACPI Global States and Transitions Legacy Boot (SCI_EN=0) Legacy Legacy Boot (SCI_EN=0) G3 -Mech Off Pow er Failure ACPI Boot (SCI_EN=1) D0 D1 M odem D2 D3 D1 D0 HDD D2 D3 D0 D1 CDROM D2 D3 C0 C1 CPU C2 C3 C0 S4BIOS_F S4BIOS_REQ

BIOS Routine

ACPI_ENABLE (SCI_EN=1) ACPI_DISABLE (SCI_EN=0) G0 (S0) Working SLP_TYPx=(S1-S4) and SLP_EN S3 S2 S1 S4 Wake Ev ent G1 Sleeping ACPI Boot (SCI_EN=1) SLP_TYPx=S 5 and SLP_EN or PWRBTN_OR G2 (S5) Soft Off

Device and Processor Power States

System design techniques

Design methodologies.

Requirements and specification.

Design methodologies

 Process for creating a system.

 Many systems are complex:  large specifications;  multiple designers;  interface to manufacturing.

 Proper processes improve:  quality;  cost of design and manufacture.

Product metrics

 Time-to-market:  beat competitors to market;  meet marketing window (back-to-school).

 Design cost.

 Manufacturing cost.

 Quality.

Design flow

 Design flow : sequence of steps in a design methodology.

 May be partially or fully automated.

 Use tools to transform, verify design.

 Design flow is one component of methodology. Methodology also includes management organization, etc.

Waterfall model

 Early model for software development:

requirements architecture coding testing maintenance

Waterfall model steps

 Requirements: determine basic characteristics.

 Architecture: decompose into basic modules.

 Coding: implement and integrate.

 Testing: exercise and uncover bugs.

 Maintenance: deploy, fix bugs, upgrade.

Waterfall model critique

  Only local feedback---may need iterations between coding and requirements, for example.

Doesn ’ t integrate top-down and bottom-up design.

 Assumes hardware is given.

Spiral model

design system feasibility specification prototype initial system enhanced system requirements test

Spiral model critique

 Successive refinement of system.

 Start with mock-ups, move through simple systems to full-scale systems.

 Provides bottom-up feedback from previous stages.

 Working through stages may take too much time.

Successive refinement model

specify architect design build test initial system specify architect design build test refined system

Embedded system design

 Embedded systems  Mixed HW and SW systems  software for features and flexibility  hardware for performance  Design of embedded systems  many different types of constraints  timing, size, weight, power consumption, reliability, and cost

Embedded system design

 Current methods for designing embedded systems require to specify and design hardware and software separately    Lack of a unified hardware-software representation   difficulties in verifying the entire system incompatibilities across the HW/SW boundary.

A priori

definition of partitions  which leads to sub-optimal designs. Lack of a well-defined design flow  It makes specification revision difficult, and directly impacts time-to-market.

Hardware/software design flow

requirements and specification architecture software design hardware design integration testing

Co-design methodology

 Must architect hardware and software together:  provide sufficient resources;  avoid software bottlenecks.

 Can build pieces somewhat independently, but integration is major step.

 Also requires bottom-up feedback.

Hierarchical design flow

 Embedded systems must be designed across multiple levels of abstraction:  system architecture;  hardware and software systems;  hardware and software components.

 Often need design flows within design flows.

Hierarchical HW/SW flow

spec architecture HW integrate SW test system test test

Example

 P OLIS at UCB  unified hardware-software representation, so as to prejudice neither hardware nor software implementation  Co-design Finite State Machine (CFSM)

Design steps

  Initial specification   Write an initial specification of the embedded system Compile the spec into the P OLIS SHIFT format (CFSM) Inside the P OLIS program        Read the design into Polis Create internal graph representation Optimize this graph Choose a target processor ( for example, MIPS R3000) Run estimation tools (the size and speed of the resulting software) Generate the C-code for each SW module Generate P TOLEMY code for each module

Design steps, cont’d

  Outside P OLIS program  Run P TOLEMY    Simulation verifying the design Repartition (HW/SW) the design to improve performance Create a real implementation of the design Inside the P OLIS program   Designate each module as either HW or SW For the HW part   Translate and optimize the design Generate the hardware in netlist format

Design steps, cont’d

  For the SW part  Create and Optimize the graph representing the SW     Choose a targer microprocessor Run the estimation tools Generate the C-code for each SW module Generate the simple OS Outside the P OLIS      Choose the HW (example: Xilinx FPGA) Translate the netlist file to the HW Plug the FPGA into your board Use the SW and HW tools supplied with the microprocessor Plug the micro-controller into your board

10 9

Moore ’ s Law

PC on chip 10 8 2000 billion-transistor system-on-chip 2012

Systems-on-silicon

 Can build significant embedded systems on single chip:  one or more high-performance CPUs;  I/O devices;  memory.

 Advantages:  higher performance and lower power;  lower cost.