This technology might even allow existing opto-electronic devices to be reengineered to incorporate new functions and to achieve sensor densities not possible today.

An image showing light scattering from a silicon nanowire running diagonally from bottom left to top right. The brighter areas are bare silicon while the dimmer sections are coated with gold demonstrating how plasmonic cloaking reduces light scattering in the gold-coated sections. (Source: Stanford University)

Inside the science, a coating of reflective metal can actually make something less visible, the engineers have shown in an invisible, light-detecting device that can see without being seen. At the heart of the device are silicon nanowires covered by a thin cap of gold. By adjusting the ratio of metal to silicon — a technique the engineers refer to as tuning the geometries — they capitalize on favorable nanoscale physics in which the reflected light from the two materials cancel each other to make the device invisible.

Quantum Dots Allow Ultra-Efficient Light Transmission
Capable of ultra-efficient transmission of light, researchers are edging toward the creation of new optical technologies using nanostructured metamaterials with potential applications including advanced solar cells, light emitting diodes and quantum information processing more powerful than today’s computers.

The metamaterial is composed of layers of silver and titanium oxide and tiny components called quantum dots that dramatically change the properties of light, which then becomes hyperbolic and increases the output of light from the quantum dots.

“Altering the topology of the surface by using metamaterials provides a fundamentally new route to manipulating light,” said Evgenii Narimanov, a Purdue University associate professor of electrical and computer engineering.

The work was a collaboration of researchers from Queens and City Colleges of City University of New York (CUNY), Purdue University, and University of Alberta. The experimental study was led by the CUNY team, while the theoretical work was carried out at Purdue and Alberta.

These metamaterials could make it possible to use single photons – the tiny particles that make up light – for switching and routing in future computers. While using photons would dramatically speed up computers and telecommunications, conventional photonic devices cannot be miniaturized because the wavelength of light is too large to fit in tiny components needed for ICs.

This graphic depicts a new "nanostructured metamaterial" - layers of silver and titanium oxide and tiny components called quantum dots - to dramatically change the properties of light. Researchers are working to perfect the metamaterials, which might be capable of ultra-efficient transmission of light, with potential applications including advanced solar cells and quantum computing. (Source: CUNY)

Nanostructured metamaterials could make it possible to reduce the size of photons and the wavelength of light, allowing the creation of new types of nanophotonic devices.

The researchers said these discoveries could help them develop quantum information systems far more powerful than today’s computers by taking advantages of a phenomenon described by quantum theory called entanglement: instead of only the states of one and zero, there are many possible entangled quantum states in between.

–Ann Steffora Mutschler

Synopsys delivered solid financial results for its fiscal Q2. Revenue was $432.6 million compared with $393.7 million in the same period in 2011. Net income was $$21 million vs. $81.1 million last year. But factoring in the $30.2 million costs for the Magma acquisition this quarter, as well as a a one-time gain from an IRS tax settlement of $32.8 million last year—its net income was up about 6%.

Cadence won a deal with Nufront, which will use Cadence’s DDR memory interface IP in its mobile applications processor.

A new startup, SiCAD, came out of stealth mode. The company will focus on complete cloud-based design environments involving multiple EDA vendors’ tools.

SLD: What’s going on with SystemC behind the scenes?
Black: The SystemC working group is starting back up. Quite a few companies are interested in making it more compatible with modern platforms. There is also interest in UVM and other areas of coverage.
Meredith: There isn’t activity yet in the working groups, but people are starting to bring information to address coverage in verification. There is certainly an appetite for a UVM-like methodology inside the SystemC verification framework. That’s an area where we will see some activity in the future.
Sarkar: What people would like is better coverage, along with UVM.
Alsop: I’m on the committee at Intel that’s looking at high-level synthesis capabilities. New capabilities we want to see over the next year are things directed at HLS. Some of the verification methodologies we’re implementing in relationship to HLS involve better coverage. We’re working with EDA vendors on better constraint solvers and better random generators. We have a very vested interest in UVM and maybe we could create a UVM environment around SystemC, as well.

