At least three major changes to NAND Flash technology in the recent past have caught my attention. The first such event I want to discuss in this blog entry is the HMC or Hybrid Memory Cube that Micron first announced last year and is now in joint development with major partners including Samsung and IBM.

I previously wrote about the HMC (see “3D Thursday: Hybrid Memory Cube—Does anyone know what’s happening with IBM and Micron?”) and its design is for high-performance computing systems that require extremely high throughput: 1 Tbit/sec. (See “Want to know more about the Micron Hybrid Memory Cube (HMC)? How about its terabit/sec data rate?”) The HMC is a DRAM example of the kinds of memory modules we’re likely to see from the marriage of 3D IC assembly techniques and advanced NAND Flash devices.

The HMC runs many, many TSVs (through silicon vias) up through a stack of as many as four SDRAM die to access the inherent parallelism of the multiple DRAM arrays on each die. Each proprietary DRAM die in the HMC stack has 16 separate memory arrays, resulting in substantial potential parallelism and consequently, substantial potential memory throughput.

However, the high-performance approach of the HMC is not the only way to harness 3D assembly and semiconductor memory. For example, at the end of last year, I wrote an extended blog describing a thought experiment that employed the HMC design concepts using Wide I/O SDRAM instead of the special NAND Flash chips in the HMC. (See “3D Thursday: Let’s end 2011 with a high-performance DRAM memory stack design. How would you improve it?”) Wide I/O SDRAM presents four independent 128-bit DRAM channels to the host system, resulting in a high level of memory parallelism. Just not as high as for the HMC. In fact, the performance is about half that of the HMC but it’s still pretty good. The same parallelism concepts could be applied to NAND Flash devices designed to a similar Wide I/O specification for NAND Flash. The lower interface speeds enabled by a Wide I/O memory interface port really drop power consumption while maintaining good performance through the parallelism uncovered by the access to the multiple on-chip memory arrays.

I have not heard of any efforts to adopt the Wide I/O interface spec to NAND Flash devices. Not yet. But the move to extracting parallelism from the arrays on all memory chips is too attractive to ignore in a world that perpetually thirsts for bandwidth at low power.

At the end of the year, two other announcements directly related to NAND Flash memory have caught my eye: the introduction of the XQD memory card format and the ONFI 3.0 interface spec. The Compact Flash Association introduced the XQD memory card format in December 2011. The XQD memory card has a slightly larger footprint than an SD memory card and a somewhat smaller footprint than a Compact Flash (CF) memory card. It’s as thick as a CF card. But the really big difference here is the interface to the memory card. The XQD memory card uses a PCIe (PCI Express) interface clocked initially at 2.5 Gbits/sec, resulting in a maximum write speed of 125 Mbytes/sec.

That’s really fast and speed is important when you’re shooting large images at a fast rate, which occurs during HD video recording and at high burst speeds in high-resolution digital still cameras. Both such conditions exist in the new Nikon D4 DSLR, which Nikon launched just last week. The Nikon D4 DSLR can shoot 16.2 Mpixel frames at 10 to 11 frames per second. Normally, DSLRs use in-camera RAM to buffer burst-mode still captures but the Nikon D4 DSLR can accept the new XQD memory cards and Sony introduced the first series of such cards last week, concurrent with Nikon’s introduction of the Nikon D4 DSLR.

Sony claims that its H Series XQD card can accept bursts of 100 uncompressed still images from the Nikon D4 DSLR in continuous shot mode. That’s a huge jump in burst length for a digital still camera and will be invaluable in shooting images of sports activities, for example.

One of the secrets behind the XQD card format’s performance is that PCIe interface port, which is also unique in that it is a memory interface and is not derived from a disk interface. That should mean that a host processor doesn’t need a disk controller to operate an XQD card. The card can be mapped to the host processor’s memory bus and the controller can reside in each memory card. Eliminating the disk controller from the serial chain between the processor and the Flash memory chips should cut costs, reduce power consumption, and boost performance.

All of those benefits are welcome in the world of low-power design. After all, do we really need controllers controlling controllers in an efficient system design? I don’t think so.

Now before you bemoan the need of a controller in each memory card, you should be aware that there already is a controller in each CF and SD memory card. You don’t think that NAND Flash arrays already look like disk drives, do you? We do indeed currently have controllers controlling controllers in existing NAND Flash memory subsystems.

