By Ed Sperling
Cadence’s Jack Erickson documents a 17 million-gate 40nm design that was completed in eight months with two designers. Does that mean it would take 16 designers one month?

Synopsys’ Navraj Nandra says that near-field communications will open up new opportunities for marketing, payment and data interactions. Why waste gas on trips to the store? You won’t even have to get out of bed in the morning.

Mentor’s Colin Walls is doing his best to prop up the European economy. Check out his conference schedule—and then try to figure out why this is where embedded software conferences are being held.

Tensilica’s Grant Martin exposes the popular misconception about power vs. energy. This raises all sorts of interesting questions, like what exactly is a power play or flower power? And if you’re drinking an energy drink do you feel energized or powerful?

Cadence’s Joe Hupcey says Amazon’s new Kindle Fire is a next step toward the paperback computer—one so inexpensive you don’t really care if you lose it. Just don’t leave your personal data on it.

Synopsys’ Eric Huang examines the market for USB 3.0 and predicts a huge uptick by 2014. That’s just one process node away.

DeepChip’s John Cooley ran a user poll of the top tools at DAC last June. Mentor’ Olympus-SoC hierarchical design flow came in first. For all the runners up, someone had to win. And for all the potential complaints, we’ll add the caveat that the real proof is in the sales numbers, not these kinds of polls. Still, the user comments are interesting. Cooley says Vennsa OnPoint came in second, followed by Oasys RealTime.

Cadence’s Richard Goering covers an interesting panel discussion on PCB data transfer formats. This is particularly interesting in light of the fact that the definition of a system is changing—and getting far more complex, more mobile and much smarter.

Synopsys’ Alex Seibulescu is aiming for intelligent coverage in verification. You can’t cover everything, of course, but you at least should know what you don’t know.

By Ed Sperling
System-Level Design sat down with Antun Domic, senior vice president and general manager of Synopsys’ Implementation Group; Serge Leef, vice president of new ventures and general manager of the System-Level Engineering Division at Mentor Graphics; John Busco, CAD manager and blogger, and Sanjiv Kaul, executive chairman at Oasys. What follows are excerpts of that conversation.

SLD: Is communication between hardware and software engineers improving?
Leef: The system guys see the problem as a software problem. But a hardware-oriented language like SystemC makes no sense to the software guys. They have no notion of concurrency or time. I have not, to this day, seen a single software guy that would willingly develop something in SystemC that could be embedded. SystemVerilog is even further away from that. What you’re doing is raising abstraction for the hardware guys, but we’re not doing anything for the entire system.

SLD: Do we need to train engineers differently, and if so, how do you get there?
Leef: My opinion is yes, because the majority of jobs are going to be in systems. In 1982, there were less than 5,000 people in the world who knew how to design a chip. That hasn’t changed much today.
Kaul: Are you saying there are the same number of chip designers and then an additional number of system designers, and that there will be more people becoming system designers than chip designers?
Leef: Yes, the latter. And my theory is that in the mid-1980s, almost everyone worked for PC chipset companies. There was a processor and a lot of other chips. Today, there is a processor and a graphics processor and not much else. There’s been a giant sucking sound on the motherboard. The same thing is happening with smart phones. There are three or four designs that are perfectly adequate, and not much separates one from the next.
Domic: But if you look at the majority of these smart phone manufacturers, they don’t design ICs.
Leef: There will always be opportunities for really smart chip designers, but there will be fewer and fewer of them.
Domic: But then the question is, who is going to provide the software? If you look at the investment Mentor or Synopsys makes, it has kept increasing. But it is not the majority of our investment.
Leef: That’s because we haven’t figured out what is the successful tool footprint in that space.
Domic: Or maybe somebody else will do it.

