By Ed Sperling
System-Level Design moderated a discussion about the future of SystemC with Thomas Alsop, corporate design solution expert at Intel; Ambar Sarkar, chief verification technologist at Paradigm Works; Mike Meredith, vice president of technical marketing at Forte Design systems; David Black, certified training instructor at Doulos. Here are some of the key outtakes of that discussion.

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.

By Ed Sperling
Synopsys’ Karen Bartleson looks at the standards efforts under way for 3D stacking. There are a lot of them. As comedian Jimmy Durante once said, ‘Everybody wants to get into the act.”

Mentor’s Dennis Brophy takes a rather unusual historical look at language transitions in IC design. Break out the tie-die T-shirt.

Synopsys’ David Hsu got a big boost for his cloud-centric blog at the Synopsys Users Group when CEO Aart de Geus pre-announced the company’s new cloud strategy. Details will follow in future blogs, no doubt.

Cadence’s Richard Goering digs into wide I/O and what it means for stacked die. Hint: A lot. That’s probably a good way to describe Goering’s output as a blogger, too. Check out his user view on transaction-based acceleration with Broadcom’s Chandrasekhar Poorna.

Mentor’s Colin Walls examines device registers in C. Dig in and you’ll find this to be an interesting bridge to the hardware world.

Synopsys’ Hezi Saar looks into whether we need another storage interface for flash memory. Short answer: Yes.

Deepchip’s John Cooley records an analog engineer’s trip to DATE in Grenoble. The travelogue is from Trent McConaghy of Solido, who takes very good notes. There’s also an interesting battle published by Cooley going on between Forte Design and Mentor over systemC support. But what happened to the other six samurai?

Synopsys’ Eric Huang looks at the performance comparisons between two iPads and a couple of Android competitors. This should help determine what to buy—and build.

System-Level Design sat down with Thomas Bollaert, product marketing manager for Mentor Graphics’ high-level synthesis product line; Johannes Stahl, director of marketing for system-level solutions at Synopsys; Ran Avinun, marketing group director for system design and verification at Cadence, and Brett Cline, vice president of marketing and sales at Forte Design Systems; What follows are excerpts of that conversation.

SLD: Is the TLM 2.0 model going to be sufficient? There is now software, power, IP, and new layout issues in 3D.
Avinun: I don’t think the industry needs more standards and levels of abstraction. I think the problem is actually the opposite. Between TLM 2.0 and 1.0 there are untimed models, loosely timed models, approximately timed models and cycle accurate. For each one of them the subject is not fully defined for virtual platforms and a synthesizable subset. The direction is to eliminate some of those levels and define them better. Obviously certain companies will push new levels and new standards. But if you talk with the customers the complaint isn’t about the need for new standards. It’s about minimizing the subsets and defining them better. They can’t maintain five or six levels of abstraction with five or six sources.
Cline: We agree with that. The state of the art for each level of abstraction may not be there. If you have a TLM 2.0 model that’s modeling virtual platforms at a software level that may not be synthesizable in a chip smaller than the size of a table. There are certain constraints to produce good hardware. It’s not just what you put in software. So you have the TLM model for a virtual system platform and what’s synthesizable and you might have a gray area in between. How do you migrate both so you have enough abstraction and enough detail?
Avinun: And the push from customers is to have enough source files so they can serve them for multiple use models. Otherwise it’s an infinite amount of work for them and it’s confusing. You have models here and other models here. Did they come form the same source?
Bollaert: In regards to TLM 2.0, there’s lots of noise and communication around it. I think it’s very good for what it does, which is bus-centric communications. But it’s not about using TLM 2.0 everywhere else because it’s not made for that. It’s not about TLM 2.0 everywhere. It can be complicated and it should be simplified, for sure, but it’s not going to be everywhere. What will be everywhere will be TLM 2.0 concepts.
Avinun: People are using a combination of SystemC and C++, but processor models are still based on C.
Stahl: It doesn’t really matter what’s inside the model. TLM 2.0 is an interface model. It can be a C model inside. It can be a model that generates C. It doesn’t matter.
Avinun: And sometimes people need to use TLM 1.0 and sometimes they need a certain point to move into C even before they move into RTL. The pins are still signal-level pins. If the IP you’re developing is interacting directly with the I/Os, at the end of the day you need to define the order of those I/Os, one to nine or nine to one. If you don’t, the tool doesn’t know what to do. It’s the same with RTL. I don’t see how people will be able to avoid RTL for the foreseeable future.
Stahl: If you look at model availability on a smaller scale, the customer needs models developed for simple transactors. A methodology is nice, but they don’t want to develop it themselves. They want to have a block to plug into a block diagram-based tool and start simulating. You don’t care about the simulation modeling standard. It just needs to work.

SLD: Over the next 18 months we start moving into 3D stacking, or at least 2.5D. What happens with the tools that are there now?
Avinun: As far as the functionality of the system, there won’t be any significant change. At the end of the day, it might affect the back-end tools. They might provide you a different number.
Bollaert: It’s not so much about the change. It’s another opportunity for system-level. If you can stack chips on top of each other, even simple things like memory with a through-silicon via, you can access much wider bandwidth. What are you going to do with that? Now you can completely change the architecture. You have much more bandwidth and different interconnects. Instead of accessing data that’s 32 bits by 32 bits, now you can have a much wider bandwidth. There is great potential with 3D chips.
Avinun: So if you are designing new IP and using high-level verification, you still want to make the tradeoffs. You will get the same library as today with different numbers. It will be transparent to you. And you may get different optimization. But it’s not that much different.
Stahl: But it is more design space. The technology we have today provides a huge space for design exploration. Maybe this will add another dimension. But it’s not fundamentally changing the equation.
Bollaert. It does provide a wider opportunity for ESL. But it’s more than that. There will be a change in technology, as well. It’s not just about libraries. Libraries will change and they will reflect some new possibilities. But you also need to be aware of placement. If you have TSVs and I/O clamps in your chip you cannot just assume your design will work. 3D adds a new dimension.
Cline: It’s trickle up technology. As soon as people get good at 3D this information will move up. You only automate and abstract something once you become expert at the root level. Over time we’ll get really good, the models will get really good, the understanding of what to do with those models will get really good, and then people will start to use those better.
Avinun: There is a challenge to link ESL to high-level synthesis and the place-and-route tools. That’s the first-order challenge. But whether it’s 2D or 3D, first we need to solve the initial challenge.Back in 2005 when people talked about the challenges in ESL, one was the specific implementation capabilities of RTL. We’ve gotten better at this, but even today many tasks are being done at the RTL level rather than earlier. We have to solve this problem before we move to 3D.
Stahl: Someone needs to simulate at this low level. Once you can simulate you can model, and then you can have a synthesis flow to utilize this information.
Bollaert: Modeling and simulation cannot go hand in hand.

