Steve Leibson

OCZ’s 32Gbyte Onyx SSD breaks $100 barrier, cuts power

It was only a matter of time. Nobody doubts that solid-state disks (SSDs) will decline in price over time. The only questions are “How fast will prices fall?” and “How much storage will I get for my money”? PC component vendor OCZ contributed some answers to those questions yesterday by introducing a new low-cost line of “sub 100 dollar,” 32Gbyte, 2.5-inch, SATA II SSDs dubbed Onyx. The first in a planned series of low-cost SSDs, the 32Gbyte Onyx sports a read transfer rate of 125Mbytes/sec and a write transfer rate of 75Mbytes/sec. The Onyx drive is based on MLC (multi-level cell) NAND Flash devices, which might raise concerns about long-term reliability, but the drive sports an MTBF rating of 1.5 million hours and a 3-year warranty. As for power—the 32Gbyte Onyx drive consumes 1W while active and about a third of a Watt on standby. That’s roughly half the power required by a mechanical 2.5-inch HDD.

It’s Raining Low-Power Microcontrollers

Wow. The Embedded World show in Nuremberg is really shaking the low-power microcontrollers out of the tree this year. Cases in point: announcements of new, low-power 8- and 32-bit microcontrollers from Microchip and Energy Micro (a Norwegian fabless microcontroller company) respectively. Microchip’s 8-bit parts are offered in packages ranging from a tiny 8-lead device to 64 leads. Energy Micro’s parts are available in 20-, 32-, and 64-lead packages.

Energy Micro’s EFM32 “Tiny Gecko” microcontrollers are the little brothers to the Gecko microcontrollers I wrote about last November when the company first announced them at the ARM Techcon 3 conference held in Santa Clara, California. Like their bigger brethren, the Tiny Gecko processors are based on the ARM Cortex-M3 processor core. They consume 180µA/MHz, have a deep-sleep current draw of 900nA, and an “off” mode where the part draws a mere 20nA. There are 13 new members of the Tiny Gecko family with Flash capacities of 8 to 32 Kbytes, RAM capacities of 2 or 4 Kbytes, and 24 or 56 multipurpose I/O pins. Other peripherals included in the Tiny Gecko microcontroller family are a low-energy UART, I2C serial interfaces, A/D and D/A converters, and several counters and timers. Unique to the Gecko microcontroller and continued in the Tiny Gecko line is what Energy Micro calls the “peripheral reflex system,” which allows peripherals to run and communicate autonomously while the CPU sleeps for a big cut in energy consumption. Architecture, instruction set, and peripherals are compatible between the Gecko and Tiny Gecko families, which is the surest way to building a following. Embedded systems designers need broad lines of compatible microcontrollers to accommodate the wide-ranging, diverse needs of embedded design.

To that end, Microchip’s offerings fill in the low-power end of its line. The PIC12F182X and PIC16F182X (PIC1XF182X) microcontrollers—which consume less than 50 µA/MHz and have a rated sleep current of 20nA at 1.8V (30nA at 3V)—extend Microchip’s “Enhanced Mid-range” 8-bit core product line into the realm of 8-pin devices and bring the total number of Enhanced 8-bit core PIC microcontrollers to 16, available in packages ranging from 8 to 64 pins. The family features a range of internal peripherals including Microchip’s mTouch capacitive touch-sensing technology and multiple communications peripherals. The PIC1XF182X microcontrollers include dual I2C/SPI interfaces, more PWM outputs with independent time bases, and a “Data Signal Modulator” that implements a variety of modulation schemes including frequency-shift, phase-shift, and on-off keying along with synchronization and polarity control. Microchip is targeting these general-purpose microcontrollers at a wide range of applications in the appliance (coffee makers, blenders, dishwashers); consumer (vacuum cleaners, printers, remote controls); and automotive markets (LED lighting, keyless entry, body electronics). Here’s a video demonstrating the various low-power operating modes of Microchip’s PIC16LF1823 microcontroller:

