Optimizing power begins with architecture

Every mobile device design team focuses on reducing power consumption, yet few designers realize those same practices can increase efficiencies 50 percent or more in stationary applications.By: Mark Andrews

Even if not having to grapple with a finite mobile device power supply, design teams often overlook potential market advantages by not making low power consumption a priority at the initial architecture stages of a new project. Those who do can increase efficiency 50 percent and speed time-to-market, according to the design automation experts at Cadence.

Dealing with power consumption as a key consideration at the architecture stage saves time and eases the burden on engineering teams that will inherit and grapple with a design, whether it was optimized at the architecture stage, or not. Too often, assumptions are made about what is possible when it fact the team is proceeding on outdated concepts, according to Cadence Sr. Principal Project Manager, David Pursley.

Cadence (UK and global), specializes in design automation tools that seek to remove assumptions and preconditions from a design equation that have no business being there. Cadence has found that when customers have a problem with power management systems they often discover a common set of issues at work that are impeding design team progress.

First is the assumption that methodologies which have been around for years and are considered to be "givens" among marketplace leaders are accurate. Many designers believe that "˜XYZ' company got to be number one by getting the details right when in fact there can be myriad reasons why one company's products are successful and others are not. Even top-selling products can have flaws; unnecessarily high power consumption is often near the top of any list. But what happens when designers' assumptions are incorrect? Delays. Miscues. Missed opportunities.

Common misconceptions in low-power design frequently include:

"¢While a designer's intuition about a system's potential performance is often 80 percent correct, "˜intuition' about power utilization is often substantially incorrect. Cadence has found this can be off by as much as 50 percent.

"¢Designers working on architecture often believe that next-stage work at the register-transfer level (RTL) will correct architecture deficiencies and that the remainder will be "˜fixed' during the march towards implementation. In reality, approximately 80 percent of power optimization needs to be accounted for at the architecture stage.

"¢Power utilization only counts in mobile applications. Wrong. The potential for creating greater efficiency is heavily dependent on use-case, and while this is especially true for mobile applications, it is nevertheless important in wired applications, especially in cases where the consuming public will choose between an energy efficient design with a standards body's certification and "˜Brand X' that carries nothing to reassure potential purchasers that the product sips instead of guzzles energy.

"¢Peak-power is not necessarily thought of as a key consideration, but it is especially so in terms of long-term reliability. Average consumption figures alone are insufficient measures and cannot be used solely to predict performance as a stand-alone approach.

These common misconceptions have led Cadence to conclude that low-power optimization is an objective that must be addressed at every point within the design flow "“ from architecture all the way to GDS, with architecture being the most important (and relatively easiest) stage at which to gets things right since up to 80 percent of a device's power consumption profile will be determined at this stage.

Why do some of the world's best companies have design teams that work under assumptions about power utilization and consumption that today's best research has proven to be flawed? Differences abound, but one of the classics finds designers reassuring themselves that a certain approach is safe to pursue because, "˜we have always done it that way,' or the even more popular, "˜this isn't a mobile app, so why should we care about power?' Cadence has also found a rather surprising trend in some established design outfits: they rely on an industry standby to save themselves from themselves: the "˜Hail Mary' approach"”asking a "˜higher power' for design assistance once a new project leaves the hands of one team and heads to another is not strategy, it is desperation.

Cadence has found time and again that unless a design team is only attempting a small tweak to an existing, well-characterized design that will be used by the same customer in the same applications as it was originally, one might be able to get away with a corner-cutting approach to optimizing power utilization. Otherwise the designer needs to start from a solid architectural basis.

For low-power stationary applications the team does not have to get anywhere near as millivolt-conscious as those working on mobile design projects, but HPC/cloud applications, cost-sensitive applications without active cooling and high-reliability systems now also have tight and unforgiving power budgets. And then there is the IoT. To realize the potential of hyper-connected sensors and actuators across a cityscape in an internet of things (IoT) scenario, power consumption, self-powered systems and energy harvesting schemes are evidence of just how serious non-mobile applications have become about power utilization, energy storage and internetworking.

For IP power characterization, start with RTL or gate-level models. For a new IP, the designer might consider starting with high-level design (e.g. SystemC). Developing at high-level allows for quick turn-around architecture exploration that will enable the team to optimize for power. Many functions are being developed this way today including image processing systems, logic processors and controllers. If this isn't an option, stick with RTL models since power estimation will be accurate; this approach should get the design within about 15 percent of the specified power consumption budget. For some, the idea of 15 percent (plus or minus) is way too great an error margin. But it should be noted that +/- 15 percent is significantly better than the 50 percent right/wrong that usually results when designers simply follow their intuition.

Next, consider what the RTL team can be expected to achieve, and it won't be cutting power consumption by 50 percent. The RTL group can realistically be expected to improve on an architecture team's work by anywhere from 15 percent to as much as 30 percent. But remember that the better power is optimized at the architecture stage, the less RTL designers have to worry about, which automatically "˜improves' the architecture work in their minds before they even begin.

Squeeze everything that can be had out of power before the design is handed over to implementation. Make certain that the design is within ~5-10 percent of budget before there is any handoff. Implementation can fine tune a design but they cannot save anyone's reputation if the power utilization is substantially off target. What they need to focus on"”and what they expect to work towards"”is squeezing out the last few percentage points needed to give sales and marketing a solid product that can win against the competition.

If architecture has done its job then implementation can focus on the last few percent of power gains, signal integrity, and making sure that thermal parameters are respected without any budget-busting; that the project will not be suddenly burdened with an active cooling system not in the original specs, or that thermal issues are suddenly pushing the red line. Thermal issues, especially peak thermal spikes, can affect EM as well as timing and could result in a thermal runaway. Even the largest, most experienced companies can get this wrong, and with disastrous results"”ask Samsung about their experiences with thermal runaway in Lithium-ion batteries caused by a power management system that didn't get all the details quite right at one or another design stage.

Conclusion

Power optimization is not a back-end feature or tool. It's a whole tool set and the responsibility of every engineering team all the way from architecture to implementation; the bulk of that responsibility begins at the architecture stage. The right way to handle this is through an integrated flow of the type enabled by tools provided by Cadence and similar companies that build their reputations on speeding design flow while adding accuracy and optimization. Why is integration important? Because a lot of getting the power budget under control and within spec has to do with consistency in handling constraints and estimation throughout every stage of the design flow, which is pretty hard to manage if a designer mixes her or his intuition with a mish-mash of tools.