SLD: From an education standpoint this is a different world, isn’t it? Right now most ESL is for top customers. In the future everyone will have a role in complex designs, and everyone can use these tools.
Avinun: But if you look at the key challenges, it’s still the integration of IP and of hardware and software. If something hangs up you need to look back and figure out if it’s the IP you bought or one of the software stack layers. Those problems are still going to be there.
Cline: A big company is a subset of the market. You have early adopters at these companies, but if you go to the designer next door they may not touch it. Then you can go find a startup that’s going to bank their future on a new methodology because it’s quicker. Any company can be a subset or superset of the market. I’m not sure it changes our education mechanism.
Avinun: We all have the challenge to educate designers. That’s half of our engagement process, especially for the new tools. But every time you go to the next group it seems they don’t know anything about this and you have to start all over again. The industry has been stuck at the same level of abstraction for 20 years. The people who were out of college 20 years ago don’t want to learn about something totally new. And if you talk to the recent college graduates they may know software but not hardware. You have gaps on both sides. Over time it’s changing, but it’s changing slower than you want.
Cline: There’s about $200 million in ESL revenue. We don’t think that’s the goal. There’s $2 billion or more. As a result all the companies here are pitching a common message. That hasn’t happened in all segments of EDA, but it is happening in ESL.
Bollaert: Today HLS can do more than blocks. It can do complete subsystems. There are a lot of benefits for people out there. Whether they want to test hardware and software ahead of time, validate architectures for performance or power, or reduce time to verified RTL, ESL can really help them.
Avinun: Once we get to the point where people can’t compete without these tools, then you’ll see a major shift in the market. I think we’re getting close to being there. Large companies—at least their executives—are realizing this is the case. They’re instructing their middle management that this is the way you need to structure the company to do this. It takes years for these shifts to occur, but once they do start the shifts happen very fast.

System-Level Design sat down with Thomas Bollaert, product marketing manager for Mentor Graphics’ high-level synthesis product line; Johannes Stahl, director of marketing for system-level solutions at Synopsys; Ran Avinun, marketing group director for system design and verification at Cadence, and Brett Cline, vice president of marketing and sales at Forte Design Systems; What follows are excerpts of that conversation.

SLD: What IP do companies develop themselves versus outsource?
Stahl: It has to be core to the business. If you’re a communications company you should be developing communications IP yourself.
Bollaert: Many companies would fall in that category and develop their own blocks, IP systems.
Avinun: But there are more and will be more IP instances rather than SoC instances. The number of SoCs will always be smaller than the number of IPs being created.

SLD: Let’s define the system level. Is it the blocks, is it the whole system including outside IP, and can you ever effectively model this stuff?
Cline: This is the problem. A system to Boeing is a lot different than a system to Sony. For Boeing it’s an airplane, and it may be made up of lots of subsystems. For Sony it’s a DVD player that’s made up of smaller subsystems. To model one is different than another, so the definition of a system is a problem that will never be fully solved and neither will the definition of system-level design.
Stahl: You model what you need for the specific thing you are doing. You verify some aspect of the software or some aspect of your transmission. You verify your mobile phone can talk to a base station. So you need a base station model. Where do you get it? You probably need to cooperate with someone.
Avinun: We came up with a definition of system as part of EDA 360. It’s the end product, or whatever you ship to a customer. Or it’s integration of hardware and software components. There is a gray area. Some people refer to an SoC as a system. But if you are talking about the ASIC or the hardware, we see it more in the SoC domain. As you add more software or more connectivity, then we start to define it as a product or a system. This is still evolving in the market. IP may even be a subsystem.
Bollaert: My definition of system level includes virtual prototyping, architectural analysis and high-level synthesis to address hardware-software integration issues, architectural design decisions, to help you get to correct RTL much faster and to reduce your verification effort. That’s what ESL can do.
Avinun: But there is some confusion in the market about this. At the time ESL was first introduced, which was about 10 or 15 years ago, it was to solve systems-integration issues. The solution is moving to a higher level of abstraction. To some extent it was successful, but not completely. My emulation business produces more revenue than the system-level tools in the market. A higher level of abstraction is one way to solve your system-level issues, but it’s not the only way. To some extent, we’re mixing two definitions. There’s a system view from the project manager, and a system level where we’re really talking about moving to a higher level of abstraction. We call it ESL or system level, but to some extent it’s confusing. If you were to ask 10 companies how many of them get to RTL with just a high level of abstraction, the answer is probably zero.
Stahl: There are three classes of system level. One is the behavior of the system. If you look at the tools that do communications system-level design, they’re still around and very successful. These tools have been established for behavior modeling of the system. Then you have the huge area of software development, which was isolated for many years. Now it’s coming much closer to the architecture design with a whole bunch of new products to help. What’s new today is the software developers rely on new methods to get their job. And they cannot get it done with the traditional tools.
Avinun: I’ve seen that and I’m not saying that virtual platforms are not a solution. But it’s only one solution. If you ask what customers are using for integration, some will tell you emulation, some will tell you virtual prototyping and some will tell you both. It’s just one of the alternatives. To say system-level design is only being done at this high level of abstraction isn’t correct.
Cline: I agree with everything except one thing—where the money is being spent. You mention emulation makes a lot more money. There is a lot of money spent on emulation and the reports say there is not a lot of money spent on system-level design. But that isn’t true. The EDA vendors may not be reaping a lot of money from system-level design, but you can be sure the customers are spending a lot of money in this area. They have their own tools and lots of people, and they’re spending a lot of money on this. It’s just that EDA vendors haven’t completely figured out how to address it. I also disagree with Thomas (Bollaert) There are two camps of customers. Some of them want to see a design flow from one vendor, but at the end of the day most of them want a design flow with best-in-class tools. I don’t think any vendor can provide a complete suite of tools. There are a lot of ways to get the problem solved, and almost all customers use tools from every vendor.
Stahl: I would love to say customers buy tools only from one vendor. That’s not true. But what they do want is a methodology that can scale. They cannot afford to invest in methodologies that are from one vendor or even multiple vendors but which don’t scale. A bigger challenge for us, as an industry, is to provide methodologies that scale and which not only three people in a gaussian distribution can learn.
Avinun: And as they integrate a system, there are multiple levels of abstraction. They also have hardware and software, and digital and analog. They’re struggling to go back and forth from one to the other and understand whether the problem is in the hardware, the software, a higher level of abstraction, or the IP they bought. The environment is so complex that to debug it is very difficult. We’ll need to help them. Each one of our companies will try to create tools that work together. We also will need interoperability standards that will incorporate multiple tools and help customers find the problem in a simple and fast way.
Bollaert: Brett (Cline) has justified the full flow. If a model from here does not match a model from there then you have interoperability issues. Customers are asking for a solution that works from A to Z, from virtual prototypes to HLS. At Mentor we’re organized internally to address just that. It’s something that does make sense. The early adopters were ready to put up with tool deficiencies and standards issues and modeling complexity. The new wave want things that work out of the box. They have different needs. If you look at the ESL landscape, it has evolved.

