By Ann Steffora Mutschler
Virtual prototyping conjures either confusion or relief, so it should come as no surprise that some chip designers are still confused about the different types of prototypes on the market.

“Virtual prototyping is going through a change right now,” explained Gary Smith, founder and chief analyst for Gary Smith EDA. “Today, users are using cycle-based tools to prototype sections of their design (if it is a big design). The hardware guys are the ones using it right now. They are trying to get it to move up to pass off to the software guys for co-development, but it’s still a little expensive for that [because of the cost of FPGAs].

Smith identifies the three types of virtual prototypes as: the architectural prototype at the behavioral level, along with the silicon virtual prototype and the software virtual prototype at the architectural level.

Some of the leading semiconductor companies have been leveraging virtual prototyping for many years.

“It’s a long story for us,” said Jean-Marc Chateau, director of system platforms and tools at STMicroelectronics. “It started before 2000 in terms of R&D, trying to bring forward technologies for hardware software co-design to be faster on the market with SoCs. At that time it was in the central R&D organization with Philippe Magarshack. The team has been very active in the standardization of SystemC driving this effort and being chairman of the board of the initiative. We have really been working from the beginning of SystemC, and in the SPIRIT initiative we have been involved and have been pushing the new standard forward. We are still pushing, by the way. SPIRIT is now in Accellera and we are still very active both on the board and in the working groups.”

ST used transactional modeling first for verification of SoCs rather than for software development. Chateau noted that ST’s big success with virtual prototyping was in verification because the random methodology being used was really tough for very complex systems. “We have used it for sure for IPs, but for big subsystems we have moved quickly to directed test in transactional mode.”

The company’s use of the technology has increased since 2005. Before then, it was more in trials, R&D and pilot projects. “In 2005, we started a phase of using transactional models for IPs and SoCs,. bringing multiple verification platforms for the same SoC to verify subsystems one by one in specific environments. We started to build the library in TLM of all of our IP, starting with consumer and moving to mobile telecom. We have accumulated both generic and dedicated IP that were written in TLM for verification purposes as a golden reference to be compared with RTL that is first emulated—in most cases—on big machines from Cadence and Mentor. We have used a lot of emulation and co-simulation with TLM in order to verify the RTL or the IP in the system environment, or at least a system that is relevant to the IP. That has been the big driving force of our effort in ESL.”

With two populations to serve—the architects who perform investigation, and software developers for the rest of software development—ST currently is developing a virtual platform for software development. Chateau explained that his team of 44 dedicated people started with drivers of the IP blocks, then moved one level up. It is now working at the application level on the virtual platform. “But still it is not 100% today. We are not yet at a level where we fully deliver the complete industrial software package based on the virtual platform,” he said.

What they do instead is half on a board and half when silicon is there, more or less, and this is true for all consumer products: TVs, set-top boxes, monitors, and mobile phones for ST-Ericsson. The team that Chateau leads is guiding both ST and ST-Ericsson on ESL and is dedicated to ESL support and development.

As there were no tools of this sort available in the beginning, ST developed its own framework based on open standards and open source. “We have put in open source a basic model library. We are in a phase where we think to put more on open source to enlarge the standards to certain gaps that prevent in the OSCI TLM-2.0 standard; there are some ambiguities,” he said.

Ambiguity in TLM, IP-XACT standards is hampering interoperability
Chateau’s bone to pick with TLM and IP-XACT is the same: both are too ambiguous. They need extensions to be really interoperable between models, tools or various sources. “As we are building SoCs with many IPs from third parties changing from one company to another, or like us with ST-Ericsson, and with mergers and acquisitions everywhere, if we are mixing IPs then we really need this interoperability. Today it is jeopardized by the fact that you need to do your own interpretation of the standard to fill the gap.”

“If we let it go for one year or more it will be a disaster because the big companies will de facto the standard. And if you are not married to them I see a risk that you cannot mix with anything that is not with that proprietary standard. There is really a danger that something that was open source from the beginning will be closed because the lack of extension. It may kill the way we work today if we are not fast enough on the extension,” he added.

Along those lines, Mike Gianfagna, VP of marketing at Atrenta noted that quality, implementation-ready RTL is important, but a bigger problem today is not really designing original RTL. It’s more about integrating existing IP blocks. “We look at most of our customers and, roughly speaking, our view is that over 80% of every SoC that starts today is already pre-ordained with predefined building blocks—either legacy blocks or third party blocks. It used to be whoever designed the most novel circuit first wins. Today, it is whoever figures out what blocks to integrate first wins.”

