The Energy Zarr Blog

Will Binary Communications Survive?

In my last post "Going Faster Has a Price" I discussed the issues with transmitting bits represented by two states at faster data rates and the problems of inherent loss in the media, ISI and many other phenomenon that screw up the signal.  Through careful channel design and active means, engineers can transmit and recover bits over copper cable and back planes with ever greater rates.  For example, National Semiconductor and Molex demonstrated 25Gbps+ communications over a back plane at DesignCon 2011 this year.  But how long can the industry keep doing this without changing the way we define a bit on a backplane?

This problem is not a new one... as a matter of fact, it is a very old one going back to the early telecom days of modems.  In the early days of circuit switched (voice) networks, filters were placed in the system to limit the bandwidth of the signal to around 3KHz which was enough to reconstruct a human female voice without distortion.  This was done primarily as a means to frequency multiplex multiple telephone circuits on a single microwave transmission between towers (before fiber-optic lines).  So when people tried to move "bits", they were limited to the 3Khz bandwidth.
Enter the Shannon-Hartley Capacity theorem (see below).

What this says is the maximum capacity of a channel to carry information is a function of the bandwidth (B) in Hertz and the Signal to Noise Ratio (S/N) which has no units.  So as your noise goes up, your capacity to move information goes down.  This plagued early engineers and limited the amount of information that could be moved through the network.  Early modems used Frequency Shift Keying (FSK).  One frequency was used to indicate a "0" state and another to represent a "1" state.  The frequencies where chosen so that they would pass through the 3Khz limit of the channel and could be filtered from the noise.  The problem is that you couldn’t switch between them faster than the bandwidth of the channel so you were still limited to the 3KHz... so how did they get around this?  They used Symbol Coding.

Symbol coding basically combines groups of bits into a single symbol.  That symbol can be represented by a frequency carrier and a combination of amplitude and phase.  This led to the development of Quadrature Phase Shift Keying (QPSK) or Quadrature Amplitude Modulation (QAM) techniques which are in use today in modern cable modems. The group of bits can be sent all at once instead of one bit at a time... clever! However, it comes at a cost and a fair amount of complexity relegated to the world of digital signal processing.

But what about the high-speed digital signal path between two systems in our modern Internet?  Today they use scrambled Non-Return-to-Zero (NRZ) coding which prevents DC wander and EMI issues... but it is still either a "0" or a "1" state - two levels representing the state of a bit.  Will this medium ever move to other coding schemes to get more data through the channel as the early telephone system did?  It might.  Intel and Broadcom are both pushing for a standard that uses multiple levels and symbol encoding for 25 Gbps and beyond.  This has the added benefit that more bits can be sent in a single transmission of a symbol.  This is already being done today in Ethernet for the 10/100/1000 CAT-5/6/7 standards over UTP cable where the bandwidth of the channel is limited to around 350 Mhz. Will we see this at 25 Gbps and beyond? Possibly...

The problem with this method is power.  It takes DSP technology at each end of the channel to code and recover the signals adding energy consumption to the mix.  With thousands of channels in a modern data center, that power can add up really fast.  NRZ techniques are very low in power consumption.  National Semiconductor has produced devices that can move data at rates of 28 Gbps over copper media and back-planes at very low power consumption - something multi-level systems will find difficult to do.  The industry agrees and is pushing back on the multi-level proposals. 

There may come a day beyond 28 Gbps where there is no alternative but to go to multi-level symbol encoded systems, but I think that may be some time off in our future when 100 Gbps is far more common - perhaps even to your cell phone!  Till next time...

 

 

 

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…