The Energy Zarr Blog

The Whole Can Be Less than the Sum – Adaptively Reducing Power

The title of this week’s blog sounds incorrect.  Isn’t it called synergy when the action of combining pieces together results in something greater than all the parts?  This is usually true, but today I’m going to discuss increasing energy efficiency through active means - that is, we’ll discuss what happens when you combine parts together in a design and the resulting power consumption of the system is actually lower (a great deal lower) than that of all the individual components.  How can this be?  It’s actually quite simple, so let’s take a look.

Here’s the concept - put together a bunch of components that monitor some power-consuming process and continuously "adapt" to the current required conditions to lower the energy consumed.  An example could be the back-light power supply for a personal media player.  While watching a video the player’s power supply is fed ambient light information from a photodiode.  As the ambient light changes, the drive current to the white LED backlight is adjusted.  It rarely needs to be at full power (direct sun light), so it adapts to the current surroundings.  In this way, the battery life is increased and the total energy consumed is reduced.

Now you may argue, "yes, but in direct sunlight the overall power consumption is actually larger due to the additional circuitry required to monitor the ambient light".  I will concede that argument is true.  However, let’s use some statistics (I love math!) to prove my point.  My theory is that if you were to create a usage pattern of the ambient lighting conditions of a large number of personal mobile devices (especially media players), you’d find most of them (around 84%) are watching their video in much less than full sunlight.  I arrived at this fairly large number by assuming a Gaussian distribution of the ambient lighting conditions that most people use - completely dark to full sunlight.  If I add 1 standard deviation on either side of the mean and then add in the remaining distribution on "the dark side" (couldn’t resist the pun), you calculate about 84% of the time users are not watching the video in full sun (or near full sun).  Actually most of the time users are in less than full sun for other reasons such as preventing a sun burn or simply being comfortable - I live in Florida and I should know!

So if you accept my theory on the usage patterns, then you must agree that if a PMP is simply designed for full sunlight viewing, it will use considerably more power then the device designed to "adapt" to the ambient conditions.  The next question is how much power is saved by being adaptive... this requires a bit more math.  First, let’s assume again a Gaussian distribution of light conditions during playback over normal usage.  We’ll use the standard Gaussian distribution formula as part of our calculations  shown in Equation 1. 

We’ll also assume a 3σ (standard deviations) spread to set the limits for full darkness and full brightness (daylight viewing with the LEDs at 100%). This will include 99.7% of the usage cases (with a 0.3% error).  To clarify, -3σ = 0% brightness and +3σ = 100% brightness (see drawing 1 and equation 2).  We will also assume a continuously variable drive to the LED back-lights (as apposed to a stepped approach) based on the ambient conditions that will never drop below 20% even in complete darkness. By applying the backlight level function in equation 2 to our distribution function shown in equation 1, we can then calculate the total percentage power used by the adaptive backlight.  Equation 3 shows the total power calculation.  This calculation is for the entire probability distribution including very bright and full sun conditions.  If we evaluate the integral from -3σ to 1σ which represents 84% of the population (as mentioned before), the power is reduced from 59.8% down to 47.1% - an incredible savings. 

 
Now let’s take a look at the system impact of the back-light savings on the total run time of the device. Assume the back-light LEDs represent 40% of the total power consumption of the device when at full brightness.  Assume a run time of 2 hours based on a non-adaptive back-light.  If we reduce the backlight power by 40% for all users, then the overall system run time improves to 2 hours and 23 minutes.  That’s an overall system improvement of 19%.  Now, if we reduce the backlight consumption by 53% for 84% of the population that never watch video in bright light, the run time goes up to 2 hours and 32 minutes - a 27% improvement in performance.

In this discussion we have not considered the power consumed by the adaptive circuit, so we’ll assume it’s negligible relative to the backlight.  In many cases it takes very little additional circuitry to perform these types of tasks.  As you can imagine, if you are watching video in almost complete darkness with this adaptive PMP, then you could probably get an additional hour of play from it.  Just some thought provoking ideas...  If you want to know more about adaptive power reduction, check out National’s PowerWise® Solutions page at http://www.national.com/powerwise.

Till next time...

The Efficiency of Moving Bits - Part 2

In my last post I talked about life as a designer in the early 1980’s… it’s funny to look back and think of what we thought was “amazing technology” – some more of which I’ll discuss today.  I’m sure someone reading this could comment on engineering marvels of the 1960’s as well.