A PCIe interface spec should simplify things somewhat.

The third development that’s caught my eye in the Flash memory arena is the announcement of the ONFI 3.0 interface specification for Flash memory. The ONFI (Open NAND Flash Interface) Working Group introduced the third major revision of the ONFI spec nearly a year ago, in March 2011. What’s new is that there are now products appearing that use ONFI 3.0.

The advantage of the new ONFI specification is that it doubles transfer rates to 400 Mtransfers/sec using the NV-DDR2 200MHz double-data-rate (DDR) protocol while adopting 1.8V SSTL_18 signaling to cut the power dissipation of the interface. See a pattern evolving here? More performance and less power consumption. The question is whether or not ONFI 3.0 is real or not. Well, the memories now seem real because Intel and Micron jointly previewed a 128Gbit NAND Flash device in December with the derivative 64Gbit NAND Flash device going into production now. According to the joint Intel/Micron announcement, the 128Gbit device will be in volume production later this year after a “rapid transition” from the 64Gbit device.

However, an ONFI 3.0 memory device isn’t sufficient. You also need a controller on an SOC that can operate ONFI 3.0 devices. Cadence just introduced an ONFI 3.0 NAND Flash controller IP block and companion PHY IP today along with appropriate verification IP so it’s now possible to include an ONFI 3.0 NAND Flash controller in an SoC design using the standard ASIC flow.

As you can see, there’s a tremendous amount of new technological development going into NAND Flash memory and I see big things ahead this year, all to the benefit of low-power system designers.

Face it, some most IP blocks aren’t that well documented. You may never know enough about the internals of a purchased IP block to fiddle with its clocking. Legacy IP blocks may have been long abandoned by their designers who have gone off to other tasks, other companies, other planes of existence. Even a block you’ve designed yourself may have scrolled off your own internal memory window long ago.

Designers everywhere have a common solution for these sorts of problems. “Give me a tool to do this” they demand from EDA vendors. “I just want to push the button.”

Usually, that’s easier said than done. Calypto’s got a tool you can try however. It’s called PowerPro and comes in two flavors: CG and MG. The CG flavor is based on the company’s SLEC sequential logic equivalency checker. That’s a tool that checks to see if modified IP block “A prime” works the same as original IP block “A.” It’s a general-purpose EDA tool with a variety of uses and one of those uses is for comparing an IP block’s function before and after clock gating.

Calypto’s PowerPro CG encapsulates the SLEC EDA tool to produce a “done for you” tool that can automatically insert clock gating into an IP design. It also checks to make sure the IP block’s behavior doesn’t change as a result of the added clock gating. Usually the insertion process takes 4 to 8 hours according to Calypto CEO Doug Aitelli who spoke to me about the product at DAC 2011 in San Diego. What do you get for this overnight run? Usually 10% to 30% reduction in dynamic power said Aitelli. Sometimes as much as 60%. Not bad for “pushing the button” I’d say.

There’s another flavor of PowerPro called PowerPro MG. Nope, not named for a cute little British sports car, “MG” stands for “memory gating.” We tend to forget that today’s SoCs are more than half memory measured by die area. Usually SRAM. We sort of allude to this fact when we talk about MPSoCs—multiple processor SoCs. With each of those processors comes a boatload of on-chip SRAM for fast execution. However, we don’t seem to explicitly call out the memory. We tend to ignore it. I guess MMSoC—mostly memory SoC—doesn’t have the same cachet as MPSoC in our processor-centric world.

However, if more than half of an SoC is SRAM, it makes sense to pay some attention to reducing the power consumption of an SoC’s on-chip SRAM blocks. That’s what Calypto’s PowerPro MG does. It can automatically add memory gating to an SoC design by evaluating the design’s behavior across many cycles.

It also goes a step further. Many SRAM blocks for SoCs now have a sleep mode where the memory’s operating power can be reduced by shutting down peripheral circuitry such as address decoders and sense amps while keeping the memory storage array alive. According to Calypto’s Aitelli, most SoC designers find these sleep modes too hard to use, so they simply don’t use them. They don’t have the time. But those sleep modes are still there just waiting to be used. PowerPro MG will add the necessary sleep/wake-up state machine to exploit this little-used memory feature. Push the button, save power.

Just a story from a chance meeting at DAC. Par for the course. There’s always something new to learn, something new to try.

