By Ed Sperling
Standards group Si2 rolled out a first step toward eliminating the discrepancy between the Common Power Format and the IEEE 1801 format, formerly known as the Unified Power Format.

The Open Low-Power Methodology, or OpenLPM, is aimed at increasing interoperability between the competing formats. And while there was some base level of interoperability, getting maximum benefits from each format wasn’t always possible.

“Today, the use of the low-power standards is unfortunately dominated by the lowest common denominator that the tools of your interest support,” said Leon Stok, IBM’s vice president of EDA technologies, in a statement. “Since numerous tools are needed in an end-to-end implementation and verification flow, this significantly erodes the ‘power’ of the very useful elements in the low power standards. We are looking for OpenLPM to significantly increase this practically useful set and drive to an eventual single standard.”

Actually getting to a single standard isn’t so simple because there are benefits from each that don’t necessarily go together because they affect different parts of the design flow. Nevertheless, using a single methodology that can extract the benefits of both without minimizing one or the other is a major step in the right direction.

By Ed Sperling
It could well be one of the strangest developments in standards history. Two competing standards for power formats were rolled out in the middle of the last decade and aside from a few cries of foul they fell below the radar screen of most chip designers and architects for a half-dozen years.

Fast forward to the present and the Common Power Format (CPF) and Unified Power Format (UPF) have chipmakers up in arms, railing about competing standards and more than one version of even the same standard. And while significant work is under way to achieve interoperability across all of them, there isn’t even a hint that they could be merged into a single standard.

Why this sudden interest by chipmakers? It’s because mainstream has shifted from a 90nm process to 50/45/40nm. At the advanced geometries power needs to be considered up front in a design for the first time rather than addressed later in the design flow. Various modes of operation have to be considered, power islands need to be turned on and off, and issues such as electromagnetic interference, electromigration and electrostatic discharge are suddenly mainstream considerations. In short, you need to define power intent.

Understanding those issues at the architectural stage can save enormous amounts of pain—and money—further down in the flow, particularly at the verification stage and later at tapeout.

What’s good?
All of this isn’t necessarily bad, however. There are things to like about both standards, even if you don’t like the existence of two.

“There were a few of us complaining from the start that there should be only one standard,” said Vic Kulkarni, general manager and senior vice president of the RTL business unit at Apache Design Solutions. “As an independent vendor we have to support all the customers because both standards are getting adopted for low-power intent. But there are differences. CPF tends to be more back-end friendly and UPF is more front-end friendly.”

He noted that UPF, which has evolved into the IEEE 1801 standard as version 2.0, is the better format for verification. It provides options for supply network semantics, power switch modeling and simulation support in power states. It also provides extensions for logic designs with power-specific capabilities and constraints without modifying the original logic, and ways to stitch the supply port to the HDL port through concept of value conversion tables.

CPF, meanwhile, provides better support for library cell-related commands so it can define always-on cells, global cells and pad cells. Unlike 1801, the same CPF file can be used at all levels of the flow. And there are more back-end-specific commands involving IR drop limits and power nets.

Source: Apache

“The best compromise will be to build bridges between them,” Kulkarni said. “That’s been the focus of Si2, which has been working on bridges for power voltage analysis and voltage scaling.”

But there’s another school of thought that says competition in this market is a good thing. “The presence of competition may have made standards happen in the first place,” said Dennis Brophy, director of strategic business development at Mentor Graphics. “Consumers say they want one standard and that the standards we have are not pro-consumer. But this also has aggregated users to ensure the information they get is portable and useful and to make sure there is some way we can understand the semantics of one and import that into the syntax of the other.”

What’s bad?
Getting that type of automatic translation from one standard to the other isn’t easy, though. Qi Wang, technical marketing group marketing director for Cadence Solutions Marketing, likens it to providing an easy translation between Chinese and English. The syntax and semantics of each language are different.

“UPF 1.0 describes everything through power and ground nets,” said Wang. “CPF is more power-domain specific.”

Source: Cadence

That’s fine for companies that develop tools with either of those formats, but most large companies and many small companies have a combination of tools from multiple vendors. That makes things confusing enough, but it gets worse on the UPF side because there are two versions of UPF—version 1.0 and the more encompassing 1801—in the new 1801 standard.