SLD: Are engineers making this shift from RTL to system-level engineer?
Busco: If you’re at one of these surviving companies that is still making chips, there is plenty of demand for RTL designers who understand deep submicron effects and who can guide the chip through physical design and take into account cross-talk. I haven’t really seen the migration yet. It’s logical that there will be so few companies capable of building chips that they’ll have their massive staff of chip designers and other people will use those as components. But I haven’t noticed a strong trend.
Leef: You won’t see it, but if you go to one of your top mobile customers, about three years ago they decided they were no longer adding value in the silicon platform. They are adding value in software and radios. Their business hasn’t fluctuated because of that.
Kaul: The group sitting around this table is biased toward standard cells. A lot of people are developing FPGAs, and we don’t see them that much. But there are more gates being designed for FPGAs. If you measure gates being designed these days, Xilinx might be the No. 1 customer of EDA. It’s a different pathway. FPGAs have become much more cost effective. It’s still RTL design, but it doesn’t have all the challenges of getting to silicon.
Leef: There are different ways to get into FPGAs, though. Some people are coming down from ASICs. They have methodologies that are traditional from our perspective. It’s just the very last step that is different. There are others coming to FPGAs from lower sophistication and from software. Those people do not believe they need EDA tools, because what Xilinx provides plus MatLab may be sufficient.
Kaul: The tools that Xilinx provides are EDA tools. But they’re given away for free as part of selling the silicon.
Busco: You mentioned the trend of systems companies moving away from chip design. In general, that’s true. But the exception is Apple. They’ve acquired companies, they’re hiring people, and they have a different perspective.
Leef: Apple is the exception that proves the rule. They always go against the flow.
Domic: We’re more concerned about the complexity than an inductive effect of the fourth order that becomes second order. We’re good at taking care of those things eventually, but one part that is becoming worrisome is the completion of the RTL and the level that the tools can take it to effectively—that completion point is taking longer and longer. We have been forced to modify tools. Engineers get clever at ignoring stuff. They may say, ‘This IP is not complete so I’m going to ignore this.’ There is a point where you’re going to have to work with very incomplete data, and to be able to proceed with the design. You can’t have the rest of the team waiting until the RTL guys have run enough regression that they can say it is safe enough to proceed. The tools have to deal more with this level of uncertainty and to produce some data. One part may be very clean and another may not. We’re connecting logic synthesis to design planning so people can see a little better what is happening. That may create a new evolution in the tools. It doesn’t go all the way to system, but it’s clearly different from what we have seen.

SLD: This is a leap of faith based upon the tools that high-level models require, right?
Domic: Yes, it’s along those lines. The difference is that the expectation is the rest of the data will be completed within the next few months, but enough has been done to say this floor plan will be okay so you can proceed to do this piece once the real data is presented. Working with this incomplete data—some people call it dirty data—and being able to derive good conclusions from that incomplete data may be a new direction for EDA tools.
Busco: That is the reality of design. Everything is not finished at the same time.
Domic: But there are also design compilers that try to take things to the letter.
Busco: Yes, and if it sees a timing violation it’s not going to look at anything else. It’s going to obsess about it.
Domic: What we need to do is get it to ignore certain things. It’s being able to proceed with uncertainty in synthesis, place-and-route and synthesis and timing analysis when you know there will be another netlist every three days. But we also have to do it cleverly so people can use the results effectively. That’s a challenge.

SLD: Does 3D stacking change the model and redefine the problem so not everything has to be at the most advanced process node?
Domic: If it works out like that, then yes. It’s not that everyone is going to use 28nm to divide something among 10 chips. People are going to use that because something works well at 130nm and they don’t want to re-do it. In that case, the changes are smaller and the traditional EDA tools, with extensions, will do a good job. If you want to create everything from scratch and divide it among 10 chips, then the game will change very dramatically.
Kaul: If you go to 28nm you’re going to have so much capacity that everything will fit on the chip. The advantage of 3D is being able to use older technologies. Going to a 28nm node is very expensive. It costs a lot of money to get there.
Domic: The analog design always lags.
Busco: So does DRAM.
Domic: Yes. And it will be a very natural extension.
Leef: I was on the advisory board of a fabless semiconductor company, which was doing an array of cores on a massively parallel chip. They made a conscious decision to use 130nm because they would have enough money to go through four tapeouts. From a monetary standpoint there were no benefits to going to more advanced process nodes.
Busco: Graphics is embarrassingly parallel and Moore’s Law is a friend. But the economics may say, ‘Why be on the bleeding edge. It’s not justified.’

