By Ed Sperling
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.

SLD: Where do models fit into the standards world?
Perrier: Models are becoming the central things that engineers work with. But it goes much further than just translating the code into gates on the chip. There are power models, performance models and virtual platform models. It can be a custom-based approach by aggregating multiple IP blocks or a top-down approach starting from a functional or architectural description or a power model. These are very different approaches for designs.
Sanguinetti: There’s a lot more impetus to settle on a standard when you have models that people want to use from different sources.
Perrier: The whole point of models in ESL is to make sure those models work together.
Sanguinetti: Right, but those models are coming from different places.
Perrier: There also are a lot of them. Today you cannot find one model to represent all the different facets of a design. If you want a full picture of a system, you need to get all those models together, combine them, and simulate them so you can make your architectural tradeoff decisions on the basis of power. Power is becoming as important as everything.
Kaiser: The first goal for a system now is to improve interoperability because of all the complexity. You need to adapt that for every domain. That’s the case with power and timing.

SLD: Whenever a company turns over technology to a standards group, they have a jump on everyone else because they know the technology better. Is that window shrinking or growing?
Sanguinetti: It depends on the technology. If you need a standard to make models interoperate, no one has a big advantage.
Schirrmeister: It’s not a complexity issue. That’s solved according to how a design process is structured. The standards support that structure. If you look at the next big systems on chip, you have blocks in there and you need to be able to deal with those blocks. That includes development of the blocks, which is where high-level synthesis comes in. You need standards for a language that you can use to synthesize. You need to be able to deal with re-use of those blocks. That’s where SPIRIT comes in. You characterize those blocks and give them power formats. And then you need to integrate those blocks into the full chip. So you need the higher-level model for verification and for performance analysis, which is where TLM simulation comes in. It’s not that complexity influences the window. It’s that the complexity changes the design process, and for the different components you have individual windows on how to deal with this.

SLD: How far along are we with this?
Schirrmeister: With TLM 2.0, it’s like we’ve standardized on the VCR with VHS, but all the remotes don’t interoperate because everyone has different controls. That’s the next thing we’re trying to standardize on—the configuration and control of those TLM models. Those standards grow and build on each other.
Perrier: The EDA industry has a lot to learn from the software industry in this domain. They are way ahead of us in this area because they have been dealing with interoperability for a long time.
Schirrmeister: They have been dealing with this problem since 1968, and the last time I checked they still haven’t figured it out. But there is at least some interoperability in the software world. I assume you’re talking about UML (Unified Modeling Language).
Perrier: UML is one. There are also meta-model techniques. IP-XACT is an XML-based standard. In the software world you have Ecore, which an Eclipse implementation of the [Object Management Group] standard.

SLD: The software world has its own issues that have been going on for decades, most notably in operating systems, interfaces and parallelization.
Schirrmeister: And I’m not sure what we’ll actually learn from the software side. In the software world you have a company like Microsoft saying, ‘Here it is,’ and everyone has to deal with it. The same was true with UML for awhile, where Rational and Telelogic were dominating the market.

SLD: But isn’t this still a top-down definition?
Schirrmeister: Everything does need to fit into a top-down model, but the work is being done in two directions. The problem is that it’s like digging a tunnel from both sides where you don’t meet in the middle. You’re pushing down with high-levels of abstraction and UML is tunneling up, but they don’t quite meet. Now we are trying to figure out ways to see how UML will fit.
Kaiser: This is the challenge of the ESL domain. But if a new standard appears, there is a question of whether it will survive because it has to join these two worlds, from UML to hardware constraints.
Schirrmeister: When you talk about standardization, it’s always about restriction. You have this big item about what UML covers, and conceivably you can develop a profile of UML that may fit into something that will be able to synthesize down to RTL. That’s like a UML for hardware profiler. If this is SystemC, there is a subset that is synthesizable. The same happened with Verilog in the past.
Perrier: The software industry calls this domain-specific languages.

SLD: So is UML the answer?
Kaiser: I’m not sure that today UML can respond to the hardware constraints. We may have to modify UML because it was not created for hardware.
Schirrmeister: A standard never does something for itself. You always have to have a user need. Hardware developers are not that concerned if something is UML compliant. They have a very specific need to get to a virtualized model of the embedded hardware they’re developing as fast as possible so they can start software development. If my solution happens to be that I have a technology that takes UML, restrains it to a domain-specific subset and then allows a fast implementation, they will happily adopt it because it serves their need. But they won’t do it because it’s UML.
Sanguinetti: That’s a very relevant point to this discussion. Back when Synapse was working on a precursor to SystemC, I looked at UML. It was too far removed from the kinds of problems we were looking at.
Schirrmeister: I think we are getting closer. It’s just a question of how fast is the train going.

