Energy design through unified hardware abstraction
While mobile device makers have been forced by consumers' insatiable mobility requirements and fierce competition to significantly improve battery life, fixed-power products have been slower to deliver better energy consumption characteristics.
But a combination of government mandates, rising energy costs, facility limitations, and a general movement to all things green makes energy efficiency a top-level concern for every type of electronics maker.
The basic principle of energy design and management for electronic devices is to optimise the electrical activity within the electronic circuitry without impacting user experience or intended purpose. During the (pre-silicon) energy design phase, also called power design in Electronic Design Automation (EDA), we focus on tuning the hardware structures, assuming certain nominal signal activities, voltages, and clocks.
In the subsequent (post-silicon) energy management phase we tune the voltages, clocks, and functional activities during the test-and-run time, assuming certain hardware characteristics of the device.
Energy-efficient, complete solutions can be obtained only with optimal alignment across the pre- and post-silicon phases of energy optimisation, supported by unified design flows, abstractions, and formats.
This requires a fundamental shift in the design infrastructures currently in use in today's product development flow. We believe a Unified Hardware Abstraction (UHA) is needed to promote a holistic, quantitative, and reusable approach to energy design and management.
The energy design and management flow for electronic devices is disconnected and lacks the abstractions, formats, interfaces, and automated methodologies long established and standardised in functional design and verification of hardware and software. We have observed that the main disconnects on energy issues are at the handover points between various teams:
From VLSI designers and IP providers to system integrators and power designers at the RTL level
From system integrators to firmware developers at the core system software level
From device developers and firmware developers to OS integrators at the OS API level
From device developers and OS integrators to the application programmers at the application software level
In hardware design, apart from Spice, none of the structural or temporal design or verification abstractions contain consistent power or energy information.
This is not a surprise. We in EDA have been systematically abstracting away time and structure in favour of high-level behavioural abstractions in order to cope with the rapidly increasing complexities.
The current Unified Power Format (UPF), although very helpful, is effectively adding information about the structure of the voltage tree and states of the voltage domains. It has no information to help optimise energy of interconnected components in realistic settings, as it does not cover clock trees, functional operating states, and the unavoidable constraints among them. (As pointed out by one of the early reviewers of this text, the wider definition or just changing community's perception about UPF's power states could be the right first step towards the next UPF version or the new standard.)
In IP design, IP-XACT is focused on functional IP stitching, with no energy or power annotations.
The situation is similar with board-level tools. As a result of the lack of unified information and structure, informal spreadsheets containing power information extracted from component data sheets are still the main tool of power optimisation engineers.
On the software side, the lower levels of the operating systems contain APIs to control power. Windows is relying on ACPI and ASL to enable easy OS porting to various platforms.
ASL descriptions feed the interpreter within the OS with information when and how to adjust the hardware. This can be used to change power states, but any notion of power or energy is not part of the description.
Linux relies on the Device Tree (DTS) to partially describe the underlying hardware and contains a couple of power management frameworks in the kernel (cpufreq, devfreq, runtime_PM, regulator framework, etc.).
Despite some attempts, like HWMOD contributed by TI, Linux lacks handover formalisms for efficient interaction with the hardware designers and device integrators. When it comes to energy management, probably the most sophisticated of the OSs is Apple's iOS, but it is well known as a closed ecosystem, both on the hardware and software sides, and thus not scalable to non-Apple products.
The emerging Internet of Things (IoT) will likely also add to the problem as designers look to optimised OS solutions for their specific system tasks. Interestingly, the OSs are not converging but diverging rapidly. This, without doubt, will add to the burden of systems designers looking for optimised performance and power.
|Related Articles||Editor's Choice|
|Related Articles||Editor's Choice|