By Ann Steffora Mutschler
While the term “design flow” can be a moving target, there are some specific requirements for a low-power/power-aware tool flow. Looking at this from a high level, where is the industry today, and where is it headed?

There are really two sides to power, which are almost like two sides of the same coin: power consumption and power integrity. And both of those are global, spanning the system and the package and the increasing convergence of both.

“One thing required in this day and age of ever-shrinking product lifecycles is some degree of predictability,” said William Ruby, senior director of RTL power product engineering at Apache Design. “You want to be able to predict early on, when you’re not even halfway finished with the design, what is your power consumption going to be with a reasonable degree of accuracy? What does the thermal picture looks, even spilling over into power integrity? If I can estimate my power, I should be able to also predict some of the power-induced noise considerations, as well. Looking at the power-aware flow from that perspective, early power analysis for the consumption side as well as the power integrity side is really one of the keys here.”

But what about the tools? The back-of-the-napkin or spreadsheet-type calculations worked to a certain extent when things were not very complicated. There needs to be more precision built in. Apache’s answer to this is the RTL power model (RPM) to get better accuracy and more predictability early on. Ruby explained the RTL description allows for a good power number early on, looking at various operating modes. It takes that data into the power integrity side for early chip power integrity analysis. The predictability comes also with the ability to use RPM throughout the design flow to maintain consistency.

Mary Ann White, director of Galaxy power marketing at Synopsys, said various tools exist today that can deal with many aspects of the complete low-power flow. The problem is that systems engineers don’t tend to think about tools in this way. “Just within the implementation flow, there’s verification and implementation, and we find that those engineers don’t exactly talk and work together as easily, so can you imagine what the challenge would be if it went all the way from system-level to somebody that has to deal with manufacturing and then packaging? Even though we tend to provide solutions in those spaces, we find that customers are still very specialized in their very specific areas.”

What engineers want
Krishna Balachandran, director of low-power verification marketing at Synopsys, said to understand what engineering teams really need it helps to segment customers into different buckets. “There are customers that are very advanced in their needs and there are some other customers who have some low-power needs but they kind of know what they are doing—they’ve been doing low-power for longer than the power formats have existed so they’ve evolved with what has happened in terms of power formats and they’ve started using that. Then there are some new customers that are being forced to think about power not because their devices are by themselves low-power, but by virtue of the fact that they are using smaller geometries to reduce the cost and to take advantage of the wafer pricing which can drop. Those customers think that if they drop down to the lower geometries they’ll have to use some power techniques now in their design, because if they don’t then the leakage power becomes unacceptable. So for these reasons some of these customers are coming into the flow and their requirements are very modest. They are almost able to address in an ad hoc way what they have to deal with, rather than by design aiming for lower power chips. There is a whole range of sophistication when it comes to low-power designs and flows. I see that their needs are very different.”

Barry Pangrle, solutions architect for low-power design at Mentor Graphics, said in the future there will be more emphasis on front-end tools. “That will include architectural-level, system-level type stuff, especially hardware/software tools that will allow designers and even software developers to be able to get a better understanding of how the code they are writing impacts the overall power of the products they are developing. You can have really great hardware and if the software doesn’t take advantage of all the capabilities of the hardware, you throw all that effort away.”

Power formats, mixed-signal designs
In the middle part of the flow, one positive step forward last year was that all major EDA vendors came together to pledge their support on the IEEE 1801 power format standard, which should help with tying everything together. More than just the power format support, the underlying methodology is also critical. Qi Wang, technical marketing group director of solutions marketing Cadence, said a converged methodology is still needed—a single power-intent description that can be used in every stage of the design flow to provide consistency.

Overall, he said, it looks as if we have all the pieces of the power-aware design flow, but there’s still a long way to go to address the multi-vendor flow. “Right now we have two formats. Even if we have one format there will still be challenges, but that will play out over the years because at least the whole market on the customer side will be adopting the same power format approach. Right now some of them use CPF, some of them use UPF. The methodology shift is happening. That train has left the station; that will not be changed. It just takes time for the vendors to work out this multi-vendor flow.”

However, he pointed out, there still are technical areas that need more investment. “One big important thing is in the area of mixed-signal design. If you look at all the hard products right now, it’s all about mixed-signal and low power: you have a mobile application, you want to access everywhere, you have wireless, you have Wi-Fi here and there. It’s all about a mobile and battery powered. This means low power and mixed signal. Customers have combined these together. The technologies need to be combined, as well.”