SLD: There have been rumblings about a SystemC verification group. Is it really happening?
Meredith: There was a SystemC working group in OSCI some years ago. The activity died down for a few years, but last fall there was a new call for membership. It is starting up again.

SLD: Any idea when something will come out of this group and what it might be?
Meredith: When is a crystal-ball question. But in terms of what’s going to come out of it, initially they’re looking at updating the existing library to work within the context of the new standard as a first obvious step. From there it could include better coverage.

SLD: We’ve all seen what happens when standards efforts go wrong. Will there be multi-language support out of SystemC.
Alsop: Intel, and even some of the other companies working with the UVM committee, really want to see multilingual support for SystemC. There are some behind-the-scenes efforts where we’re trying to get end users to look at the spec and what kind of infrastructure or framework we want to place around this. We’re still trying to get our hands around what the spec will look like. The good news about the merger between Accellera and the Open SystemC Initiative is that it will help a lot with collaboration across different committees. We’re not sure if this will enable work on a new subcommittee that will work on ML and bring in numbers and help from across different committees, or whether it will do this under one of the existing committees. But it is definitely one of the things being investigated.
Black: A lot of EDA companies have their own private interfaces across the boundaries. For example, with TLM 2.0 there are some proprietary implementations. It seems to me that the boundary between SystemC and System Verilog has to be crossed and standardized.
Meredith: Another area where the multilanguage issue is prevalent is in the analog space. With the Accellera systems initiative there is SystemC AMS and Verilog activity. There is definitely some movement, not toward a single language solution, but toward getting these languages to work together.
Sarkar: A similar problem to UPF/CPF came up with the coverage stuff. There are so many domains of coverage that there is a problem of how you deal with it in the first place, and then how do you get access to the data afterward. We have to define a common coverage data model and then choose an API. In this case, it may be C, which is the lowest common denominator. That approach may not work for everyone, though.

SLD: What’s the relationship between SystemC and UVM?
Alsop: I’ve had lots of discussions with vendors about this. The issue right now is there is no standard mechanism for interaction. One of the things we want to enable is IP re-use. That requires any connections—whether it’s TLM connections or other communication protocols across languages that need to happen—it has to happen in a standardized way. If you have IP that’s communicating with some other block, we want the industry to provide IP that already has the communications embedded into it. When you acquire IP you want it to just automatically start communicating with other IPs. So how does SystemC interact with UVM? Long-term we want to set up a framework that enables that.
Sarkar: The fact that we’re using TLM is a big step toward that. System Verilog now works with TLM and SystemC works with TLM. That means both communities need to come together and help out. That’s one area.
Alsop: We have different data types to support. How do you do that? What subset of TLM has evolved and how do you support it? That has to be dealt with.

SLD: There’s another standard out there called the Unified Coverage Interoperability Standard (UCIS). How does that fit into SystemC?
Sarkar: There needs to be something common across both. The good news is there are a lot of common goals. We don’t want to solve the problem two different ways and then try to bring it back together. We are coming up with a standard, and it has a very good start. But we have to be able to capture coverage and use it with the same content. That’s what this enables.
Meredith: Do you anticipate people building environments where some of the verification is done in System Verilog and some is done in SystemC and then you try to accumulate coverage across all of that?
Sarkar: Sometimes you don’t have a choice. Whether you want to do it in one environment or another, you have to deal with different methodologies when you’re talking about emulation or formal verification. But we have tools to make sure you are covered, regardless of which one you’re using.
Alsop: There are a lot of religious wars among designers. At Intel we see a growing use of SystemC. We think we’re still in the infancy here. SystemC has been around for a while for verification, but now designers are moving to a higher abstraction language. That’s still in its infancy. But once designers get hooked into a language and know how to use it, they stay with it. Then there’s also performance. When you’re trying to do certain things in System Verilog it’s slower than SystemC.
Black: There’s another effort going on. A lot of folks are interested in parallelization of SystemC. It’s a matter of distributing your simulation across machines, which is not a trivial task. It doesn’t matter whether it’s System Verilog or SystemC. Both languages need to do that. There are a lot of people talking about that right now.

