Steve Leibson

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.

What do Superman, ASIC and SOC Design, and Newport Beach have in common?

Hi.

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

Drop-in Synopsys’ DesignWare minPower IP components and cut ASIC power

Last week, I listened to a Webinar by Synopsys’ Jay Chiang on the DesignWare minPower IP components that the company introduced at this year’s DAC. Chiang did an excellent job and made a compelling case for using these IP components. Bottom line: some early users of DesignWare minPower IP components report as much as a 48% power savings at the block level and as much as a 24% power savings at the chip level. Those reported results should be significant enough to make every ASIC/SOC design team sit up and take notice although be cautioned, your mileage may vary (YMMV). (An archived version of the Webinar can be viewed here.)

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.

Could A Low-Power Middle Ground Between ASICs/SOCs and FPGAs Help You?

You can’t always get what you want,
But if you try sometime,
You’ll find,
You get what you need.

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

Squeezing Excess Power Out of Synthesized Blocks

With the glacial-like industry move towards transaction-level simulation using OSCI’s TLM 2.0, I think that C and SystemC will be used more and more for the initial descriptions of large portions of many systems. Many system blocks will therefore end up as compiled software (or firmware) running on standard-architecture processors and application-specific processors because it’s just easier to compile such descriptions and run them on processors. C and SystemC are sequential languages and they just beg to be implemented as firmware running on a processor.

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.

System-level design provides maximum control over power

Yesterday morning at DAC, Mentor Graphics rolled out a system-design tool called Vista (I guess Microsoft isn’t using that name any more). Mentor’s Vista is based on the OSCI TML 2.0 transaction-level modeling standard, which Mentor has adopted as a simulation platform. Mentor’s Vista allows system designers to perform design-space exploration and power analysis and it allows the software-development team to run and debug code on a virtual prototype.

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.

DAC’s Free Monday Returns to San Francisco. Apply Now. DAC’s in Three Weeks.

John Cooley’s DeepChip email this morning reports that EDAC, the consortium of EDA vendors, has decided to underwrite the long-time tradition of Free Monday at DAC which is coming up on July 27-less than three weeks from now. DAC’s at San Francisco’s Moscone Center this year, so it’s accessible to all of Silicon Valley with a short car, bus, or train ride.

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