Unified Power Format (UPF) has been an ever evolving standard started as a technical committee by the Accellera organization in 2006, producing the first revision of the UPF specification, UPF 1.0 in 2007. Soon after UPF 1.0 release the group reformed under the IEEE organization as IEEE1801 with a major goal of merging in a competing standard, the Common Power Format (CPF). IEEE 1801 has since released three new versions of the UPF specification over the past ten years: IEEE1801-2009 (UPF 2.0), IEEE1801-2013 (UPF 2.1) and IEEE1801-2015 (UPF 3.0).
UPF solves some unique problems in the design world. One is the lack of any need to consider power supplies in traditional digital design at the RTL level (or higher). Others cope with the desire to separate what is supported by an IP component from what is actually implemented on a given chip. From an IP developer’s view: How can I provide one functional description and let my user choose what power features to use and how to implement them? From a chip architect’s view: How can I describe the power structure on a chip without having to embed the architecture into every block of the functional description?
UPF addresses these needs by separating the “Power Intent” description from the functional description. So, when the UPF description is overlaid on top of the functional description, a complete view of the device, including the implementation of the power features, can be used for simulation, synthesis, verification, power analysis, and place and route.
One of my favorite features is being able to simulate an RTL description and have the logic simulator model the power switches, clamping logic and save/restore flip-flops. To me, this makes the simulation much more accurate when interacting with these features; for example, when a power switch is disabled, all the logic within the power domain will go to an unknown state and if your isolation signaling is correct, the unknowns will not propagate other logic that is still powered. This makes it feel almost like a gate level simulation, but I did not have to modify the RTL to tell it about all this new logic, or even the power supplies. Instead, I just needed to provide a UPF description along with the RTL description.
Which UPF Version?
But the question is: Which UPF version do I need to supply? When I look at the support for UPF in the simulator, it was pretty specific about what set of commands and options it supports. I notice that this set does not cover 100% of any given version of the standard and that the supported commands do not even come from the same version. Instead, I find a mixture of versions and, unfortunately, some commands require a slightly different interpretation of the specification syntax. Well, when I am only using one simulator version, it is not that hard to create the right syntax by looking through the EDA vendors support table, see example shown below.
Example support table for a UPF command (S=Supported, NS=Not Supported, NA=Not Applicable)
However, remember the UPF description supports many different parts of the design flow, including synthesis, verification, power analysis and layout. So, each new command or other improvement in the UPF specification requires support in many different tools, providing a significant challenge for the EDA tool makers. The user is stuck with large tables within the EDA documentation stating exactly which commands and options for each UPF version are supported in each tool version. Here is a small example below for one UPF command.
To see what commands a full design flow would support, I took a look at a UPF description from an end user. It was not a simple description that uses only the most current UPF syntax. In fact, it does not use any of the latest features from the most current specification. Instead, it combines various versions of UPF: some commands are from 1.0, some from 2.0, and a few from 2.1. These command and option choices directly relate to the various tools and versions in their flow. I have no doubt that this was a lot of work to discover and something that the user does not wish to repeat often.
So, users tend to develop a tool flow and then stick with this flow for one or more design cycles until something forces them to make a change. This means the tools in their flow are typically not the most current and can lag behind the support of updated standards by several years.
The Nightmare Begins
This is where my nightmare begins. As a provider for power-saving IP, how can I generate the proper UPF for each customer, when every customer flow is different and therefore would require a different combination of UPF syntax?
Some ideas will not work: Create a UPF file based on the most recent version and hope that the user can translate this format backwards to the format that they require. Allow the user to pick a UPF version from a list and generate a UPF file for that version. Or provide every possible combination of every command and let the user configure which ones to use through some complex table. Some of these solutions are too simplistic and do not provide what is needed, while others are too ambitious and would require too much development and support resources, with no ability to verify that I got it 100% right.
Sonics’ solution to solving this nightmare is to provide our users with a Tcl API that accesses the abstract data model of power information that we captured to represent their power control logic. We give the user a set of Tcl procedures that write out this information using various UPF commands from different versions, which are each guaranteed to be consistent with the customer’s configured EPU design. By combining the desired set of commands, the user automatically generates a customer tuned UPF for their flow. Standard UPF commands can be referenced quickly, while non-standard implementations can be crafted as needed using the API. The result is a UPF file that fits the flow already defined by the customer with minimal effort and maximum results.