SLD: What are the important trends in analog and RF simulation?
Subramanian: I see two big trends. One is related to physics, namely, the need to bring in physical effects early in the design process. The second trend relates to the increased importance of statistics in doing design work. Expertise in statistics is becoming a must. One of the strongest demands made on our company is to help teach engineers how to do statistical analysis. What is required is an appreciation of the Design-of-Experiments (DOE) approach—common in the manufacturing world. Design engineers need to understand what simulations are needed for analog versus digital designers. For example, in a typical pre-layout simulation, you may want to characterize a block with very high confidence. Further, you may also want to do that block extracted in post layout with very high confidence. But what does ‘high confidence’ mean? How do you know when you have enough confidence? If you have a normally distributed Gaussian variable, you may have to run 500 simulations to get a 95% probability of confidence in that result. Every simulation waveform and data point has a confidence band associated with it.
McConaghy: As always, there is always a pull from customers for simulators that are faster and better. In general, simulators have been delivering on this. Simulators are getting faster, both in simulation time for larger circuits, and by easier-to-use multi-core and multi-machine implementations. Simulators are also getting better. They converge on a broader range of circuits, handle larger circuits, and more cleanly support mixed-signal circuits.
There’s another trend: meta-simulation. This term describes tools that feel like using simulators from the perspective of the designer. Just like simulators, meta-simulators input netlists, and output scalar or vector measures. However, meta-simulators actually call circuit simulators in the loop. Meta-simulators are used for fast PVT analysis, fast high-sigma statistical analysis, intelligent Monte Carlo analysis and sensitivity analysis. They bring the value of simulation to a “meta” (higher) level. I believe we’ll see a lot more meta-simulation, as the simulators themselves get faster and the need for higher-level analysis grows.

SLD: This sounds a lot like the Six Sigma methodology, a manufacturing technique use to find and remove defects from high volume productions—like CMOS wafers. Will design engineers really be able to incorporate this statistical approach into their design simulations?
Subramanian: Tools can help engineers incorporate statistic methods into their works. But let’s talk about the need for high sigma values. To achieve high sigma, you need a good experiment and a very accurate simulator. If you have a good experiment but you want to run it quickly and give up accuracy, you may have a Six-Sigma setup, but a simulator that has been relaxed so the Six-Sigma data is meaningless. This shows the difference between accuracy and precision. You can have a very precise answer but it isn’t accurate.
To summarize: Today’s low-node processes have associated physical effects that only can be handled by statistical methods. These two trends mean that new types of simulation must be run. Engineers need to give more thought as to which corners should be covered in their design simulations. Semiconductor chip foundries provided corners that are slow, fast and typical, based upon the rise- and fall-times of flip-flops. How relevant is that for a voltage-controlled oscillator (VCO)? In fact, are there more analog specific corners? Yes, there are.

SLD: Statistical analysis, design-of-experiments, and corner modes—designers already hear many of these terms from the yield experts in the foundries. Should they now expect to hear it from the analog and RF simulator communities?
Subramanian: Designers must understand or have tools that help them deal with statistical processes. For example, how do you know if a VCO will yield well? It must have a frequency and voltage characteristics that are reliable over a range of conditions. But if you only test it over common digital corners, you may miss some important analog corners where the VCO performs poorly. A corner is simply a performance metric, such as output frequency. You want to measure it within a particular confidence level, which is where statistics are needed. It may turn out that, in addition to the digital corners you’ll need to include a few analog ones.
McConaghy: These terms imply the need to address variation, and designers do need to make sure that variation doesn’t kill their design. Variation causes engineers to overdesign, wasting circuit performance, power and area or under design, hitting yield failures. To take full advantage of a process node, designers need tools that allow them to achieve optimal performance and yield. Since variation is a big issue, it won’t be surprising if simulator companies start using these terms with designers. The best EDA tools handle variation, while allowing the engineer to efficiently focus on designing with familiar flows like corner-based design and familiar analyses like PVT and Monte Carlo. But now the corners must be truly accurate, i.e., PVT corners must cause the actual worst-case behavior, and Monte Carlo corners must bound circuit (not device) performances like “gain” at the three-sigma level or even six-sigma level. These PVT and Monte Carlo analyses must be extremely fast, handling thousands of PVT corners, or billions of Monte Carlo samples.

