The latest terminology to permeate the ranks of systems engineers and the makers of automation tools is, ‘What If.’

On the face of it, this concept is a progression from the old matrix model, which provided a set of possible interactions and variables. What it adds, however, is an extra layer of dependencies and interdependencies, a concept that was developed largely in the software development world. And then, of course, systems engineers add their own spin on it, building up complexities like hierarchies of function and how they relate to different power islands and various cores on a chip.

A good way to visualize this is to think of an SoC like a software stack. There are layers of abstraction that are hierarchically arranged, and then there are services that run up and down the entire stack. In the SoC world, though, you have to think of this as a 3D diagram, where you add those dependencies across cores and across functions. By the time you’re done, you’ve got a 3D model of an SoC with lots of services that work across the entire system and others that are localized.

This is basically the approach taken by these virtual models, without the brain-busting attempts to solve this all by hand. You can’t use a spreadsheet or a block diagram anymore because the possibilities are too numerous to figure out by hand and still get the final product to market on time.  You’ve got variations like, What if you did it this way versus another way? What would be the impact on terms of power, performance and area? And what if you sliced down the size and increased the density? Or what if you added another layer above all of this in a stacked die model?

Not all of these pieces are available today, but that’s the general direction. ‘What if’ is no longer just a discussion over a cup of coffee. It’s a critical part of the up-front design process, and an integral part of the design several steps down the line. It’s also part of the software development and the interface discussion. And increasingly it’s part of decisions involving the foundry and the manufacturability of the device.

Engineers have been asking ‘What If’ for years, of course. What’s changed is that the number of possibilities is now to great to figure out by hand.

What do you think? What pieces are still missing from the ‘What if’ modeling tools?

–Ed Sperling

The EDA world is either doing better than most segments of the economy or coming apart at the seams, depending upon your perspective and your definition of exactly what an EDA company is. But at least one trend seems clear: As we push into the world of system-level design from chip design and SoCs instead of ASICs, the high-level trend is broader companies with more complete integrated packages rather than lots of little pieces.

While this may cause all sorts of gyrations and lots of discomfort in the interim, the industry around system-level design tools ultimately will emerge significantly stronger if not overtly different. It has no choice. Either it begins eliminating pain for engineers developing incredibly complex chips or they’ll lose market share to companies like IBM and Toshiba, which already have their own proprietary tools, and the foundries, which easily could cobble together a suite of tools on their own.

To no small extent, Mentor Graphics and Synopsys are well along the path of creating much more integrated flows that reach well beyond the bounds of where they used to be. Cadence clearly sees the need to change, as well, which accounts for the board’s recent actions to boot all upper management—including longtime CTO Ted Vucurevich this week. He mysteriously has disappeared from the management roster, even though the company never announced his departure.

Cadence’s new CEO, Lip-Bu Tan, has more experience on the finance side than anyone since former CEO Ray Bingham, but he also has one other benefit. According to company insiders, he has very strong ties inside China, which Cadence’s board clearly sees as a growth opportunity.

Magma, meanwhile, has gone under a cloak of secrecy in recent months to develop its new strategy. Sources say the company is working on automating parts of the analog flow, but exactly what and how successful Magma will be in that space remains to be seen.

What happens to a number of startups along the way is another question. Our guess is that consolidation will begin in earnest when the economy hits bottom and begins climbing back from the depths of despair. The bigger question is where do the next startups get going. Silicon Valley will still be strong, but not all the VC money will end up there.

What do you think will happen next?

The easy stuff is over, not that anything was ever really easy in the semiconductor world. But getting the most from a chip in terms of lowering power and boosting performance will no longer be a function of the silicon alone.

Most software engineering has been done with existing languages and operating systems, but the well-known versions are aimed at general-purpose computing. They’re grossly inefficient for most tasks, and most of them are based on the need for regular communication between various components.

In the future, application code—not the operating system—will have to be written directly to the chip. That can be done in Verilog or some other language—with a superset of limited functionality built on top of that rather than underneath it. This is something along the lines of what Intel has started thinking about with its multicore development language, but even that relies heavily on hardware services that span a device and backward compatibility. The real gains in performance for the least amount of power will come from direct interaction with one or more cores for a very specific purpose.