By Geoffrey James

Until a few years ago, SoC designers focused almost exclusively on ASICs. While it was theoretically possible to create an SoC design for an FPGA, the programmable chips were too bulky and pricey to be useful for much more than prototyping. Today, however, designers are increasingly turning to FPGAs for their SOC targets for production systems.

Why the sudden upsurge in SoCs on FPGAs? The answer, as usual, is Moore’s Law – and the design hassles it creates. ASIC designs at sub-65nm are becoming increasingly expensive to develop. And turning an ASIC design into physical silicon can take months, so if there’s a design flaw that’s elapsed time that could mean missing a market window. By contrast, FPGAs offer SoC designers the flexibility to tinker and test without the expense and risk of a manufacturing run.

Even so, there’s more than economics at play here. Four key technical trends have conspired to make FPGAs more viable as a platform for serious SoC production.

Trend #1: Today’s FPGAs are gaining features appropriate for SoCs.

In the past, FPGA were often implemented as an element in a larger chip set that would be integrated on a board. Standard functions were relegated to other (smaller) chips, while the FPGA (which was hefty by comparison) carried the part of the design unique to the end product. This tended to make FPGA designs expensive because the FPGA chip was more expensive than a comparable ASIC and the additional chips and assembly added additional design and manufacturing costs.

Today, however, FPGAs are much smaller and more efficient than before. Xilinx, for instance, makes FPGAs at 40nm, while Actel has developed a 65nm version with flash memory. Though FPGA circuitry still takes up more physical space than non-programmable circuitry, at 65nm and below there is more than enough raw circuitry to support a wide range of designs.

“We see FPGAs as a major vehicle for innovation among our customers, who have used it to develop capabilities that we were later able to incorporate inside our standard products,” says Pranav Mehta, CTO of Intel’s embedded and communications group.

Newer FPGAs also include standard functions such as USB communications, sometimes encapsulated inside “hardened” (i.e. non-programmable) portions of the chip. Some FPGAs even have CPU cores built into them or support special versions of CPU cores (such as an ARM processor) that can run inside the programmable portion of a hybrid FPGA.

“The inclusion of advanced features makes FPGAs strong candidates for even complex SoC designs,” says John Swanson, senior manager of the solutions group at Synopsys.

Trend #2: The FPGA tool sets are becoming more sophisticated.

Programming FPGAs originally involved using rudimentary tool sets provided by the FPGA maker. However, as FPGAs (and the applications on them) have gotten more complex, EDA firms have come to the assistance of designers with better FPGA development tools. Forte Design Systems, for example, provides an ESL design environment that supports FPGAs as effectively as ASICs, according to Brett Cline, the company’s vice president of marketing and sales. “We have one client who is doing seven designs, three of which are targeted at FPGAs,” he explains. “We even have one client who is porting an ASIC design back onto an FPGA for further development.”

The traditional EDA vendors have taken FPGA more seriously over the years because their customers demanded it, according to Daniel Platzker, the product line director for FPGA synthesis products at Mentor Graphics. “While FPGA tools have been around inside Mentor since 1992, it’s become a major market for us in the areas of synthesis, verification and simulation,” he says. (See Figure 1)

Fig. 1: Mentor Graphics' FPGA design environment.

Andy Biddle, director of business development at Magma agrees. “We see even customers using FPGAs to develop mix-signal designs that previously would have been difficult or impossible,” he says.

The demand for better tools was spawned by the fact that newer FPGAs can experience some of the same challenges that occur in ASICs. “These designs get so complex that it’s necessary to have professional-grade routing tools, for instance, to ensure that the chip doesn’t run into any problems with timing and closure,” says Juergen Jaeger, director of marketing, for the Confirma rapid prototyping platform at Synopsys.

Trend #3: SoCs are proliferating into a wider range of products.

As sophisticated electronics get built into an ever-wider variety of devices, it’s creating an almost insatiable demand for FPGA-style SoCs. “Designers in third-world countries work in environments that won’t support and can’t afford a full ASIC development process,” explains EDA analyst Gary Smith of GarySmithEDA.com. “In order to save money, they’re using FPGAs in everything from vacuum cleaners to fans to pumps.”