Microchip’s Enhanced Mid-range 8-bit architecture employs 14-bit instructions that improve performance as much as 50% relative to 8-bit instructions and 14 new instructions in the Enhanced architecture improve code-execution performance by as much as 40% over Microchip’s previous-generation 8-bit PIC16 MCUs. Significantly, the “enhanced” architecture and instructions extend the instruction address space from 8K to 32K instructions and RAM space from 446 bytes to >4 Kbytes.

Although these new microcontrollers from Energy Micro and Microchip both focus on extremely low-power embedded design and essentially cost a buck each, give or take, they’re really quite different. There’s a substantive difference in both ability and ease of programming between a 32-bit device and an “8-bit” device (I still find it hard to label a processor “8-bit” when it has 14-bit instructions, but Microchip’s parts do operate on 8-bit data) and there are many differences in the available on-chip peripheral devices. Your specific application will likely not need all of the available on-chip peripherals but there are some unique ones in there from both vendors that can make the difference between an easy design and a tough one. Microchip has been in the microcontroller business for decades, has built a substantial ecosystem around its devices, and has recruited a small army of loyal users familiar with its architectures. Energy Micro is the definite newcomer, first announcing products late in 2009. It is inheriting and leveraging the huge ecosystem of the ARM 32-bit architectural empire. You, fortunately, get nothing but tremendous advantage in the form of choice.

Power Over Ethernet: One Cable Defines an Entire Product Envelope

Last week, I moderated a Power-Over-Ethernet (POE) session at the Ethernet Technology Summit held in San Jose. The idea of supplying high-speed communications and power over one standard cable that works anywhere in the world is certainly compelling because there are many difficulties in developing a power-delivery scheme that works worldwide thanks to differing wall-socket connectors and line voltages but that RJ45 Ethernet plug works anywhere. Consequently, POE makes a lot of sense for a large number of diverse, high-volume products including VOIP phones, thin clients, wireless access points, security cameras, and digital signage.

In an interesting twist on the concept, the amount of power delivered over a POE cable fairly well defines the power envelope of the end product. The initial 802.3af POE specification can deliver a maximum of 13W to the end product, after power losses in the cable are accounted for. The new 802.3at specification nearly doubles the available power to 25.5W, but that’s not even enough to run the laptop I’m using to write this blog post, so there’s clearly a limitation there. (However, as Microsemi’s Dan Feldman explained in his presentation, there’s also a way to get nearly 50W from a POE cable by using all four cable pairs to deliver power. Two of the pairs must then serve double duty by carrying both power and communications.)

In addition to the lack of a universal wall power plug, most of the devices that are candidates for POE adaptation are currently powered by wall warts, the ubiquitous black boxes that most of us plug as best we can into inexpensive power strips that are not designed to accommodate these “fat plugs.” In addition to their inconvenient form factor and the extra wiring they create—which often ends up creating a rat’s nest of wiring under your desk—wall warts bleed energy because they are not efficient. Because they’re generally inexpensive, not much engineering goes into the design of a wall wart. In fact, said Matthew Tyler of ON Semiconductor, the best you can get from a 50W wall wart is 84% efficiency. Wall warts delivering less power are even less efficient.

Consequently, one of POE’s advantages is the ability to develop high-quality, highly efficient power supplies for the network switches that deliver power to POE devices. (The POE realm refers to these switches as PSEs, power sourcing equipment, and calls the end devices PDs—powered devices.) Using POE topologies, says Tyler, you can drive efficiency up to 90%. In addition, says Akros Silicon’s Amit Gattani, the PSE becomes an intelligent controller that can manage the power supplied to the network’s PDs. For example, in a digital-signage application, the PSE can automatically power down the signs 15 minutes after a store closes and can power them back up 15 minutes before a store opens.

Reduced energy use saves companies money, so that’s one economic advantage enjoyed by POE. However there’s an even bigger economic advantage—one you might not expect. You need licensed electricians and permits to run ac power cables while you generally do not need either to run Category 5 Ethernet cable. Consequently, a system employing POE has lower installation costs compared to a system that employs a combination of ac power and wired Ethernet or even one that uses ac power and wireless Ethernet. There are real installation saving to be had for applications such as VOIP telephony, thin clients, and digital signage.

