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
With design complexity always on the rise and an increasing amount of embedded software encapsulation in designs today, engineering teams need to be concerned with power consumption in the initial architectural design. The only way to do that is to model power consumption at the transaction level.

While power is typically estimated after RTL synthesis, the better approach is to model it and then add it into a library to help the design team quickly determine the best balance between performance and power consumption. In this way, the lack of structured high-level modeling capabilities hinders power analyses during early design phases. Power modeling also enables
development of the power-related software drivers, as well as efforts to optimize the architecture and power domains.

Technically, power models allow the user to see how their power might vary based on whether they are running, for example, an MPEG decoder or just reading email on their iPhone or taking photographs, said Sequence Design CTO Jerry Frenkil.

“They can see what the power consumption of different applications would be, and once they see that they can make some decisions about what they want to do,” Frenkil said. “Knowledge is power. This gives them the knowledge of what to go tackle. This is an area where there hasn’t been a lot of practical work done yet because it is so difficult to do. These models are really an [enabling technology]. They enable design teams to get an understanding of their power characteristics even earlier in the design flow. It enables them to see power characteristics under different application loads. It enables them to see the results of different design decisions before they begin RTL coding.”

Similarly, Frank Schirrmeister, director of product marketing for system-level solutions at Synopsys, views power modeling at the system level as a technology that allows the designer to instrument transaction-level models with power information depending on their different states. He pointed to specific power information that users have modeled in Synopsys’ virtual platforms as representative power parameters (‘kernels’), which are then used in power equations to calculate power. “We are flexible to support specific component characteristics like different states and such, which are then interactively changeable by users,” he said.

Power consumption numbers typically are delivered by semiconductor companies based on budget planning, estimations and measurements, Schirrmeister noted.

Power modeling mostly ad-hoc…until now
In terms of power modeling usage today, Schirrmeister said that interest and use of power modeling is increasing, but just like transaction-level modeling there is a tendency to use it mostly in bigger projects with derivatives, i.e. bigger product families.

Meanwhile, Frenkil said in terms of how power modeling is done today, “The simplest way to say it is that it is all ad-hoc. I would venture to say that if you talk to half a dozen different groups that have done high-level power modeling, you’d find half a dozen different approaches. Partly it’s because it’s an immature technological area where it’s really a vanguard item right now, and partly it’s because it’s not well understood. For example, one can create a power model for any circuit or any piece of IP rather simply but whether that power model is any good or not is another question altogether because there are multiple perspectives on goodness. One aspect of goodness is whether it is accurate. If it is accurate, to what degree and under what conditions? Those conditions can be operating conditions or they can be operating modes. One of the problems with models that people do use today is that they work pretty well for exactly what they created them to do but if someone comes in and uses the model in an ever-so-slightly different way, the numbers are way off. And that’s because the model wasn’t created for that.”

Contrast that with what the industry does with standard cells and Liberty models, which are considered rock solid. “Any way you use them, they are going to give you good results and that’s a big reason why they are so widely used,” he said. “Designers know they can depend on them. In our case, looking at these high level models, we know that if we create a model for a particular usage and if everyone knows it works well for that, but it is questionable how it works for other things, it’s not going to get reused. And then if it is not going to get reused, then from a management perspective it’s very hard to put much effort into creating the model in the first place. So we see that one of the requirements for these high level models is that they have to be sufficiently robust so as to be used in a variety of ways and produce acceptable results in each of those ways.”

He added there is no standard way of creating power models or even a list of best practices.

Synopsys has a different opinion. “Naturally, we at Synopsys in the system-level team focus on instrumentation of SystemC transaction-level virtual platforms in Innovator,” said Schirrmeister. “The support is part of the Innovator infrastructure, which allows engineers to define, set and manage power parameters as part of the models integrated in an Innovator block diagram. We gather data from lower level tools like Power Compiler, providing more accurate data once the implementation has progressed beyond the system-level. We see more and more support to derive power related information from hardware based prototypes and high-level synthesis.”

Innovator, then, is an infrastructure in which the designer can instrument models. “We have the transaction-level SystemC models there already and you basically annotate just like you would annotate timing and performance information. You are just annotating power information,” he explained.

Another tool in the market is ChipVision’s PowerOpt, which takes a high-level model, which is essentially a C model, performs high level synthesis on it and produces a power estimate, i.e., what the implementation will cost from a power budget perspective given a certain target technology the design is being implementing into.

Then, one level down, in the RTL domain, Sequence tools perform RTL power analysis and optimization.

Notably, and possibly changing the landscape in this area is Mentor Graphics’ Vista platform, announced at this year’s Design Automation Conference. Vista promises to perform comprehensive architecture design and prototyping, and allow users to model, analyze and optimize power at the transaction level of abstraction.

The Vista platform allows engineers to model power at the transaction architecture level using advanced power estimation policies long before an implementation becomes available, or annotate more accurate power behavior based on attributes of the technology process of the target implementation IP blocks.

Also, Mentor said its Vista platform is a “layered” behavioral, timing and power modeling design methodology coupled with the SystemC Transaction-Level Modeling Standard (TLM-2.0) supported by the Open SystemC Initiative (OSCI) and offers an advanced design platform that allows chip designers and system architects to make viable decisions on hardware/software partitioning and architecture structures.

With its advanced debug and analysis toolset, Mentor said users can verify system-wide functionality, analyze and optimize systems under realistic traffic loads, and adjust system resources for optimal performance and power. Users also can explore various voltage scaling and shutdown techniques and apply the most efficient power management strategies.

As a result, designers can ensure a cost-effective architecture with a suitable bandwidth that can carry the target application. Given the abstraction and fast simulation of the hardware representation, a model of the system can then be used as a virtual platform for early software development, analysis and validation, including the ability to profile power while executing application software, the company said.

Looking ahead, Guy Moshe, general manager of ESL/HDL design creation at Mentor, believes in the near future that IP providers will provide IP models with power models. “Today, it is very rare to find any power models in the market. The only things the IP providers deliver with [their IP] are some manual spreadsheets that describe, ‘If you are using this mode and this mode in your memory controller, this will be the power consumption.’ Everything is static. In the future, you will be capable to do everything dynamically.”

Moshe estimates the industry is about a year from this seeing this as reality. “We are not far away from that however, I think the current economic climate actually accelerates this path because first, they don’t have any more time to release intermediate products just to be fast. They need to be accurate; they don’t have the bandwidth to do many turnovers. They have to be first to market and successful.”

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.