Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

About three years ago, timing closure for large system-on-a-chip (SoC) designs began to develop into one huge headache. Every EDA vendor’s toolset had its own interpretation of timing constraints, and there was little or no consistency between those representations. So if you used tools from more than one RTL-to-GDSII vendor, you were in hot water. Designers began clamoring for a single open standard for the modeling of nanometer timing effects, and EDA vendors agreed that a single modeling standard for timing would streamline verification and implementation flows.

The only problem was that the industry did not end up with a single standard for the modeling of nanometer effects. Instead, as is the EDA industry’s fractious wont, it served up two: the Effective Current Source Model (ECSM) and Composite Current Source (CCS) models. And while two standards are better than 20, they still aren’t as good as one.

Today, a parallel scenario is unfolding, only this time it’s in the power domain. Once again, EDA vendors are charting a typically divisive course that will result in multiple standards for the specification of power intent.

Two groups have coalesced, each claiming that it is “userdriven” and giving priority to “interoperability.” How they define interoperability, though, may not be to the liking of the design community. So who is behind these two emerging power-intent standards? Why are there two standards and not one? How are they the same, and how are they different? And why might you choose one over the other?

A Tale Of Two Standards
On May 22, 2006, Cadence Design Systems announced the launch of the Power Forward Initiative (PFI), which it claimed would “address obstacles to lower-power IC design facing the electronics industry.” PFI members would gain access to the first version of the Common Power Format (CPF), a means of specifying power intent and constraints in a single file that would be applicable across the design flow. CPF would constitute the basis for a holistic approach to the specification of power intent that would ride atop the existing infrastructure.

“CPF was developed in 2006 and made available to everybody at the end of that year,” says Pankaj Mayor, Cadence’s group director of business enablement. “It’s been used in a production environment in our products since January of 2007 and in several other EDA companies and IP companies in their deliverables. Customers have had over 50 tapeouts with our low-power solution,” claims Mayor.

According to Frank Childers, the Silicon Integration Initiative’s (Si2’s) director of business operations, the ecosystem now supporting CPF includes 38 companies, including large systems houses, IP vendors, foundries, and service providers.

In December of 2006, Cadence donated the CPF to Si2 with an eye toward launch of a standardization effort. Meanwhile, a parallel effort was born of a meeting held at the Design Automation Conference in July of 2006. There, a number of Cadence competitors, notably Synopsys, Magma Design Automation, and Mentor Graphics, met with several systems houses, among them Texas Instruments and Nokia.

Citing a lack of openness and haste in the PFI/Si2 process, the group enlisted Accellera for its own standardization vehicle. Dubbing the competing format the Unified Power Format (UPF), a kickoff meeting in September of 2006 yielded an accelerated timetable for standardization and subsequent donation to the IEEE (Fig. 1).

“UPF was actually instigated by users who saw what Cadence was doing with the Power Forward Initiative and CPF and realized that Cadence was out to control and define it such that it wouldn’t be open,” says Steve Bailey, product marketing manager for Questa in the Design for Verification and Test Group at Mentor Graphics and chairman of the IEEE P1801 Low Power Working Group. “Users were afraid that the other vendors whose tools they use wouldn’t be able to be full partners in it. They wanted something truly open.”

The two groups have wrangled ever since, amidst calls from all corners of the industry for the standards efforts to converge. Backers of the CPF have insisted that Si2 and its Low Power Coalition (LPC) is the proper venue for convergence, while the UPF camp has pushed for the IEEE as the umbrella organization. Further squabbling erupted over patents and IP issues.

Where Things Stand
Unable or unwilling as they are to come to terms with each other thus far, the two camps have pursued their agendas separately. The Si2’s Low Power Coalition released the CPF 1.0 specification in March of 2007; the format is freely downloadable from the OpenEDA.si2.org Web site. Meanwhile, Accellera’s board of directors approved the UPF 1.0 standard in February of 2007 and has since passed the standard into the hands of the IEEE’s P1801 Low Power Working Group.

One insider with a direct view into both the CPF and UPF development efforts is Gary Delp, LSI distinguished engineer, office of the CTO. Delp is vice chairman of the IEEE P1801 Working Group and a former member of the Accellera UPF Working Group. He also serves as an architect in the Low Power Coalition of Si2.

“It is very much in the user’s interest to have a single format,” says Delp. “I would very much not like to get into VHDL and Verilog kinds of dual maintenance issues.”

In fact, just about every interested party on all sides of this controversy, be it EDA vendors, representatives of standards bodies, or tool users, echoes the desire for a single standard. “We absolutely agree that there’s benefit for EDA companies as well as for designers to have one standard,” says Cadence’s Pankaj Mayor.

As to why Cadence and the PFI has declined to pursue convergence between the standards, Mayor cites parochialism and a lack of broad support. “Why does Cadence decline to participate in the IEEE P1801 Working Group? That’s really a UPF effort, just moving from Accellera to IEEE,” says Mayor. “And, representation in the group is fairly limited.” Voting membership in the P1801 Working Group includes Accellera, ARM, Intel, LSI, Magma, Mentor Graphics, Synopsys, and TI.