There is far more subtlety in the design of POE equipment than I’ve described here. All three of the companies listed above have developed expertise in the design of POE equipment and are willing to share that expertise with you.

Designing Low-Power Systems with FPGAs, Part 2

Literally within an hour of posting my last blog entry on designing low-power systems with FPGAs, Altera’s marketing engine issued a related email and dropped it into my inbox. Altera’s email pre-announces the company’s upcoming FPGAs based on 28nm lithography. The email included the following marketing graph (with no scale) to explain the advantages of the smaller geometries for FPGA manufacture.

The first set of bars in the graph set the baseline using Altera’s 40nm devices as a reference. The next set of bars show that the feature shrink alone improves FPGA gate density by 25% and power consumption by about 12.5%. (Note: That’s my eyeball talking, not Altera’s official numbers.)

The next set of bars shows what happens incrementally when Altera takes some major logic blocks and hard-codes them. Suddenly, gate density doubles and power consumption drops by 40% compared to 40nm FPGA.

The last set of bars shows what happens when you combine the lithography shrink and hard-coded IP. Suddenly you’re getting 4x the gate density at a mere 25% of the power consumption compared to 40nm devices. (Note: I’m not sure what suddenly happened to the transceiver count, that third bar in the group, which had been constant until everything got combined in the last set. My guess is that the marketing artist who drew the graph got overzealous, cut everything 75% for visual consistency, and the proofreaders missed it. I think the number of transceivers is supposed to stay constant, based on the first three sets of bars in the graph.)

Two things to note here. First, you get a lot of bang out of hard-coded IP. Coincidentally, MIPS announced that Altera had licensed the MIPS32 architecture back in October, 2008 but Altera was mum on the subject back then. RISC processor cores make lousy targets for programmable FPGA fabrics, largely because of the routing congestion around their large register files, so processor core IP is one of the IP types that really should be hard-coded onto an FPGA. Although both Altera and Xilinx did not have much success with their first-generation FPGAs that incorporated hard-coded processor cores, that doesn’t mean they’re not going to try again and the MIPS announcement late last year telegraphed that move.

Want more proof? Last week at the Real Time Embedded Computing Conference held in Santa Clara, California, Xilinx’s Senior VP of Worldwide Marketing and Business Development Vin Ratford did more than telegraph his company’s intent to put processor cores back into FPGAs. He announced and elaborated on that intent. Xilinx will be adopting the ARM architecture and an FPGA-friendly version of ARM’s AMBA interconnect in future FPGA generations.

Make no mistake. Processors are coming to FPGAs for several reasons. First, a RISC processor core consumes between 25,000 and 50,000 gates. You can drop one of those puppies into an FPGA fabric and never see it. In essence, those transistors are “free.” That’s the nature of an FPGA’s programmable interconnect. Logic just sort of disappears.

Second, you can’t build a system without at least one processor these days. Which immediately leads to the third reason. If Xilinx and Altera truly wish to convert their “We’re taking over everything” or “All your chips are belong to us” attitudes, then the processor will just have to live on the FPGA silicon. Otherwise, the FPGA companies don’t get all of the chips. It’s as simple as that.

However, as both Altera and Xilinx discovered last time they tried this, dropping a processor core into an FPGA and making it usable is not just a matter of burying some gates into the FPGA fabric. Effective ways of connecting the processor to the programmable FPGA fabric must also exist and the software developers—who represent more than 90% of modern embedded development teams—must also be happy with the integration. You only make them happy with good development, profiling, and debugging tools.

And there’s the rub.

(It’s possible that Shakespeare’s Hamlet was indeed an embedded systems developer.)

Designing Low-Power Systems with FPGAs

Actel has published a White Paper discussing low-power aspects of using FPGAs. It should not surprise you that the White Paper’s points and conclusions favor Actel’s Flash-based FPGAs over SRAM-based FPGAs from other vendors but that bias should not stop you from extracting some good meat from the document.