To read my blog on the Low-Power Report Card Panel at DAC, click here.

Schedule:

Thursday, April 7, 2011

• 8:30 AM: Check-ins and On-site Registration
• 9:00 AM: Morning Keynote Speaker
• 10:00 AM: Parallel EDA
• Noon: Keynote Speaker
• 1:30 PM: High-Level Design
• 4:30 PM: Cloud Computing

Friday, April 8, 2011

• 9:00 AM: Low-Power Design
• 11:30 AM: 3D ICs

This is an inexpensive conclave with an emphasis on discussion and networking. It’s only $280 for IEEE Members; $100 for unemployed IEEE members. Save $50 through March 18th.

Full information and registration: www.eda.org/edps

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.

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.

• Do you design ASICs or SOCs?
• Do you work on a team that designs ASICs or SOCs?
• Do you manage a team that designs ASICs or SOCs?

Let me ask you a question then. What’s the one thing you will do from now to the end of the year that will put you or your team ahead of the rampant, cutthroat global competition it will face in 2010? Do you even know?

Let me give you the typical answer, the answer that I know I’d get from most of the engineers, designers, managers, and executives in this industry. It’s a one-word answer. I know it because I’ve heard this answer over and over again. That answer is… nothing.

What!?!?!

Absolutely, positively nothing.

The depressing reality of the SOC design industry is that it has been on cruise control for years. It’s been on incremental improvement for years while increasingly advanced silicon outstrips our ability to exploit it. Here are some of the things I’ve heard over and over again during this decade:

• Just give us tools that are a little better than last year’s.
• I just want to push a button and have all my work done for me.
• I don’t have time to read.
• I don’t go to DAC.
• I don’t go to any shows or conferences because my travel budget’s tight (or gone).

Sound familiar?

Well, you’ve got another chance. Early next month, the Seventh International SOC Conference takes place in Newport Beach. This hidden gem of a conference has been quietly going on under the noses of almost every SOC design team in the world for nearly the entire decade and chances are very good that your competitors have never gone to even one of these conferences. Heck, chances are good that you haven’t either.

Beyond the meeting room doors of this conference, a very few forward-looking people from the industry elite have spent the few bucks needed to drive or take a Southwest Airlines flight to the Orange County/Santa Ana/John Wayne airport, which is almost within walking distance of the inexpensive conference hotel. This is one SOC design conference where it’s easy to convince your boss that you’re not on a junket. One look at a photo of the hotel will be all it takes.

There’s not a design team on the planet right now that’s not frightened and confused, uncertain of what to do, worried, and struggling. What every one of them lack is insight. What they expect, I guess, is to somehow be struck with insight by divine inspiration.

It ain’t coming.

You want inspiration? You have to go out and get it. Aggressively.

In the high-stakes game of chip design, one idea is worth hundreds of thousands or millions of dollars if it saves you a week or a month of development time. Many millions of dollars if it saves you a respin. Many tens of millions of dollars if your team gets the design win and your competitors don’t.

Can YOU imagine getting that design win, recession be damned? If you can’t, doesn’t that suggest there’s something you don’t know? Something that someone else possibly does know? Something you need to know? Someone with that one idea may well be presenting at the Seventh International SOC Conference. Maybe it’s a new facet to low-power design. Maybe it lies at the intersection of silicon tech and biotech. Maybe it’s not in the head of someone on stage at all but in the head of that person sitting right next to you. Who knows?

One thing’s for sure. You won’t find out sitting in front of your PC’s screen yet another day. If you find it in there, your competition has found it too.

I read a lot of comic books when I was young. Perhaps you too are familiar with the origin legend of Superman. If so, you know he was sent to earth as a child, rushed off the planet Krypton in a one-man rocket, barely in time, before the entire planet exploded. His life saved by his father Jor-El. When he landed on earth, due to the difference in suns, gravity, and atmospheres, little Kal-El had gained superhuman powers.

He was, in fact, an alien from another planet in a distant galaxy.

The analogy is obvious. Our “planet” as we’ve known it (planet SOC) is literally in destruction, endangered by economic forces beyond the control of your design team or anyone else’s. Continuing as you have guarantees pain and suffering. OR YOU CAN CHOOSE TO ROCKET TO A DIFFERENT PLANET IN A DIFFERENT UNIVERSE NOW. Actually, all it really takes is a flight or drive to Newport Beach in Southern California.