Another key area is verification. Erich Marschner, product marketing manager for functional verification at Mentor Graphics said, “The verification aspects of low power are largely related to methodology because of the capabilities in the tools have been developed over the last four or five years to model the effects of low power, power management and active power management. Users are still behind the curve in terms of trying to understand what to do with those capabilities. Most of the low power simulations that are done today are still done in the context of UPF 1.0 – the previous version of the standard.”

In this regard, many users still have a way to go to take full advantage of the technology available today.

By Pallab Chatterjee
SoC design has a number of techniques for power management. One of the more prevalent methods is to use power gating to turn on and off blocks based on applications being run, and mode controls. Power gating while being supported by the two major EDA power design flows, UPF and CPF, still has some implementation challenges.

The flows have to make sure that the states of the logic at the interface to the blocks being turned off do not get corrupted due to changes on the shared ground/supplies. Basic power gating is well known. However, its use in both multiple power supply systems and multi-logic threshold systems still has some challenges. Power gating requires the outputs of the switched gates to be isolated from the control signals on the inputs, and also that the output get clamped at some state—low, high or “last value.”

The power gating function results in a reduction in the logic level swing due to the IR drop of the “on” device between the logic cell and the power supply/ground. Gate bias and level-shifting to a second set of power rails to drive the gate buffer control logic allows for the power gating devices to have a reduced IR drop to the virtual supply (VVDD). Timing construction for this type of function, however, is transparent to the UPF/CPF design flows.

A workaround for the logic that has to interface with power-controlled blocks is to use state retention registers. This solution has quite a bit of area/performance penalty as it requires a formal and powered-on register bank for each I/O-facing logic block in the sub-block. The gate count is expensive for full state coverage, and partial state coverage has validation issues. There is an additional cost of power and latency. The latency is due to the loading and unloading of the software state for save/restore.

To address these issues, designers can use an enhanced DFF with connection to the always-on retention register power supply. This cell would have to support save, hold, restore and normal operation functions. UPF and CPF do not always work directly with these non-RTL states and impact the validation flow. A further challenge is the functional planning and implementation of set and reset signals through the retention registers and the impact of those signals on the data being held for the “off” blocks.

ARM, in the Cortex M class products, has implemented low-cost state retention using sub-period clocks and secondary power supplies for the retention devices. These sub-period clocks allows Set and Reset functions to occur on an asynchronous basis with the system clock. The logic blocks are generally built using clocks from a DVFS control system.

The challenge for using these blocks is to not only integrate them into the timing flow of the circuits, but to make sure that the retention registers can safely provide data, at the correct logic level, with the blocks that are on. As application programs gain control of the power gating function, simple state machine-based control for these registers is not sufficient. Programming optimization of the high-level language function now have more interaction with the data flow per block. This results in environments such as OpenCl, which sends tasks to both distributed CPUs and GPUs through common and segmented memory controls, having a great deal of impact on when blocks are on or off. Normally, a compute task that has no output view is contained just in the CPU signal path, and the GPU can be powered down. Under OpenCL, it is possible to have this task sent to both the CPU and the many threads of the GPU and then combine the results in central memory. This has an impact on the power control, because to achieve the performance enhancement of the extra computation capability you cannot tolerate the latency of a turn-on, reset or restore, and then store and turn-off cycle of the GPU. This latency is typically longer than the compute cycle.

The design verification is still hampered by the fact that none of the logic verification environments can model these turn-on and turn-off state transitions as the power supplies change under application software control. The simulations are based on timing for the power supply control switch transitions, and estimates based on RC load for the blocks to be either available or not.

By Ed Sperling
Multiple power formats and increasingly complex SoCs don’t sound like a winning formula. So just how bad have things become? Low-Power Engineering asked Sorin Dobre, senior staff engineer at Qualcomm, for a real-world assessment of the situation.

LPE: There are three power formats—CPF, UPF and IEEE 1801. How big a problem is this for Qualcomm?
Dobre: Actually we have CPF 1.1 and 2.0 and UPF 1.0 and UPF 2.0, which is also called IEEE 1801. In the CPF area there is a unified approach. There is backward compatibility and consistent methodology for power intent and verification. In the UPF area there are many inconsistencies between UPF 1.0 and IEEE 1801. Instead of parallel formats there is a level of confusion about what can be used in a consistent fashion.

