The Moving Target Known as UPF

As if engineers did not have enough difficulty just getting everything right so that their designs are implemented functionally correct, the demands of lowering power consumption require changes that can affect functionality and verification. Techniques such as power gating, clock gating, mixed supply voltage, voltage and clock scaling are commonly used to reduce dynamic and static power consumption of ICs. Each of these methods require changes to the design in ways that can affect functionality. Thus power reduction methods must be something that can be specified and even more importantly verified, both in the context of whether they work correctly but also such that they do not adversely affect chip operation.

Starting back in 2006 the IEEE took on the challenge of providing a standard to help the process of reducing power consumption with their IEEE 1801 specification. The first version of IEEE 1801 also known as the Unified Power Format (UPF) specification was published in 2007. It would be nice to say that this specification worked perfectly and remains little changed to this day. Sadly, the industry has encountered a steep learning curve regarding what makes an optimal power specification format. Commensurate with this, adoption of 1801 has been chronically low. To deal with issues in the 1.0 version, the 2.0 version followed fairly quickly in 2009.

Each newer versions of IEEE 1801 has worked to improve the specification. Usability, clarity and ambiguity have all be improved. The latest version is 3.1. It differs from the previous versions in both syntax and semantics. The challenge for designers today is that IEEE 1801 is used in design specification, power analysis and implementation tools, as well as in functional implementation and verification tools. In short, there are a lot of touch points for IEEE 1801. Things get messy when among the tools used in the flow engineers encounter support for differing versions of the spec.

But it gets worse, legacy designs may have used earlier versions, muddying the question of which version to use across a new design. Likewise, externally sourced IP, which may be a black box, might lack visibility or insight so that IEEE 1801 can be used effectively. Optimistic designers might hopefully wish that UPF directives such as “upf_version” will help to sort things out. However, “upf_version” is really only a suggestion to tools indicating what syntax was used to write the directives. It by no means is a get out of jail card for designs built with earlier versions.

There is some help in the form of useful guidance in a white paper written by Madhur Bhargava from Mentor, a Siemens business, where many of the key differences between the versions are discussed and strategies for dealing with them are offered. The white paper, titled “UPF 1.0, UPF 2.0, UPF 2.1, UPF 3.0, and now UPF 3.1: Which is the right design standard for my design?”, helps by offering some clarity to the changes over time.

First off the paper gives its own summary of the evolution of UPF. There is a discussion on the newest UPF 3.1 that goes over the most important changes and provides historical context regarding the reason for the changes and previous handing, if any, of the issue being addressed. The paper has a detailed section on backwards compatibility, which necessarily covers both syntax and semantics – and they do need to be addressed both individually and together. While this is not light reading, and one could hope that in the end there was an easier story to tell, it is fortunate that major progress has been made and much learned. Anyone contemplating using UPF should read through this paper, as it offers a lot of useful information in one place in a well-organized format. If you are interested, the paper can be downloaded from Mentor’s website.