SLD: There also have been huge changes in the market, which is why all the major EDA vendors have invested well outside the normal EDA market. You’re all defining the system well beyond the hardware.
Cadence: We’re investing a lot in methodology and solutions that can work across multiple tools. All the products need to work across the flow. Initially this is for mostly Cadence tools, but ultimately we will add other vendors’ tools. This kind of work is hidden. It doesn’t get the big press coverage. But from the investment standpoint, it’s as big as an acquisition.
Cline: One of the things we’ve done is partner with all the larger EDA companies. We have a partnership with Mentor for some of the verification tools. We partner with Synopsys for verification, system-level and implementation tools, and we partner with Magma for a number of tools. And once upon a time we had a partnership with Cadence before they threw out all the small companies because they didn’t want you to play nicely with their tools.
Avinun: We didn’t throw out the small companies. We had a Connections program where we had 200 companies. We couldn’t give the right amount of attention to all of them so we had to prioritize. We looked at what it meant for us and what we were getting out of it, and we eliminated companies that weren’t providing value. It was not because one company was smaller than another.
Cline: We see it differently. We see it competitively.
Avinun: But we are still working together on standards committees for synthesizable subsets.
Cline: Yes, we are. But to build a flow it should come from best-in-class tools. Is Cadence interested in supporting that flow?
Avinun: Absolutely. The verification here is based on UVM, which should work with all the tools. And the synthesis is based on a subset defined by OSCI. There is nothing unique for us except we have the expertise to help customers implement a solution. There is no proprietary methodology just for Cadence.
Stahl: It’s interesting you brought up the methodology. I totally agree that this is very instrumental to roll out to customers because they really don’t know how to use it. But the very first question we get from customers is, ‘Do you have the models I need?’ This is part of the external investment Synopsys has been making in buying technology and methodology that are in the market already. The ESL application is driven, to a very large extent, on whether you have the model they need. If you do have the model for a platform they want to describe and use, then how do you do all the rest of the system, what is the methodology, how do you plug it into the back-end verification flow. This is extremely important. We have to agree as an industry on a methodology, so the model race is a race in the industry. That includes the high-level synthesis tool that develops the model.
Bollaert: Beyond methodology it’s also the education. People have to feel comfortable that this isn’t that far out of reach. They can really do this.

System-Level Design sat down with Thomas Bollaert, product marketing manager for Mentor Graphics’ high-level synthesis product line; Johannes Stahl, director of marketing for system-level solutions at Synopsys; Ran Avinun, marketing group director for system design and verification at Cadence, and Brett Cline, vice president of marketing and sales at Forte Design Systems; What follows are excerpts of that conversation.

SLD: What are the big problems in system-level design?
Cline: When it comes to high-level synthesis, we’re like the dog that caught the car. We’ve been talking about this technology coming and coming and coming, and all four companies here now have real customers, real tapeouts, and real products in Best Buy or Fry’s that have had a chip designed with one version or another of software that has produced a new design flow in these chips. As an industry, we need to figure out how to unify that and make it more of a standard among companies that have spent hundreds of millions of dollars over the years on their own internal flows and now can start to adopt different technologies. There’s a different side, too. There are a lot of pieces available in the RTL flow that are just now making their way up to the system-level design flow. That includes new tools, migrating abstractions up beyond just high-level synthesis—everything from virtual platforms to high-level synthesis tools to code coverage.
Avinun: Over the last 10 years many of us have been involved in ESL. Initially, the focus was just to get the tools to a sufficient level of maturity. With high-level synthesis the goal was to get quality results so customers are willing to look at these tools compared to hand-written RTL. In the last few years there has been more interest by customers. Customers don’t question whether they can do it anymore. We’re moving to a different problem. If 90% of a design was written with legacy RTL, what can be done with those pieces? If every new design was created at another level of abstraction it would take another 5 to 10 years.

