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.

Tags: Automotive, EDA, IBM, Mentor Graphics, Oasys, RTL, Synopsys, TI, VHDL

This entry was posted on Friday, March 5th, 2010 at 7:49 am and is filed under Round Tables, Technology Features. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.