Low-Power Standards War

To the uninitiated, establishing a technology standard may seem straightforward. In reality, the process is mired with technical and political issues as evidenced by the ongoing battle for a de facto low-power design standard between the Unified Power Format (UPF) and the Common Power Format (CPF).

Currently, UPF is with the IEEE for final ratification as P1801, set for vote this month, which some believe ends the debate. Shrenik Mehta, chairman of Accellera, the standards organization that previously managed UPF was reluctant to comment for this article stating, “This is a two-year-old news item.”

However, proponents of CPF are still at work revising their standard, strong in their position that users are adopting CPF constructs and chip design software providers are on board as well.

Steve Schulz, president and CEO of EDA standards consortium Si2 noted, “CPF has had very good support on a relative scale. The industry at large has a huge need for improving low-power design methodologies in semiconductor design and we’re probably—if you think about the penetration in terms of these standards formats, we’re still pretty early in it—about 20% to 25%. A lot of companies are not yet in production with it, but many are getting ready.”

Meanwhile, Vic Kulkarni, president and CEO of Sequence Design, observed that both CPF and UPF are emerging as reasonably well-adopted standards in their own ways because the customer base for both standards seem to be using them for low power design chips. He said that with CPF, for example, there are 100+ design starts – some of which already have taped out.

Sequence and other EDA tool providers are working to support both standards due to customer demand. Kulkarni is quick to note that the company is standards-agnostic from an industry perspective, even though he is on the board at Si2. Some European and U.S. customers want UPF, while Japanese and East Coast-based customers want CPF support.

“From an industry point of view, our dream is to create one standard, to what I fondly call the Common Unified Power Format,” he said. “The key thing is the emotional content at this point rather than the standards themselves. At the end of the day, if you look at our 30 years of history as an [EDA] industry, the de facto standards always won. Even a lot of IEEE standards started as de facto and became IEEE standards over time.

In the last big standards race between Verilog and VHDL design languages, it took about a decade for Verilog to win out, even though some VHDL tools are being used. “As long as there is silicon success using certain methodologies or standards, that typically tends to win in the industry,” he added.

Interoperability is key

Technically, while the same low-power constructs can be represented with either UPF or CPF, much work still needs to be done to make the formats interoperable, said Jerry Frenkil, an Si2 technical steering group member for CPF, as well as general manager of the Silicon Business Unit, CTO and VP of R&D at Sequence Design.

As such, the Si2 technical steering group is explicitly working to try to make sure CPF is interoperable with UPF. While Frenkil doesn’t personally believe the two formats will converge into one super format, he envisions – very much like Verilog and VHDL – that they will become interoperable.

This interoperability is crucial going forward because of the increasing amount of IP in SoCs today, whether it comes from within the company designing the SoC or from outside the company. Especially if the IP comes from outside, the designers can’t control whether the low power intent comes in CPF form or UPF form, so the likelihood is that a given SoC is going to have blocks in CPF and other blocks in UPF. To make either one practical, they are going to have to be interoperable.

In addition to interoperability, another issue that has frustrated users is the fact that different companies apparently have slightly different versions of the standards. Frenkil noted that in a recent Si2 technology steering group meeting, much discussion was paid to how to deal with and help prevent the problem.

“This is a problem within the CPF camp and separately with the UPF camp. Both have that issue. I think the standards organizations (Si2 and IEEE) are going to have to work hard to address that. Interestingly, I think Si2 may be in a better position to deal with it since I don’t believe the IEEE is set up to address it other than publishing a standard. With Si2 there are a variety of things that can be done to address multiple versions of a standard such as having a test suite that indicates specific conformance to a given version of a standard; developing a standard parser that Si2 could give out to the industry to check CPF if it conforms to a particular version of the standard or not,” he said.

“Ultimately it will come down to individual companies being diligent in their development and their practices in terms of how they test and what they release, Frenkil added.

Technical differences

Specifically, the biggest fundamental technical difference between UPF and CPF is the way they deal with libraries, which represent the ancestral heritage of both.

It is understood that UPF doesn’t have a syntax to define the low-power-specific cells like level shifters or switch cells because it assumes the existence of a .lib file in which all those things are defined. That represents the Synopsys heritage. Cadence, meanwhile, had a less-developed library position and included in the original CPF a number of commands that address library elements specifically. Frenkil believes that helps CPF a bit because if, for some reason, the user has a library that doesn’t have those instances to find in .lib, they can be redefined or obtained from CPF. “As time goes on and more libraries have these special cells in them specifically, it probably won’t be much of an issue,” he said.

Achieving UPF-CFP interoperability

Given that both formats are in use today with SoC developers, interoperability is the next logical step in order to avoid the political aspect of dealing with two standards.

From a technical standpoint, there are two main issues. The first is to make sure that individual commands in one language have their specific counterpart in the other, and that correspondence between them can be established by the user. For example, in some cases the correspondences are very similar, the command names are almost identical, and the options to the commands are almost identical. In other cases, there is no one-to-one correspondence but there may be some structures in one that, in group form, map to commands in the other language.

The other key UPF-CFP interoperability issue is that UPF/P1801 allows some the commands to be placed inline in the RTL code. Frenkil asserted that the original intent with CPF and with UPF 1.0 was that all these commands would be contained in a side file, in addition to the RTL. However, P1801 added the capability to put some of these commands inline with the RTL, which poses a bit of a challenge for CPF. While one-to-one correspondences with those commands have been established to allow for comparable functionality, it is still not settled as to whether CPF will be able to read it out of the RTL the way the P1801 community will.

Ultimately, users will decide the outcome of UPF and CPF. Until then, the work continues.

Users, we want to know what you think about UPF and CPF. Please comment below with your issues, complaints and concerns.