By Ed Sperling

System-Level Design sat down with Antun Domic, senior vice president and general manager of Synopsys’ Implementation Group; Serge Leef, vice president of new ventures and general manager of the System-Level Engineering Division at Mentor Graphics; John Busco, CAD manager and blogger, and Sanjiv Kaul, executive chairman at Oasys. What follows are excerpts of that conversation.

SLD: The EDA industry often gets the blame for lack of progress in semiconductor design. Why?
Domic: Sometimes the EDA industry gets criticized that we haven’t invested in systems—whatever that means at a certain level. Part of the issue is the wide spectrum of the problem and the lack of definition. We can get you a tool to get from ‘D’ to ‘G’ in a certain sequence.
Leef: And combined with that are poor economics. People interested in solving the system-design problem at the front end are not very numerous. When I used to run the internal EDA organization inside Silicon Graphics we had a guy who was the architect of the graphics pipeline. He had all sorts of fascinating problems and all kinds of things he wanted to model—but he was only one. If a commercial EDA vendor could satisfy him they would sell one copy of the product and charge $1 million for it. The areas with the problems also have poor economics.

SLD: With modeling environments like TLM 2.0, hardware-software co-verification and high-level synthesis, there are a whole bunch of new areas that are not well defined or included in the flow. How do you deal with this?
Leef: There is a dimension of co-verification that has been well understood, which is at the RTL level where you have your design in RTL and you introduce a processor that is expected to run embedded software. The co-verification problem is essentially solved. You have a transmission mechanism that allows the software to be simulated very rapidly with hardware that is not all relevant, and the transmission slows down when you want to observe the bus cycles. At that level of abstraction, this has been solved. But at the higher level of abstraction what we’re running into is a lack of commonly accepted practices as to how people model systems like that. There are numerous examples where people decide to create abstract models that go really fast, and at the end of the day these models are rejected because they do not have enough details to be useful. And once they have enough details to be useful they lose the speed.
Kaul: Most of EDA is not market-sector dependent. RTL-to-GDSII uses the same synthesis tools and place-and-route tools. But when you get to system-level design, people designing cars have very different needs from the people designing airplanes, who have very different needs from the people designing DSPs. The models are key to that. The amount of detail needed on the models varies based on the kind of analysis you want to make. That’s one of the reasons why the market requires very deep domain problem about what the end customer is doing. For most of EDA, you need to understand semiconductor design. But with system-level design you also need a deep understanding of the end market. It’s hard to build, and especially to build it in a cost-effective way.
Leef: If you look at Bosch in the automotive sector, they really do need to model the hardware. However, once they deliver their solution to BMW, then BMW no longer cares what’s inside the electronic control unit. They care about the software and the network. They assume the electronic control unit and all the underlying hardware works correctly. Even though they characterize the problem as system simulation or co-verification, what they’re trying to analyze is drastically different from what Freescale or Infineon are trying to analyze before they gave it to Bosch.
Domic: The problem there becomes how many. In general, the EDA industry is investing much more. EDA has had emulation for quite awhile. We offer boards based on FPGAs where you can map and do some of the software verification. The reason a larger investment is going into these areas is the need for models. It may be hard to create a model for BMW when all they care about is the connection with the outside world. But when a platform gets standardized like a TI OMAP, where you have a couple of ARM cores and DSPs, you can’t provide a virtual platform. The problem has to be bound and specified.
Leef: The back-end part is relatively predictable. At the end of the day you’re going to build silicon. But the front-end part is more and more application-specific. IBM uses similar language to what we use, but once you dig into what they’re trying to accomplish it’s quite different. For example, they were talking about doing simulation at the car level and they were talking about simulating a network that contains 80 computers with sensors and actuators, gigabytes of software, all united by different types of networks. You’re not trying to verify the correctness of a Freescale semiconductor that lives on the ABS (antilock braking system). You’re trying to figure out when a customer presses the brakes, what are the external things that can be tolerated. That involves simulation of traffic on the network, mechanical modeling of the brake system.