FPGAs also are showing up in products elsewhere in the industrialized world, according to Tom Feist, senior director of marketing for IP products at Xilinx. “We’re seeing substantial FPGA interest in the automotive industry for SoCs that can be easily upgraded to handle new features, like shape recognition and object avoidance,” he explains. (See Figure 2)

Relative markets for FPGAs vs. ASICs

Given the wealth of potential markets, it’s probably not surprising that the number of FPGA design starts dwarf the number of similar ASIC design starts. “There are 140,000 FPGA designs done every year as opposed to 10,000 to 12,000 ASIC starts,” says Rich Wawrzyniak, senior analyst at the market research firm Semico. While he counsels that only 5% of those FPGA starts end up in finished products, that’s still an enormous amount of SoC development.

Trend #4: Converting from FPGA to ASIC is constantly getting easier.

Targeting an SoC design at an FPGA platform is a cost-effective way to develop a product. Typically, companies use the FPGA in the new product until it becomes clear that product volumes will be large enough to justify an ASIC version of the chip. “The FPGA has come a long way in terms of the fundamental hurdles of unit cost and power utilization,” says Intel’s Mehta. “But there’s still no question that for large volumes, ASICs will continue to remain more economic.”

Fortunately, it’s becoming easier than ever before to re-target an SoC design from an FPGA to an ASIC. Forte, for example, supports two design trees from the same code base, allowing chip designers to target both platforms. “We encourage designers to think about their designs at a higher level, without being forced to worry over much about whether the final chip is programmable,” says Cline.

The use of an FPGA in early development phases can reduce overall costs at the corporate level because the lower cost lowers the risk of a product failure. “FPGAs allow you to more easily hit a market window, thereby making it more likely that you’ll have a hit product,” explains Synopsys’s Jaeger. And because the door is open to move the design to an ASIC, if and when the time is right, it’s no wonder FPGAs are proving so popular among the SoC-savvy.

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.

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 (OCP-IP), and Michael Meredith, vice president of technical marketing at Forte Design Systems. What follows are excerpts of that conversation.

By Ed Sperling

SLD: How much of the standards effort is being driven by the foundries?

Schulz: Let me try to answer that in context. Timing of a standard in the market is a very delicate thing. It depends on when you can get the resources together to really do the job right to define a standard and when the market is ready to adopt it as a standard. You have to do dynamic adapting, which is a case in point with our DFM coalition. Back in 2002 we had heard about the rising mask costs and predictions were that by 2006 we would be unable to mask anything because of the cost. We formed a coalition, thought we would get all the mask makers involved and everyone would win because it was about efficiency. What we learned was the mask makers’ business model was broken. They felt they had very little to gain from efficiency. They had no incentive. The others said the real problem wasn’t masks. We tried to get the foundries engaged at that point but the market wasn’t ready. There was a lot of debate about what DFM was. We had two years to get the right folks together, the right dictionary, and now we are putting together reference flows and standardizing hot spots and meta language and DFM libraries.

Trivedi: That’s part of the need to experiment and learn from mistakes and then do the right thing.

Mackintosh: I think the fundamental problem is that people don’t understand that standards are products. We’ve actually invested a lot at OCP-IP in thinking about this. We’ve created an infrastructure that adds value to the standard. But all the items in the infrastructure were developed from a single concept—we don’t develop anything unless there is a need and greed dynamic. There are a bunch of people working on it because they need it and a bunch of people who say it benefits them financially to get that. That’s why the infrastructure we have is so extensive.

Schulz: We engaged in phases and steps. It was a long set of phases in DFM before the foundries would commit. The first group that said they need it from a greed standpoint was the Common Platform. But even though that was six or seven very large companies, it wasn’t enough. We recently added more very large companies, and then we got other contributions. We got more participation. And then we got questions like, ‘If we get involved, will you support encryption so we can put our secret processes in that?’ We of course said yes. And then the interface became standard and stable because they were all contributing with a high level of trust. But it takes time to build that trust. The foundries started out saying, ‘That’s a design issue. It’s not our problem.’ Then they went to, ‘It’s just the interface.’ But then something else came up that intersected with that, and they said, ‘Well, maybe we should be engaged.’ The foundries are just driving the back-end part, but they’re having more and more influence in the reference flows and they’ll continue to drive that.

SLD: Historically, standards were the lowest common denominator and for the real value you had to go beyond that. Has that changed?