Continue to page 2

Indeed, it can be said that until recently, CPF had much more forward momentum in terms of infrastructure. Cadence announced a full CPF-compliant design flow a year ago (Fig. 2). Cadence’s Incisive Design Team and Enterprise simulators, the Incisive Design Team Manager and Enterprise Manager, the Encounter RTL Compiler global synthesis tool, and other Cadence tools have been ported to CPF.

A number of PFI member companies cite early tool support for CPF as a chief reason for their participation in that effort. “We began looking at how users of our processor-core IP could define power intent upfront in the flow,” says Gagan Gupta, senior director of technical product marketing at ARC International. “At the time, CPF and PFI were at the forefront. ” Gagan points out that ARC remains open to supporting both standards if customers ask for that. He also states that to his knowledge, no customer has taped out a design with ARC cores using CPF.

But just last month, Magma, Mentor Graphics, and Synopsys silenced critics of UPF’s lack of tool support. The three vendors rolled out a bevy of tools supporting UPF 1.0 (see the table).

Close But Not Quite
For all of the discord over these two standards, it’s well worth noting that they’re far more similar than they are different. “If you look at both CPF and UPF from the format standpoint, they are 80% or so identical in concept, but 100% different in syntax,” says Dave Allen, product director for power at Atrenta. “There’s about 10% in CPF that’s not in UPF, and vice versa,” Allen says.

One thing that is found in CPF, but not in UPF, is representations that are useful for multicorner static timing analysis. CPF provides facilities for associating different .lib files and different process-voltage-temperature (PVT) corners. UPF 1.0 (the version that was approved by Accellera and donated to the P1801 Working Group) has no equivalent for this capability.

Another difference between the two formats is that UPF intentionally has no ability to describe library cells in addition to design data. CPF, on the other hand, permits representation of both library cells and design data.

An example of something that’s in UPF but not in CPF is specific reference to simulation semantics. “When you perform simulation in a power-aware framework, you have to corrupt data when the power supply goes unknown,” says Allen. Simulation semantics for data corruption caused by a block turning off all of its outputs are present in UPF but not in CPF.

In terms of syntax, both formats are based on the Tool Command Language (Tcl). “Syntactic differences are relatively easy to get around,” says Allen. “But the real issues come in where there are differences in the underlying data model and in the vision for how the information would be, and should be, used. And, perhaps, in some cases, capturing information in one format that’s not being captured in the other.”

For example, says Allen, CPF enables users to specify a kind of overwriting of Liberty types of library data within the CPF commands. “For the most part, we try to keep that out of UPF and just rely on what’s in Liberty as the format, and define what the interface is, or the interaction between what’s in UPF versus what’s in the Liberty format. There may be something that would be specified in UPF that would overwrite what would otherwise happen based on what’s specified in Liberty. But in general we try to avoid that,” says Allen.

Hierarchica l Design
At present, neither format is particularly well suited for dealing with hierarchical views of a design’s power structure. Extensions to CPF 1.0, however, are being considered by the Si2 Low Power Coalition working group.

Meanwhile, the IEEE P1801 Low Power Working Group has added to UPF 1.0 the ability to create a logic net. “The purpose for logic nets is to help facilitate connecting signals or ports that are on the power-control block of the chip or system to actual control signals that must exist down in the design,” says Steve Bailey, the Working Group’s chair. Such signals might control switches or facilitate signal-restore functions on retention registers.

Adding the command that allows creation of logic nets gets around the issues related to large IP blocks, which in a bottom-up design scenario typically have not had these power-control signals routed to them. “With logic nets, when you synthesize these large bottom-level blocks, you can create the logic nets locally so that they’re in place when you synthesize top-level blocks,” says Bailey. By doing so, users can create connections to the low-level blocks for things that are created in the UPF domain.

Is Translat ion An Option?
Often in the EDA world, competing languages and formats are dealt with through translation between the two. It’s generally agreed that because the CPF and UPF formats each have constructs that the other doesn’t, lossless, bidirectional translation between them is not a likely scenario. From the IEEE P1801 group’s point of view, bidirectional translation between the formats isn’t necessarily needed or even desirable.

“The Working Group’s scope document says that because we recognize that you can’t do lossless translation between the two known formats, being able to do a lossless translation into P1801 is a design goal,” says Gary Delp, the Group’s vice chair. “Then, if you have tools that understand P1801 moving forward, you have the ability to not worry about the two formats. You then have lossless translation with clear semantics coming in from both.”

But as Atrenta’s Dave Allen points out, translation between formats could remain as a sticking point. “Any big system company will have some divisions that will use Cadence tools and some that use Magma or Synopsys,” he says.

If blocks are shared between these divisions, some are apt to come with power-intent files authored in CPF and some in UPF, and those files would require translation. “This is a consequence of getting stuck with two formats,” says Allen.

“If your design flow is going down a single path, and you don’t need to come back to another tool that only supports either one standard or the other, that’s probably easier to address,” says Bailey of the IEEE P1801 Low Power Working Group. “After the P1801 version is finalized, I’m not sure whether bidirectional translation will be more or less feasible than it is today.”