SLD: Would a typical digital corner be a transistor’s switching speed?
Subramanian: Yes. Foundries parameterized transistors to be slow, typical and fast in terms of performance. The actual transistor model parameters will vary around those three cases, e.g., a very fast transistor will have a fast rise and switching time. So far, the whole notion of corners has been driven by the digital guys. That is natural. But now, analog shows up at the party at the same time as digital, especially at 28nm geometries.
The minimal requirement today is that all designs must pass the digital corners. But for the analog circuits to yield, they must pass the digital and specific analog corners, i.e., they must also pass the condition and variations relevant to the performance of that analog device. How do you find out what those other corners are? Most designers don’t have time to run a billion simulations. That is why people need to start doing distribution analysis for analog corners like frequency, gain, signal-to-noise ratios, jitter, power supply rejection ratio, etc. For each of these analog circuit measurements, a distribution curve is created from which Six-Sigma data can be obtained. Will it always be a Gaussian curve? Perhaps not.

SLD: How will this increase in statistical distribution analysis affect traditional analog electronic circuit simulators like Spice?
Subramanian: Spice needs to start generating these statistically-based distribution curves. I think we are at the early days of that frontier where you can literally see yourself having a design cockpit where you can make statistics simple to use. You have to make it simple to use otherwise it won’t happen. I think that is the responsibility of the EDA industry.
McConaghy: The traditional simulators will be used more than ever, as the meta-simulators call upon them to do fast and efficient PVT and statistical variation analysis up to 6-sigma design. The meta-simulators incorporate intelligent sampling algorithms to cut down the number of simulations required compared to brute force analysis. Today, many customers use hundreds of traditional SPICE simulator licenses to do these variation analysis tasks. However, they would like to be able to get the accuracy of billions of Monte Carlo samples in only thousands of actual simulations. These analyses are being done on traditional analog/RF, mixed-signal designs as well as memory, standard cell library and other custom digital design.

SLD: I know that the several of the major EDA tool vendors have recently released tools to make the statistical nature of low process node yields more accessible and useable by digital chip designers. Are their similar tools for the world of analog mixed signal design?
Subramanian: Analog and RF designs are now going through this same process, to move from an art to a science. That’s why I say that the nanometer mixed-signal era is here (see figure). Simulation tools are needed, but so are analysis capabilities. This is why our simulation tools have become platforms for analysis. We support the major EDA simulators but add an analysis cockpit for designers.

Figure 1: Mixed-Signal and RF designs are now part of the nanometer SoC design process.

SLD: Why now? What is unique about the leading-edge 28nm process geometries? I’d have expected similar problem at a higher node, e.g., 65nm. Is it a yield issue?
Subramanian: Exactly. At 65nm, designers were still able to margin their designs sufficiently. But now the cost of the margin becomes more significant because you either pay for it with area or with power, which is really current. At 28nm, with SerDdes (high frequency and high performance) and tighter power budgets, the cost of the margin becomes too high. If you don’t do power-collapsing, then you won’t meet the power targets.

SLD: Is memory management becoming a bigger market for simulation?
Subramanian: Traditionally, memory has had some traditional analog pieces like charge pumps, sensitivity chains, etc. Now, in order to achieve higher and higher memory density, vendors are going to multi-level cells. This allows storage of 2, 4 or 8 bits on a single cell. But to achieve this density you need better voltage resolution between the different bit levels, which means you need more accurate simulation to measure the impact of noise. Noise can appear as a bit error when you have tighter voltage margins. You might wonder if this is really a significant problem. Consider Apple’s purchase of Anobit, a company that corrected those types of errors. If you can design better memory, then you can mitigate the need for error correction hardware and software. But to do that, you need more accurate analog simulation of memory. You cannot use a digital fast Spice tool, which uses a transistor table look-up model. Instead, you must use a transistor BSIM (Berkeley Short-channel IGFET Model) model.

To download this white paper, click here.

To download this white paper, click here.

