Extending UPF For Use In System-Level Design

Energy efficiency as a design constraint continues to dominate, and now that we see greater momentum behind a shift left toward system-level design, we are naturally seeing power-aware system-level design as a key area for EDA and IP enablement, especially among mobile and IoT platform providers. In my last article I highlighted the role that IP power models play in the architecture and design of low-power platforms, especially when used within a virtual prototyping environment. In this article I will highlight how interoperable, industry-standard IP power models coupled with virtual prototyping can be used in both the development of energy-efficient software and for the bring-up and verification of system power management. For those interested in understanding more about virtual prototyping and its application to software development I would highly recommend reading “Better Software. Faster”.

Platform development today continues to adopt a core-based design approach—designs that contain many IP titles from a number of IP vendors. These designs are created, validated and implemented using a wide variety of EDA tools and methodologies, and so the need for interoperability for any IP model is obvious. The ability to develop energy-efficient platforms, including the hardware, software and system power management components of the platform, requires the ability to use appropriate levels of design abstraction for the task at hand. So it follows that our abstractions of IP power behavior also should support that requirement.

IEEE 1801 Unified Power Format (UPF) is now an established industry standard that facilitates the specification of power intent for use in low-power design. Having a standard way of defining both the design description (HDL) and the power intent (UPF) enables portability across EDA design tools and methodologies for the implementation and verification of low-power SoCs. UPF is very well supported across the EDA and IP community, and its adoption within the design community continues to grow. Through active participation from a wide variety of interests within the semiconductor industry, UPF has continued to evolve from its roots back in 2007 with Accellera v1.0 to the current IEEE standard today (IEEE 1801-2013).

As we make this shift left into system-level design with our platform development approach and methodology, it makes sense that we would also make a shift left with the definition of our industry standard power intent. In support of that, the IEEE 1801 UPF Working Group created a sub-group almost exactly a year ago to focus exclusively on power modeling, with the goal of defining an extension to the UPF standard for use in system level IP power modeling. A fundamental working assumption for the 1801 power modeling sub-group was that these system-level IP power models would support the development of both energy-efficient hardware and software. This would be the first time we see UPF enable key aspects of software and system power management development.

Well, the sub-group has been busy over the last year and is now very close to submitting a set of system-level power modeling extensions for this year’s revision of the UPF standard, which is informally dubbed UPF3.0. We currently expect the UPF3.0 revision to go to IEEE ballot before DAC and to be approved during the second half of 2015, with EDA and IP vendor support of UPF3.0 based system-level IP power models following shortly after that. UPF3.0 will support the definition of system-level IP power models, including enumeration of more complex power states and transitions with associated power functions used to calculate power consumption, as well as power-state activation conditions that support all levels of design abstraction including hardware, software and power management events.

One of the key advantages of these UPF3.0 based IP power models is their applicability to both hardware and software development, especially the software aspects of system power management. The ability to abstract and package up key power-related characteristics of a piece of IP, and present those characteristics in a way that is suitable for consumption by software development teams working at very high levels of design abstraction, enables these teams to profile the energy behaviour of the platform under full or representative software load. Having this visibility of power and energy behaviour long before silicon is available helps identification and removal of software-based energy bugs (software-based defects that do not affect the functionality but adversely impact battery life and thermal constraints), but more importantly it enables the early development, bring-up and testing of system power management software.

System power management software plays a critical role in the overall energy efficiency of a platform because the way in which the platform hardware is used absolutely determines its energy consumption. The more efficiently we employ the hardware resources in our platform the better battery life and thermal behavior we will see, and this is the responsibility of system power management. Being able to simulate the lower level hardware-software interactions for tuning of performance levels, power states and power management strategies and algorithms gives us the ability to assess the robustness of power management software early rather than having to wait until silicon is available.

System power management in the hardware is complex, and that complexity is mirrored in the software through many layers from lower-level firmware control, through OS power management, all the way up to application-level power management. In order to optimize these many layers of control we need good and relevant visibility into the power behaviour of the system, including the complete power state space as well as the sources of power consumption. Small errors in system power management can cause catastrophic errors in the energy integrity of the platform — stories of simple OS updates that suddenly drain the battery are not uncommon.

Through the use of virtual prototyping with IEEE 1801 UPF3.0 based IP power models we now can provide a comprehensive mechanism to detect and correct system power management issues early. We can use this visibility into the energy behavior of the system to tune the software and optimize power and performance tradeoffs, thermal tradeoffs and overall energy efficiency of the platform in ways that simply were not viable before, and we can do this early in the development cycle to help develop platforms that are correct by construction.

There are a couple of tutorial sessions on the Tuesday at this year’s SNUG Silicon Valley that will present this work in more detail for those that may be interested.