LPE: Which standard should everyone be using?
Dobre: On the UPF side, IEEE 1801 is the standard that can be used by the EDA community to develop all their tools, and it can be used consistently by designers. Keeping both UPF 1.0 and IEEE 1801 is creating problems. There should be a consistent power intent and a road map for tool development. That’s well defined in the CPF camp, and there is a path toward convergence to have one format in 2012.

LPE: What holds you back from just choosing one or the other?
Dobre: Today we can use IEEE 1801, but not all the EDA tools vendors support that standard. Even if you have a very good standard, you are limited by the set of tools.

LPE: And you have every vendor’s tools?
Dobre: Yes.

LPE: So as a result you have to support both?
Dobre: That’s correct.

LPE: How do you get around this problem?
Dobre: There is no easy way. It adds a lot of complexity. We have to define the power intent files and maintain the power intent files. Having a consistent, fully automated power intent flow for verification is difficult. You need translation from CPF to UPF and back to CPF. And it is not a straightforward translation process.

LPE: What do you want to keep from CPF?
Dobre: We believe we can take the hierarchical methodology, which is very well defined in CPF, and have that ported to the next version of UPF. We also need the automated macro-modeling generation, and it all has to be put into an agnostic format. If we have all of that we can have a very strong and powerful single standard.

LPE: Is there any movement in that direction?
Dobre: There is a big effort by Si2.

LPE: If you’re designing a chip now, what do you have to do now?
Dobre: Today, we define power intent at the system level for the product. We define the power domains and power modes. It’s a high-level description. From this high-level description you create UPF and CPF files and provide a reference to the block-level owners. They have to generate CPF and UPF files. Then there’s an integration process where the lower-level files are integrated with the higher-level power format files. You create a complete power intent file for the whole SoC, which can be used for functional verification and design implementation.

LPE: Do you need separate models for UPF and CPF?
Dobre: With power intent files you are dealing with multiple voltages. There are two ways to describe the models. One is multi-models. The other is libraries. If I have 10 voltages, I can use 10 libraries. It’s a much bigger port to have 10 libraries. It’s much more power efficient to have one model rather than a family of libraries.

LPE: If you have an engineering change order, do you have to adjust both formats as you go forward?
Dobre: That’s a very important aspect of power intent work. You need to define an integration methodology. You need custom integration capability for every change. What is required is to have an integration methodology. All changes at the system level or block level must be integrated with the top-level power intent file. As long as you don’t impact the macro model it won’t impact the top-level power intent file.

LPE: Does having more than one power format increase the risk of something going wrong?
Dobre: Yes. I get more power intent information in CPF than in UPF. Without it you are missing some power intent information. But there also is a lack of consistency. You need to pay attention if you do a check in UPF, you need to make sure you do all the checks with CPF so you have complete information.

LPE: What are the real-world ramifications of this?
Dobre: The biggest impact is in the overall design flow. You don’t have all the verification capabilities.

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 Cheryl Ajluni
Over the years, new techniques, technologies and design tools have been brought to market with the explicit intent of simplifying design verification. Despite these efforts verification still manages to consume a huge chunk of the time spent during design. By some accounts that number tops 70%.

The problem is that verification is hard, and it certainly doesn’t get an easier when we move into the low-power design realm. Low-power design techniques have become increasingly complex and, in the process, have led to an explosion in verification complexity. As a result, low-power verification is now the key challenge in low-power design. As Ying-Chih Yang, technical director of Home Entertainment Products at Sunplus Technology points out, “Because power consumption is one of the most critical factors of today’s SoCs for mobile applications, the ability to accurately verify low-power functionality is essential to achieving first-pass silicon success.”

The low-power design challenge is complicated by the fact that there are many problem areas that need to be addressed. Consider the use of Intellectual Property (IP), for example. In the past, designers could throw IP together and be comfortably assured that things would work okay. Now, because of the heavy concentration on low power, if a design with IP is not properly verified, the designer runs the risk of throwing off their power budget or worse yet, ending up with non-functional silicon. The key here is proper verification. But with no well-defined or widely accepted low-power design and verification flow, it’s hard to agree on exactly what issues that verification flow needs to address.