The first important point from the White Paper: designers considering the use of an FPGA have decided not to take the ASIC/SOC route for one of several reasons. Carefully tailored ASICs and SOCs should always deliver the lowest unit-cost system chip with the lowest power—but there’s always a cost. That cost involves a large and complex design process that requires a substantial team of trained silicon designers, a big stack of expensive ASIC design tools, expensive fabrication masks, and weeks or months of fabrication delay after tapeout. Contrast that with no up-front NRE costs for an FPGA, inexpensive FPGA design tools, and no need to be familiar with the arcane world of chip design when using an FPGA to implement a system. For system designs shipping in lower volumes, FPGAs are mighty attractive.

Once you decide to use an FPGA, you must then decide on the FPGA technology you’ll use (SRAM-based, Flash-based, or antifuse-based) and you must pick an FPGA vendor. Given that you’ve selected to take the FPGA route, there are five components of device power consumption for you to examine when evaluating different FPGA technologies:

• Static power (leakage)
• Dynamic power (frequency dependent)
• Power-up (or inrush power)
• Configuration power
• Sleep-mode power

The total energy consumed by the FPGA (which is the most important design criteria for battery-powered designs) combines all five of these power components over time. It’s here that the Actel White Paper unsurprisingly starts to make the case for Actel’s Flash-based FPGAs, but again, the information provided in the White Paper is instructional.

Figure 1 shows a startup scenario for SRAM-based and Flash-based FPGAs. Power is applied to the system at T0 (time = 0) on the graph. As the input power supply voltage rises from zero volts, the SRAM-based FPGA draws a large inrush current as its SRAM configuration array powers on. Is the inrush current really as large for an SRAM-based FPGA as shown in Figure 1? Is it as small for a Flash-based FPGA as shown in Figure 1? Well, there’s no scale (making Figure 1 a marketing graph), so who’s to say? What you should get from this point is that you need to find out what that inrush current is for the FPGA’s you’re considering.

Figure 1: FPGA power consumption for power-up stage

Something else of interest is happening in Figure 1 and you might be tempted to misinterpret it. The blue line representing the Flash-based FPGA power consumption starts to ramp up well before the purple line representing the SRAM-based FPGA. At first glance, the lines make it appear that the Flash-based FPGA will consume more power over time than the SRAM-based FPGA. However, what the curves actually show is that the SRAM-based FPGA needs time to download configuration data into its configuration SRAM while the Flash-based FPGA starts to perform its system duties more quickly because there’s no configuration overhead.

Figure 2, another marketing graph, compares the power consumption of an SRAM-based FPGA with that of a Flash-based FPGA. Keep in mind that this is a marketing graph comparing two unspecified FPGAs which may or may not have similar gate counts performing some sort of unspecified workload. However, what’s shown that is useful is that you do need to consider the FPGA’s power consumption in these various operating phases and you need to weight the power use by the amount of time your system will spend in each phase to arrive at an estimate for battery life.

Figure 2: FPGA power consumption in various operating stages

One final note of interest in the Actel White Paper is that a Flash-based FPGA configuration cell is smaller than an SRAM-based configuration cell, so leakage currents are also smaller for Flash-based FPGAs. This point appears in the “Static” sections of Figure 2.

More on Mentor’s Catapult C from John Cooley and Other Designers

Earlier this month, I wrote about Mentor’s C-to-gates synthesis tool Catapult C and low-power design. The EDA industry’s self-appointed gadfly and uber-user John Cooley has just written an extensive blog posting about Catapult C complete with detailed comments from several of his reader/users. These comments and Cooley’s conclusions are very, very interesting for people in the ESL space, as well as anyone involved in chip design, so I thought I’d highlight some of Cooley’s conclusions.

First, Cooley quotes EDA analyst Gary Smith’s published numbers to quantify Catapult C’s lead in the high-level synthesis arena. He then uses the anecdotal evidence of the large number of comments (both good and bad) that his reader/users make about Catapult C relative to the other high-level synthesis tools to conclude that there do seem to be more IC designers using Catapult C than competing tools.