“There’s a lot of legacy in 1801,” said Wang. “To really get to convergence you need to clean up 1801. The number of command options has increased five times.”

Synopsys sees things differently, of course. Synopsys and Mentor support 1801, while Cadence supports CPF. And while all support interoperability and overlap between the standards, there will still be two standards for the foreseeable future.

“There are issues being dealt with inside the standards committees, but part of this has to happen outside of what the standards committees can do,” said Yatin Trivedi,
director of standards and interoperability programs at Synopsys. “Synopsys supports a subset of what 1801 customers are asking for and Mentor may ask for a different subset. The overlap is probably 80% to 85%. Many Synopsys users are focused on certain types of design and power while at Mentor they may be focused on multivoltage designs.”

What becomes particularly problematic is third-party IP, although work is under way to eliminate that discrepancy. Synopsys is one of the largest IP vendors in the industry, particularly after its acquisition of Virage Logic, but the IP it acquired with Virage supports CPF while Synopsys is firmly behind the competing 1801.

“Moving forward, we see the format will not be the end,” Trivedi said. “It will only be the enabler. The first part will be understanding the capabilities of the formats and interoperability. The second part will be assessing whether users are feeling confident enough with methodology embedded into the tools.”

The future
Standards group Si2 has been working on bridging these two worlds in multiple areas. Steve Schulz, president and CEO of Si2, said the results of that work will be unveiled early next year.

Schulz noted that the starting point for interoperability is the 1801 standard. While these two standards will never completely converge there will be enough interoperability and an interoperability guide—as well as an understanding going forward that each standard needs to proceed with an awareness of the existence of the other. “This ought to get better over time,” Schulz said.

There are a lot of large chipmakers banking on that.

Ignoring The Rules
In a classic example of how technology gets used in ways for which it wasn’t designed, the University of Massachusetts at Amherst has been experimenting with running embedded flash memory at voltages lower than what has been recommended by a microcontroller.

Using software algorithms the team at UMass’ Department of Computer Science has developed what it claims are reliable storage methods at low voltages without modifying the hardware. This is an interesting development, but it also raises lots of questions about how IP will ultimately be used.

The researchers presented a paper on the subject at the Usenix conference in San Jose, Calif., this week, and said the energy consumed was 34% lower using this method. The question for companies evaluating this approach is what effect it has on performance and security– and what the tradeoffs are in terms of area and cost.

Unifying Power Intent
Si2 has released version 2.0 of the Common Power Format in an effort to bridge the gap between CPF and the Unified Power Format (UPF). Just for reference, Cadence developed CPF while Mentor Graphics and Synopsys support UPF. Both try to define the power intent of a design, but interoperability has created problems—particularly at the verification stage for fabless companies that rely on third-party IP and specs.

Smarter Windows
Philips Research has developed an “e-Skin” panel that switches from black to transparent using scavenged energy from a mobile phone’s RF signals. Aside from just being interesting, it’s particularly useful for smart windows in an office building, which can be dimmed when the sun is bright and clear when it is not.

Reconfigurable radios
Imec has developed low-power spectrum sensors for cognitive radios and networks. This is the kind of technology that will mean fewer dropped calls, no matter where a phone—or more accurately, a communications device—is used.

–Ed Sperling

By Geoffrey James
There’s never been a greater demand for power-efficient silicon. As consumer electronic devices get smaller, with increased functionality, battery power becomes a premium resource. At the same time, “Green IT” is a major corporate trend, and the best way to be environmentally sensitive (while saving on energy costs) is to buy technology that ekes the maximum computing oomph out of every watt it eats.

The bad news is that today’s small geometries and touchy chip manufacturing processes can turn energy efficiency into a design nightmare. The good news is a wealth of techniques and tools are emerging that make chips less power-hungry, creating a generation of chip designs that satisfy the need for more compute power without squandering the electrical power that makes it work.

