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.

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.