Cooley then hands the microphone over to his designer/readers for comments. One thing that really strikes me about these comments is the number of people who want to use C++ to describe hardware. Now C++ compilers have a tough enough time creating streamlined object code out of C++ descriptions. C++ allows such a high level of abstract description that algorithmic descriptions more resemble poetry than precise engineering-style descriptions. My opinion is that expecting any and all C++ descriptions to result in efficient hardware is a bit of a reach. No matter how good the compiler is, C++ descriptions can be so abstract that it can be tremendously difficult to infer any sort of efficient hardware design from such descriptions. The likelihood of developing mind-reading compilers in the near future seem mighty slim to me.

Other designer/readers seem to share my concerns. One engineer who sent a comment to Cooley and who preferred to remain anonymous wrote: “I remain concerned that quality-of-results derived from designs developed in ANSI C/C++ will not compare well to hand-coded RTL for our design area (hardware accelerators for broadband communications), regardless of claimed market share of Catapult C.”

Now don’t make something out of this skepticism (mine and “anonymous”) that’s not there. When logic synthesis first appeared in the early 1980s, it too “suffered” from a quality-of-results issue. The earliest logic-synthesis tools could not generate gate-level designs that were as efficient as manually-created designs by even moderately good human logic designers just as C compilers could not initially generate assembly code that was as efficient as code written by a good human codesmith. However, two things happed to make this issue become a non-issue.

First, the tools simply got better. Adoption of Verilog and VHDL as description languages helped to standardize the sea of HDL slopping over the EDA bucket back in the 1980s. Standardization gave compiler designers a focused target and channeled their creative energy into building better synthesis tools rather than creating ever-more-elegant description languages.

Second, Moore’s Law made irrelevant the difference between 10 and 100 gates or even between 100 and 1000 gates. At some point, we stopped counting gates just as we’d previously stopped counting polygons and transistors. We don’t really know how many gates there are on a chip any more and what’s more, we not longer care. Not really. Because it’s square millimeters of silicon that actually costs money, not gates. So today we use square millimeters and then use a fudge factor to estimate the number of gates represented by the square-millimeter metric.

Perhaps something like that will happen with high-level synthesis. The jury’s still out.

Laser Spike Annealing of Nickel in Nanometer CMOS ICs Cuts Leakage 10x

One of the sad facts of life for nanometer silicon has been the rise of leakage current as device geometries shrink. At 65nm, CMOS leakage currents roughly equal operating currents, making it virtually impossible to reduce overall operating current by more than half. I’ve long thought this was the result of low-V_t transistors that can never fully turn off, a consequence of the drive to recover speed that’s lost when supply voltages are cut to reduce operating power. Turns out there’s another culprit: nickel contamination that occurs when nickel atoms drift away from the nickel-silicide interface layer used to improve the connectivity of metal inter-layer contact plugs. The nickel atoms drift during the annealing process, which is used to drive the deposited nickel atoms into the transistors’ source and drain contact pads. The first of two annealing cycles drives the metallic nickel atoms into the silicon source and drain pads creating Ni₂Si silicide. A second, higher-temperature annealing process converts the Ni₂Si into NiSi, which has lower resistance and thus provides good electrical connectivity between the contact pad and the metal interconnect plug.

It turns out that the current “soak” annealing (which lasts for tens of seconds) processes allow the nickel atoms to drift far afield. Like beach sand in your bathing suit, the nickel gets into places you’d rather not have it. The drifting nickel atoms seem to have an affinity for silicon lattice discontinuities, which can be found at the outside ends of the transistor where source and drain diffusions meet the isolation trenches and in long, narrow voids that run from the source and drain regions towards and into the FET channel. Both of these hiding places cause leakage because the metallic nickel conducts electricity where there should be insulator or semiconductor material. Nickel at the ends of the transistor causes substrate leakage and nickel atoms in the channel naturally cause channel leakage.

