Picture this common design dilemma: Marketing has decided that the company’s latest portable device must be 35 percent smaller and have 50 percent more runtime. What is a systems engineer to do? If the system has 50 percent more runtime, then it seems the battery must have more capacity or the device’s power consumption must be lower. If the battery has larger capacity, then it will have larger volume. Meanwhile, the mechanical engineer is starting the model and needs a battery identified.

To solve this problem, the situation can be divided into areas of responsibility. First, the technical lead needs a tool to track power consumption in the design. Next, product leadership needs to define use cases for the design. Finally, the engineering team needs a tool to measure power and quantify the result of changes.

Tracking with a power budget

One fundamental tool for a battery-powered design is the power budget. The power budget contains entries for each element of the design with their power and currents. It is used to track overall power, document test scenarios, and experiment with use cases.

A power scenario represents an overall device state, whether it is sleep, deep sleep, idle, active, or processing data. Use cases are at a higher level. For example, in an eight-hour day, the device will start with a charge of 90 percent. Every hour, the device will be in idle mode for 45 minutes, active for 10 minutes, and processing data for 5 minutes. During the 10 minutes when the device is active, 5 minutes will be full speed with the display active and 5 minutes will be with the display backlight dimmed and processor speed reduced. When the idle timer expires, the device will return to deep sleep.

The power budget is typically maintained as a spreadsheet with a row for each component in the design, as shown in Table 1. For each row, the spreadsheet contains nominal (active) current, nominal voltage, sleep current (if applicable), and a way to represent on-time percentage in the various states. Because there can be a range of current consumption for both nominal and sleep, it is wise to enter either a range or median plus standard deviation of current. This allows nominal, worst, and Monte Carlo test cases to be set up. Note that worst-case currents on the data sheet are worst-case. In many cases, the typical current is more appropriate; however, measurements and consultation with the semiconductor vendor are essential to confirm.

 

 

For the processor, it can be useful to add entries for processor speed and time/power to accomplish typical tasks. Example tasks include processing data, transferring files, responding to user input, and displaying data. Pay attention to power during the task and when the task is completed. Some processors like Texas Instruments’ OMAP family have dynamic frequency control, which drops processor speed to the minimum after a task is complete.

Product management will generate use cases based on customer interviews and visits. Technical leadership should review the test cases and test the built-in assumptions. Check to see if the use cases are worst-case or typical. Based on this analysis, technical leadership can examine the trade-offs of size and cost, then discuss this with product leadership.

A handful of use cases will be like this. Each will have a different combination of activity durations. When these are combined with the numbers from the power budget for active, idle, sleep, and deep sleep, overall battery capacity can be determined.

Evaluating computing efficiency and power consumption trade-offs

The largest source of power consumption in a battery-powered design will be clear in the power budget. Typically, this will be the CPU, display, and power supply losses. Several strategies can help reduce power consumption in peripherals: disabling or reducing their supply voltage when not active, using the minimum possible voltage, and designing for power supply efficiency.

Low-dropout regulators are a beneficial element in the design toolbox; however, they do turn battery capacity into heat. A low-dropout regulator with 3.3 V input and 1.8 V output will consume 1.5 mAh for every milli-amp it supplies. With a 10 mA load, this is 15 mAh. In contrast, a small switcher could easily have an 85 percent efficiency rating and would consume less than 3 mAh in the same situation. Thus, it is important to be creative in the power supply architecture. Examine the currents for the processor as a function of frequency and pick the best power versus performance operating point. Split up the power supply domains and give software control of peripheral power. Looking deeply into the power architecture can render 20 percent reduction in total power.

Peripherals often can be grouped together and powered up and down as a group. It is wise to test this on a development kit or breadboard, as powered-down devices can affect other component and signals. Powered-down devices might also need to be reinitialized by software when powered up again. Grouping peripherals comes from the use cases; if idle, turn off the LCD and backlight. When active, enable all peripheral interfaces.

The design team should also check for phantom power losses: processor pins initialized to the wrong state or pull-ups that consume too much current. This analysis can save a significant amount of the battery capacity.

Managing power as a performance metric

It is common to think the CPU needs to run at the slowest possible rate in a battery-powered application. This assumption should be checked carefully, as it could take less overall power to run at a higher speed for a shorter period of time.

This situation can be analyzed using current measurement resistors on the processor’s main rails. Logic PD’s Wattson software (Figure 1) allows current to be measured easily over time. Using this application on a DMX3730 processor, power was measured at 600 MHz and 250 MHz running a checksum on a large file. Total power dropped by 50 percent at the higher speed. Comparing the total power shows that the higher speed reduces overall power by 50 percent.

 

 

Another factor to consider is file location. If the files are on storage media like an SD card, processing time can be dominated by access speed, which can increase overall power. If files can be transferred to main memory or placed on faster media, then processing speed will dominate.

Battery capacity must be maintained over the product’s useful life. Battery life is affected by charging, temperature, and depth of discharge. The end result is that even with a lithium ion battery, there should be 20 to 30 percent excess capacity if the product lifetime extends over many months. An alternate approach is to provide for battery replacement.

Start designs with a reality check

To make the end product work, power must be managed from the start. Before the schematic is started, build a block diagram and pick some typical parts. Create the power budget and do a reality check. With that particular LCD, how much capacity will be needed? Can those peripherals be put to sleep or have their power cut off? Measure one peripheral at a time on the development kit or breadboard and update the power budget weekly.

Review the block diagram and power budget with the design stakeholders: marketing, software, and hardware. As the design progresses, update the power budget with revised components, measured values, and use cases. Track the results at weekly meetings and pay attention to areas that need work. In some designs, the overall power budget can be allocated to subsystems.

Battery size is physical as well as electrical. The good news is that battery chemistry sets an energy density, allowing calculation of overall physical size early in the program. Batteries also get warm when discharging and charging. This affects another critical factor in many designs: the thermal management process. In most designs, the case must allow for battery expansion and contraction, as well as venting. Careful attention to the design, continuous tracking of the power consumption, and selecting the right speed for the job can help meet all of the product constraints.

Curt McNamara, a principal engineer at Logic PD, is a practicing designer with more than 20 years of experience in the commercial, medical, and industrial markets. An active IEEE member, Curt received the IEEE Millennium Medal in 2000 for his ongoing work in education. Curt teaches innovation and systems thinking and is an Education Fellow of the Biomimicry Institute. He holds a Bachelor’s degree from the University of Minnesota and a Master’s degree in Engineering from Portland State University.

Logic PD 855-461-3802 [email protected] Linkedin: www.linkedin.com/company/logic-pd Facebook: www.facebook.com/pages/Logic-PD/38901519572 Twitter: @Logic_PD www.logicpd.com