SLD: Is this even an EDA problem?
Busco: And how have companies solved this in the past? Is it through in-house modeling? Or have they not even used automation?
Leef: The degree of design automation declines as you move further from tier-two suppliers. The silicon providers in this case—Infineon, Freescale, Renesas—are no different than TI and Intel in terms of the problems they’re trying to solve. When you go to Bosch and Delphi, they start to look more like PCB players. And then you go to the next set of players, they’re airframe designers. It’s a system of systems. The people who run those companies come from either a mechanical background or a financial background. They don’t have a direct appreciation of design automation. They wouldn’t think twice about spending $300 million to $400 million on prototypes, but they would argue over a $5,000 or $50,000 piece of software forever.
Kaul: People in those areas would use C models or The Mathworks.
Leef: The degree of automation in automotive is variable. One company has been trying to use MatLab Simulink, which only allows them to look at one dimension.
Domic: Given this lack of uniformity, and everyone trying to build something ad hoc, people try to answer very specific and narrow questions. Does the ABS react and work with the steering system? It’s a very specific question. You’re not trying to create a model that describes everything that happens to the car because that’s impossible with the current technology. On the other hand, when you do RTL for a chip you have an expectation it is an incredibly complete description of what a chip does. We have no tools that would synthesize a transaction-level model into a C model down to RTL. One part of the problem is that when you build a model you are trying to answer a very specific question.
Leef: The problems you’re describing are deterministic. In distributed systems, determinism is lacking. The problem they’re trying to find as the customer presses the brakes is why the signal doesn’t get to the brakes. It’s because the network is jammed with the temperature reading from the rear seat. The traffic on the bus is something that is irrelevant.
Kaul: These are very domain-specific and very hard to make a commercial business out of. That’s why customers end up doing a lot of this on their own.
Busco: To take a baby step of synthesis and try to raise the abstraction of that hasn’t been more accepted in the design community. Everyone does RTL synthesis. There are so many different domain languages, whether it’s C or SystemC or something based on MatLab, and yet designers are very hesitant to let go of the control and the quality of results they get from RTL.
Leef: The hardware guys are really married to this idea of precision and concurrency and timing being embedded into the language and the software guys see it differently.

SLD: Is it becoming a choice? You’re no longer designing the RTL. You’ve got power issues, software and signal integrity issues. Can you ignore these new techniques and still progress with a chip?
Kaul: Why haven’t people moved higher? Because getting from RTL to silicon is still such a problem. People need to have the level of control they get from RTL, and they need the visibility downstream to be able to design those chips.
Domic: The tools have progressed in terms of taking care of these things. But 20 years ago, if you look at RTL description languages, Intel had its own language, IBM had its own, and Digital [Equipment Corp.] had its own. VHDL took over. There are a myriad of descriptions above RTL.
Leef: But they don’t have a link to implementation.
Domic: I don’t think that’s a problem, because RTL methodology in large companies took over before synthesis was a viable alternative. Intel was using IHDL in the mid-1980s. I don’t think the key issue is a lack of a path to synthesis. But we have not done a good job in telling developers that C may not be perfect, but it’s more than enough to make good progress. Verilog may not be perfect, but for a lot of people it solved 90% of their problems.

Can startups still survive in an increasingly complex, high up-front investment world? System-Level Design posed that question to Mentor Graphics, Synopsys, Oasys and an end user.

By Ed Sperling

System-Level Design sat down with Antun Domic, senior vice president and general manager of Synopsys’ Implementation Group; Serge Leef, vice president of new ventures and general manager of the System-Level Engineering Division at Mentor Graphics; John Busco, CAD manager and blogger, and Sanjiv Kaul, executive chairman at Oasys. What follows are excerpts of that conversation.