Many engineers who developed chips for the military decades ago are familiar with this kind of hardware-software interaction, but it’s been largely absent from the industry because classical scaling on CMOS has made it possible to gain performance at every process node. That ended at 90nm, and short of a couple tricks such as moving from CMOS to SOI, straining silicon and adding more cores, the Moore’s Law roadmap will run out of steam. It still will be technologically possible to advance to future nodes, but the benefits in performance and lower power will disappear.

Radically changing software design could add a couple more nodes to the road map, as well as improve the performance and lower the power requirements of older process nodes. But it also will require significantly more complex modeling of the interactions of the software and the hardware rather than just making sure the software works with the hardware. Compatibility is only part of the problem. Efficiency in communication between hardware and software is the other piece, and that has never been fully developed.

In the ESL world, we will always live in interesting times. What remains to be seen is just how much of a curse this actually becomes.

Downturns have a way of changing things forever—sort of like the earthquake of 1812, which permanently re-routed the Mississippi River in three places. And while the common thinking is that things will go back to where they were before, they never do.

For one thing, the trend isn’t just smaller, faster, cheaper. It’s also shorter development cycles. Incredibly complex chips now take 12 to 18 months to design, verify and produce, versus three years a decade ago.

The only upside is that the basic designs sometimes last longer before they become completely obsolete. Moore’s Law is slipping, if it even applies at all. Trying to fit the formula into multicore chips and, in some cases, stacked die, is a stretch. And many companies have abandoned the Moore’s Law approach altogether, saying that older process nodes are sufficient for getting the job done.

Another change that is irreversible is globalization. There are more opportunities, more markets, and more trained people around the globe. The downside is more competition for skilled engineers at all levels—and that trend will only grow.  What used to be done in the United States, Europe or Japan can now be done using global teams.

The silver lining is that the cost of labor is less of a deciding factor. Global companies are paying the same wages around the globe for top talent. Instead of being reduced to the lowest common denominator, some companies are paying top dollar for engineers no matter where they are. IBM is a case in point. Experts say that will become more common over the next few years.

That also will fuel new market growth in some densely populated areas, such as India and China, where the opportunity for growth dwarfs the market for every piece of electronics that has ever been sold. 

In the system-level design space, where engineers live and breathe complexity, that also means the creation of new approaches and tools. While many companies still develop their own tools, best of breed is becoming a necessity rather than an option. And black-box strategies, such as TLM 2.0 and IP-XACT, will become necessary evils among engineers who were trained to understand every step of every action they take. And like the other irreversible trends, once these are tried and implemented there is no turning back.

Where are the weak links in the ESL ecosystem?

That question isn’t idle speculation. With complexity in many SoC designs reaching well beyond the level of human comprehension—even beyond the capabilities of the most brilliant engineers or architects—chip developers on all levels need to know what can go wrong from both a technology and a business standpoint.

No company can develop everything itself and still get to market on time and on budget. That means various pieces of IP are almost essential to build a chip. Sometimes that involves code, sometimes it’s a reference design. Understanding the capabilities of the IP vendors, not to mention their sustainability, is just as critical as understanding how to build a complex system.

In the chip world, this is the equivalent to a supply chain in the manufacturing world. In the consumer electronics market, in particular, this is a proven hazard. One well-known company, which shall remain nameless, is now trying to rebuild its reputation after outsourcing much of its development work. What it discovered, after thousands of customer complaints, was that its top contractors had subcontracted to other subcontractors, and from there it was further subcontracted. It looked like some derivatives scheme, and by the time the pieces were assembled they discovered some problems—but not before the products ended up in the hands of consumers. The seller’s reputation suffered. It’s still suffering, in fact, several  years later.

Ecosystems are like supply chains. They can be customized, depending upon the parts that are needed. And they can cause problems if all the parts don’t adhere to the same standards, or if they were developed with different languages or tools, and if the project specs aren’t tightly defined.

Products are only as good as the pieces used to create them, but if anything goes wrong the entire ecosystem suffers. Understanding the potential pitfalls used to be relatively simple when everything was built under one roof. It’s a lot harder, and requires a lot of extra up-front planning on the front end and testing on the back end, to make up for the loss of in-house oversight.