Low-Power SOC Design and Modern Times

EDN just published an excellent article by Dean Andersen on Extreme Low-Power Design. I categorically agree with almost all of Andersen’s points regarding low-power SOC design. I think they’re important enough to repeat here. At least one of Andersen’s points needs serious updating for modern times.

Disclaimer

My day job as Technology Evangelist for Tensilica means I spend a lot of time thinking, writing, and talking about configurable processor cores and SOC design. I’ve written a book about the topic, published by Elsevier, sister to the company that owns EDN. My EDN blog generally steers clear of topics that overlap my work at Tensilica, but this isn’t always possible. As EDN.com’s Editor in Chief Matt Miller says, it’s silly to remove the Tensilica part of my brain when I blog for EDN. Besides, I wrote a book on this stuff. Oh, did I already mention that already?

End Disclaimer

Here are the important points Andersen makes:

1. Power reduction can occur at each design stage…The greatest benefit comes at the system level. The least benefit is at the circuit level…As a guideline, the system-level and architecture-level reduction can be orders of magnitude larger than any other level.

SOCs have been around for more than 10 years. IC circuit designers and manufacturing engineers have made tremendous progress in cutting power yet I see amazingly little advances in SOC system design. System design seems frozen in time, somewhere back in the 1980s. Much more is possible today.

I still see system designers using the “hang everything off of a bus” school of system design. Take multicore, the SOC buzzword de jeur. Designers accept that SOCs now should have more than one processor to get all the work done yet keep clock rates low to cut energy consumption. So, how do they hook these processors up? The first approach is to stick them all on a bus. Wrong, wrong, wrong. Buses create shared interconnect that instantly becomes a scarce on-chip resource.

These system-design habits arose during the old circuit-board days when board real estate and circuit traces were dear. But nanometer ICs have far more raw interconnect ability than we ever dreamed of in the ancient G10 and FR4 days of discrete chips on fiberglass pc boards; there are tons of available interconnect in every square millimeter of a 90nm chip. Use it!

Some academics have stepped up and said, “Clearly, you can’t use buses to hook everything up on an SOC.” (Right on!) “You must therefore use on-chip networks.” (Oops! No! No! No!) Take a hard look at the overhead of some of these on-chip networks. Their sophistication sometimes requires more circuitry than the processors they interconnect. And your scheduling problems jut got a lot more complex.

Is there an exotic on-chip interconnect we can use? How about point-to-point interconnections? Everyone used them before microprocessors arrived. Now no one does. Buses have become such a powerful tool, such an omnipresent interconnect fabric that we automatically reach for one without thinking. Sort of like your favorite beer.

Unfortunately, many SOC designers subconsciously think that IP blocks still come in plastic packages. Some of these blocks are indeed packaged so that you can’t reach the signals inside. Many are not. Got bits that need to go all over the SOC? Send them on their merry way with wires. Don’t try to funnel them all into a universal bus. That indeed wastes power.

2. One of the most fundamental concepts of conserving power is to shut it off when you don’t need it.

Absolutely correct! Yet try to find an EDA tool that will help you automate the process of designing voltage islands that can be programmably switched on and off. It’s still a depressingly manual design process. Clock gating, now that’s another matter. Andersen advocates clock gating of manually designed logic blocks. Make certain you understand how the clock is gated in every purchased IP block. As it happens, processors can be massively gated because they execute instructions, so the needs of every instruction can be mapped and the associated function blocks’ clocks gated accordingly.

In comparing hardware implementations versus software implementations, I think Andersen’s concepts are somewhat dated:

3. For a software algorithm, you implement the function in a general-purpose microcontroller unit or DSP… All operations operate at a higher clock rate…than needed for actual processing, because a serial process of events must happen before and after the actual computation. A clock can run at a lower rate in a parallel-custom-logic implementation of the same function.

If Andersen were writing about board-level design back in the 1980s, these statements would be correct. However, Andersen’s article is about SOC design now, so his statements reflect obsolete concepts.

IP vendors (including Tensilica) have offered configurable microprocessor IP cores for a decade. Configurable processors can swallow that parallel custom logic that Andersen writes about. The result is a processor with special registers and execution units that replicate custom logic’s parallel execution capability and therefore replicate custom logic’s ability to execute tasks at lower clock rates.

The difference between using the processor and hard-wired state machines to directly manage these parallel operations is that augmenting a processor’s execution pipeline with parallel hardware-execution units keeps the task under firmware control. Putting parallel execution hardware in the processor keeps the algorithm under firmware control so it can be more easily debugged and more cheaply fixed, often with just a firmware change, thus avoiding a silicon respin. The reduction in energy consumption is very similar with both the custom logic block and configured processor approaches. As I said, I did write a book about this stuff.