SLD: Where is EDA today? Is it more valuable than it used to be?
Leef: EDA user crossroads right now, which has to do with what’s happening with our customers. The group of customers we historically have served is dividing into two camps. One group is doing huge, very complex platform chips. They need sophisticated back-end flow tools, as well as sophisticated front-end tools that allow them to model and experiment with sophisticated 500 million-gate designs. The process for those people is being strained on both edges. However, there are fewer and fewer people that can afford to do huge chips like this, and certainly fewer that can afford to manufacture them. The second group that is emerging and becoming much more prominent is the group that does systems. Their challenge is to take those systems and add value to them, whether it’s through software or industrial design or packaging. The community that’s emerging includes system designers, for whom the large, vertically focused platform chips are becoming more adequate. The motivation for them to do original hardware declines. But they do have to solve system-design problems.
Kaul: You can’t get a chip designed without EDA, and chip design is still very important to our economy. But if you do an analysis on the EDA industry, its competitive position is diminishing. There are fewer people doing these big chips. There is less differentiation between the EDA players. Some would argue there are too many EDA players, and therefore the differentiation is less and the negotiating power of the EDA players is diminished. If you talk to EDA companies, they think they’re not getting enough value for what they produce. It’s more a structure of the industry, with regard to the customers and the competitive position of the industry.
Leef: The trend of the separation of the design community means the EDA industry is having a hard time satisfying the platform chip designers because they really are pushing the state of the art. At the same time, they don’t know what to do about the system-level designers. We have one market that’s diminishing in size but growing in complexity, and then we have this other market that is potentially large but we don’t know how to tap it.

SLD: What’s the user perspective?
Busco: Of course EDA is important, but the value is splitting because the way the design community is getting strung out over many generations of silicon. For people that are still willing to design ASICs for their application at 130nm, or even FPGAs, EDA is necessary. But it’s more of a commodity product. If you’re designing at 40nm 32nm or 28nm, EDA is not only important, it’s incredibly valuable. You can’t do you design without it. That market is getting smaller because the NRE costs are becoming such a high hurdle that many companies cannot justify the design. But for those that can justify it, EDA is just as valuable as it was in the past.
Domic: There are people doing very important and profitable designs at 130nm, and there are people moving to 28nm. The spread is much larger than it used to be. I don’t need the latest signal integrity analysis tools if I’m going to be doing another 130nm derivative. On the other hand, I see that even with the decrease of the number of very large chips, the number of licenses we see being consumed by our customers continues to go up. Going to 32nm and 28nm and forward, we’re finally getting to the point where the only ones able to make the investment will be two or three [EDA] companies. Startups tend to go for not even a tool but a subset of a tool. To design a 100 million-cell chip, very few companies can do it.

SLD: We’re coming at this from two perspectives. One is from the user, the other is from the EDA company.
Domic: But if someone today wants to provide a full place-and-route solution with all the parasitic extraction, DRC and LVS, the R&D investment EDA companies need to make is enormous. You can’t invest more than 30% or 35% of your sales in R&D or Wall Street will question your existence. So we’re seeing a similar problem in EDA. A customer cannot just say they’ll design a 50 million-cell chip. EDA is seeing the same problem. They have to be selective about where they develop their tools.
Kaul: One of the challenges for EDA has been that with new technologies it doesn’t take a very large team to build the technology. Most successful products were built by four or five brilliant guys. Obviously the first release of the product has to have enough value that people will buy it, and the bar can go higher and higher as you move into more complex technologies. But that’s one of the reasons there has been more competition in EDA than is probably healthy.