It’s your choice. I dare you to click here.

PS: Either way, it doesn’t matter to me. I’ve no financial interest in this conference. Just an interest in seeing this industry move forward.

DesignWare minPower IP components complement and do not replace existing low-power design techniques such as clock gating and the use of multi-Vt transistors. These IP components also work with more advanced low-power design approaches such as multi-voltage islands, MTCMOS (multi-threshold CMOS) logic, multi-voltage with power gating, and DVFS (dynamic voltage and frequency scaling) techniques. The minPower IP approach introduces new IP blocks at the logical design level, just after functional design and just before physicla layout. You add these new IP components by simply adding the new minPower IP database before logic synthesis.

One of the most effective ways to save power in a design is to determine the design’s functional operating modes and then to turn off whatever’s not needed in each mode. Using this approach, you can turn off the clocks to the unused blocks to cut dynamic power and you can also gate the power to these blocks, which cuts both dynamic and static power. However, you usually cannot turn off everything in a design. Something must remain awake so that the appropriate functions can be awakened at the proper time. For example, you cannot turn off the receiver in a mobile phone handset or you’ll miss incoming calls. For those blocks that cannot be shut down, you need other power-saving design approaches.

That’s where the Synopsys DesignWare minPower IP components come into play. They provide low-power logic structures that derive their low-power characteristics from one or more of three design approaches:

• Low-power datapath architectures. These datapaths are specifically designed to reduce glitches and to prevent glitches from propagating. They are also designed to minimize switching activity.
• Power- and switching-aware datapath structures. The use of these structures is based on power criteria when the synthesis tool can infer switching activity and power consumption.
• Instantiated low-power IP based on data tracking, enhanced clock gating, and data-specific datapath gating.

The DesignWare minPower datapath structures are designed to be balanced and shallow to minimize switching activity. They’re also designed to generate fewer glitches and to prevent glitch propagation. Synthesis of these datapaths also focuses on generating less switching activity by exploiting the presence of low-activity bits based on the distribution of data values moving through the pipeline. Consequently, datapath encoding is based on an analysis of operand activity through the pipeline. There’s also some amount of optimization based on variable data slack through the pipeline. Different signals propagate through a pipeline at different speeds and the DesignWare minPower IP blocks can be modified to exploit available differential slack within the pipeline to reduce power consumption.

The synthesis tool will also look for ways to reduce the number of pipeline stages that high-activity signals must propagate through and will swap the inputs on two operands entering into a function if doing so reduces power consumption. All of this evaluation would seem to require substantial amounts of simulation to evaluate the data-specific results of power optimization.

The power-aware structures in the DesignWare minPower IP collection are designed for the optimization of delay first (you still must meet timing goals), followed by power consumption and then area. Thus you might actually see some area increase with this approach if it produces substantial power savings and indeed, some of the results shown in this Webinar indicated an area increase of a few percent.

There are three IP categories within the DesignWare minPower IP line:

• Data-tracking pipelines (patented by Synopsys)
• Enhanced clock gating
• Datapath logic with built-in gating

The data-tracking pipelines are designed to suppress data bubbles within the pipeline that contain invalid data (indeterminate, glitchy data), which reduces the extraneous switching activity caused by this sort of data. These structures alone reduce power consumption on the order of 20%. That’s pretty significant. The enhanced clock gating takes the amount of clock gating in specific IP blocks from about 60% to more than 90%, which can also result in a power savings on the order of 20%. Still significant.

Even better results come from merging clock-gating logic with the datapath’s computational logic-treating the clock gating as just part of the datapath’s logic and optimizing the whole ball of wax. Power savings on the order of 30% can result.

More significant than all of the above however, is that this design approach is the Holy Grail that designers seek: a drop-in tool that requires that designers learn next to nothing while saving substantial amounts of power. Because it appears at first glance that Synopsys’ DesignWare minPower IP is just such a drop-in tool, it’s sure to get a good, close look by design teams questing for the Holy Grail of design tools.

Those lyrics from a song from the Rolling Stones describes the situation with ASICs/SOCs and FPGAs. For low power, you want an ASIC or SOC. However, there are huge obstacles to using an ASIC or SOC. First, you need a team that knows how to design custom silicon or you need to rent one—which is expensive. If you have your own design team, you should be prepared to drop a million dollars or so on design tools and another million or so on NRE charges. Also be prepared for a 6-18 month design cycle, lots of painstaking verification, and the risk of at least one silicon respin due to design errors or spec changes. High risk indeed.

