System-Level Design sat down with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Ghislain Kaiser CEO of DOCEA Power: John Sanguinetti, CTO at Forte Design Systems, and Vincent Perrier, Cofluent Design co-founder and director of products and marketing. What follows are excerpts of that conversation.

By Ed Sperling
SLD: Does interaction of new and not-so-new improve a design, or is it something of a legacy drag on a design?
Sanguinetti: Standards improve a design. If they restricted it, people would go outside the standard. One of the lessons I learned doing design verification at a startup is that if the designers restricted themselves to what the tools did well, we got our job done faster and better. Restriction is often a good thing.
Perrier: All of the standards leave some room for the designers to go around them. There are vendor extensions to IP-XACT. With TLM, you can do pretty much whatever you want because it’s C++ and VM. There’s always this kind of area around a standard for it to be effectively implemented and used.
Schirrmeister: There’s always a price to pay for adoption. You understand German history better if you speak German. That is an entry price. Standards do make the design easier because you have fewer ways to shoot yourself. The current standards have restrictions on how you do modeling for effective transaction-level simulation, but you are much more productive using them because the tools interoperate. So you can take vendor A’s model and synthesize it with vendor B’s tools and simulate it with vendor C’s technology. That productivity boost comes with an entry price. You need to follow the standard. If the standard is well thought out, you won’t do it with a completely blank sheet. You have a starting point that is 80% there.
Perrier: At this point, the customer doesn’t have the technology in-house for virtual platforms. They don’t want to start everything from scratch. They will turn to available standards and solutions.
Schirrmeister: Still, it’s solving the problem of simulation that’s now interoperable. It’s like a VCR playing on every TV. The next step is how you do save and restore, how do you configure a model. Those are sideband signals. They are proprietary things you have built on standards.
Kaiser: The first goal is to improve the design, not to make tradeoffs.

SLD: Do we get to the point where there’s an inflection point, like power issues, and nothing works anymore?
Sanguinetti: That’s when additions get made to the standards. You add new features and different ways of describing things.
Schirrmeister: It depends on the standard. Standards like SPIRIT always had user extensions. That’s where sideband signals come in. If 80% is covered by the standard description and for the next 20% you need to invent something, if someone takes that into a different tool they are at risk of only understanding 80% of it. The other 20% was not known. That’s the proprietary sideband signals. Those are typically used for extensions. If something changes, we need to add in. A good example is multicore. How do I describe functionality so that I can split it across different processors? You create your secret sauce with an extension, and over time you feed them back into the standard. It’s all about the flexibility of description.
Sanguinetti: If you want an example of a standard that wasn’t well thought out for an extension, think about Verilog AMS. People said, ‘We need to add analog/mixed signal to our modeling,’ but Verilog had no extension capability. So they figured out how to add it in and it became something different.
Kaiser: There’s a difference between an extension and secret sauce, as is the case with SPIRIT. This is what we’ve seen with UPF and CPF. Many companies adapted it for their own needs. This is a nightmare, because we have to develop a specific interface for every customer. IP-XACT is an example of where you have a standard and extensions that can be adapted for special needs.

SLD: One of the problems with models is that they can be wrong. Do standards make that better or worse.
Perrier: By definition, a model is an abstraction of reality so there is always a margin of error.
Schirrmeister: Just for the sake of argument, I would question whether models are wrong. It’s really difficult to re-create the pig from the sausage. You do something with the model. You add to it. You process it. And out comes a more detailed representation. The model can only be wrong if you are trying to recreate it from something that is more detailed. Depending upon who you talk to, you can take away the wrong piece of information to abstract it. The verification engineer needs cycle accuracy and the algorithm engineer couldn’t care less about the registers. You can take away the wrong pieces. So models in an ideal world, as long as they’re part of the implementation process—in essence, they’re part of the pig from which you make the sausage. They are something different than what you process downstream. Do standards help to improve that? In my mind they do. Especially at the interface, to achieve a higher level of abstraction and get faster you use different simulation technologies. You use stream-driven simulation or synchronous data flow. And then the RTL person, later on, questions whether this higher level of abstraction is accurately reflecting what they’re doing on the hardware. The answer is no. You’re trying to solve a different problem. But for standardizing the description and how you translate that, standards do help.
Perrier: That’s a good point. Where standards can help is in the transition from one level to the next.
Sanguinetti: A standard just reduces the amount of freedom, so you have fewer opportunities to make a mistake or go down the wrong path. It doesn’t reduce the amount of freedom to the point where you can’t make mistakes or you wouldn’t be able to create anything interesting.

SLD: How accurate are these models?
Perrier: If you look at an airplane control, that’s built using models. This is a mix of formal languages and models, but there’s no ambiguity. These models fly aircraft, so they can be very accurate.
Schirrmeister: The reason why it works in the military world is that you believe in the transformation from one level to another. Some of the mil/aero applications require code inspection at a higher level. But you are very precise in how you restrict yourself so you can formally prove that things work from one level to another. The problem with UML is that one representation can mean five different things. In consumer electronics where people are hacking away on hardware they think will be developed, it’s different.
Kaiser: The UML standard has come a long way. That limits the misunderstandings between teams to reduce errors.

Tags: Cofluent, Docea, ESL, Forte Design Systems, standards, Synopsys

This entry was posted on Thursday, November 19th, 2009 at 12:01 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.