Archive for October, 2010

Who Does What

Friday, October 29th, 2010

Software has moved from an afterthought to a top priority for chip designers, which is why all of the Big 3 companies are focusing a huge amount of effort in this area.

Cadence’s whole EDA360 initiative is focused on software driving the hardware rather than the other way around. Mentor Graphics has one of the most popular RTOSes in the history of software. And Synopsys has moved rather quickly into software prototyping and standard IP.

To some extent, these moves are a recognition that the ASIC market will be flat to down over the next couple years because the number of companies that can afford to build chips at 28nm and 22nm is shrinking at each node. That will change once 3D stacking gets underway commercially, probably late next year and into 2012. But when that change occurs, the focus will be more on re-use and integration than building a new chip from scratch. When that happens, the really big opportunity that will open up will be on the software side.

In lock step with that shift is an understanding that the way to really improve power consumption in devices is to make the interaction between hardware and software more efficient. Power permeates all these changes because it saves money in plugged-in environments and it affects the user experience in the portable electronics world. Software is the place where the biggest gains can be made in power consumption. And because hardware and EDA companies are the only ones that really understand how to improve efficiency—at least for now—the push to control a greater piece of the software stack will take on new urgency.

This will play out over the next couple of years as tools companies and their customers jockey for position on how to differentiate themselves from the competition—and to eke more value out of what they do. But there are two big questions that remain unanswered. One is the extent to which software will be designed specifically for hardware, which has been done largely through operating systems in the past, or whether the hardware increasingly will be designed for the software. The second question is who exactly will be doing this work. Will it be the application vendors, the operating system vendors, the virtualization layer vendors or the hardware and tools companies?

In every transition there are lots of pieces that can come together in unusual ways, and this transition is no exception.

–Ed Sperling

A Question Of Balance

Friday, October 15th, 2010

Saving power with software seems like the next logical step, but finding a middle ground to make that happen may prove to be a tough balancing act.

Hardware has come a long way toward saving power with a variety of techniques, and it will continue pushing for additional power savings. But the real savings will have to come from the software side because most of the low-hanging fruit has already been picked on the hardware side.

The problem is that most software developers have never considered the impact of their efforts at any level—whether it’s embedded software, middleware, operating systems or applications. For software engineers it’s all about speed and functionality, not to mention things like backward compatibility and interactions that hardware engineers never have to consider. And while operating system vendors have begun streamlining their software, the further the code moves away from the hardware the less of a consideration power actually is.

Even at the embedded level power is often an afterthought rather than part of the power budget consideration. As Glenn Perry, general manager of Mentor Graphics’ Embedded Software Division, put it: “Embedded software development can wipe out 30 years of hardware development (in power savings) with one line of code.”

The trick will be finding people who can manage teams of engineers with widely diverging priorities and getting both sides to understand each other’s needs. It also will require far more data than ever before about the power consumption of both IP and software in the context of the environment in which it will be placed. And more than likely, it will require much more up-front modeling by teams of hardware and software engineers rather than just one or the other.

If power is really to be dealt with effectively, it will require a change in the way most design teams work at the most fundamental level. The bad news is we have barely scratched the surface. That’s also the good news, because it means there’s huge savings possible even at future nodes.

–Ed Sperling

Power Play

Thursday, October 7th, 2010

EDA vendors like to call it simplifying complex technology. End customers call it “dumbing down” the tools.

At least part of the difference in language has to do with perceived value, and what the customers are willing to pay. But an interesting middle ground is forming in this tug of war, and much of it centers on low power.

Because power is a global issue, it affects everything from front-end design to back-end manufacturing processes, the packaging of an SoC, how it works on a board, the I/O and the IP—as well as verification, place and route, synthesis and modeling. While performance will remain important—it’s expected to increase at each new process node—it’s less important in most cases than staying within a power budget.

Add in a bunch of new functions onto a single SoC and it becomes harder to keep within that budget, particularly while maintaining quality and signal integrity. Stack multiple chips together and it becomes harder still. Use cheap packages, bulk CMOS and commercial off-the-shelf IP and it gets even harder.

The solution, however, may be as complex as the problems that are being created, and it may require some significant prioritization that is set not just by the EDA vendors and their customers, but by everyone working together. While there has been discussion about ‘good’ vs. ‘good enough’ in chips, the same discussion now needs to be applied across EDA. Some tools may be good, some tools may be good enough, and rather than continuing to create new revs of existing tools R&D budgets might be utilized far more effectively if they are applied to longer-range issues while minimizing changes in some of the existing technology.

In the past this kind of work generally was done through acquisition. Point tools made by startups became part of the overall design flow. But the problems now have exceeded the capabilities of startup budgets while the funding for startups in EDA has largely dried up. As a result, there isn’t much to buy. Moreover, the problems that need to be addressed are far beyond the scope of any single startup—and possibly even the largest EDA vendors.

Just as companies have created ecosystems for manufacturing processes, they now have to create them for automating some of the most time-consuming and troublesome tasks. These are expensive efforts because they are also expansive and extremely complex. But if semiconductor companies ever hope to get out of the ugly cycle of doing more for the same price without impacting their margins, they’re going to have to put some money back into the EDA industry that supports them.

Likewise, EDA companies are going to have to work more closely with their customers and potentially their rivals to develop new tools, new techniques, and new value that extends well beyond the comfort zone they have put in place over the past 10 years. There are plenty of adjacent markets to tackle, but the primary ones—those already shaken by a growing list of power-related issues—are in need of some serious attention.

–Ed Sperling

Little Things Matter More

Friday, October 1st, 2010

The idea of smaller, faster and cheaper has become so synonymous with progress in the semiconductor world that most people really never stop to consider how that concept is changing.

There has been a lull in the demand for performance, but it’s about to get much more attention as device manufacturers look for ways to drive demand for their products. Streaming video is one such change—including streaming 3D—and that will ratchet up the demands for performance like never before.

This isn’t business as usual in the semiconductor world, either. With classical scaling gone several nodes ago, it has been assumed that an acceptable tradeoff is performance for power—the same performance for longer battery life. Voice and text perform adequately with current processor performance, and people are used to waiting for downloads. But with streaming that becomes a much bigger issue. Wait time interrupts the flow. That makes a device frustrating to use, which in turn impacts consumer demand.

At the most advanced nodes, though, there is no single approach that solves the power issues. Power islands and clock gating certainly help. If you can power down large portions of a device you can save lots of battery life. But it won’t solve the problem of streaming because the biggest power drain in a device is the screen. With streaming, the screen is perpetually on. With 3D, it’s being used even more intensively.

The solution ultimately will be even more granularity in advanced designs. We will need to understand how software impacts power. Applications development will need to be in lock-step with hardware from a power perspective. Instead of figuring out what resources are available to run what features they will have to understand what features can be offered at the lowest power consumption. Blasphemous as it may sound, some features may have to be cut.

There also will need to be a better understanding of how turning on and off sectors and modifying the signal path will affect everything from thermals and signal integrity to single-event upsets caused by electrostatic discharge and even some types of radiation. The types of memory used can affect speed, but they also can affect reliability. And all of this has to be balanced against business issues involving cost.

There is no longer a single thing that can be tweaked to solve all of these issues. There are many of them, and they all have to be solved concurrently rather than sequentially. This is easier said than done, of course, because the human brain is very effective at sequential problem solving but not at parallel problem solving. Nevertheless, this is the next big challenge in semiconductor engineering—lots of little pieces working together better. And lots of companies working more closely together to make this happen.

–Ed Sperling