On the other hand, there are FPGAs. The NRE cost is zilch. The design tools are low-cost or no-cost. There’s no physical chip design required, hence a lot less verification. In short, it’s much easier to design a system based on FPGAs than on SOCs or ASICs, but there’s a price to pay: higher unit cost, less performance, and higher power consumption. All three figures of merit are 10-20x out of whack for FPGAs versus ASICs/SOCs. In addition, you’ll not get the same maximum gate count in an FPGA, not by a long shot.

So if you need an ASIC or SOC, then you need one. If not, and if an FPGA’s part cost, power consumption, and/or performance aren’t where your design needs to be, there is a middle ground. In the recent past, this middle-ground component has been called a “structured ASIC.” That’s become a tarnished name. In the distant past, the name for a similar sort of device might be called a “gate array.” Today, eASIC calls it a “new ASIC.”

What’s a “new ASIC”? If it’s an eASIC Nextreme or Nextreme2, then it’s a predesigned field-of-LUTs device with a preconfigured routing fabric on the metal layers. The only unconfigured layer is the via 6 layer. Standard Nextreme wafers are processed to metal layer 6 and stored. When a design is sent in, the via 6 and metal 7 and 8 layers are added. Depending on how fast the part needs to be made, the via 6 layer is customized using either direct-write e-beam or a standard lithographic mask and then the standard metal 7 and 8 layers are added on top.

So, what do you get from this technology? You get a zero-NRE, FPGA-like device that has much higher silicon density than an FPGA because there are no switches or configuration RAM cells in the routing fabric—just fast, tiny layer-6 configuration vias. Consequently, you get a chip that can clock faster than an FPGA—250 MHz (typical) for a 90nm Nextreme New ASIC and 500 MHz (typical) for a 45nm Nextreme2 “new ASIC.” You get a device that operates at lower power than an FPGA and you get a device that offers more gates/chip at lower component costs (but not as low as for an ASIC/SOC). You also get a chip that’s easier to design than an ASIC/SOC and one that can be delivered in as little as 4 weeks. Design-tool cost is lower than for ASICs/SOCs as well because eASIC offers a specialized, Nextreme-specific version of Magma’s design tools for as little as $8k per seat.

What are Nextreme parts used for? I asked Jasbinder (Jazz) Bhoot, eASIC’s VP of Worldwide Marketing, that question. His answer was both interesting and a bit surprising:

• Cell phone microprojectors (where cost and power dissipation are critical)
• Other microprojectors
• Medical devices such as ultrasound imagers where power is not so much of a problem but device cooling is a big problem
• Portable medical devices that run on batteries
• Wired networking products where Nextreme parts are consolidating several FPGA designs into one chip with much lower power consumption

But processors just aren’t the right implementation solution for every design problem. Sometimes, it just has to be gates; Lots of them. There are two ways to generate gate-level designs. One way is to write an RTL description of the block by hand and then verify it through simulation. I discussed a way to fit such a block into a system-level simulation using Mentor’s Vista in a previous blog entry. Mentor’s Vista incorporates a model builder that will generate a TLM 2.0 functional description of an RTL block. Another way to generate gate-level block designs from a C or SystemC description is to synthesize the description and produce an RTL description.

Whether manually produced or synthesized, there’s a good chance that the resulting block will need some attention to squeeze excess power dissipation out of the design. Why? Because designers creating RTL descriptions often do not have the time to go back and make sure that all of a block’s clocks are gated off whenever possible and C or SystemC descriptions mostly omit any hints as to what portions of a block can be switched off during block operation, giving synthesis tools little to go on.

Enter Calypto and its SLEC (sequential logic equivalence checker) technology. I had an interesting discussion about SLEC and derivative products at DAC with Venkatram Krishnaswamy, Calypto’s VP of Applications Engineering and Solutions. The original idea behind SLEC was to formally verify equivalence between two block descriptions. Today, these block descriptions can be written in C, C++, SystemC, or RTL and SLEC can compare the blocks for equivalency. The original intent for creating SLEC was to find bugs but the resulting deep circuit analysis is useful for other tasks, like power reduction. The detailed sequential analysis technology developed for Calypto’s SLEC can deduce facts about that design that can help cut operating power.

