Experts At The Table: Evolving Standards

System-Level Design sat down with Keith Barkley, senior engineer in IBM’s systems and technology group; Steven Schulz, president and CEO of Silicon Integration Initiative (Si2); Yatin Trivedi, director of standards and interoperability programs at Synopsys; Ian Mackintosh, chairman of the OCP International Partnership (OCPIP), and Michael Meredith, vice president of technical marketing at Forte Design Systems. What follows are excerpts of that conversation.

By Ed Sperling

SLD: What’s the value of standardization vs. differentiation
Trivedi: It’s a question of what’s the cost of differentiation. Differentiation is only worth spending money on if there is a business value. More and more people realize that languages are not the differentiator. It’s the simulation or synthesis or timing analysis of that. You distinguish between the standards or formats or features vs. the algorithims and implementations. This part may be common knowledge, so everyone benefits equally. That’s where you go into defining standards. But maybe our algorithm can squeeze .2 seconds out of this. That’s a differentiator.
Schulz: That applies to when we stopped doing tools development in-house. I’m actually seeing things go both ways, though. Companies that have come from a large infrastructure with internally developed tools suddenly realized that it isn’t unique leverage for them—particularly compared to what else they could do with those resources. That’s a buy decision. You move from make to buy. There are other companies that never did any internal development. Now, in very specific areas, they want to plug in something that’s particular to some vertical market they’re trying to fit into. They can’t implement the methodology that’s important to them without some software development. They don’t really want to buy an EDA tool with a graphical user interface. They just want some capability put into the flow. There will always be some part of that.
Barkley: At IBM, we can’t afford to duplicate. It doesn’t make any sense. I work in an advanced processor design organization, and historically our requirements for tools are technology are usually one generation ahead of what’s commercially available. So the stuff we really focus on now is a differentiation. At IBM, 45nm is considered legacy now. The things put into standards are there for a reason, and it allows us to be a little more proactive and less reactive. We’re able to share IP and research without having any official contract.

SLD: How much of this is being driven by the foundries?
Barkley: A lot of the gaming companies come to IBM and collaborate with us, and they’re quite happy to have stuff made in our fab. But they also want a second source. They can go to Chartered or Samsung. The Common Platform and standards have made that possible, while 10 years ago it wasn’t. But now that we’re putting together our customized design flows made up of internal and external databases, the one area we’re having trouble with is design automation and testing and verification. We need automated software testing in flows. This is a big problem. For an EDA company standpoint, the last thing you want is for IBM or any other large company to find bugs or defects in your code in their design shop. We’re taking tools from Synopsys, Cadence and Mentor and plugging them in with tools from IBM on top of Open Access and putting flows together, and that’s when some of these things break. We can’t afford internally to find these bugs. I’m not convinced there has been a lot of effort put into this. We really need this.
Mackintosh: One of the classic illustrations of industry being product-centric and really adding value is that you end up with a very short list of providers. The motivation for collaboration between the major players is startlingly low. There have been some minor points of contact, but they perceive it as being their individual markets as opposed to growing by collaboration. And they’ve always behaved that way.
Barkley: But I would think that if it would benefit IBM and other large customers, that should be enough motivation. We’ve made great progress using Open Access.
Trivedi: That decision was very straightforward. The development resources that have gone into it under the Open Access Coalition over the past several years have made it almost irrelevant for us to consider building our own. It doesn’t make sense. There is a ready-made interface and you make use of it. The same happened in Accellera where users said they have a VMM-based methodology and an OVM-based methodology and they can’t share test benches. A year later that reference library is available for everyone to use.

SLD: Is this approach working?
Mackintosh: What we’re doing is retrofitting standards to fit the technology, when in reality we should be planning the standards and having people build the products.
Trivedi: It’s a question of how much did you know beforehand and how much did you learn through mistakes. You sometimes need short-term solutions. The next phase is longer-term because you don’t have to do the interoperability. In general, interoperability almost always implies changing formats and there is overhead associated with that.
Mackintosh: There’s an inherent education problem. People specifically want to compete with one another and don’t want to share. They don’t understand the concept that you can grow a market by collaborating. It’s like we’re forcing collaboration out of need—time, money and risk.
Meredith: That’s correct. The standards come late in part because people do things their own way, then realize that they need to collaborate and so standards are formed. But you also have to finish a certain amount of innovation before you wrap some strings around it and combine it with standards. A premature standard is as bad as having no standard. It may only allow you to solve 80% of the problems, and therefore you solve nothing. If there is agreement on best practices to solve 100% of the problem and then you standardize those best practices, you end up with a more solid standard.
Barkley: The other problem is that we have so many concurrent projects going on at the same time, there’s a cost in transitioning to this new stuff. We don’t have a bunch of people off on the side working on this advanced tool methodology stuff. While we’re doing these advanced projects, we have to be dealing with all of this.