The low-power challenge
When it comes to lowering the power consumption of semiconductors, Moore’s law is a double-edged sword. On one hand, the smaller the circuitry, the more computing and memory bang you get for your energy buck. Consider: a typical PC sold today consumes about the same amount electrical power as a PC sold 25 years ago, but has enough computer power to replace ten thousand vintage 1984 units.

On the other hand, Moore’s law also creates a real problem when it comes to power management: leakage. Chips expend electrical power in two ways. The first is dynamic power, which is the electrical power it takes to make the chip do what it’s supposed to do – like turn switches on and off. The second is static power (aka leakage), which is the heat that circuits generate as a byproduct of having electrical energy flowing through them.

In ancient times (i.e. back when 180nm was considered state-of-the-art), designers could largely ignore static power because it gobbled up only a tiny percentage of the electrical power flowing into the chip. But as geometries have shrunk, static power has become ever more intrusive. “With a small enough geometry and a big enough chip, we have to deal with as much as 20 percent of the electrical power dissipated by leakage,” says George Zimmerman, CTO at Solarflare, a maker of 10 Gigabyte per second Ethernet controllers.

Leakage also can make other, nearby circuits act unpredictably – always a bad thing – and that unpredictability is determined not just by the chip’s layout, but by the specific manufacturing process used to generate the chip.

“There are variances in circuit behavior even among the different manufacturing lines within a given foundry,” explains Brian Leibowitz, senior member of technical staff for circuits design at the memory IP vendor Rambus.

Even dynamic power presents challenges at the smaller geometries, mostly because today’s SoCs integrate so much content onto a single piece of silicon. “Different components used to live on different chips, each with its own power requirement,” explains EDA guru Gary Smith. “SoCs force designers to manage different power requirements on a single chip.” And, just to make things even more complicated, the way circuits use dynamic power can vary, especially at the newest nodes, based upon the characteristics of the individual manufacturing process.

Techniques and tricks
There are several ways to make chips more power efficient.

First, a designer can make sure a circuit only does the minimum amount of work (i.e. switching) when it’s actually in use. This is typically accomplished through clock-gating — adding additional logic to disable portions of the circuitry so that its switches do not change state unnecessarily. This causes the switching power consumption to drop to zero, but does not (alas!) eliminate leakage, which continues as long as the circuit remains active, according to Darren Jones, engineering director at the CPU IP company MIPS.

A more comprehensive approach is to completely power down a block of circuits when they’re not needed. For example, if a quad-core CPU is running a simple spreadsheet, it may be using only 10% of a single CPU core. In that case, cutting the power to the other three cores vastly reduces the power consumption of the entire chip. Powering a block down intelligently, however, requires considerable design savvy. There’s always a danger that the powered-down block might get out of sync with the rest of the chip or, even worse, get its circuits fried when the power comes rushing back.

A variety of clever, but less radical, techniques also serve to reduce, if not eliminate, power consumption. For example, you can lay down a CPU block that’s got more potential muscle than you really need and then run that block at lower power. As a result, you get less processing power out of the block than its full potential, but because the block is optimized to run faster (and therefore hotter), the net result is far less leakage. “This technique can be applied in a wide range of embedded designs,” explains Jones.

Another sophisticated approach is “dynamic voltage and frequency scaling” where the chip (and surrounding system) selects the amount of power to feed into each block, based upon the kind of processing that the block in question is expected to accomplish. “That way you end up paying the full leakage cost only when each block is working its hardest,” says Jones.

However, these fancy techniques, while useful, aren’t free. There’s design overhead because the operating system running atop the chip must understand exactly what’s going on, lest it suddenly discover that an expected resource is no longer available. That means the chip designer must think architecturally from the start, and look at the entire target system, rather than simply the characteristics of the chip itself.

There are also tricks that can be played at the system level. Power transistors are a perfect example. As any system designer knows, feeding a smooth flow of electrical power to a chip requires a power transistor either on the board or (more rarely) on the chip itself. Even though power transistors are typically built using fairly large geometries, they can be shockingly inefficient, losing as much as 40% of their incoming power to leakage. Fortunately, it’s possible to build and tune such transistors so that they approach efficiencies as high as 90%, according to Dermott Lynch, the vice president of sales for Silicon Frontline, a company that provides power transistor test and analysis.