SLEC can look at RTL blocks synthesized from C or SystemC and verify that a synthesized block is functionally equivalent to the original description. This is an important aspect of the product because C and SystemC descriptions are essentially untimed and therefore give synthesis tools many problems. Many C coders write C and SystemC code that’s not easily synthesized. Let’s face facts. It’s almost too easy to write hard-to-synthesize code in a language not originally intended to be synthesized. Calypto’s SLEC can detect the presence of synthesis impediments in the generated RTL and can help coders rewrite their source code with more detailed functional descriptions that help a synthesis tool generate better RTL. Think of SLEC as a second pair of mechanical eyes on the code that helps the code writer iterate on a C model that results in a better QOR (quality of results).

Detailed sequential analysis can deduce facts about that design that can help cut operating power and so Calypto has produced two additional tools based on sequential analysis that provide push-button power reduction for RTL blocks. The first such tool is called PowerPro CG, which inserts clock-gating enable logic into the RTL description based on an analysis of the RTL block’s sequential operation. This added RTL allows the logic-synthesis tool to more easily infer the required combinational clock gating. Gating clocks in sequential circuits cuts a block’s dynamic power consumption while raising static power consumption slightly due to increased gate count so there’s a balance to be struck. Of course a good block designer with sufficient time can analyze the block’s function and insert the clock-gating circuits manually. But who has the time? Typically, you find extensive clock gating only in highly leveraged blocks such as commercial processor IP cores.

Often, you need test vectors that exercise a block to ensure that you’ve caught all of the clock-gating opportunities. Although PowerPro CG isn’t perfect, Krishnaswamy estimated that PowerPro CG can find roughly 80% of the clock-gating opportunities without test vectors. If true, you know that most engineers will push the button and just take the 80%. Even though they might get most of the remaining 20% by writing a comprehensive test vector suite, well, “Who has the time?”

The other Calypto power-reduction tool is called PowerPro MG. It gates memories using similar analysis techniques. PowerPro MG exploits a “light-sleep” mode available in many of the latest static-memory IP cores available from vendors such as Virage Logic. The light-sleep mode, which is activated by a pin on the memory core, powers down the memory but retains memory state. PowerPro MG can take sleep and wake-up memory timing into consideration when determining the opportunities for exploiting light-sleep modes. Casual analysis of memory usage on SOCs will demonstrate that many memories are never put into a sleep mode, so there is much opportunity for power savings in this arena.

The power-simulation features of Mentor’s Vista are critically important because system architects have the biggest knobs when it comes to dialing in system power. That may seem counterintuitive to you because we’ve been relying on circuit-design tricks and IC process-technology improvements to deliver the bulk of the reductions in system power for years. However, as the following bar chart shows, the really large reductions are available at the highest level, the architectural level.

It’s at this level that the design team makes critical decisions about how to allocate tasks—whether to firmware running on processors or to direct-execution hardware engines. These decisions directly affect system clock rates and therefore operating power. It’s also at this level that the software team can make tweaks to the system software that also have a huge impact on operating power. Algorithm selection does affect power dissipation, although many software-development teams may not be aware of the link between algorithm and power.

The key to making high-level TLM models work in a power-predictive way is to include power estimates in the same model with the functional description of the transaction-level model. Mentor’s Vista packages a transaction-based power model, a functional model, and a timing model into one TLM model package so that simulations can use one, two, or all three model components during a simulation. Of course, the simulation speed varies depending on how many of the model components are active during a simulation. The following image shows how the models are packaged in a Vista TLM model.

Vista can use functional models that are hand-written in SystemC. Vista also incorporates a model builder that can read an RTL model and produce a TLM functional model. This is really a key feature for Mentor’s Vista because most designers are currently not running system-level simulations due to lack of models. The model builder in Mentor’s Vista is a way to create those needed models.

Using TLM models for power analysis results in power simulations that run an estimated 100x to 1000x faster than power simulations that use RTL or gate-level simulations. Of course, the power-consumption results of TLM simulations are only as good as the power estimates for each transaction but the same can be said for RTL and gate-level simulations, which are also based on estimates.

The big advantage of TLM-based power simulations is the simulation speed. If architectural-level design is really the doorway to control over system power, then fast simulation is the key to that door because it provides a way to rapidly explore the available design space in a way never before possible.