First, it is important to define what a system-level model is, noted Frank Schirrmeister, group director of product marketing for system development in the system and software realization group at Cadence. “If a system-level model is defined as a TLM model or something even higher above then by virtue of its abstraction, it’s actually re-usable by definition so to speak. I always compare them to the gate-to-RTL jump. Is the RTL model re-usable? Absolutely, because we have automation underneath to remap it to several technologies. Is the TLM model/the system level model for, let’s say, your high-level synthesis input re-usable? Absolutely, it’s reusable for that particular implementation it does. And then, you have the automation around it to actually get the implementation done.”

Further, are these models reusable in general terms the higher up in levels of abstraction? From his perspective they are—they are reusable across different applications and different designs. Otherwise it wouldn’t be commercially feasible for system-level houses or EDA vendors to provide them, he argued.

However, Schirrmeister pointed out, “You need to be precise about what you re-use them for. If you go up from the RTL to the TLM level first, then these models are re-usable for sure when it comes to processor models because they are re-usable for every design that uses the processor model.”

But not so fast, said Drew Wingard, co-founder and chief technology officer at Sonics. “The place where the system models have the bigger challenge is in trying to imagine when I integrate these things together, how is it going to perform? And there we have some challenges.”

The challenges boil down to the fact that for most of these applications, the cost mandate requires that the cheapest DRAM system is used for the SoC. The SoC maker may want to sell its SoC for $10 while the DRAM cost was approximately $8, but if more expensive DRAM is needed it could bump the SoC price to $12. At that point the end user may say they are still willing to buy the SoC but are only willing to pay $7 for it.

“The real challenge of modeling the performance of DRAM with enough accuracy to predict is not the bailiwick of most of the system level modeling initiatives. The virtual platform models don’t give you any real concept of performance and certainly nothing near detailed enough,” he explained.

These cost pressures combined with design complexity is changing the perspective on how models should be used.

“The notion of having a seamless path from having a high-level model and synthesizing it to maybe VHDL/Verilog model and onto hardware—I don’t see it happening. It might still be an industry dream of a couple of people and it would help a lot. It would help proliferate virtual prototyping a lot and it would help proliferate platform architecture design a lot, but it just doesn’t seem feasible to really have that seamless flow,” asserted Tom De Schutter, senior product marketing manager for system-level solutions at Synopsys.

Instead of an implementation point of view, he believes the view on re-use of models currently is defined more on a use-case point of view.

Besides developing the use case for creating testbenches from models, De Schutter explained that work is being done on how can models be re-used across different types of use cases for different types of software developers, be it OS porting or middleware development onto more verification use cases of IP blocks or looking at it from a software performance and energy point of view.

“Because the software is becoming so important, maybe it’s not that important that the model has an implementation path as long it provides value across the lifecycle of the different stages of software and the different types of software—the value of the model establishes itself, as well,” he said.

Toward this end of making the models re-usable across different use case scenarios, it comes down to defining the different things that a model has to do to be useful for those use cases.

“In a lot of cases, the way we as an industry—customers and vendors—looked at it, there was always a notion that you need a lot of accuracy, you need a lot of timing for models to be useful and, of course, the more complex systems become the more that breaks,” De Schutter continued. This becomes clear particularly with the latest approaches to processor design such as ARM’s big.LITTLE approach. “If you look into those systems, just that specific subsystem has up to eight processors, and that’s not taking into account the rest of the system where the baseband, Bluetooth, WiFi, the power management system—everything has cores. So it’s becoming very hard to have very accurate models, and accuracy then defined as timing accuracy, and simulate them in a reasonable simulation speed.”

De Schutter said the current thinking is that the software itself doesn’t need timing accuracy or cycle accuracy to be developed or even optimized. “Again, looking at it from a different point of view rather than from a hardware point of view and an architecture design or an implementation point of view, we are starting to more and more look at it from a software point of view. How can this software help optimize the system? ARM big.LITTLE is actually a perfect example of this,” he added.

In closing, Wingard offered some harsh criticism for some approaches promoted by some vendors today. He believes the models some companies are providing to their customers are not accurate enough to do architectural sign-off exercises.

