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
"¢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
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
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
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
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.