SLD: But companies are comfortable with this technology now?
Avinun: That’s the other issue, education and getting to a comfort zone. In 1993 when RTL was introduced to replace schematics, customers still kept their schematic books. But that happened pretty fast—five to six years. Now there are a lot of legacy tools that have to go through this shift. If you talk to 10 engineers, 8 would say they’re not comfortable with C++ or software and they aren’t interested in doing this—unless someone forces them. Over time successful companies will force them to change to be competitive. We tend to talk about ESL in isolation. We need to look at the overall issues in design verification, not in ESL. If we don’t, we’re still looking at point tools and point domains and ignoring other domains that are just as important. The big picture is designs are getting more complex and there is software that needs to run on this.
Stahl: The big picture is important. What drives ESL from a top-level perspective isn’t necessarily tied to the SoC guys. It’s the guys who use the SoC at the end of the day. Ideally for them everything would be in software. After all, why do anything in hardware if you can avoid it? So they use as many cores as they can to get everything to run, but they find it’s not good enough. They cannot implement everything in software because it takes too long. In many cases it is faster to develop a hardware block. Most companies that develop hardware blocks using high-level synthesis add content that is innovative. But if you cannot integrate a high-level synthesis flow into a good chip-level verification flow then people won’t adopt it. If you cannot integrate it into a software flow it won’t happen, either. It’s not a standalone event. From a high-level perspective, high-level synthesis helps you to develop a block faster and to verify it faster, but you have to do it in an overall context.
Bollaert: The technology is not the challenge anymore. Many companies have been working on this for 5 or 10 years. Whether it’s high-level synthesis, virtual prototyping or other components, this is proven and customers should not be worrying about that. But you need flows and methodologies, and you need a complete ecosystem. It’s way beyond just EDA vendors. You need support from foundries, IP vendors and potentially from consulting and design services. These are the kind of resources people rely on. When you look at ESL, five years ago none of that ecosystem existed. We’ve seen a lot of progress since then. TSMC’s Reference Flow 11 is an example of that. These components give confidence to the user that it’s more than just tools. Beyond the ecosystem, the methodologies need to be firmed up a little bit. Until now there have been a lot of point tools. While this was adequate initially, people are asking for flows and high-level solutions. ESL is not only about high-level synthesis. Customers are asking for virtual prototyping and high-level architectural exploration. They also want tools that can talk to each other.

SLD: What changes in ESL now that we’re using more off-the-shelf reusable IP?
Stahl: What’s changing is that instead of using more internal IP companies are using more commercial IP. With commercialization, the expectations of customers are much higher in terms of quality and integration into the flows and verification and implementation. That means we need to have all the models for the IP. I’ve lived through this pain at CoWare, getting models for critical IP out to customers. It took a long time for the industry to convince IP vendors to do this.

SLD: But it’s getting even harder with proximity effects and thermal issues, right?
Stahl: Yes. At all levels of abstraction you have the complexity of the IP. And down at the technology node things are extremely complex. At the system-level, you have to understand what is the level of detail you want to have in the model to have a reasonable result from your simulation and verification—and speed. Customers want fast and accurate models. That’s possible in certain areas, but not in all, and not for all kinds of IP. We are defining what are the models you need and what makes them useful in the flow. That still is happening. It’s by no means complete.
Bollaert: It’s all about the make vs. buy decision. Even though IP is very prevalent there are still a lot of blocks and subsystems being created because IP does not address everything. The IP question is very important. You need to understand whether you can re-use something and how best to use it. These are system-level questions. One of the issues customers have seen with IP is that it has a limited life.
As you shrink the nodes, the IP may still work but it becomes sub-optimal. The need to re-optimize for a new technology node and avoid power issues and integrity issues isn’t easy.
Stahl: That’s not the biggest challenge for IP. The biggest challenge today is the moving standard and the moving stack. You may get a completely new standard, which means you cannot re-use IP.
Bollaert: That’s very true. The IP question needs to be looked at by specific application. If you are doing an image signal processor there is no need for IP. You need to develop that. For bus IP, it makes sense to buy it.
Avinun: We need to define IP. For small digital IP there are two challenges. One is re-use. They don’t want to re-invent the wheel every time they go from one process to another. They don’t want to re-invent an algorithm each time, either. This is about productivity. If you look at the transition to higher levels of abstraction, that’s what’s driving IP re-use. IP also can include subsystems. ARM’s IP is on a different scale. In their case they need a full ecosystem of IP providers. That’s one set of challenges. The other set of challenges is integration. You take IP developed by other companies and integrate that together. We are a long way away from where all IP can be integrated at a high level of abstraction, so we can’t throw away the other tools.
Cline: Companies are running into problems where the IP never completely meets your needs. It may not be at the cost you want or the process you want. What we’re finding is IP vendors are just now having the same problems as the semiconductor companies. They have to produce their IP faster, smaller, lower power, and if they’re using an older process they’ll never be able to keep up with a company like Sony or Samsung generating chips at all different nodes for all different kinds of products. Customers are now starting to take a look at the IP they’ve been buying and do it themselves because they can trim off 10% of the area or lower the power to spec or add some unique value—and maybe even do it more efficiently. We’re seeing more people move to their own internal IP model.
Stahl: That only holds for IP that’s specific to their products. Nobody in their right mind should do standard IP today by themselves. It’s not economical. The investment to set up an infrastructure, verify the IP and track a specification is the business of IP vendors.

System-Level Design talks about the challenges of ESL with Cadence’s Ran Avinun, Synopsys’ Johannes Stahl, Mentor Graphics’ Thomas Bollaert and Forte Design Systems’ Brett Cline.

By Ed Sperling

Every now and then a new trend comes along in the semiconductor design world, often because an old tool doesn’t work well anymore or because a new one is achieving critical mass. Lithography moved to immersion when the wavelength couldn’t be refracted far enough anymore. Designers at the advanced end of Moore’s Law began using tools like high-level synthesis and Transaction-Level Modeling 2.0 to help sort out the complexities of multicore, multi-voltage, multi-power island designs.