Applied Materials and European semiconductor research powerhouse IMEC have jointly developed a laser-annealing process with one-millisecond duration instead of taking tens of seconds. As a result, the diffusing nickel doesn’t have time to drift into these unwanted places during the second annealing step that generates NiSi. Applied Materials described a similar laser-spike annealing process back in 2004 (see article here), but reportedly achieved only a 3-4% leakage reduction back then. This latest development appears to be a refinement of that earlier technique. The two companies will be presenting their findings at this week’s IEDM conference in Baltimore, Maryland.

IMEC and Applied Materials will indeed have pulled a rabbit out of the hat if this laser-spike annealing process plus the application of appropriate transistor-design rules result in cutting leakage currents by 90% for nanometer CMOS. Leakage-driven power loss has become a significant problem for advanced IC design and had appeared to be insurmountable, even with the addition of high-K and metal-gate processing. Now, it appears there’s a real solution with the best of all possible implications for system and logic designers: they don’t need to learn anything new. They can leave this fix to the design tools and to the process engineers and once again skirt the system-level and architectural issues of low-power design.

C-to-Gates Synthesis and Low-Power Design

One of the many “pushbutton” design-automation tools that chip designers have sought is a “C-to-Gates” tool that would allow the automated development of hardware from algorithmic descriptions written in the C programming language.

The place to start almost any system design is with the most fundamental aspect of system design: algorithm development. Systems are collections of independently and dependently operating algorithms. For example, a DVD player uses one algorithm to decompress the combined media stream, another to decode the resulting video stream, and yet another algorithm to decode the resulting audio stream. All systems are based on the execution of one or more algorithms.

Most algorithm development begins and ends with C. One exception to this rule is MATLAB from The Mathworks, which is very popular with many algorithm developers. However, there are ways to get MATLAB to produce C from MATLAB-based algorithms as well.

Given the close association between algorithm development and the C language, it’s only natural to want a tool that automatically converts C descriptions to hardware netlists. However, early attempts to create such tools didn’t meet with much commercial success, largely because the quality of results (number of gates, operational speed, and resulting power consumption) compared poorly to manual RTL-generation design techniques.

The tools have been getting better over the years, leading to this recent announcement by Mentor Graphics:

“Mentor Graphics Corp. (NASDAQ: MENT), today announced that Fujitsu Kyushu Network Technologies Limited (Fujitsu QNET) has chosen the Catapult C Synthesis tool for use in its design tool environment to implement complex algorithms in hardware that were previously processed by a processor implemented on LSI. Fujitsu’s growing expertise with the Catapult C tool is also a key enabler in the expansion of their design services business.

Fujitsu QNET was able to dramatically cut power consumption by using the Catapult C Synthesis tool to create a dedicated hardware accelerator for mobile voice processing algorithm versus running in software. The resulting silicon implementation yielded a reduction in power consumption of 83%. This was made possible by the ability of the Catapult C tool to find the optimal trade-off between power, performance and area, in this case, implementing a design satisfying voice performance requirements while running at a lower clock frequency than the previous implementation using a processor.”

Based on this announcement, it would seem that C-to-gates tools, at least Mentor’s Catapult C, are getting closer to reality. In fact, the above announcement would lead you to believe that such tools are here and production-ready today. Indeed, Mentor’s description of the Catapult C synthesis tool appears mighty attractive:

“Catapult C Synthesis reduces design time and verification effort. When writing pure C++, designers focus on the functional intent of their application. Timing and architectural information is abstracted away from the source description. With fewer details in the model, testbench development is also simplified.

Implementation of specific details are automatically added during the synthesis process, eliminating error-prone manual interventions and resulting in RTL designs correct by construction. Debug of the resulting RTL is in turn eliminated, further reducing the overall verification effort.

The Catapult C automated verification environment allows any RTL implementation of a C++ model to be verified using the original C++ testbench. This eliminates the need to write pin-level interfacing and bit-timed RTL environments to verify the RTL blocks created by Catapult before moving to system integration.”

There’s a caveat or two to remember, however. First, there’s good C code and bad C code whether you’re writing code to run on a processor or code that’s to be synthesized into gates. In the case of C-to-gates synthesis, good code signals the design intent as clearly as possible so that the synthesis tool needs to infer as little as possible. Machine inference is the second caveat. Every detail that Catapult C—or any synthesis tool for that matter—must infer is a design detail that you didn’t put into the design.

