• 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.

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.

If you want to take advantage of “Free Monday” DAC registration, go to http://www.deepchip.com/FreeMonday.html. Complete all four registration pages. On the third page of the online registration form, you’ll find a newly added “Free Monday Exhibits” option. You must check this box to get free registration for Monday. The fourth page of the form will show a web receipt with their unique bar-code confirmation on it. You must print this entire page and bring it to DAC on Monday, July 27, where you’ll present the bar-code page to the Advance Registration desk located in Moscone Center’s North Lobby.

Coincidentally, I’m on a Pavilion Panel at 1 pm on what’s now Free Monday at DAC. I’m joining EDA luminary Jim Hogan, Stanford’s Per Enge, and Sonics’ Grant Pierce. We’re discussing the long road to system-level signoff. Hope to see you there because there’s no better way to wring power out of a system design than at the architectural level. Meanwhile, here’s an excerpt from a system-level design manifesto written by Hogan and Peter Levin:

“…we’re stubbornly bullish on the idea that abstraction is always, with no exception, the key to utility and productivity.  Because of the tremendous advances in – and therefore commoditization of – semiconductor manufacturing the value of complex devices, especially SoCs, is utterly dependent upon the ability to specify well, implement quickly, test for fidelity, and validate for function.  Of course, like the engine under the hood of a car, hardware matters; it can add to or detract from the user experience.  On the other hand, how many of us know or care about the brand of the motor. Most drivers take such things for granted, as long as their propulsion needs – expressed in (high level) terms of fuel economy, power and performance – are well satisfied. It is no accident that SoC design feels very similar to systems design, especially as software content becomes the primary factor of differentiation and scalability.

But don’t expect the polygon pushers to reach high into the system any more than you would expect an assembly programmer to build the advanced apps in a smart phone. Too expensive, too slow, too restrictive. When the wise men come, they will know two things:  how to integrate the components of design implementation in a way that obfuscates the details, and how to use abstraction to their benefit.  And they won’t call it ESL; however they may call it virtualization, just as they do today in the IT industry.

In fact, our customers are already years ahead of the tools they buy.  Sure, they care about compactness, manufacturability, and power.  But the real battleground – at least between them – is the truly differentiated trade-space between device integrity (does it do what I want it to do?), reliability (will it perform well, long, and under duress?), and security (am I assured of my privacy, and protection against nefarious intrusion?).

The promise of ‘system level’ anything – we’re going to propose a more ambitious new name in a second – is to break down the parochial boundaries that separate abstraction layers like so much cruddy varnish, and instead integrate them under in a common methodology and view.  This hypothetical tool – none exists yet but we’re unshakably optimistic – would truly facilitate architectural exploration without the constraining ties to hardware targets, bastardized (or proprietary) language, and prohibitive cost of migrating from simulation to emulation, and emulation to target platform.  Moreover, and crucially, it has to conveniently and sensibly accommodate the application software that differentiates our customers’ products in the market.  With possibly one large exception, this is basically how they make their profits.  In other words, it is a pre-requisite, and a recipe, for the holy grail of scale.”