August 1, 1997

Interoperability: myth vs reality

by Wolfram Blume

The need for two products to agree on interpretation--or to agree on anything--is at the heart of the issue.

Interoperability is the most often requested capability of EDA software. In survey after survey, the biggest gripe of EDA users is that products do not talk with one another. Despite 15 years of customer dissatisfaction, little progress has been made.

In an attempt to address the interoperability problem, various standards bodies have promoted--and overpromoted--various standards. EDA vendors have cited Frameworks, EDIF, and, more recently, Microsoft's object linking and embedding (OLE) as the Holy Grail of interoperability. Yet, the goal of EDA products' ability to talk with each other is as elusive as ever. To understand why these standards haven't solved the problem, you have to consider what standards can provide and what interoperability actually requires.

Communication requires both a common syntax--rules for arranging messages--and common semantics, an interpretation of the meaning of messages as they appear within contexts. Rules are rather straightforward; interpretations are not. Not surprisingly, interface standards provide only a common syntax.

Suppose you want to cross-probe between a schematic editor from one vendor and a pc-board-layout editor from another vendor. OLE provides a means of sending a message between processes. If both programs conform to the OLE standards, then they can successfully pass messages in a syntax back and forth. However, OLE says nothing about what the messages mean. If the schematic editor sends a message with a command code and a text string, then the layout editor can interpret this message as a request to highlight the net in its database whose name matches the text string (that is, cross-probe). Or, the layout editor can interpret this message as a request to delete the component whose name matches the text string (that is, a forward-ECO-delete command). It all depends on how the two products agree to interpret the message.

The need for two products to agree on interpretation--or to agree on anything--is at the heart of the issue. This agreement requires access to the source code of the products. Even if the same manufacturer develops both products, this agreement requires work. (Communication among family members, after all, is seldom effortless.) Having two manufacturers involved exacerbates the problem. If three manufacturers are involved, forget it.

Manufacturers could theoretically agree on a common set of semantics. But in reality and by necessity, a common set of semantics would lead to the lowest common denominator of capabilities. This approach would hold back all possible advances until all the parties could agree on them. Contrast the progress Unix made while AT&T owned it with its stasis since a consortium took it over. This scenario proves that most expectations of interoperability have been unrealistic--a fact that will probably remain as true for the next 15 years as it has for the previous 15.

| EDN Access | Feedback | Table of Contents |