SLD: Will that continue?
Kaul: As long as the current solutions are not meeting the needs of customers—if it takes five days to run place-and-route on a complex block, for example—there is an opportunity for someone to come in with a better solution. If you need 20,000 servers to run simulation and you’d like to see a 20x improvement, there’s an opportunity. It’s not easy, but it’s what you have to do.
Leef: When I started working at Intel in 1982, they believed the reason they would win was architectural superiority, their ability to push the state of the art in process, and because of their CAD tools. At that time, the EDA landscape was pretty bare and Intel had 300 to 400 people working on EDA tools. It was predicated on the fact that Intel didn’t believe anyone outside of Intel understood their problem well enough to solve it for them. At 22nm, Intel once again believes no one else understands its problem. It’s not inconceivable we might start seeing big semiconductor players bringing EDA back in house.
Kaul: IBM already uses a lot of internal tools.
Domic: It’s more complicated than that. Every quarter Synopsys announces we had one customer that contributed more than 10% of our revenue. At the same time, the internal team than what they had for EDA is larger. I don’t see a return to internal tools, but I do see a combination where they work with a few suppliers in specific areas, and those areas may change in time.
Leef: But if Intel decided one day that it was important enough to distinguish itself with EDA, that could have a big effect. It’s not economically challenging for them.
Domic: Nobody has money to do everything.
Busco: There will continue to be innovation by startups and small shops. It’s something that everyone benefits from. EDA is an academically rigorous and exciting field, so there are a lot of extremely bright people going into these areas. They’re anxious to start up a company with a small team, and we see the benefits. There are needs for new point tools. Some of the existing tools can’t keep up with design sizes or process complexities. Either the point tools from these startups will solve the problem or they will wake up the major players, which is a side benefit. The major players have a strong tendency to become complacent or focus their efforts elsewhere. When a startup shows them that something can be done in a revolutionary way either the startup will walk away with the business or the established player will turn the battleship and come up with a much better product, as well.

SLD: At 28nm and below, are the big chipmakers relying on internally developed tools until the other stuff becomes commercially available?
Busco: It depends on the style of designs. For digital ICs, commercial EDA comprises the vast majority of the solution. Companies have CAD groups to integrate flows and develop point tools where they can add value, but a customer will not write anything like a place-and-route or synthesis tool. Back when signal integrity was a novelty, we may have had to develop our own tricks. But now it’s part of every EDA tool, so there’s no need to develop an in-house solution.
Kaul: Whatever EDA can solve, customers will buy commercially. But EDA companies also have to make business decisions. They try to solve problems they think will give them a competitive advantage or which they can make a business out of. There are certain problems where the data required to make a good product is proprietary. Intel and IBM don’t want to share that with you. They’ll develop it themselves. Either that or the EDA companies don’t want to solve the problem for them because it makes no sense economically. But if these companies can buy commercially, it’s less expensive.
Domic: If you look at innovation at the large companies, Mentor and Synopsys have done a good job providing things that didn’t exist like, lithography checks. Everybody did chip layouts, even though to keep up with the set of rules at 28nm is tough. But when you look at lithography checks, we built a completely new router that will carry us to 28nm and 22nm. When I do see internal efforts, it’s because there is a lot of flux in terms of preferred rules. Every company interested in coming out early with a new technology is doing their own schemes to develop what is important and what isn’t. The investment from the large companies has been pretty significant and has managed to satisfy IC developers. I don’t see many people trying to develop their own lithography checker.
Leef: In the areas where the tool footprint is well defined, the major EDA vendors jump in, invest heavily and come up with good solutions. In areas where the footprint of the tool and the definition of the need are fuzzy, that’s where the customers have a tendency to invest their internal cycles and do things specific to them. But if you’re architecting a chip with 500 million gates, the architectural and system-level alternatives are profound and the EDA industry has not come up with a cohesive set of tool footprints in that area. Almost every customer I talk with that’s trying to solve front-end problems has a home-cooked solution or some combination of commercial, public domain and home-cooked. The boundaries between what the commercial tools can provide and what the in-house tools can provide are fluid, and that’s where we see internal EDA groups putting a lot of effort.

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.

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: Why is high-level synthesis, which has been around for awhile, suddenly so necessary?
Kaul: In the typical chip there are multiple physical partitions. It can take a typical design team 15 hours to get through the logic synthesis portion and a week to two weeks to get through physical implementation—per block. And it can take multiple iterations through that loop. Some design teams go through that loop seven to 10 times. They’re looking for ways to get timing closure much faster, and the only way to do that is to bring physical information up earlier in the process.
Cline: That’s not the only way. High-level synthesis guys can make much better tradeoffs into the RTL schedule before it even hits a logic synthesis tool, which can eliminate a huge class of timing problems.
Kaul: You’re still dealing with RTL after that.
Cline: I agree, but we own the schedule. So if the schedule gets filled up and you go through synthesis place and route and don’t meet the timing, you can go back through the high-level synthesis tool and change the schedule. You just can’t do that in RTL. We can make the flow smoother by allowing people to not make stupid decisions in the creation of that RTL.
Eddington: That’s one of the big advantages of high-level synthesis. You iterate quickly at the architectural level and you minimize the iterations that you have to do for back-end place and route.
Cline: You should never miss timing with high-level synthesis.
Kaul: It’s not so much a question of missing timing closure. It’s how long it takes you to get there.
McCloud: High-level synthesis allows you to get to timing closure more quickly. Let’s say you’ve hand-coded an architecture that completely misses timing. The time it takes to re-code , especially if it’s a significant architectural change, could be weeks to months depending on the complexity of the design. With high-level synthesis it’s easy to adjust the percentage that you’re reserving for placement and reschedule the design. And what happens when you have a spec change late in the design? That’s a nightmare to deal with in hand-coding, but it can be dealt with relatively quickly with high-level synthesis.
Cline: In addition, the tools that are coming out at the RTL level are doing smarter things with these designs. It does make it easier for us in the long run. The things that people are happiest with using high-level synthesis, which you would never expect, are the verification improvement and the predictable timing closure. You’d expect them to say productivity.