Ashwin Matta, director of IP Verification at Denali Software, says one of the challenges associated with the verification of IP in low-power designs is that it “needs to support special features for power optimization. Addressing this problem requires an investment in a state-of-the-art verification methodology and tools that verify the correctness of low-power IP behavior.” To prove this statement, he points to the example of a memory subsystem, which is a major source of power consumed on a low-power chip. The subsystem consists of a memory controller talking to external low-power DRAM memory that supports a variety of low-power modes (e.g., power down and self-refresh). A combination of hardware and software interfaces is used to exercise these low-power modes.

“Software control of low power requires that the driver software detect the need to save power, possibly due to low density of memory traffic, and then program the controller to enter the appropriate power-saving mode,” says Matta. “Software can exercise fine-grained control of power entry and exit, providing considerable power savings without an appreciable loss of performance associated with exiting a low-power mode. Hardware interfaces are necessary for more catastrophic events such as a sudden loss of power to the chip. Under such conditions, software control isn’t possible and the controller is required to put the memory into self-refresh mode to prevent data loss or memory corruption.”

From a verification perspective, being able to test the controller for function and performance under all possible conditions of hardware- and software-controlled low-power operation is absolutely vital. Adds Yervant Zorian, Virage Logic’s chief scientist: “Because today’s SoCs include an ever-increasing amount of embedded memories, the need for an integrated embedded memory test and repair solution that can identify and repair faults is critical as companies seek to ramp to volume at the advanced process nodes.”

But this is not the only verification concern when it comes to IP. Ensuring IP functions according to a design’s power intent, for example, requires that it be verified throughout the design implementation flow using the same constraints format. A heterogeneous tool environment and flow is also required (See figure 1). As Kiran Vittal, director of product marketing for low power & test products at Atrenta explains, “Here power intent can be captured in standard formats like CPF or UPF for implementation and verified at RTL, gates or post layout with structural verification or simulation tools.”

Figure 1. SpyGlass-Power is a structural verification solution that supports power intent constraints through SGDC format (SpyGlass Design Constraints, in use since 2004), CPF and UPF. For effective verification in low-power designs, IP needs to be verified in heterogeneous tool environments and power intent formats as shown here.

Another area of concern is interface IP like PCIe and USB 3.0, which include power management features and low-power states that must be verified like any other protocol feature. Or so says Neill Mullinger, group marketing manager at Synopsys, whose responsibility includes verification IP and methodology support. “This requires additions to the testbench to verify the correct transitions through the low-power states,” says Mullinger. “Verification IP must support the low-power features needed to test the interface IP’s low-power capabilities and verify the design is transitioning to low power as documented in the protocol specifications.”

Of course, ensuring all of these concerns are adequately addressed would be a lot easier if the industry agreed on a low-power design and verification methodology and flow. As Erich Marschner, manager of low-power and static/formal verification solutions at Mentor Graphics explains, “Today, most design teams define their own ad hoc flows that incorporate legacy methods, depend on proprietary languages and tool features, and often result in incomplete verification of the low power aspects of the design. They continue to look for new verification methods to address holes in their flow, but incremental patches are not going to be sufficient in the long run.”

One possible answer to this dilemma lies with the IEEE 1801-2009 (UPF 2.0) standard for design and verification of low-power ICs. According to Gary Delp, chair of the IEEE P1801 standard, “UPF provides conservative simulation semantics. So, when the UPF is written to describe a design, the simulator makes sure that sources of potential corruption, structural errors or inconsistencies are pointed out. When the same description (along with the rest of the design) is used to implement the design, the implementation requirements are also conservative. Thus, the simulation semantics provide a bounding box for the implementation whereby it must safely operate under all of the specified conditions, and provide logical accuracy whenever the simulation does.”

Such a low-power design and verification methodology and flow is crucial to enabling low-power verification tasks to be accomplished much more easily and effectively, but even without it low-power verification tasks are getting done. One such task is voltage-aware simulation. According to Krishna Balachandran, director of low power verification marketing at Synopsys, “Non-low-power designs are verified for functionality without any regard to operating voltages. Low-power design techniques, on the other hand, use voltage to control power and as a result verification done without considering voltages can’t find the low-power bugs that may be lurking in a design.” Voltage-aware simulation plays a key role in allowing engineers to consider voltages during verification.