Conventional RTL-driven logic synthesis makes such inferences all the time and, over the years, designers have gotten savvy to the kinds of inferences that will be made by their logic-synthesis tools and have compensated by adapting their code-writing styles when writing hardware descriptions in the Verilog and VHDL hardware description languages. However, C has largely been used as a sequential algorithm description tool to create software that runs on single processors and use patterns by engineers reflect that long history. In addition, C describes algorithms at a higher level of abstraction than descriptions written in hardware description languages. As a result, there’s always more to infer from a C algorithm description just due to the higher abstraction level.

So eye that 83% power-reduction that Fujitsu QNET achieved for that voice-processing algorithm with envy. Just remember that engineering isn’t as simple as pushing a button.

The Surprising Popularity Rise of On-Chip Memory

I attended the 7^th International SOC Conference in Newport Beach last week and several of the speakers addressed issues relating to SOC and system power. One of these speakers was Bob Madge, Director of Technology Marketing at LSI Corp (formerly LSI Logic). In case you didn’t know, LSI has been evolving its business from its original focus on developing ASICs and SOCs for customers to a focus on programmable ASSPs (application-specific standard products) and custom silicon specifically aimed at the networking and storage markets. Madge’s first slide explained the reasoning: annual storage-capacity growth is a projected 49% per year and annual network-traffic growth is a projected 42% per year. Good growth numbers for a business to target.

To deliver competitive parts, LSI stays on top of IC design and manufacturing trends. One trend that caught LSI and the semiconductor industry by surprise has been the rapid growth in on-chip memory use. On-chip memory makes sense for two reasons. First and foremost, it provides better performance than off-chip memory because putting memory on the chip along with the logic circuitry eliminates two sets of off-chip drivers and receivers, which reduces power consumption for memory transactions. Second, on-chip logic can communicate with on-chip memory over extremely wide memory interfaces—pin count is not an issue if you stay on the chip. A wide memory interface reduces the number of transfers needed to move a given amount of data and lower transfer rates cut power as well.

However, merging logic and memory on one piece of silicon has always presented design and manufacturing issues. Bulk, high-volume, high-capacity memory manufacturing processes differ from logic manufacturing processes because the two processes must optimize different parameters. Memory processes emphasize low cost manufacturing and tend to have fewer metal layers than logic processes, which emphasize speed and on-chip connectivity. “Frequency, density, and power are always a challenge,” said Madge.

For example:

• Today’s network routers use 400-Mbit buffers. Switches need 512 Mbits of storage or more. In the future, said Madge, these devices will need as much as 1 Gbit of on-chip memory in multiple configurations.

• IP controllers used in network storage applications currently use 60 to 100 Mbits of cache memory. In the future, these devices will need 200 Mbits of memory or more.

• Media processors currently use 60 to 80 Mbits of memory running at 500 MHz. Future needs will be on the order of 100 to 200 Mbits of memory running at 600 to 700 MHz.

All of these examples demonstrate the coming challenges for fast, dense, on-chip memory.

LSI is looking at embedded (on-chip) DRAM and the use of 3D, through-silicon via technology for chip-to-chip stacking as ways of increasing the amount of on-chip memory. The company is doing this because it sees a continued and rapid rise in the amount of on-chip memory needed for its networking and storage chips.

Embedded DRAM cuts power because it uses a 1T (one-transistor) cell, which obviously improves density over a 4T or 6T static RAM cell. However, embedded DRAM also reduces static and dynamic power consumption because the fewer transistors use less power and leak less current than the greater number of transistors required to build the same amount of SRAM memory.

LSI is also investigating other power-saving features that become possible when you move memory onto the logic chip including a sleep mode for the memory, dual power rails, and low-voltage operation. However, said Madge, the biggest benefit appears to be a move to embedded DRAM because of the huge reduction in transistor counts.

Green Chips in Newport Beach

