Component Library and Design Interoperability

by Uwe B. Meding

Protecting Your Most Valuable Design Investment

The reality of current electronic CAD design work is basically that it’s a nightmare — a patchwork of
incompatible file formats and descriptive languages. For each task in the product evolution, there are many different CAE applications that can be used. Each CAE application includes primarily an application program and a unique component library containing the requisite data. CAD tool interoperability is an important issue in the electronics industry because without the ability to share design content, CAD users are not free to use best-in-class point tools at each step in the design process, causing designs to suffer. In addition, design libraries are the most valuable assets of today’s design
organizations and they must be protected and effectively utilized. Proprietary design formats limit the ability to share design information both internally and with external organizations, severely damaging design efficiency and productivity.

Fortunately, many solution providers have taken steps to tackle barriers to CAD interoperability, library standardization and design reuse. ChipData and other software vendors now offer schematic design and component conversion products that enable files to be quickly and accurately converted between different formats. For many companies, schematic data and component library migration could represent a significant savings in time and resources.

The following guidelines outline what types of data will and will not migrate, using new CAD conversion solutions:

Migratable EDA Data
Schematic data and component library conversion tools migrate these types of EDA data in an automatic or semi-automatic migration process:

• Component Symbols.
• Schematic circuit pages.
• Component package information.

The following types of EDA data are NOT expected to be migratable through either an automatic or semi-automatic process.

• EDA system specific scripts (for example Mentor’s Ample or Cadence’s Skill).
• Simulation system specific model attributes and values.
• Tool specific model descriptions.
• Library macros; corporate-project-user relationships;intermediate design files; configuration files.

Conversion Tools in Action
A recent migration of component libraries and schematic design data between Mentor/ViewDraw and Cadence Concept tools gives insight into the scale and level of detail that has to be addressed to achieve full interoperability. As an example of this process, ChipData’s SchematicXpert application recently tackled an important design challenge from a customer who was using different design flows in different product divisions. They were using Mentor ViewDraw schematic front-end design entry system in conjunction with a Mentor Pads back-end tools suite. And Cadence Concept front-end
and Cadence Allegro back-end were also being used. The customer needed to have this environment extended, so that design groups could take advantage of retaining their design investments in the Mentor ViewDraw environment, but can also use the Cadence Allegro environment to complete the PC board design flow. It was also important for design groups to be able to choose either a Mentor ViewDraw environment or Cadence Concept environment in which to design PC boards.

The migration process was broken into several steps. First, the Mentor ViewDraw parts libraries were made available in the Cadence Concept environment. Specifically, this included the creation of the Concept symbol body data, the chips part files, and the physical parts table files .
Second, the schematic designs were migrated from the Mentor ViewDraw environment into Cadence Concept environment.

The Migration Solution

Scaling: The symbols used on the ViewDraw schematics were drawn on a 1/10-in. grid with a 2/10-in. pin spacing. The target Concept symbol libraries were drawn on a 1/16-in. grid with a 2/16-in. pin spacing. The symbols and schematics were scaled down in size to adjust to the
Concept grid spacing.

Symbol replacement mapping: Maps were created for replacing components between the ViewDraw and Cadence systems. Library, name, and view mappings, along with origin offsets and rotation codes, were defined for each ViewDraw component to be replaced by a Cadence component. For situations where pin name conventions differed, a pin name map was also created.

Packaging information: ViewDraw and Concept both manage physical packaging information, however in very different ways. ViewDraw keeps pin names and corresponding package pin numbers on the different schematic symbols for a component. Concept, on the other hand, maintains a component-centric view in its design data representation; a separate component view “chips part file” contains the pin name and pin number information for the entire component. The ViewDraw packaging information was consolidated from the individual symbol views into the appropriate Concept component definitions.

Package catalog information: Special rules and processes were set up to assist the migration of the component catalog information databases. This enabled the customer to leverage and tie into existing component requisition processes.

Standard property mapping: Rules were defined for mapping standard properties and labels between the two systems. The mapping included the addition, deletion, renaming or changing of property names, values, and text labels.

Non-standard property mapping: Special property mapping requirements for simulation properties required the reformatting of single properties into multiple properties. These requirements were handled by extending the functionality of the migration software using the Java API plug-in facility. By using the API to handle the unique formatting requirements, we achieved a high degree of automation with
no manual post-translation cleanup.

Bus syntax translation: ViewDraw and Concept differ in their definition of legal bus syntax. For example, ViewDraw allows condensed busing syntax: “A0” is equivalent to bit 0 of bus A [0:15]. However, Concept requires that bus syntax be explicit, and A0 is not equivalent to A [0]. Translation rules were created to map between syntaxes. ViewDraw and Concept also differ with respect to bus postfix indicators. ViewDraw permits the use of post-fix indicators such as the minus sign in
the “myBus[0:15]-”. This syntax is not understood by Concept — in fact it is illegal. For these nets, the postfix indicators were adjusted to keep the net names unique (myBus[0:15]).

Hierarchy and off-page connectors: ViewDraw and Cadence Concept maintain similar rules defining the interaction between different levels of the design hierarchy. The customers’ design methodology, however, required explicit use of either hierarchy or off-page connectors. Translation rules were set up governing the mapping and addition of the hierarchy and off-page connectors. These rules defined translations of the type of connector (input, output, or bidirectional); the library, cell, and view names of the connector; and any offsets or rotation codes. Off-page connectors represented a more difficult task, because ViewDraw connects same signal names across multiple pages implicitly. The connectivity
challenge was addressed by maintaining an understanding of the connections during the migration process. The geometrical challenge was addressed by adding off-page connectors to the end of wires if a floating wire was determined, or to the side of the schematic sheets for these internal connections.
Global Signals: Rules were defined for the labels, names, and/or instances of objects, and how they were mapped to the corresponding instances on the target system. Similar to the replacement of components, offsets and rotation codes were required to map the replaced components to the correct location on the translated schematic. When the schematic was received by the target system, it used global instances and connectors from the native component libraries.

Cosmetic issues: A host of cosmetic issues existed, including the height and width of fonts. Font characters in ViewDraw are typically smaller than in Cadence, and the origin of each character is offset from the baseline. For example, if the character “E” is placed on a line in ViewDraw, it may appear as an “F” when translated directly to Cadence Concept. Rules for character scaling and offsets were defined in order to correctly align text.

Verification: Careful design of a data translation strategy is insufficient to guarantee correctness of the translated data; design data translations must be independently verified. For this translation, the customer performed the verification using his own software package.

Today’s companies have tremendous investments in their CAD designs and technologies. They face the challenge of managing the increasing interrelationships of many engineering data types over a range of point tools and EDA vendors. To stay competitive, today’s companies must leverage their existing design investments and must take advantage of design reuse.