Trivedi: I’m not sure it’s the lowest common denominator. Sometimes standards are enablers. In the upper end of the design spectrum, once we had System Verilog as a standard language, that’s when things like the verification methodology became an issue. People recognize now there’s a standard and it’s stable and you can build your infrastructure around it, so there’s a notion of methodology based on the language. The move from language to methodology isn’t lowest-common denominator. It’s a broader methodology. What’s happening is we are minimizing duplication of effort.

Barkley: A lot of the industry is very reactionary. People tend to react to yesterday’s problem with a standard so you can go forward. I think it has to go both ways. You’re not going to anticipate everything that’s going to happen. On the other hand, you can’t be totally reactionary. When we do advanced processor design we don’t let standards dictate what we do. But obviously we want to take advantage of them. From a high level we look at where we want to go and what’s already in place so we’re not duplicating efforts. We want to focus on the differentiation part. But by participating in these standards we actually learn from other companies. There’s lots of cross-pollination going on, and frankly it’s not entirely clear who our competitors are anymore.

Meredith: Rather than holding down the users of standards to a least-common denominator, I think they provide a stable structure on which everyone can innovate. It’s something they can depend on. You use the pieces of standardization that lift you up, and you innovate above that.

Barkley: We bring stuff, other companies build upon that and bring more stuff to the table, which actually helps us.

Schulz: Part of it is an understanding of where to compete and where to share. Mature industries have a good handle on that so they can promote growth. We are beginning to get near maturity. I don’t think we’re there in either EDA or semiconductor. EDA isn’t as far along as the semiconductor industry, and semiconductors aren’t as far along as the general electronics industry. But I think we are improving, and the standards do not need to be the least common denominator. There does need to be alignment before you can create a standard, but it doesn’t mean the standard is holding anything back.

Meredith: This all reflects an organizational equivalent of the tall, skinny engineer. If, to succeed, the engineer needs to know how to build a microprocessor, write the compiler, write the application software that runs on it, write the RTL that constructs it, lay it out, build the mask and do the lithography, he can’t succeed. Organizationally, companies have the same problem. If they attempt to be the best at all of those things then they lose focus. They find things that are key to the special things they do to deliver value. That requires collaboration, and the collaboration forces standards.

Mackintosh: The industry today is still internally focused. Folks will always do everything themselves unless they believe there is something they can move out and standardize on, and get to that standard in a reasonable amount of time. But the primary motivation is still internally focused.

SLD: There’s also some religious issues involved in standards, right? No matter how they interface, there are still battles over these.

Mackintosh: Yes, but I don’t think you need to resolve those. There are some places where standards do compete, and from a business and/or technical reason, people need to have more than one. They find their own niches and applications and the world works with that.

Schulz: But you always have to have a pulse on connecting with people in all parts of the supply chain. Sometimes there’s no boundary to a standard. If you carve it too small it doesn’t have any value. If you carve it too big, sometimes you’re stepping on competitive toes. And if you time it wrong, it’s not going to be effective even if it’s sized right. When you get enough people saying it’s a thorn in their side and not adding a competitive advantage, that’s the right timing.

Trivedi: Standards represent information. The question is what are you going to do with that information. The standards that are more successful are the ones that are used in a broader context of multiple ways to use that information. For example, HDL by itself is useless. But as soon as you put your design information into it, that standard use allows you to go do synthesis, simulation, timing analysis and power analysis. The standard itself wasn’t interesting until you find a deployment for it because it allows the interoperability among tools. If it is broader, it is better. If it is only one vendor that’s supporting the standard vs. broad support by a number of companies it is less useful.

Schulz: We’re wrestling with power modeling right now. How do you represent a model of power at an architectural level? It’s an open question. The industry needs an answer, but we haven’t figured it out yet. There are implications all the way down to your test strategy and other parts of your physical view in your DFM into your timing. Power is a flow, which makes it a very broad effort.

Barkley: I think many competing standards are going to work themselves out. It’s like Blu-ray and HD. The reason this happens, though, is there are so many smart and innovative people in this field. This is an evolutionary journey. We’re never going to be done. But I also think this levels the playing field a bit. The small companies are benefiting from IBM and TI and Synopsys and Cadence and Mentor Graphics, where they wouldn’t necessarily have access to this information and knowledge if there were no standards.

Mackintosh: Darwinism is particularly relevant to the standards world.

Meredith: But there’s also another way in which we end up with the competition within standards having less impact. Quite often, as we move forward, another abstraction gets put into place, and then the differences between some lower standard don’t matter as much. They can either use one or the other, or both.

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.