On a larger scale, he has observed that one of the fundamental challenges in the virtual prototyping space is the interface between hardware virtual prototype and the software virtual prototype.

“Those two worlds are reasonably well-defined, but the way they interact with each other is not well-defined so that’s the opportunity. What’s the interface between the hardware architecture and the software model associated with that hardware architecture? And do you make that interface robust enough so that you can change things on one side of the interface and then see how they affect the other side? There’s a lot of work to do there in that data handoff, representing things like the register map, the interconnections and how you profile performance at the software level that are meaningful for the hardware. There are a lot of connections to be made between the software and hardware virtual prototypes,” Gianfagna said.

Getting the balance right
Based on his experience at ST, in order to properly implement virtual prototyping, Chateau advised a single SoC development plan. “You cannot have a software plan and a hardware plan. You need to have one plan considering the speed at which the development will be done on the hardware virtual model to be able to develop the software. The most critical problem is that you have three categories of customers for the virtual platform. Verification was the driving force for us. For other companies it will be early software development and for others it may be tools for architects to do what-if analysis and investigate the whole architecture approach.”

The constraints of those three populations are quite different. For the architecture they need a cycle-accurate approach. With software they may not care if it is cycle accurate, but they do want a quick simulation that works. With verification, they don’t need cycle accuracy at the beginning but at the end they will need to replace that RTL. There needs to be a flow down to the lowest level, Chateau explained.

“Those constraints are quite different and you cannot find a perfect model that matches all of them, so you need to accept a compromise,” he said. “You also have the need to synthesize with the high-level synthesis tool more and more IPs to go faster. The level of accuracy of those models is quite large, so therefore it is another level of abstraction. There is no magic compromise. You cannot afford in any company to have three types of models–or even four if you want to do high-level synthesis. You will do only one and maybe try to generate the one that will be before synthesis, but you can do only one. Even one is quite constrained to have enough resources to do it on time, much before silicon. You have to think about this compromise at the beginning and not focus on only one customer type because if you do it for only software development, it may not be useful in verification. Therefore in verification you will have low productivity, the same for architecture and so forth. You need to find the right compromise at the beginning when you introduce these kinds of techniques.”

By Ed Sperling
One size no longer fits all, and that’s causing consternation across the supply chain from established EDA vendors to point tool developers all the way up to the largest chipmakers.

While the overall number of design starts for SoCs really hasn’t changed much, despite a drop in the number of companies working at the most advanced process nodes, what has changed significantly is how companies are getting chips out the door, what process node they’re using and how they view the future of design. And for EDA companies, which get the biggest return on investment when they can build tools that automate processes and tasks for the multitude of engineers rather than just a few, this puts them into a quandary. Do they develop tools for the few that are willing to pay for automating some of the complexity at advanced designs, or do they look at alternative approaches.

The answer for the Big Three—Mentor Graphics, Synopsys and Cadence—has been to cater to the most advanced customers while also spreading into adjacent markets for incremental growth. The question for them is whether the adjacent markets will provide enough growth to warrant the investment.

For point-tool makers, the question is what kinds of problems need to be solved and who’s willing to pay for a solution. And at the most advanced process nodes, the question among chipmakers is whether they’ll be forced to develop their own tools at greatly added cost, whether the tools will be available from commercial vendors as regularly as in the past, or whether they can get buy with existing tools from older nodes.

Cause and effect
At the most fundamental level, there is a schism in the design community between those looking to reach the most advanced node—those who make memory chips, smart phone SoCs, GPUs and CPUs—and those who can live with improvements at older nodes ranging from 130nm to 180nm where tweaks can improve performance and/or lower power consumption.

One of the best real-world measurements of this trend is in the standard IP sold by companies like Synopsys and Virage Logic. John Koeter, vice president of marketing for Synopsys’ IP and Systems, said the number of SoCs with one or more processors is staying constant at about 3,500 design starts and expected to increase to 3,700 in the next few years.

“From a raw number standpoint, the TAM (total available market) is the same or growing,” said Koeter. “But what’s also going on is people are staying longer at any process node. We track 1,000 to 1,500 IP requests, and of those about 43% of the demand is at 65nm and 35% is at 45nm.”