What’s changing at 32nm and beyond is the number of different directions the industry is heading. In the past, each new node brought new changes. At 130nm, the changes were considered extremely difficult because manufacturing moved from 200mm to 300mm wafers, added copper interconnects and low-k dielectrics for insulation. Most developers and chipmakers heaved a sigh of relief when that transition was over. But in retrospect, that was relatively tame.

Interviews with dozens of engineers, vendors, scientists, researchers and business managers over the past six months show that what’s ahead cannot be bounded into just one or two shifts. The change under way now is geographically global. It’s moving to a higher and higher level of abstraction, from semiconductor to system to device. And it is as much driven by business as technology. Moreover, taken in total these changes will completely alter the basic fabric of the design community in ways that have never been seen before.

Business
Behind many of the changes afoot in the market there is always a business case. In the past, technology trumped business. Those with steely nerve and enough backing could often carve out a space for themselves in markets, and even if they weren’t entirely successful they could minimize their losses.

Three things changed over the past decade to alter this approach. Business now trumps technology in almost all cases. First, the venture community has grown more cautious about the rate of return in hardware and EDA tools ever since the dot-com bubble burst in 2001. It’s not possible to return to the tap anymore without a real product and a real business model.

Second, the cost of failure has gone up. It now costs $4 billion to $5 billion to build a state-of-the-art fab. Consortiums of very large companies and governments are now involved in this business. And it can cost upwards of $100 million to build a very complex SoC at the latest process node. Stalwart adherents to Moore’s Law such as Freescale, which made the leap to the next process node without hesitation until 90nm, have begun skipping nodes on certain products.

Third, chips are now so complicated that it takes too long to build everything from scratch. That means chipmakers must buy IP from third parties. Even Intel doesn’t make everything itself anymore. And all but a very few companies now use a fabless or fab-lite model for at least the digital portion of their chips, which forces them to adhere to design rules and process technology developed by the foundries.

Put these together and the result is that business issues are forcing a handoff of some of the most basic parts of semiconductor engineering—defining a unique architecture, tinkering with the layout, refining the process, and balancing all of these pieces together at tape-out. Fast yield, time to market and standardized interconnects and IP are no longer just goals. They are requirements. Some companies have handed off the building of chips entirely to a new class of value-chain producers like eSilicon, Global Unichip and Open-Silicon.

Globalization
For the first 50 years of its existence, the semiconductor industry defined global as North America, Europe and Japan. Taiwan was a latecomer to the part, and TSMC’s vision of a foundry model was considered revolutionary well into the 1990s. Companies like Texas Instruments and AMD said they had no intention of letting go of their own fabs.

Fast forward through two downturns and 10 process nodes and the situation now looks much different. Software is increasingly a part of the design process, heavily automated foundries can be located anywhere in the world where tax breaks and the cost of power are lowest, and massive education programs are under way in multiple countries that see semiconductor and computer engineering as a fast way to economic health.

While many lament that the semiconductor industry is declining or not showing growth, the opposite is happening. It’s expanding significantly. In 1977, the Semiconductor Industry Association reported total semiconductor sales of $2.88 billion, with about $1.92 billion of that in the Americas and only $182 million in Asia/Pacific (not including Japan). In the first 11 months of 2009, sales were $196 billion worldwide, with $102 billion in Asia/Pacific and $33 billion in the Americas.

By any standard this represents an enormous increase in sales, but the profits are now far more dispersed around the globe. Moreover, IP for chips is being developed in places like Eastern Europe and former Soviet republics, and in the future that kind of work will accelerate in other parts of the world because the barrier to entry into this market is one of the lowest—you don’t need to build full systems—while the return on investment is one of the highest. Virage Logic, ARM and Synopsys have been snapping up these kinds of operations around the globe over the past couple years.

Technology
Most of these changes are being driven by the technology itself. There are fewer design starts for ASICs these days, but the problems being solved are far more numerous on each chip than in the past. The tradeoffs of area, power and performance have been relatively balanced over decades of development. When lithography became an issue, there was enough slack in power and performance to tide chip designers over until the next node.

At 90nm that began to change. Classical scaling ended, lithography stalled at 193nm, defect density increased as irregularities in silicon and process technology became evident. Power forced even companies like Intel to begin adding more cores onto a chip rather than continuing to turn up the clock speed, creating problems about what to do with more and more cores.

At 22/20 nm—the next node for companies that live on the edge of Moore’s Law—things get even more interesting. Both Synopsys and Mentor Graphics predict that FinFETS will start showing up on chips—3D transistor structures that will wreak havoc on parasitic extraction because of the amount of data that will now need to be analyzed and synthesized. IBM has talked about potentially reducing the functionality on chips at future nodes to be able to get chips out the door that fit into the power budget.

All major chip companies are now looking at heterogeneous cores instead of homogeneous cores and matching software and core size for a specific function. IBM and Mentor are experimenting with computational scaling to compensate for the limits of 193nm lithography. And power techniques that used to be considered exotic and extraneous are suddenly becoming necessary.

Even substrates are changing. Intel, which examined and then rejected partially depleted silicon on insulator (SOI) is looking seriously at fully depleted SOI for future nodes. And work is under way to sidestep much of this entirely with 3D stacking of chips, which have many problems such as heat dissipation and parasitic issues still not fully understood.

Abstraction
Perhaps even more daunting in this whole process is a complete shift in control within the design flow. The number of computations necessary at advanced nodes, coupled with business pressures and time to market issues are forcing engineers to rely on models. For many, this is like black-box technology. You put requirements in one side and the software adds a lot of the things in between.

For engineers who learned to solve problems the hard way–that is, without software models–this is perhaps the toughest change of all. RTL engineers who work at big chipmakers say there is enough work at the moment to stick with their core competencies. The problem is the amount of data they are dealing with is going up, and over the next few years it will skyrocket into the stratosphere.