“While they might help the designer try to get to an intermediate design point, they’re still forcing the development team to go to an emulator to prove whether the architecture is viable or not. They have this additional problem that even if it works on the emulator, it doesn’t mean it will work on the layout of the chip…so that when they get into layout the floorplan changes associated with dealing with the actual layout constraints end up rippling back to their architecture and creating additional substantial performance problems that need to be re-architected. That generates an additional round of problems that basically force the customers to tape out sub-optimal solutions,” he concluded.

Right now, however, it’s a different story.

“As an industry, it’s pretty nascent for EDA applications,” observed Dave Desharnais, senior group director for product management in the silicon realization group at Cadence. “We ended up getting permission to use our tools in the cloud with constraints because there really was no formal way to do that in a third party cloud context. It’s really been large-scale companies that have been coming to us for about the last three years, on the tune of probably 10 to 12 a year, asking us because they are Cadence customers, ‘How do we use your tools in the cloud? We want to use your tools in the cloud.’

A frontrunner in this model, Cadence has offered its Hosted Design Solutions since 2007. It is a turnkey, private cloud offering born out of its design services. “It’s not a driver for our business but it’s certainly an option for a certain class of customers—mostly small and medium sized,” he said. With about 50 customers today, it has seen linear growth since the program began.

Desharnais is quick to point out, “This is really our entrance into the software as a service (SaaS) market because the customer owns the data but we want to provide that pathway in, all the compute resources, it’s turnkey and it’s beyond emulation, it’s everything: custom analog to digital ICs, all the physical and logic verification, emulation.”

Datacenter at Cadence Design Systems (Source: Cadence)

“It’s really no different from a business model in traditional EDA—you buy a license for a certain time. In this case you’d buy a set of licenses for a certain time with some bursting capabilities. That’s the SaaS model,” he said.

An even earlier player in the cloud arena is Sonics. Drew Wingard, co-founder and chief technology officer, said he feels like a grizzled veteran of this topic. He explained that way back in 2001, Sonics introduced a vehicle called SoCworks. Today it would be referred to as SoC- and IP-core-based design in the cloud.

“A challenge we were trying to address in those days, if you look at the basic business transaction model behind selecting IP cores to go onto an SoC, is that one of the big challenges is this horribly long dance that happens at the beginning before the customer can actually do the evaluation,” said Wingard. “It ends up being very messy, and in many cases it’s like six months to get through this process. The idea we had at the time was the reason for a lot of this protectiveness is around worries about the theft of the IP or worries about the pollution of the engineering, and that in the chip field we don’t worry about this as much because the chip that we distribute is pretty obscured. It’s buried inside a package, and you can’t really figure out what’s going on inside. The distributor can ship you a chip for evaluation purposes without all of this stuff. What if we could get to that same level of abstraction around IP cores?”

Sonics built a set of servers, in what would now be called the cloud, that ran the development environment that was part of its solutions. It still is, and it “allowed people to mix and match IP cores from who were then some of the major providers of IP cores—guys like MIPS and Tensilica, the inSilicon part of Synopsys—and actually plug and play them together around our interconnect fabrics, run some basic simulations so they could try before they had to go through all that legal stuff. We were way ahead of the curve on this clearly,” he added.

Mentor Graphics too is not new to the private cloud. Michael Buehler-Garcia, senior director of marketing for Calibre design solutions explained that as part of Calibre, there is a multi-thousand CPU farm in the floor of the building where the Calibre team is located, which is run as a private cloud to its different development teams around the world. “So are we doing cloud? Well, yes, and anybody who runs OPC accesses an SoC cloud because the size of designs requires multiple CPUs to run it.”

Datacenter at Mentor Graphics (Source: Mentor)

