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.”
Reprints