EDA to the rescue
While chip designers thus have a variety of techniques to draw upon, the design process is not always straightforward, and must account for variances in manufacturing processing, according to Sudhakar Jilla, director of marketing for the place and route group at Mentor Graphics. “To do this correctly, you essentially need to think about the problem at all levels, from the first initial ESL architecture, all the way down to the final tape out,” he says.

Because of this, EDA firms have built power management capabilities into a wide range of their software tools. Synopsys, for example, has created a solution called Eclypse (see Figure 1) that helps manage power issues throughout the entire design flow, according to David Hsu, the company’s director of solutions marketing. “We’re finding that our customers are deeply concerned about these issues and are looking for a complete solution that spans the entire tool flow,” he explains.

Figure 1: Synopsys' approach to cutting the power.

In addition, there are plenty of smaller companies helping designers to cram as much efficiency as possible into their chips. The company Mellanox, for example, has a tool that allows companies to explore the power consumption tradeoffs between running a CPU at low power continuously and running it in short bursts of high power, based upon the intended usage of the final device, according to Ghislain Kaiser, the company’s CEO and founder.

Such tools work well with the larger suites because the EDA industry had the foresight to settle on a design standard, Unified Power Format (aka UPF or IEEE P1801). “It provides a single power specification for your chip defined in a single file,” explains Arvind Narayanan, Olympus-SoC product manager at Mentor Graphics. “This allows Mentor’s tools to be applied across a wide range of design environments.”

(Editor’s Note: UPF is backed by Accellera and is supported by Mentor Graphics, Synopsys and Magma. A similar standard called the Common Power Format, put forth by Si2 is supported by Cadence.)

While today’s chip designers are successfully coping with low power requirements, the future may prove more challenging, according to Cary Chin, director of technical marketing for low-power solutions at Synopsys. “At 65nm and 45nm, it’s not unusual to see chip designs where dynamic power and static power are gobbling up equal amounts of energy,” he explains. “At even smaller nodes, designers are worried that the leakage problem may get worse.”

Even so, the semiconductor industry, along with the EDA firms that help them, has overcome similar challenges in the past, Smith points out. “When it comes to solving problems, the creativity of this industry is truly phenomenal. If there’s a way to manage power effectively as we get to the smaller nodes, you can rest assured that some smart group of designers will figure it out.”

By Cheryl Ajluni
Regardless of what you are designing these days, one fact holds true: Your design is only as good as the design tools you use.

Gone are the days when a design could be done on the back of napkin. Today, engineers require a complex ecosystem of interworking tools to guide them through the complex design flow. This is especially true when it comes to low-power design, as its complexity now permeates every aspect of the design flow, creating challenges that threaten to derail design closure at every turn. Here, automated design tools can play a key role in speeding the design process, selecting optimal low-power architecture and ensuring design closure.

The problem, of course, is low-power or “power-aware” design tools and flows are still in their infancy—a fact that poses a bit of a dilemma for designers. Not only do they need to figure out what type of power management and low-power design techniques to employ, but they must also determine which tool vendors support those techniques. Then they have to evaluate the possible tool options and make a selection. This can be a stressful and time-consuming process, especially when you consider the decision is critical to the success of any design project and, for that matter, to a company’s overall success and vitality. While there are no hard and fast rules for selecting the right tool, or the right vendor, there are a number of considerations—over and above a tool’s verified functionality—that engineers can use to help simplify their decision. Those considerations include:

• Cost. A tool’s actual cost and its available pricing options are important considerations when evaluating a design tool. Of course, a tool’s true cost is also impacted by its learning curve and overall reliability—both of which can affect downtime—and therefore must also be considered prior to making a tool purchase.
• Speed. While it may not always seem like a key consideration, how fast a tool operates can directly impact the designer’s time-to-market schedule as well as overall design costs and therefore should not be overlooked. Was it designed for multicore processors, or simply updated to take advantage of them?
• Support for Industry Standards. Using a tool built to emerging low-power industry standards, such as the Common Power Format (Cadence and Magma) or the Unified Power Format (Synopsys, Mentor and Magma), ensures that it will interoperate with a range of other design tools and flows. It is also smart to select a tool that can be used within industry-accepted reference flows such as the power-aware reference flow recommended by the Low-Power Coalition (LPC) of Si2 or Accellera, respectively.
• Ease of Use. Is the design tool easy to use? Does it require special training or low-power design expertise? Does it make you more efficient or productive? Does it support multi-language user interfaces for globally disperse design team members and are the user interfaces familiar? Is it easy to deploy, administer and maintain? Does it integrate well with other low-power design tools and design flows? All of these factors should be carefully considered during a tool’s evaluation.
• Flexibility. Is the tool flexible enough to accommodate changes in technology and can it adapt to changing business conditions—an especially critical question given the current state of the global economy? Can it support the needs of a globally-disperse design team with features like revision control and policy control for IP management?
• Customer Support. How responsive a tool vendor is to the designer’s support needs can be vitally important to the success or failure of your low-power design. Does the vendor provide quality documentation, training when needed or on site technical support? Does the vendor have proven expertise in low-power design? Such expertise may prove invaluable if you find yourself facing a difficult low-power design problem.
• Vendor Credibility. Don’t forget to verify the tool vendor’s reputation with other designers. If they have had trouble with the vendor, then chances are good that you will, too.

Design Tool Options
Despite the fact that low-power design tools and flows are still relatively new, there are a number of options to choose from. A sampling of these tools includes the following:

• Catapult C Synthesis and SpyGlass-Power, from Mentor Graphics and Atrenta, respectively. SpyGlass-Power is an RTL power estimation and reduction tool that is used to automate multi-level clock gating. Catapult is a high-level synthesis tool that offers a fast path to verified RTL from pure C++. New low-power optimizations enable the tool to thoroughly analyze a design to determine gateable clocks and build the appropriate logic. An interface now exists between these two tools that allows RTL output from Catapult to be handed off to SpyGlass-Power. Static and dynamic power estimates from SpyGlass-Power can then be fed back into Catapult C.
• Eclypse Low Power Solution from Synopsys. Eclypse is an integrated flow of tools, intellectual property and methodologies that allows designers to include everything from MTCMOS power gating, multiple voltages, dynamic voltage and frequency scaling. The goal is to dramatically simplify design and the increasingly complex verification portion of that design. Eclypse also includes clock gating, low-power clock tree synthesis and leakage power recovery. As you might expect, it includes UPF support, as well as support for the Low-Power Methodology Manual created by Synopsys and ARM.
• Cadence Low-Power Solution from Cadence Design Systems. Cadence’s Low-Power Solution is a CPF-enabled design-to-signoff methodology that makes it easy to incorporate low-power design techniques in advanced SoCs. It includes tools like the InCyte Chip Estimator for chip planning, Encounter RTL Compiler for logic synthesis, Encounter Conformal Low Power for structural, functional and equivalence checking; the Encounter Digital Implementation System for physical implementation, the Encounter Power System for power rail analysis, and Incisive Formal Verifier for formal property checking (Figure 1).

Figure 1. The Encounter Power System solution accelerates power optimization and signoff with a unified timing and power database. It can be used by front-end logic designers seeking high-quality early power and rail analysis, as well as by back-end physical designers looking for comprehensive signoff analysis and silicon-correlation.

• PowerPro CG and PowerPro MG, from Calypto Design Systems (www.calypto.com). The PowerPro CG tool reduces power by implementing sequential clock gating logic in the non-memory portions of an RTL design. PowerPro MG is a memory gating tool that automatically generates power-optimized RTL by taking advantage of the low-power modes available in on-chip memories. It works with PowerPro CG to produce the lowest power design possible.
• Talus Implementation System, from Magma. The Talus implementation system provides a fully integrated RTL-to-GDSII flow for high-performance, high-complexity, low-power nanometer designs. Talus Design and Talus Vortex are key tools in the system. Talus Design is a full-chip synthesis environment, while Talus Vortex is a physical design environment. Another tool, Talus Power Pro, works in conjunction with Talus Design and Talus Vortex to enable optimal power management throughout the flow.
• PowerArtist-XP and PowerTheater, from Sequence Design (now part of Apache). PowerArtist-XP is an RTL Design For Power (DFP) platform that features fully-integrated advanced analysis and automatic reduction (Figure 2). Using it, designers can achieve a 10 to 60 percent or more power savings. PowerTheater is a solution for RTL power analysis.