Yesterday, I moderated a panel on green chip design in Newport Beach at the 7th International SOC Conference. Chances are you didn’t see or hear any of it because there were only 100 people at this conference in total. That’s really too bad because we had a great set of panelists:

1. Michel Laurence co-founded Octasic, which is a Montreal specialist in echo cancellation and has mastered the art of self-clocking or self-timed (asynchronous) logic design.
2. Jauher Zaidi, CEO, PalmChip Corporation, which was in the chip-design business but has now spun off those activities to focus more on SOC platform software.
3. Alan Ruberg, SPMT architect for SPMT, The Serial Port Memory Technology consortium, which is developing a high-performance, low-power, next-generation memory interface to replace the DDR families with an interface that uses fewer pins.
4. Dr. Simiack Haghighi, Principal Architect of Qualcomm’s CDMA Technology Architecture Group, which should need no introduction…and
5. Steve Carlson, VP of Product Marketing at Cadence (who kindly volunteered from the audience at the last minute when a panelist from another leading EDA company didn’t show).

I tossed out questions from readers of my blogs, some I developed on my own, and some that came from the panelists themselves. Here’s the first question and the panelists’ answers.

This was a cynical question from one of my blog readers: What’s the difference between the design of a Green Chip and one of those greyish Silicon ones?….More to my point – doesn’t Darwin take care of those companies who don’t design to a lower power solution than their competitors and, therefore, is this “Green Chip” thing just hopping aboard the Hype Bandwagon?

Cadence’s Steve Carlson quickly snagged this first question. His cool reply was that the industry’s focus on green technology has little to do with tree hugging. It’s all about business. The confluence of business issues such as cost and power and the social issues that draw the general press coverage, but business drives the design decisions.

Palmchip’s Jauher Zaidi agreed. There’s lots of hype about “green” these days, he said, but cost drives everything. Energy costs drive purchasing decisions at data centers, which use a lot of electrical power. Chip-design teams need power engineers now, he concluded.

SPMT’s Alan Ruberg also chimed in for this first question. Every Watt dissipated by a system requires another Watt in cooling, he said. So every Watt you save in a design delivers a 2-for-1 return in terms of energy savings. He added “By the year 2020, if trends continue on the present course, you’ll only be able to power 9% of a chip at any given time.”

How can that be? Why not just omit the other 91% of the design? Because all of the panelists can foresee a time in the rapidly approaching future when there will be specialized blocks for all the tasks performed by a chip, but not all tasks need be running simultaneously. For example, a mobile handset chip with functional blocks for a still camera and a video camera need power up only one of those blocks at a time because they share the lens and cannot operate simultaneously, yet they each require different optimizations so it makes sense to design special-purpose blocks (or get the relevant predesigned IP) for both functions and then power the one that’s needed.

There were some interesting independent observations that I noted in addition to the answers to the questions asked during the panel session:

Palmchip’s Jauher Zaidi noted that Amdahl’s Law applies to the power component of systems as well as to its usual application for analyzing execution time. It does no good to reduce the power of one system block by 10x in a system like the iPhone, for example, if it represents only a small part of the overall system power consumption. You end up reducing the system’s energy consumption very little. Power reduction requires a systemic approach.

Zaidi also noted that he needs to charge his iPhone three times a day and that he also manually turns functions on and off to extend battery life. He recommended that designers make it easier for users to manage their increasingly complex devices. I countered, saying that my kitchen doesn’t require such management. The microwave oven doesn’t turn itself on spontaneously and the refrigerator turns itself on and off automatically to maintain set temperatures. Surely we can manage more of the functions in today’s more intelligent systems in a… more intelligent manner. I submit that we’re better off trying to engineer smarter systems than smarter customers. Social engineers we’re not.

Cadence’s Steve Carlson estimated that less than one third of SOC designs today use DVFS (dynamic voltage and frequency scaling) and 10% or more don’t even use clock gating. Those are pretty dismal numbers in my opinion for practices that reduce an SOC’s power consumption and are known to work well.

Carlson noted that there’s lots of room for improvement.

Amen.