So what about the other 22%? “As an IP provider, we’re being asked to re-optimize IP at older nodes,” he said. “In some cases it’s how you enable a lower-cost system. We’re seeing a lot of demand at 110nm and 130nm in Asia/Pacific for devices fitted with the latest standards like USB 3.0 for low-cost applications.”

Hedging bets
Evidence of this change is everywhere in EDA these days. All of the Big Three are pushing into adjacent markets. Mentor’s push into DFM with Calibre is paying off big for the company, despite the fact that when the company began going down that path it was greeted with widespread skepticism. Mentor also has pushed into other areas such as mechanical analysis and more recently PCB design.

Synopsys, meanwhile, has focused on IP and software prototyping, so that software can be developed in conjunction with the hardware. The moves are more in line with Synopsys’ overall flow, but its push into power analysis with Eclypse and more recently into high-level synthesis and FPGA tools are a step outside the company’s traditional borders.

Cadence, in contrast, has pushed heavily into a software-first approach with its EDA 360, an idea that has been circulated around EDA for years but which is being taken seriously now in part because of the complexity and cost of developing chips at advanced nodes. The company also just announced plans to buy Denali, which makes modeling IP.

“About 70% of a chip is re-use,” said Vishal Kapoor, vice president of product management at Cadence. “The challenge is integration. So far we’ve made sure it is compliant, but what we need to develop are tools that are built with a focus that ranges from creation to integration. And then we have to make it so it can be integrated into an SoC.”

Kapoor said IP is what’s expected from EDA vendors. But he said the rest of the world is software-driven, with the application being the most important. “If the hardware guys do not present differentiated pieces of hardware we will see commoditization of the hardware. The consumerization trend is forcing us to think about getting the most out of hardware.”

But even IP vendors aren’t just IP vendors anymore. Virage Logic, which started out making logic and memory IP, is now extending into other areas of the design such as built-in test.

“It’s not architecture first and then the system,” said Yervant Zorian, Virage’s chief scientist. “It’s building blocks coming together. In the past it was build everything together and then think about testing. It’s not an add-on. It’s now an integrated part of the smallest units that you’re building.” He noted this approach first began with memory more than a decade ago, but it is now being implemented into almost everything.

Thinking in 3D and other technologies
Perhaps the biggest changes will come by way of packaging and three-dimensional design. That will allow chipmakers to keep some of the old design, particularly the analog blocks, while leveraging the digital components that do benefit from Moore’s Law. Analog has never fit into that equation.

“What we’re seeing is the impact of system in package,” said Gary Smith, president of Gary Smith EDA. “You lag on analog and try to keep up in digital. What’s interesting is we probably have all the technology you need to switch already. In 3D, we’ve got most of the problems already solved. The next step is to get the cost out with volume.”

One of the interesting things about 3D technology is it allows companies to focus on a smaller piece of the overall development and to utilize the most advanced process nodes in addition to less advanced ones. That drives down the cost of development significantly and brings companies that have abandoned Moore’s Law because of cost back into the two-year digital process cycle. Processors and certain types of memory can still progress to the next node while analog and I/O may persist at older nodes for years and still gain performance and power consumption benefits through shorter wires and through-silicon vias.

Smith says 10% to 20% of the chip still needs to be created each time a new chip is introduced to remain competitive, but even if that number remains constant some of that development may be on the analog rather than the digital side. It also may be the software, or it could be the hardware optimized for the software or the software optimized for the hardware. Or it could be a faster I/O channel and a virtualized chip environment.

Smith, for one, believes the big innovations will be in packaging and stacking. He also believes that CMOS as we know it will run out of steam over the next few process nodes, and that what will make other substrate materials more cost-effective will be the same volume production that has kept Moore’s Law viable since it was first introduced in 1965.

FPGAs have taken an early lead in this arena. Actel’s SmartFusion platform includes programmable analog with an FPGA. Xilinx reportedly is working on its own version of programmable analog blocks.

Conclusion
While it’s too early to tell which approach is the right one or exactly what path will prove most profitable for developing chips, IP and ultimately software, it is clear that a transition is under way. And while transitions are always interesting to watch, they also produce fallout in the way of winners and losers—and potentially new competitors.

By Brian Fuller
It’s been more than a decade since electronic system level (ESL) abstraction started to gain traction in EDA. It’s been more than a few years since the industry began to plan for the day when the benefits of embracing C-language approaches to design description and validation would find designers churning out massively complex and profitable designs while sitting in lawn chairs sipping drinks with little pink umbrellas in them.