Japan has been particularly accepting of tools like TLM 2.0, high-level synthesis from companies like Mentor, Forte Design Systems and Synopsys, and network-on-chip technology from companies like Arteris and Sonics. The acceptance level in Europe is lower, and it has been lower still in North America. But that is likely to change at future process nodes as business pressures take root, something that is already becoming evident with the rapid proliferation of DFM tools and automated test suites.

Tools vendors characterize these changes as a shift from design engineer to systems engineer. But there’s far more to it than that. In the future, a systems architect will have to understand how the software will behave in the system they’re designing and how all pieces of the verification can be matched to the progress in the design. The next phase of systems engineering will be concurrency in multiple pieces of the design, with real-time feedback across the flow to make a series of modifications and more modifications until tape-out.

This is already evident in the number of tools players around the fringes that are trying to solve unusual problems–companies like Atrenta, Jasper, Oasys, CoWare, and a slew of others that have made inroads and will continue to make inroads.

Conclusion
Taken as a whole, the confluence of a variety of factors ranging from technology to tools to business is coming to a head. Each node from here gets tougher not because one problem has to be solved, but because more and more problems have to be solved simultaneously at each successive node.

Moore’s Law will continue, but not in the form in which it was originally conceived. A FinFET is not a classic transistor, and 3D stacking moves things into a different plane. Moreover, the tools to create these new devices will continue to change, the way they are manufactured will change, and the skills necessary to create these structures will change.

Perhaps even more important, all of these changes will begin showing up over the next couple of process nodes. We are all living and working in interesting times, but whether it’s a blessing or a curse may depend on each engineer’s role, their training, their ability to accept change and possibly even where they’re located

By Ed Sperling
System-Level Design sat down to discuss the future of synthesis with Shawn McCloud, product line director for Catapult C Synthesis as Mentor Graphics; Chris Eddington, director of marketing for system-level products at Synopsys; Bret Cline, vice president of marketing and sales at Forte Design Systems; Sanjiv Kaul, executive chairman at Oasys; and Andy Biddle, director of business development at Magma. What follows are excerpts of that conversation.

SLD: Who’s going to be using these tools? Is it the hardware or software engineers?
Eddington: There are limitations to a C-based description. But if you take the guru for an OFDM timing circuit—very often those guys think in system-level designs. They read math books and they do blocks. They draw systems out and map out what it has to do at a very high level, and then they throw it over the wall to a hardware engineer who is going to describe it in a more hardware-oriented C-based or an RTL-based language. This might be an algorithm engineer, a system engineer or a product architect, depending on the organization of the company, but these guys are sitting together with the hardware team. Those front-end guys are already using some of these languages to think through their ideas. MatLab is a good example. It’s an array language with numerical functions you don’t have to write yourself.
McCloud: Most companies have algorithm engineers. But we see the best success when these two work together. The algorithm is being written to be more friendly for hardware engineers. If not, these algorithms can be used as a seed for the hardware designer to produce the design. I believe that ultimately the hardware designer will be the user of high-level synthesis. I think that’s going to take some time. Not all will convert, but some will convert.
Cline: I’m on a mission to squash the term, ‘RTL designer.’ They’re a hardware designer. You’re forced to use RTL because of the tools of the day. As we pull the whole flow together, if RTL is an intermediate format to any of the logic synthesis tools, no one really cares what that looks like. I also think that 80% of the RTL hardware designers will move up. You’ll get some smart verification, software, algorithm and systems, but I still think it’s a hardware design task. I do think there is a differentiation on the Matlab side. We don’t deal with that. But we certainly see it.
Kaul: The transition from gates to RTL happened when the chips got bigger than 50,000 gates. It happened pretty quickly, too. But high-level synthesis has been around awhile. Is there a triggering event that will make people move?
Cline: I think re-use has kept RTL around longer than it needed to be. One of the interesting things about the recession is that it has forced everyone to come to high-level synthesis. Who wakes up in the morning and says, ‘My chip has double the number of gates and I have half the staff I did last year. But I’m going to do exactly what I did last year.” Japanese companies have been building a flow with high-level synthesis since 2001.

SLD: What causes the shift?
Eddington: It’s complexity in both verification and design. The road maps I’ve seen from some of our largest customers show zero hardware designers, all systems engineers describing their designs at a high level.
Cline: That would be impressive.
Eddington: That’s their goal. I don’t know if they’re going to get there, but that depends on us, too.

SLD: As we get into more complex designs with multiple cores and multiple power islands, does synthesis work for that or is it still block by block?
Cline: It’s not block by block, but it’s not everything you’ve mentioned. There are really good tools that can handle implementation of RTL into designs and that can do smart things with power islands, how you’re going to implement clock gating and all the other things you’re going to use. Our strategy is to give hints about what we think should happen, but they still let the tool get everything right at the RTL level.
Kaul: There are very few tools that can look at the entire chip. There are floor planning and timing, and that’s it for a large chip. Even the physical implementation is broken up into partitions. But you have to look at the whole chip to do tradeoffs. Synthesis has to look at the entire chip, too.
Eddington: The high-level synthesis tools in the market today have affected the trend. There are fewer algorithms being implemented in DSP firmware and instead being implemented as hardware accelerators. That’s been an effect of the high-level synthesis tools, which makes it easier to develop those hardware accelerators. If you look at the partitioning between hardware and software and synthesizing from the spec, ‘Here’s the part that I want in hardware and here’s the part that I want in software,’ no one has done that yet.
McCloud: That’s the Holy Grail.
Eddington: Yes, and it’s a very challenging problem. High-level synthesis is a foundation to that.
Cline: When we talk about high-level synthesis, we just take for granted that we’re going to produce RTL and get a chip out. That’s a very hard problem. We actually think of RTL synthesis as the back end now.
Biddle: About 40% of our customers are spending most of their time on timing closure and routing today. They don’t really care which synthesis tool they’re using as long as it comes out about right. They know they’re going to have a problem down the line when it comes to polygons.