SLD: Is there a cost for that timing closure?
Biddle: And do you see more flip-flops?
Cline: You certainly can. We have a timing address knob. You can overfill the time schedule or you can underfill it. On average, we beat a hand-coded design between 10% and 20% in terms of area and still meet timing. Generally people would worry we are larger. We’re just a compiler. We can shrink down without a penalty.
McCloud: It’s a question of how much time you want to spend on a design. We’re typically within 10%. Sometimes we’re a lot smaller. Sometimes we’re bigger. If someone wanted to spend enough time they might be able to do a better job.
Kaul: It’s not an ‘either-or’ issue. It’s an ‘and’ issue. High-level synthesis can do certain things. If you want to add a pipeline to your design or you want to change your architecture, high-level synthesis is very well suited. If you want to go from RTL to GDSII in a 28nm design, then you have to have technologies that understand what’s going on downstream.
Cline: I agree. The better the logic synthesis tools get, the better the overall results.

SLD: How accurate does synthesis have to be?
Cline: It’s different for different abstractions.
Eddington: For architectural decisions you’re leveraging the capabilities of the logic synthesis tools. The decisions you’re making aren’t exactly where you’re going to put a register but roughly how many you need and roughly where they need to go. You let the logic tool do the fine-tuning.
Kaul: It’s very design-dependent. Some designs are pushing the performance. Logic synthesis has to get you very close to where you’re going to be at the end of place and route. Otherwise you can have a lot of iterations. If your design is not pushing performance, then I think you have a lot more give.
Eddington: Logic synthesis has to be pretty accurate. You need to make better decisions at the logic level. Integration with placement is still an ongoing area of innovation and improvement. The high-level synthesis, in terms of logic accuracy in the architecture and placement of registers and so forth, doesn’t have to be quite as accurate as the RTL logic synthesis.
Cline: Our customers get a number for a baseline, run that through logic synthesis and then correlate the two. You want them to be as close as possible. After that, one of the nice things about a high-level synthesis flow is the turn is really quick—literally minutes. We don’t hear people running things for four days. If it’s running for four hours, we wonder what’s going on. That’s a curse from a licensing standpoint because you don’t run this stuff for that long. But at the end of the day, they’ll run a number 100 times and then track a number. If that number correlates with what logic synthesis would have looked like, had they run it every single time, then I think they’re generally pretty happy. It doesn’t have to be 100% correlation, but we’re not going to run logic synthesis every time because it’s fairly expensive.
McCloud: It needs to be able to give you relative comparisons. All of these tools eventually take a candidate design down through RTL synthesis to give you some accurate estimates. Once you have that, you’re comparing the candidate architecture to new ones you can create in a matter of minutes. If your candidate architecture has 150,000 gates and you have another one that has 200,000 gates, is that relative comparison correct? Our number is accurate enough to do exploration. Typically you’ve got a high-level design model that’s technology independent. You take that into an FPGA and prototype it. When you take it to ASIC, almost always you do multiple architectures. We estimate the timing and where potential timing issues will occur. The next step is to take those through RTL synthesis, and that’s when you’ll know for sure. Did it meet timing or not. The architectural exploration benefits are really the big win, along with the verification benefits—being able to do those transformations without having to change your high-level model verification.