I’m going to continue my discussion on moving bits with some comparisons of bus architectures from that time and today.  We’ll take a look at how much has changed and the evolution of connecting systems and subsystems together.  I’d like to start with the S-100 bus which was essentially the Intel 8080 processor’s external bus, but not many engineers might remember that architecture.  I had friends that owned (yes, owned) the IMSAI 8080 and built automated amateur radio repeaters using these machines as controllers.  My first “computer” designs used the ISA bus made famous by IBM in the PC released in August of 1981 (I purchased one of those early machines and was the first geek on the block to show it off!).

The ISA or Industry Standard Architecture bus was not a standard (yet) when IBM introduced it in their PC.  Actually, the fact that IBM published a technical manual that including a listing of the BIOS (Basic Input Output System) source code and complete schematics, made it quite easy to clone…  I still don’t understand that decision.  This basic 8 bit bus originally ran at 4.77 MHz (like my old machine did), but later was enhanced and supported an 8 MHz clock, so every 250nS, 8 bits were transferred over the bus.  To actually move data into RAM or read an I/O address several cycles of the bus were required to latch the address, allow for settling of the bus, and give time to the peripheral to respond.

As processors improved in speed, buses needed to keep up.  The first logical step was to simply speed up the clock (as IBM did from the original PC 4.77 MHz clock to the 8 MHz clock in the XT) or use both edges of the clock.  Additionally, by making the bus “wider” with more communication lines (e.g. 8 bits to 16 bits and beyond) also improved performance.  The bus wars raged for years getting ever wider and faster.  As engineers, we continued to look for ways to move more data between subsystems and this led to us bumping into the physical laws of nature… primarily skew between bus lines and waveform distortion.  It was even more difficult if you wanted to extend the bus farther than the 10 inches inside the chassis, which at times seemed almost impossible.

It seemed counter-intuitive that the solution would be to move away from wider buses and serialize the data, but this is exactly what happened.  As the speed of the buses increased, there was little margin between each communication line (i.e. data, address, or control signals).  A tiny amount of skew would cause errors in the transfer of data.  Additionally, the mechanics of connecting large numbers of lines to a circuit card added expense.  Serializing the data reduced the number of mechanical connections, reduced or removed issues with skew, and had one additional feature – it reduced the overall power consumed.  This was accomplished by moving away from large voltage-swing technologies such as TTL and using devices based on LVDS.  Additionally, bus designers could now have point-to-point connections to each peripheral due to low connection count (e.g. PCI Express) which greatly improves bus bandwidth.  An example is the DS92LV16 SERDES (Serializer / Deserializer) transceiver. This device simply takes 16 data lines, serializes them, embeds the clock transports it to another DS92LV16 which reconstructs the 16 data lines and clock.  This is a transceiver so it has an upstream and a downstream and is LVDS based so it uses 2 wires for each path (4 wires total).

To compare old bus architectures such as ISA with serialized LVDS, we’ll need to define the parameters.  In my old ISA designs, I decided to use buffers to drive the data over the back-plane (rows of 62 pin edge connectors).  I needed enough drive to make sure the loading caused by a full complement of circuit cards would not degrade the speed of the edges.  The buffers were industry standard 74LS24x TTL level buffers.  I needed one 74LS245 and two 74LS244 buffers to drive the address lines.  There were others for control and bus management, but we’ll use only the 74LS245 for simplicity.  The bus was about 10 inches long (0.254 meters) and the transceiver consumed about 250 milliwatts (with a supply current of roughly 50 mA at 5V).

If we apply the equation from last week’s blog post to calculate energy per bit-meter for the old ISA bus we get 15.4 nJ/bit-meter.  This is using the bus clock rate, not the bus transfer rate. The calculation for the serialized bus running full duplex to the peripheral, we get 1.6 nJ/bit-meter over the same circuit card – an almost 10 to 1 improvement in data transfer energy efficiency.  These calculations are for a single end of the connection.  This ISA example does not take into account all the supporting bus electronics since it was a shared bus.  The serialized bus is much simpler since it connects directly to a single peripheral and can have multiple peripherals communicating with the host at the same time.

If you look deeper, the older parallel bus architectures are even less efficient at moving data than stated above.  If you think about extending the bus to an external chassis (i.e. 1 meter or more), the problems really pile up for parallel buses.  Serialized buses simplify everything from the connector to cable (with less wires) and even the number of connections to processors or FPGAs and are far more efficient at saving energy when moving data.

Let me know your stories or opinions by commenting on this blog or dropping me an email.  I’d love to hear from you.  Until next week…