What happened?

Well, it’s still with us, but no one’s broken out the lawn chairs just yet.

ESL in general, and SystemC at the transaction level in particular, still hold promise—and have had tongues wagging for years—because of the design-efficiency gains that should accrue to the industry. Describing and verifying at a higher abstraction level a project of mind-boggling complexity that’s slated to cost tens of millions of dollars has got to save time and energy, right? Embracing C-language approaches to design would make hardware design as simple and carefree as software design, right?

Not so fast, notes Jon McDonald, technical marketing engineer for the design and creation business unit at Mentor Graphics. In February, he opined:

“For those of you who were around for the last big design shift—from schematics to RTL—you may remember hearing these kinds of statements back then. Managers believed or were sold the story that hardware design was going to be more like software as design moved to RTL. Back then there were a number of projects that tried to have software programmers writing the RTL code. What I remember most are some spectacular failures, primarily because the people writing the RTL did not understand the hardware implications of the choices they were making.”

Longtime industry analyst Gary Smith of Gary Smith EDA notes that while ESL in general caught fire in 2004, increased adoption has come at a sober pace.

“Our survey that year showed significant use of ESL, albeit often with in-house, proprietary C/C++ tools,” Smith said at DVCon. “Our survey two years later showed that, of the engineers who could be expected to benefit from the use of ESL methodologies, about 4% were actually using it. This year, it’s about 5%. Remember that the shift to RTL took about eight years. If ESL pans out the same way, it should be done by 2012.”

Where’s the beef?
If time to market is more critical than ever and design productivity crucial to the very survival of some companies, shouldn’t we be seeing proof of productivity gains through higher abstraction approaches to design?

It could be, as Smith noted, that it’s still early. It also could be a cultural-transition issue. Wholesale change comes slowly to most industries, even ones as creative and electronics. And it’s a complex world.

“SystemC and transaction-level modeling takes its place in what is now a multi-language world and a very complex flow involving modeling issues and then design issues and verification,” said John Aynsley, CTO of Doulos, in a recent presentation.

One school of thought argues past is prologue. Steven Brown, blogging at Cadence, suggested that the history of RTL adoption—which has been a design automation workhorse for three decades now—suggests the next abstraction to System C transaction-level modeling will boost productivity. He illustrates the historic improvement in productivity as an improvement in the design of gates per day. But productivity as defined by gates-per-day isn’t necessarily an accurate measure of design engineering productivity, as more gates per day could be attributable to the gains from a higher abstraction level, faster computing systems and or more (or more experienced) engineers. (Still, it’s hard to argue that we should still be clinging to the schematic capture wagon today).

Think different
There are some voices that argue different definitions (and a complete rethinking of EDA assumptions) are necessary if we’re to stay on top of design complexity.

Mike Eneboe, former vice president of programmable platforms at LSI and now a business and technology consultant at Ridge Partners, LLC, is one of those voices.

“We are the EDA industry’s equivalent of the Donner Party with everyone waiting to see their neighbor fall asleep,” he said. “There is little movement and minimal efficiency in technology, business models, or investments. We can change this.”

He argues that as the industry converges around C for high-level languages and abstractions, the proof points should revolve around short time-to-market, simple, deterministic. In this way, he gives the software-development industry an ‘A’ grade for improving time to market, simplicity and deterministic design. “I don’t want to hazard a guess as to the EDA industry’s grade over the last 10 years,” Eneboe said.

Eneboe believes a different way of approaching the problem needs to be considered and argues for improvements in four areas:

1. Find a way to abstract the timing challenges of hardware. Clock to clock, nanosecond-sized timing calculations can no longer be handled efficiently across entire complex designs. Abstract the system-level needs up to frame and packet timings.
2. Wrap or otherwise get IP blocks (or functional blocks) to not be as bursty as they are today. Use of temporal fabrics (with QoS) can help facilitate the deterministic throughput to/from the functional blocks.
3. Create new metrics for the target platforms (FPGA, structured ASICs, full ASICs) in the form of new, high-level guaranteed libraries. These new libraries would present the low-level resources (with guardbanded area and timing) as high-level objects that are malleable and deterministic.
4. Tools need to be written to efficiently convey the “completability” (design completion all the way through place and route) of the design at the point of architectural integration. What it means is that if a designer connects 10 IP blocks and targets the design to a 45nm library, the tools need to quickly indicate to the designer if the design will absolutely complete or not.