SLD: What happens when the industry moves to vertical stacking?
Eddington: If you’re using your downstream tools effectively, it’s just another technology that your flow plugs into.
Cline: This is the caution of not just stopping at RTL. You need to give the high-level synthesis tool the data that it needs to make good decisions. Ideally one of the big vendors would have an API that we could tap into and get everything we need to know before we synthesize. That doesn’t exist. You can get some feedback from the logic synthesis tools, but it certainly isn’t the be all and end all. As you go down to the smaller nodes you need more and more information. The question is how much you’re going to get.
Eddington: Did you say you’re feeding back IP-level estimation data up to high-level synthesis?
Cline: In our case we’re feeding back gate-level implementation decisions.
Eddington: We feed back IP-level information, as well.
Cline: What does IP-level mean?
Eddington: You’re estimating an operator like an FFR filter or an FFT, and that makes the whole flow more efficient. A gate-level implementation of an FFT would take forever, but you can do that quickly if you know the pieces and the general architectural decisions you want to make. You make the right calls to the logic synthesis tool and you can estimate that.
Cline: And you can even go more fundamental than that. How much will it cost to implement this multiplier and this technology library at this speed?
McCloud: It’s also about the quality of the library. High-level synthesis has a library just like RTL synthesis does. As you get into lower geometries and 3D, the library you’re creating has to be of higher quality. The more information you put into that library the faster your tool is going to execute and the more accurate it’s going to be. You also need a feedback path from the physical side. We’ve taken a path of partnering with the silicon vendors.

SLD: How does software fit into all of this?
Eddington: It’s a huge part of the verification problem. Everything you do in hardware ultimately is going to interoperate with some software. Once you plug those things together, does it work? The sooner you can do that verification in the design flow the better. High-level synthesis plays the role of getting the hardware done earlier so the software guys can start using it.
McCloud: This is where TLM virtual platforms play a big role. One of the biggest challenges our customers face is the unpredictability of their system. It’s not until they get everything done—their RTL, the software and the chip—and they’re ready for tapeout that they have a predictable system where they can see if it works. TLM allows you to verify the software with the hardware with which it’s going to be implemented.
Cline: But that’s independent of synthesis. Most people that use virtual platforms are doing that in a way where they’re not synthesizing afterward. We think they should be. But a lot of them are just rewriting that into RTL and then going into a traditional flow. Interestingly, they’re coming up with larger chips because they can do more in a high-level model than they used to.
McCloud: The problem is when they go to rewrite the models, that introduces a huge verification challenge. What they try to verify at the beginning of this virtual platform now has been rewritten. So how do you know if what you’ve rewritten is correct?

SLD: How many people are actually using TLM 2.0 for modeling?
McCloud: TLM 2.0 is a fairly new event. It’s a big step forward for the market. It’s an attempt to separate functionality from the interfaces and power and performance. Part of the challenge with building virtual prototypes is the modeling challenge. TLM has tried to make that easier. But everyone is doing some level of virtual prototyping, even if it’s just a spreadsheet.
Cline: I agree. I think people do TLM. They just don’t call it that. The synthesis side of TLM is not defined yet, but it will get there.
Eddington: It’s attempting to standardize all the different methodologies you need to be able to deal with writing C code that models systems. There are different levels of abstractions. TLM 2.0 delineates untimed vs. approximately timed, abstractions in communication and computation.

Experts At The Table: The Past, Present And Future Of Synthesis
High-level synthesis raises the abstraction level, but it doesn’t eliminate the need for synthesizing at the RTL level; still no all-in-one solution.

By Ed Sperling
System-Level Design sat down to discuss the future of synthesis with Shawn McCloud, product line director for Catapult C Synthesis as Mentor Graphics; Chris Eddington, director of marketing for system-level products at Synopsys; Bret Cline, vice president of marketing and sales at Forte Design Systems; Sanjiv Kaul, executive chairman at Oasys; and Andy Biddle, director of business development at Magma. What follows are excerpts of that conversation.

SLD: Is synthesis changing, and if so, why?
Cline: It’s definitely changing. The reality is there is a merging of various capabilities throughout the synthesis design flow to allow better transformations of data to happen in shorter order. It’s easy to say it’s because of productivity, market pressures and cost, but that drives EDA all the time. The key point is that with tools like the new logic synthesis tools, the new place and route and the new high-level synthesis you’re able to combine functions that typically were in three or four different tools into one or two, which allows you to make better tradeoffs and ultimately get better results.
Biddle: The focus on RTL to GDS is becoming more important because of the challenges of 65nm, 40nm and now 28nm designs. Traditional RTL synthesis has to become much more physically aware. Engineers can no longer throw netlists over the wall and expect to meet timing on schedule. We’re seeing the merging of technologies, as well. There’s a need to tighten up the links between the front end and the back end. We’re similarly seeing the need for greater productivity, particularly for algorithmic-type work.
McCloud: One of the most important things is that when these new synthesis tools come out they need to build on the existing RTL flows. One of the mistakes we see is when a tool tries to replace RTL synthesis. That’s reinventing the wheel, and there are already years of R&D behind RTL synthesis. It’s more important to have high-level synthesis built on top of existing RTL methodologies. Even today, gate-level design hasn’t gone away. That helps reduce risk. RTL is a necessary stopping point. It gives the security it’s working.

