Power optimization

1. Power optimization

2. 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.

3. 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

4. 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.

5. Probabilistic shutdown • Assume service requests are probabilistic. • Optimize expected values: • power consumption • response time • Simple probabilistic: shut down after time Ton, turn back on after waiting for Toff.

6. 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

7. Advanced Configuration and Power Interface • ACPI: open standard for power management services. applications device drivers OS kernel power management ACPI BIOS Hardware platform

8. 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

9. Global Power States

10. ACPI Global States and Transitions

11. Device and Processor Power States

12. System design techniques Design methodologies. Requirements and specification.

13. 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.

14. Product metrics • Time-to-market: • beat competitors to market; • meet marketing window (back-to-school). • Design cost. • Manufacturing cost. • Quality.

15. 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.

16. Waterfall model • Early model for software development: requirements architecture coding testing maintenance

17. 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.

18. 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.

19. Spiral model system feasibility specification prototype initial system enhanced system requirements design test

20. 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.

21. Successive refinement model specify specify architect architect design design build build test test initial system refined system

22. 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

23. 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.

24. Hardware/software design flow requirements and specification architecture software design hardware design integration testing

25. 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.

26. 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.

27. spec spec spec architecture HW architecture SW architecture detailed design detailed design HW SW integrate integration integration test test test system hardware software Hierarchical HW/SW flow

28. Example • POLIS at UCB • unified hardware-software representation, so as to prejudice neither hardware nor software implementation • Co-design Finite State Machine (CFSM)

30. Design steps • Initial specification • Write an initial specification of the embedded system • Compile the spec into the POLIS SHIFT format (CFSM) • Inside the POLIS 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 PTOLEMY code for each module

31. Design steps, cont’d • Outside POLIS program • Run PTOLEMY • Simulation verifying the design • Repartition (HW/SW) the design to improve performance • Create a real implementation of the design • Inside the POLIS program • Designate each module as either HW or SW • For the HW part • Translate and optimize the design • Generate the hardware in netlist format

32. 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 POLIS • 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

33. Moore’s Law 109 billion-transistor system-on-chip PC on chip 108 2000 2012

34. 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.