Today, the company expands its cloud play with its announcement (http://www.mentor.com/company/news/) of a cloud-based DFM Analysis Service based on the Calibre platform for TSMC 28nm and 40nm foundry customers, which analyzes the customer’s design database to meet the requirements for TSMC’s lithography process checking (LPC) flow. It delivers a results database containing hotspot locations and fixing hints that can be used by routers to perform corrections. Buehler-Garcia expects it to be attractive option for customers who tape out only a few advanced- node devices per year.

In addition, Synopsys has been offering verification-on-demand in the cloud for a few years.

IaaS Before SaaS
Before engineering teams embrace SaaS, Cadence’s Desharnais believes the infrastructure as a service (IaaS) model will take off as an interim step.

Interestingly, he said, customers are requesting permission to run Cadence software in the cloud…even if they don’t know what to do with it yet.

“What is shocking to me is very large sophisticated mobile telecom-type companies [like those] in the San Diego area—those guys aren’t doing it. Those guys are leading, bleeding edge, and they are the guys you would expect would have it. They want permission but they haven’t pulled the trigger on it yet because they are still trying to figure it out and how they are going to use it,” Desharnais continued.

“What I’m seeing the most, if you look at the semiconductor industry at large, it’s not so much a SaaS model, it’s more of an IaaS model. There’s a huge reluctance to put anything like an RTL on the Web or any sort of physical design that can be effectively pirated or moved so the security pieces scare them. As an EDA vendor, we’re actually not in a position to solve that. There are more systemic kind of things that are in the way. But we see companies taking a baby step in this direction, and this is where they are getting pressure from their CFO or their CIO or their CEO to start moving to more of an operational expense versus a capital expense model. And they say, ‘If we’re doing it for other things in our company (financials, HR) why not do it with EDA tools?’” he suggested.

In the long run, what probably makes the most sense is for EDA tools to be hosted by third party cloud providers such as Osmosix, Plunify and Xuropa, as opposed to private clouds hosted by the EDA vendors since customers won’t want a locked solution.

A newcomer to this scene is SiCAD, which comes out of stealth mode today. What’s different about this company is that it makes no tools of its own, but pulls together a cloud-based multivendor solution for a number of vendors’ products, including all of the Big 3 EDA companies and many point tools. As CEO Jai Iyer tells it, the key was to identify the pain points where utilization is extremely high but utilization over a year is low.

“The problem is that peak use for some of these tools last two to three months, and the rest of the time they’re sitting around idle,” said Iyer. “When you look at signoff tools for static timing analysis, extraction and DFM, they’ve all got low utilization and they’re expensive.”

It remains to be seen whether a multivendor complete solution will fare any better than previous attempts by established companies. At the end of the day, many will still argue that the business model is not working. But there are still those who believe that—at least someday—it will. The only question is when.

Customer IT Deployment Types (Source: Oracle)

A good way to think about virtualization is as an opportunistic use of available resources. Rather than waiting in a queue for a single processor core in a multicore SoC, for example, virtualization allows a compute task to take advantage of whatever processor is available if another is in use.

The concept is hardly a new one. Virtualization was invented by IBM in the late 1960s as a way of running batch processing while also still doing other work. But virtualization also creates a challenge for keeping caches in sync, which is why the concept of cache coherency was created. And as more cores are added into SoCs, rather than more processors within a single machine or on multiple machines, cache coherency has moved from mainframe to PC to processor and now across multiple processor cores.

What’s changing now is that these concepts are spreading well beyond just the processors. Virtualization is being applied to memory, storage, I/O and graphics processing units (GPU)s. But to make all of that work efficiently coherency will have to grow well beyond just the cache, and that may prove to be a very difficult problem, particularly in a multivendor ecosystem.

The starting point
Much of this shift has come into focus inside large data centers over the past decade as a way of reducing costs. In the 1990s, the availability of inexpensive blade servers and ever-increasing density made it possible to begin replacing expensive mainframes and minicomputers with off-the-shelf commodity machines. You could stuff them into a single cabinet and blast in chilled air to cool them sufficiently. Two things happened to change this equation. One is that the cost of electricity suddenly went up, because these cabinets were running hotter than ever before as density and current leakage increased. The second was that data centers had bought so many servers over a period of 15 years that just the cost of keeping them running was beginning to show up as seven-figure annual expenses for many large data centers.

Virtualization proved an effective way of reducing that cost because it allowed data centers to increase server utilization from an average of 5% to 15% utilization all the way up to 85% or more. That meant fewer servers overall, less electricity, less heat to remove, and far more available real estate. But with that problem now under control—at least for the moment—data center managers have shifted their attention to the exponential rise in the amount of data being stored. In the 1990s, most of the data was simply text or code. It is now a combination of text, video, data and voice, raising the same kinds of fiscal red flags about powering and cooling storage as servers prior to virtualization.

“What we’re seeing now is a move toward virtualized storage,” said Bob Pierce, flash business development group director at Cadence. “The next step is to merge storage and memory, which is why we’re seeing such strong interest in PCI Express. It’s a great transport vehicle. We’re also going to see back-end storage mixing with front-end storage data. What’s in between will be cache in the form of virtualized memory.”

This more fluid boundary between storage and cache has ramifications at all levels of design. It can affect everything from a processor to multiple processor cores on a single SoC, on multiple chips in a stacked die, and on multiple systems in a grid or mesh network.

“What’s happening is that you’re moving the back end closer to the processor,” said Pierce. “It changes the way big data and databases will be addressed in the future. If you have four CPUs, you can take them and, using PCI Express, prioritize them into a given drive sector and share them. That’s where all the VC startup money is these days. It’s the ability to configure servers for the function necessary at any given time. But you also have to virtualize storage and memory, and it has to be done dynamically.”

PCI Express has the dual advantage of adding a single protocol to keep all of this data coherent. While it’s useful to store and retrieve data quickly, it all has to be updated to reflect any changes that were made in any part of the system.

Adding other resources
Mixing storage and cache is fairly obvious, though. Less obvious is the mixing of processing between CPUs and GPUs.

“In the past, GPUs were directly assigned to a virtual machine (VM),” said Sumit Gupta, senior director of Tesla GPU Computing at Nvidia. “Every VM would get a full GPU, which meant that each server was limited by the number of GPUs it could hold.”

Nvidia’s new Kepler GPU architecture uses more cores—192 vs. 32—compared with its predecessors, and a significantly lower frequency of .175GHz compared with the old 1.35GHz. The result is faster processing with less power.

“We invented several technologies in order to virtualize the CPU, including an improved Memory Management Unit in the GPU,” he noted. “This is key because most of the data acted upon by the GPU comes from memory.”

But memory is being virtualized, as well, making this whole scheme even more complicated. Startup Memoir Systems, which touts its solution as algorithmic memory, is an intelligent virtualization scheme for almost any available memory in a system. And there are moves afoot to do the same for the multiple I/O feeds to improve the speed of downloads and uploads from a system.

Making it all work together
While virtualization all makes sense from a performance standpoint, complex systems aren’t just about performance. Coherency is a critical piece, and it’s an extremely difficult one.

“The reality is that I/O coherency has been around for a long time in the x86 world,” said Laurent Moll, CTO at Arteris (and formerly a systems architect at both Nvidia and Broadcom). “The next frontier is when you start adding in other devices, and there’s a big disruption when you’re adding full coherency between the CPU and other things. It’s easiest when you have a small team designing the cache and all the protocols. When you start plugging multiple things together it gets a lot harder. You need to be a lot clearer about the specification, the verification and the tests that need to be run.”

He said there are two key challenges in this scheme. One is simply getting it right, which is difficult for multiple companies using different teams and with different cultures. “It’s very easy to have corner cases that the guys who wrote the spec didn’t think about,” he said. The second challenge is that there is no known path to do this. Quite simply, it has never been done before.”

Conclusion
The upside of getting this right is a huge boost in performance. Being able to utilize more resources at any time can improve speed on almost every part of a chip or system, and virtualization plus coherency is a big win for the user.

The downside is that, assuming this can be done in the first place, it also could have an impact on power. The whole goal of most advanced SoC designs is to keep the majority of silicon dark except when it’s needed, and even then to run at maximum performance for a very short time to get everything done quickly. Having more resources to manage on an ad hoc basis solves the use model issue for performance, but it can create havoc on power management schemes.

In addition, it may require new software to even work in the first place. Cadence’s Pierce said some of this won’t even make sense on platforms such as Android until the multithreaded OS release called Ice Cream Sandwich becomes more prevalent.