SLD: What determines who wins in high-level synthesis?
Cline: The technology takes a bit of time to mature. It’s quite easy to synthesize a C algorithm into some RTL. That’s not a hard problem and it makes the barrier to entry look fairly low. But getting a C algorithm into RTL that’s actually manufacturable is actually quite a hard problem.
McCloud: It is centered around completeness of flow. But I would say the most important aspect is the tool that addresses the verification side of things. When you look at the RTL design flow today, 60% to 70% of the design cycle is consumed by verification. A high-level synthesis tool needs to address the verification side of that problem. The approach you take with high-level synthesis can actually complicate verification if you don’t do it right. One of the important things is to have a source description that is deterministic and predictable so you can re-use that work you’ve done in C down at the RTL level. The tool that combines synthesis and verification is the right approach.
Eddington: Both of you guys stated the obvious. A high-level synthesis tool has to deliver productivity in design. It has to deliver productivity in verification. That means reliable verification from high-level models. But right now we’re all limited by these application-specific domains. The question is how we expand beyond those.

SLD: What are the limitations?
Eddington: Mostly it’s the algorithmic guys who are adopting this.
McCloud: I think that was the case three or four years ago. That’s not the case anymore.
Cline: I would agree.
Eddington: Achieving higher levels of abstraction and having design entry environments that are tailored to the different application spaces is what’s going to help this expand a lot more. We’re doing something a little different. C is important, but we have the Matlab in the model-based stuff. That seems to work very well for designers in the system-level space who may not know RTL or C. Software engineers and video engineers know C. But other environments are needed to expand this beyond the application spaces now being addressed.
Cline: Do you worry that ability of the system designer who doesn’t understand RTL is diminished because of their lack of understanding about how the architecture is implemented?
Eddington: No. I don’t think there’s any reason you can’t have a fundamental description that’s understandable and capable of being captured by a guy who has no understanding of RTL.
Cline: We would disagree. We’ve had designs that involve a hardware engineer who knows nothing about C and someone who’s an expert software engineer who understands C to the nth degree. The hardware designer will kick their butt almost every time. The reason is that algorithms can be specified in ways that imply architectures that cannot be implemented in a reasonable amount of silicon. An H.264 implementation is a good one. You can read the data in, but data has a temporal aspect in hardware. In software it’s always there in a buffer and you just go get it. But in hardware it comes in 8 bits. What do you do with the first 8 bits?
Eddington: I agree that if you ask a software engineer to write something in a sequential language, he’s going to write something that cannot be converted into a hardware implementation without having to do some fundamental changes. In our case, we’re not doing pure language. We’re building on an approximately timed, higher-level, model-based data flow graph.
McCloud: High-level synthesis doesn’t remove the need to design. You don’t just download an MPEG-4 algorithm and push a button. It’s not a tool intended to turn software developers into hardware engineers. You still need to understand what you’re trying to create, and that’s best done by hardware designers. But what it does do is remove a lot of the details you don’t have to worry about.

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.