Some of the other verification tasks being addressed include:

• Modeling different use modes (e.g., the MP3 or active call mode in a cell phone) to meet a specific power budget. In addition to their modes of operation, low-power designs have many power modes. These modes can affect the circuit’s function and must be properly verified, but doing so implies that all intended combinations of power and operating modes must be verified, If not, various problems can arise (e.g., data loss, dead lock conditions or unpredictable behavior).

An early power analysis of an application’s different use modes during architecture planning and chip assembly is one way to attack this problem Another way, according to Neil Hand, director of low power solutions marketing at Cadence, is through power-aware metrics-driven verification. With this approach, “the power intent of the design is captured, usually in a format such as CPF. This power intent is then used during verification to ensure that the design behaves as it would with all of the power-control logic in the RTL. It is also used to infer all of the power modes that need to be covered in the design, creating the appropriate coverage metrics and assertions automatically. Verification then continues as normal, only now it is fully power-aware.”

• Verifying power-management elements. Low-power designs often introduce power-management elements that are not part of the original design specification. Verifying the functionality of these elements, along with their correct insertion and connection, can be quite challenging. Here, static low-power verification tools can be used to check and report errors in the implementation of the elements in comparison to the design’s power intent throughout the design flow. Static equivalence checkers can also prove useful—ensuring that following insertion and connection of any elements, the design is functionally equivalent and performs the power-management function as specified.

Even if the industry can get closer to a low-power design and verification flow, it doesn’t address the problem of education. After all, one of the reasons that verifying low-power designs is such a difficult task for today’s verification engineers is that most are not yet well trained on low-power concepts. There may be some truth to this, but a range of tools are now available that can help guide the engineer through the steps necessary to address many of the challenges in low-power verification. Some of the vendors currently offering solutions include:

➢ Atrenta: ITeam Genesis and Spyglass platforms for power analysis, optimization and verification.
➢ Cadence Design Systems: Incisive Enterprise Verification, Conformal Low Power, Palladium PDA, and Encounter Power System.
➢ Denali Software: Configurable and fully verified low-power memory controller IP.
➢ Mentor Graphics: Questa verification platform.
➢ Synopsys: MVCIM with VCS, MVRC and Formality.
➢ Virage Logic: STAR Memory System, advanced semiconductor IP solutions.

There is little doubt that low-power designs have had a profound impact on verification. Addressing the challenges this creates is no easy task, but creation of a low-power design and verification methodology that the industry can rally behind and that tool vendors can support is a good starting place. It will be crucial to dealing with verification of IP, among other tasks, during low-power design.

The constant scaling of transistors has made power one of the critical design constraints. Convergence of various technologies in portable battery operated devices has put pressure on designers to reduce leakage and maximize battery life. As a result, they utilize various power management techniques to reduce power consumption in their designs. Thus, designs consist of multiple operating voltages, power islands, multi-threshold devices, and different sleep modes (voltages).

A common problem that exists with power-related verification of multi-voltage designs involves the accurate placing of level shifters and isolation cells. Normally, these are done manually or by using scripts, and they are inserted during or after synthesis. These techniques are error prone and cause unique verification problems that are difficult to rectify and typically require costly respins. The new Unified Power Format (UPF) low power specification standard allows designers to explicitly specify the insertion of isolation cells and level shifters at the RTL. The requirement for level shifting is static. It is based on the specification of voltage domains (voltage(s) at which a power domain may operate within specific system power states). Deferring validation of an electrically correct supply network to simulation needlessly burdens the simulator with checks that can be performed statically. It also raises the risk that the simulation tests will fail to expose potential problems. Therefore, a static, lint-type check for level shifters and isolation is needed.

In this paper, we demonstrate a technique that leads designers to places in the design that are prone to bugs related to multivoltage paths. The power intent is specified by the user in UPF and includes specification of the power domains, system power states, switches, and other power management features. This information will be used by the tool to perform static lint checking related to power/voltage domain crossings that are normally very difficult to figure out from simulation data. We also present formal verification techniques that can be automated by the tool to reduce the burden on the designer. These techniques involve generating assertions, which test the power control sequencing, check for invalid sleep mode transitions, and catch the race condition between the retention controls (e.g., save and restore) and design controls (e.g., clock, set, reset).