SLD: What will synthesis look like in the future?
McCloud: I think we’ll see more and more technology built inside and leveraged.
Cline: I agree that leveraging the technology people already have put into a design flow is important. That’s a strategy we’ve employed. When you go to a customer that’s had an ASIC signoff flow with Synopsys or Magma or anyone else and they are going through to gates you don’t disrupt that. But we also believe you can make better decisions inside the high-level synthesis tool if you know more about what logic synthesis is going to do with it. We don’t specifically go down to GDS II as part of our flow. But there are some tricks you can do if you have an embedded logic synthesis engine inside of your high-level synthesis tool to bring some of the higher-end pieces of the RTL synthesis up.
Kaul: You need a robust RTL platform to be able to take the RTL and go down. For large parts of the design, RTL synthesis is pretty stable, but for the very large designs, it’s becoming deficient. You have designs that are 50 million or 100 million gates. Most logic synthesis tools go from RTL to a mapped netlist, and then they optimize the gates and map it to a technology platform. Then you do physical synthesis after that. There can be 50 or 60 blocks that do not quite match your physical partition. So now you’re managing constraints, you’re dealing with very long runtimes, and you’re talking about closing the loop with physical implementation. When you move up to high-level synthesis, one of the things that would be useful is a capability that allows you to get quick feedback on whether your architecture is going to work or not. Is the QR going to be good enough? Is the implementation going to be good enough? Tools have improved a lot, but you need to know whether the chip architecture is going to be good enough. As the chips get larger, it’s harder to get a good answer.
Eddington: High-level synthesis has to utilize the key technologies in the RTL flow. It has to know what the RTL logic synthesis is going to do in order to make its decision. RTL logic synthesis is not going to go away. It’s part of the design flow and well established, and you’re crazy to try and change those. The high-level synthesis tool has to plug right into that. But it also has to have the right information to make its architectural decisions. That’s all about leveraging the downstream flows and making sure that information is brought back up.

SLD: How do you define synthesis vs. high-level synthesis?
Eddington: Synthesis is logic-level decisions and optimization. High-level synthesis is architectural-level optimization that takes a behavioral description and brings it down to a logic-level description.
Kaul: From RTL down is logic synthesis. Above that is high-level synthesis.
McCloud: To me the difference is in the source. A source to high-level synthesis is, by definition, untimed. It doesn’t contain any registers or clocks or I/O timing. In RTL it’s fully timed. It has a register with logic in between. That definition is part of the source. Another difference is the set of building blocks. High-level synthesis tools are working with adders, multipliers and muxes. RTL synthesis is dealing with gates. The process of inserting time is the process of scheduling.
Eddington: I disagree with one point. Some descriptions are approximately timed and have a notion of latency. They are very valuable ways of describing something at a high level that can be synthesized.
Cline: There are certainly people in the market claiming to have high-level synthesis and it’s debatable whether that’s really high-level synthesis.
Eddington: But even in the C environment where SystemC is defined as approximately timed and untimed. I consider the untimed is high-level synthesis, for sure. But approximately timed is also high-level synthesis because it isn’t describing all of the clocks and logic-level architectural details.
Cline: High-level synthesis is a bad term. Behavioral synthesis is better but it got a bad rap a couple years ago, so people are trying to stay away from that. And so if we’re high-level synthesis, what’ the next thing that comes out? Is it higher-level synthesis?

SLD: So how much of an SoC design is done with high-level synthesis these days?
Cline: It depends on the customer. The possibility is 100%, other than processor, bus and analog. One multifunction printer company does everything that isn’t analog, bus or processor in SystemC with our tool. A lot of it is re-use from the past. You can describe all that stuff in SystemC. Some of it may look pretty low level and it can be done with RTL synthesis. It’s not what we recommend, but let’s face it. Designs have all different levels of abstraction. You need a way to handle everything.

SLD: It sounds like the definition is far from clear-cut.
Cline: Some of us disagree with the definition. We output RTL. That’s our job, and our customers go off and use that RTL. In the real world, they have to go off and use some tool and they get gates out of it. What we’re finding is that when they use a tool that combines Talus or DC-Topo into place-and-route, as well, then they get some more advantages in optimizing. You have one pinch point in the middle, which is RTL, which is our common language. I don’t think the definitions matter. But there is a real sense in the market that a different task is taking place. It doesn’t matter what you call it.
Biddle: We have a handful of customers that are using SystemC. We’ve been partnering with Mentor on making sure the structures they’re putting out can be synthesized and that we can build a flow. Ultimately, one of the big bottlenecks we see is formal verification. Most people rely heavily on formal verification today. There are a lot of techniques and tools.
McCloud: There’s no single approach for verification. There’s classic functional-based simulation as well as prototyping and emulation. Calypto has a product out called SLEC that does do C-to-RTL verification.

SLD: What happens at the next level above this?
Cline: The RTL market has a well-defined flow and there are tools that plug into this flow. At the ESL level above that there’s a lot of interesting stuff—everything from virtual prototyping to formal verification. But that hasn’t jelled into a flow that everyone uses. Everyone picks their parts and puts them together.
McCloud: You are starting to see some parts of the flow solidify. We’re seeing that in the way that people verify designs. You develop a C description, you spend as much time as you can verifying that C description is correct, and what you’re generating is something that hopefully is predictable. You want to be able to re-use it, not re-do it at the RTL level.

SLD: How accurate are RTL synthesis and high-level synthesis?
Biddle: Everyone is always demanding greater predictability. There is constant pressure to correlate better. Once you have a netlist, what will area and timing really look like? That’s forcing us to add more physical modeling. But where we’re starting to have problems, particularly as we move to 40nm and 28nm, is how long it’s going to take to close timing. Once you come out of synthesis, are you done? We see designs where they’re throwing in gates just to meet timing, so chips are getting bigger than then need to be.
Kaul: For a large chip at advanced nodes, doing timing without understanding the placement is becoming less prevalent. You have to have placement information to have accurate timing. But for larger chips, understanding the floor plan is very important. Where the block goes in relation to the rest of the chip becomes very important. You have to look at global wiring, congestion and timing convergence. It’s important for the synthesis tool to look at all of that.
Eddington: There’s more innovation available in physical synthesis—integrating these placement and logic synthesis optimizations and doing them better. We’ve been adding physical synthesis in the FPGA space, but it’s still an area that needs further innovation.

Five experts sound off to System-Level Design on the state of synthesis and what’s needed in the future: Shawn McCloud, product line director for Catapult C Synthesis at Mentor Graphics; Chris Eddington, director of marketing for system-lvel products at Synopsys; Brett Cline, VP of marketing at Forte Design Systems; Andy Biddle, director of business development at Magma and Sanjiv Kaul, executive chairman at Oasys.