Figure 2. PowerArtist-XP enables designers to make intelligent design decisions that maximize power savings while minimizing design impact.

The Bottom Line
While designing for low power remains a difficult and complex challenge these days, appropriate use of low-power (power-aware) design tools can help simplify the process. Such tools will only become better and easier to use with time. Of course, selecting the right tool or tools is absolutely critical to a successful low-power design, perhaps just as critical as determining which low-power design and power management techniques to implement. While there is no set criterion to follow when making this decision, the considerations outlined above can serve as a guide in helping to make your decision that much easier.

By Ann Steffora Mutschler

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.

By Ed Sperling

Verification has always been the time-consuming part of designs. Even at 120nm and above, where power wasn’t much of an issue, verification accounted for an estimated 70 percent of the non-recurring engineering expense in a chip.

Since then, the tools to automate design have become more effective, but the complexity of designs has grown by leaps and bounds beyond those tools. As a result, verification still accounts for at least 70 percent of designs, and according to a study by the Synopsys User Group (see chart below), the problem is getting worse. Some 69 percent of tapeouts are late.

There are two extremely thorny issues that engineers have to deal with in verification these days. One is the problem of verifying multiple power islands. The average cell phone chip has anywhere between six and nine different power islands, and those islands often use different voltages and run in different modes—on, off or standby.

The trouble occurs when those islands have to be verified, because many times that verification is state-dependent depending upon their mode. If all of the islands are on, the results can be dramatically different than if they are off, completely burning through the power budget and either generating too much heat or drastically reducing battery life.

“Verification of power domains is extremely difficult,” said John Koeter, vice president of marketing for the solutions group at Synopsys. “There are significant power differences depending upon the power management options.”

The second issue is verifying low-power IP, which has become particularly attractive in complex designs. Gary Delp, distinguished engineer at LSI, said that should change sometime in the near future with the introduction of the IEEE 1801 standard for the design and verification of low-power integrated circuits.

“Standards allow us to view things in abstractions, which means a decrease in complexity with more predictable results,” he said. “Power, timing and area have all become more complex. What we’re doing is drawing a trust boundary around proven IP with interfaces. A key piece is to tie the 1801 standard into the simulation environment and pull IP-XACT support into tools.”

Bridging the IP-XACT with the low-power verification world requires a leap of faith in design, however. Both of those standards also have a connection to the Transaction-Level Modeling 2.0 standard, which is another black-box type of technology. Some of the work already is done for systems designers, but trying to figure out exactly what’s happening can be unnerving to an engineer who has been able to understand the effects of every action and interaction until now.

The approach with 1801 is to establish a safe, well-tested zone, and then to work within that zone.

“What you’re doing is designing to an interface and incorporating that interface,” said Delp. “You’re also adding consistent semantics for things like corruption, isolation and level shifting, and separation of power, intent, configuration and implementation. All of that is being layered and structured for implementation checking.”

OVM, VMM, CPF, UPF

It doesn’t help that two languages are dueling for dominance in the verification space—the Verification Methodology Language supported by Synopsys and ARM and the Open Verification Methodology supported by Mentor Graphics and Cadence Design Systems. Both are currently working on supporting low-power designs, but industry insiders say neither has solved the low-power design issue.

“There are two big differences between VMM low power and OVM low power,” said John Decker, solutions architect at Cadence. “With OVM, low-power is always on. There is a problem if they get out of sync.”

On top of that are the battles between Accellera and its followers with its Unified Power Format, and Si2 and its adherents with the Common Power Format. (see related story????) Until these issues are resolved, either through one standard emerging as the de facto winner, or until the differences can be bridged or wrapped, this will create added complexity in areas such as IP compatibility and low-power verification.

The bottom line: Things are getting harder, and while standards and tools are getting better and more comprehensive, it’s debatable whether they’re improving at the same rate as the rise in complexity.