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; Vincent Perrier, Cofluent Design co-founder and director of products and marketing.

By Ed Sperling
SLD: System-level design goes faster with standards. Where are we today?
Schirrmeister: In chip design there is a difference between designing the IP and integrating the IP. There are standards for designing the IP, and going toward implementation there is the SystemC synthesizable subset, which feeds into high-level synthesis. That’s one standard. When it comes to integration, you need to be able to simulate. That’s where transaction-level simulation based on TLM 2.0 comes in. You need to be able to express topology, which is where the SPIRIT standard comes in. Then there are other standards for data capture. Then there is the whole embedded software world, where there are 10 or more standards for debugger integration.>
Perrier: For us, the standard that is really important is TLM 2.0. It has given very good results.

SLD: How is TLM 2.0 working out?
Sanguinetti: There’s always a tension between current practice and standardization. If a standard is going to be successful, there’s always some precursor work that existed to set it in that direction. A standard then coalesces. It’s not that common to have a case like Verilog where it became a standard. In the case of SystemC, there were several things that did the same things in the same way. TLM 2.0 is the same. People have been doing transaction-level modeling with SystemC in a non-standard way. They made their own. OSCI gets involved and comes out with a standard, and now everyone has to move to that. In a lot of cases, you can argue that the standard du jure is inferior to some of the technology.
Kaiser: It is a long time from the time a new standard is introduced to when it is implemented. Last year we saw a lot of new standards with IP-XACT and TLM 2.0, and UPF and CPF. Now they will be implemented by design teams. It seems that after this period, some of these standards will converge, as we have seen with Accellera and SPIRIT. UPF and CPF will likely converge. So will some of the other ESL standards.
Schirrmeister: This is like driving an automobile. Standards bring the car from second to third gear. Proprietary techniques take you from first gear to second gear. With Synopsys there were tools in C that were merged into SystemC. It’s really the second to third gear where you want to make sure the proprietary tools don’t remain a niche market. With TLM, for 10 years we had the tools to do virtual platforms, but it turned out we always needed a custom interface to go from one tool to the next. We’re finally moving that from the second to third gear, and hopefully it’s like a Ferrari so it happens really fast. SystemC is the platform, but all the interfaces today may not have found a working group. We are trying to gauge with proprietary work the user interest.

SLD: Frank (Schirrmeister) said the best way to get to a standard is from a collaborative base. John (Sanguinetti) said the best way is from a proprietary base. Who’s right?
Sanguinetti: Most standards evolve from initial efforts that are proprietary.
Perrier: Some company has to invest at the beginning to do something. Companies don’t get together and say, ‘We’re going to create a standard today.’
Schirrmeister: If you have enough user pressure and proprietary technology, that’s when standards work. You need to get over the niche market. That’s why we did SystemC back in 1998. Later we got together with companies like CoWare to drive TLM interoperability platforms. Those proprietary tools are good for the very early adopters, but once you hit the plateau you need to make sure standardization kicks in to get it into the mainstream.
Kaiser: The market doesn’t like a too-perfect world. There needs to be competition between standards. That is the case with CPF and UPF and between System Verilog and SystemC. Competition is required.

SLD: Is this like Darwinism for standards?
Schirrmeister: Yes. When we donated part of the technology that had been acquired from Virtio into the TLM working group we were very clear that virtual platforms were at a crossroads and it was essential that models can come from all sources. The problem we had at the time was that if you integrated a processor from somewhere, you either had to do a very tight integration or it would be very slow. Users were telling us it was too slow to use, so we basically took all the pieces in the working group that make virtual platforms fast and standardized on those. That includes things like the DMI and temporal decoupling. But there is Darwinism in there because once you have standards, proprietary tools have to follow. If you donate something, you are at a disadvantage for awhile because they do change your stuff. You have a proprietary solution, but it now has to work with the new standards, which are slightly different from what you developed in the first place. The company that comes in after the standard is created actually has an advantage in that respect.

SLD: Do restrictive design rules at the advanced process nodes have an effect on standards?
Sanguinetti: If what you’re doing becomes the standard, you’ve got a leg up on everyone else. But I think it’s still really the case that successful standards are built from the ground up.
Schirrmeister: You need the cooperation of others even if you are the monopolist.
Sanguinetti: It depends on how much market share you have. Cadence was the one with the greatest market presence and they could say Verilog was a standard. SystemC was a different story because there wasn’t much use out there.
Perrier: What is new with ESL is it is trying to address new problems driven by the complexity in new chips and systems. In the past you had standards mainly driven toward implementation and silicon prediction. Now there are standards for all sorts of problems that become mainstream. Today ESL is addressing implementation and high-level synthesis, but it’s also addressing early software development, early power analysis and architecture exploration. There are different standards emerging for these different areas.

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

This entry was posted on Thursday, October 29th, 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.