“If these four concepts are done well, then the language—C, C++, SystemC, Java, and so forth—do not matter,” Eneboe said. “Pick the most efficient one and use it. Verification is only done at the transactional level because that’s all that the interconnect fabric guarantees and ‘cares’ about.”

In any case, this story is, as they say on television…to be continued.

By Ed Sperling
Throughout system-level design there are gaps. High-level modeling doesn’t connect directly to RTL code. Synthesis and high-level synthesis remain worlds apart. There are even gaps in the expertise, from the people who handcraft RTL to those who take it for granted.

Some of these gaps will get closed over time. Others will never be closed. In same cases it doesn’t matter. In other, it adds inefficiency into the flow. Gaps can result in errors, they can delay designs, and they can cost money.

“There is always a gap between those two stages,” said Serge Leef, vice president of new ventures and general manager of Mentor Graphics’ System-Level Engineering Division. “There is no implementation path from ESL onward. In fact, the two worlds are barely connected. People who do system-level modeling are basically done because the benefits of that system model are not connected to implementation. Test benches become the ‘bridges’ between the two worlds.”

Leef said that what is missing is true system synthesis. Right now engineers work with synthesized blocks or even pieces of blocks, but it takes far too long and too many cycles to synthesize an entire SoC.

“There are too many dimensions to optimization,” he said. “Add software and the number of optimization knobs is vast. Also, there’s no really good language for synthesis that addresses concurrency, timing and pre-emption. SystemC, which is the best we’ve got, is really a hardware modeling language. On the software side there are C and C++, and lately there’s been a push toward UML and SysML. But there is no single language that does everything.”

System prototyping
Industry consultant Gary Smith said the one critical piece that has been missing in ESL-based design is virtual prototyping.

“That’s the only way we’re going to be able to fix the flow and get the cost of the design down and get simulation,” said Smith. “We need RTL handoff.”

One of the key pieces in this puzzle is software prototyping. Both Intel and Synopsys have been on an acquisition spree in this part of the market lately, grabbing most of the startups. Smith said the prototyping has to be radically faster, though, for it to have a real impact on design—something in the neighborhood of 100MHz.

The second missing piece is virtual prototyping for hardware. Both Atrenta and Cadence are known to be working on this problem, and sources say all the major players are exploring this market.

But Aart de Geus, Synopsys chairman and CEO, said all the pieces may never come together. “There will always be different levels of abstraction,” de Geus said. “The benefit of one level is not the same as another level, and you need success on all levels of abstraction. There will always be a tradeoff between efficiency and quality of design.”

He noted that there is a big difference between systemic complexity and the scale complexity inherent in Moore’s Law. “The opportunity is to keep scale complexity going while dealing with systemic complexity.”

Alex Shubat, president and CEO of Virage Logic, said the future may be in integrating the supply chain rather than the individual pieces of technology.

“Everyone has a center of excellence,” Shubat said. “The key is to make sure you can integrate up and down. No one company spans the whole world. The bigger the vertical stacks, the greater the efficiency. If it all works smoothly, you should be able to get to tapeout in half the time.”

Unexpected winners
That has paid off for IP vendors, who provide some of the pieces. It has created new opportunities in other areas. For example, the disconnect between the high-level modeling tools and the engineers who like to see exactly what is going into synthesis has opened the market for tools that can dig down into the code and analyze it. Mike Gianfagna, Atrenta’s vice president of marketing, said his company discovered that somewhat accidentally when chip developers began using Atrenta’s SpyGlass exactly for that purpose. It was an unexpected win for the company, considering SpyGlass was created to analyze RTL.

“There are a completely different set of things that each of these groups care about,” said Gianfagna. “With high-level synthesis you get machine-generated RTL, but you generally don’t know what the machine generated. Then you’ve got the other side of the engineering world where they handcraft RTL. They want to know what’s in the RTL, but the machine-generated RTL from high-level synthesis is not all that well documented.”

The result is that not everything can be optimized effectively without that level of granularity. But at the same time that higher level of abstraction is essential just to get the analysis done. Every time a team of engineers wants to do synthesis place and route it can take the better part of a week. Both speed and automation are essential, but it has to be linked back to the RTL side.