Overview of Library Translation

Once the main requirements have been satisfied, your schematic can be transferred between Advanced Design System and Mentor Graphics Boardstation. Importing and exporting can be initiated from either EDA design environment.

IFF Schematic and Layout Transfer Use Model describes the general use model for translating a design using the IFF Interface as it applies to Advanced Design System and Mentor Graphics Boardstation. The link between the two EDA environments is established via the ADS and Boardstation IFF Interface. The component libraries in both ADS and Boardstation must be compatible to support an IFF translation.

IFF Schematic and Layout Transfer Use Model

Creating the ADS Component Library from Mentor

IFF Schematic and Layout Transfer Use Model shows that, in order to do an IFF transfer of a layout and/or a schematic, you must have an LMS component library in Mentor Graphics, and a component library that matches it in Advanced Design System (ADS).

The ADS library system is not identical to the Mentor Graphics library system. Nor are the component definitions in ADS identical to the Mentor Graphics component definitions.

What the IFF translator is doing when it translates a schematic or a layout is using a component definition that has been designated the same between ADS and Mentor Graphics.

These component definitions have many attributes in common. The common attributes include such things as the following:

But, the Mentor and ADS libraries do not share the same database, and they can have unique attributes that are specific to either ADS or Mentor Graphics (such as the simulation model).

The IFF translation process is assuming that the Mentor Graphics library was created first. This means that the ADS library must have been made from the Mentor Graphics library.

The ADS component library is an image of the Mentor Graphics library. This leads to the following rules:

While it is possible to take ADS library components and transfer them to Mentor Graphics, this is not considered a good practice. Transferring libraries to Mentor will not be covered in this manual. Library Translation assumes that all transfers are being made from Mentor Graphics to ADS.

A Brief Overview of an LMS Library

Since one of the rules is that the ADS representation will attempt to look like an LMS library, it is important to designate what the important aspects of an LMS library are that must be duplicated.

Note
This information is not copied from Mentor Graphics manuals. It is being presented based on observations made by using Mentor Graphic's tools. For more information on LMS libraries, consult Mentor Graphics documentation.

Library Management System (LMS) is Mentor Graphics method for creating a company-wide set of libraries that contain all of the information needed to develop, release, and maintain all of the parts that are used to manufacture a board design. A library being managed via LMS library will contain:

LMS is meant to manage libraries across multiple sites, and would typically be company wide. It would not be typical for a single site to use multiple sets of libraries that are managed via separate LMS setups. Parts from multiple vendors are managed by a single LMS setup.

Catalogs

A Catalog is a grouping of entries that share common attributes. Often, you will see a catalog referred to as a family of parts. Also, within Mentor Graphics, each catalog could be considered to be the listing of all of the elements within a single library. The catalog is actually a text file. Each line in the text file represents one catalog entry. Each entry is unique based on an index number that cannot be duplicated within all of the libraries that are being managed through LMS. For LMS managed libraries, this unique index is the part number. Entries within a catalog are normally referred to as Components within the context of Mentor Graphics.

Parts

A part is the complete set of information used to identify, describe, and distinguish any object that might be used within an electronic design. In LMS, a part is defined by an entry in a catalog which specifies and/or references all the data describing the various aspects of a part.

A part can have a number of attributes associated with it. All parts in an LMS library that you wish to transfer to ADS must have the following attributes:

Parts may also have electrical parameters (e.g. capacitance on a capacitor), but this is not required. It is very important to realize that, from an RF perspective, Mentor Graphics is primarily a manufacturing environment, not a simulation environment. Many Mentor Graphics parts will have no simulation parameters associated with them.

Parts can have as many Symbols or Geometries associated to them as the librarian wishes. Usually, a part will have a single geometry, and multiple symbols that will represent the part in a schematic with different rotations.

Parts can represent packages. A packaged part means that the part number has multiple distinct schematic instances that can be traced back to the single part number (this tracing is done via the Reference Designator). Packaged parts will be represented in Mentor by having several distinct symbols, with each symbol having pins that link to specific pins of the geometry file. The symbols do not need to be identical. Note also that, from a database standpoint, the symbols are stored separately from the part. Many parts can utilize the same schematic symbol.

A given part will usually inherit properties that have been set up in its catalog. Thus, a family of capacitors will have a capacitor catalog, that could specify what the appropriate symbols are for the entire family of capacitors. It is possible, though, to override the catalog entries for particular part numbers in the family.

Components

In the context of Mentor Graphics and ADS, a component is a user generated part. Rather than being a member of a catalog file, a component is something that is created in a library that is essentially not managed by LMS. Components would consist of one or more schematic sheets, layout, symbols for hierarchical representation, and, potentially, logical or behavioral simulation models. When a user transfers their schematic and layout designs between ADS and Mentor Graphics, they are transferring components.

Symbols

A symbol is a graphical representation of a part for use within logic based tools, such as schematic capture or VHDL code generation. A symbol will consist of symbol pins, symbol body graphics, symbol pin properties, and symbol body properties. The symbol pin properties and symbol body properties are independent of the catalog entry properties. A symbol can be used by more than one part. For example, if the parts C0123 and C0124 are contained within the catalog "capacitors", it is possible for both of those parts to be logically represented by the same symbol, "cap". In addition to the symbol properties, it is also possible to add in text. Text can be interpretive (e.g. display the value of PART_NO), or non-interpretive (e.g. put a label, "P", next to the positive symbol pin, which is named "pos").

Because Mentor Graphics schematics are used as documentation, multiple symbols will be used as opposed to simply rotating a symbol. This is done so that the location of text in the symbols can be controlled.

Symbols are linked to Geometries via a mapping file. As was noted, Parts may have more than one logical symbol to represent them within a schematic. This means that there is not necessarily a one-to-one match up between the symbol pins, and the leads of the geometry footprints. The mapping file contains the information that links a given symbol pin to a given footprint. The map file is specified in the catalog entry, and can be different for every part number that uses a given symbol (although the map file can be shared if multiple part numbers share the same symbols and footprints).

Geometries

A geometry is the physical description of an object used in a board design. A geometry consists of a type designation, a name, and the graphics which define the geometry's size and shape. Geometries are required to package logical symbols from a schematic to a physical part in a layout. A common term used to describe a geometry that represents a part is a footprint; geometry and footprint will be used interchangeably.

Parts may have multiple geometries that can be associated to them. For example, for a through-hole process, one geometry may be needed. For a surface mount process, a DIP package might be needed instead. This one part could then have multiple allowed geometries (although the software would disallow one of them during packaging, based on the process being used).

Geometries can also be shared amongst multiple parts. For example, part numbers C0123 and C0124 could both use the same through hole geometry, CAP_TH.

A mapping file is used to link the geometry to a symbol. The mapping file contains information that specifies how a geometry pin matches up to a symbol pin. The mapping file is organized to specify the name of the symbol, the name of the symbol pin, and the number of the geometry pin. The mapping file can be unique to a given part number, or shared amongst multiple part numbers, depending on whether the symbol name, the symbol pin names, and the geometry numbers match up correctly or not.

Menus

Mentor Graphics Design Architect (DA) can be started in a special LMS mode, using the command da_lms. When DA is started in LMS mode, it will automatically bring up a menu dialog. The menu dialog will show the user the allowed library of parts that they may use, based on the LMS library set that they are attached to. The menus are centrally controlled, and eliminate the need for the designer to know which parts are currently allowed in designs, and eliminates the need for the designer to do elaborate setups to get access to the parts. The menus are text based files, that contain the part numbers, as well as some descriptions of the parts. The menus can be hierarchical (i.e. top menu has menus capacitors, inductors, etc., which are menus that contain the part numbers for those part categories).

Ample Code

Ample is Mentor Graphics extension language. When libraries are set up via LMS, special directories can be set up, which will then be read and interpreted by the assorted tools within the Mentor Graphics toolset. These directories will contain files with Ample code, that will add to or modify the way that the Mentor Graphics tool will work. Mostly, this is used to add new menu options that allow special checks or procedures to be done for a company's library set.

A Brief Overview of How an LMS Library is Represented in ADS

Based on the overview of LMS managed libraries in Mentor, a description of how each of the elements of a Mentor Graphics library are represented in ADS is in order. This section contains descriptions of how the Mentor library elements are represented, and why they were represented this way. The relevant elements are as follows:

Parts in ADS

ADS contains a construct for representing a part. Like Mentor Graphics, a part can be thought of as the set of information necessary to identify, describe and distinguish an object in an electronic design.

In Mentor Graphics, the part description is handled by an entry in a catalog file that contains all of the necessary references for the part. ADS is organized slightly differently. In ADS, all parts are described by program calls to ADS' extension language functions. During part creation, these function calls will typically be collected into a single file, which will be loaded into memory sometime prior to usage of the part in a design. When the part description has stabilized, the files can be collected into a single file; the ADS library manager will then dynamically load the part descriptions as they are needed. The part description that is loaded in memory is called an Item Definition in ADS.

ADS does not have an "index" field to designate which entry to use. ADS has a name field. Because there is a single name space for the Item Definitions, each part must be given a unique name. The logical assumption is that the part number is simply used as the part name, so that a unique name is created. Unfortunately, this is incorrect.

The methodology of using IFF for doing the part transfers between ADS and Mentor Graphics pre-dates LMS being the defacto standard for library management in Mentor Graphics. Additionally, there are still numerous libraries that may need to have parts translated (genlib for example) where the parts are not defined as entries in a catalog file. As a final additional problem, ADS only supports one symbol per part, unlike Mentor Graphics.

To avoid problems, and fit in the "historical" mode, the ADS part name is derived by using the component name (the mgc_comps parameter in the catalog entry), the symbol name, and the part name. These three elements are concatenated together with underscores. For parts that are not in LMS catalogs, the part will simply be the component name, or the component name concatenated to the symbol name.

ADS has a single simulator (eesofsim) that is associated with it. The simulator itself actually has two separate parts to it, a system level simulator (adsptolemy), and a circuit level simulator. At present, the expectation is that any devices that are imported into ADS from Mentor Graphics will be set up to work with the circuit level simulator.

When a part is imported into ADS, it does not have a definition for use with the simulator. It is up to the librarian to add whatever details are necessary for the part to simulate. Setting up a part is covered in Adding Simulation Setups to an IFF File, and Setting Up Components for Simulation in ADS. Mentor Graphics does not have any information that is readily usable for an RF simulation setup. It is possible to reuse the electrical properties that are defined in the MGC catalog entry (for example, the resistance on a resistor), but for RF, do NOT set up your devices as ideal components. At present, there is no way of automatically creating an accurate simulation model by looking at the geometry and device parameters.

ADS 1.5 does have packaging capability, but, by default, it is expected that a single ADS schematic symbol will be associated to a single layout object. If the package capability is enabled, as of ADS 1.5, the IFF importers and exporters for Mentor Graphics and ADS are unable to synchronize to use the ADS packaging information, and it will not be used. If you have multi-pack parts, the current recommendation is ADS for schematic editing only, and to use Mentor Graphics for doing all layout. If you do not have multi-pack components, all parts will have their Mentor Graphics geometry associated to them properly during the library import. See Importing Library Parts from Mentor Graphics into ADS for more information on how this is accomplished.

The reference designator in ADS is essentially non-existent. ADS parts will all receive an instance prefix. The REF property can be used as the instance prefix in ADS. However, this will not operate identically to the Mentor Graphics usage of REF. In ADS, the instance name will be the reference designator. In a hierarchical design, each sub circuit still retains the same instance ID. Within Mentor Graphics, the reference designator is different for all instances, even if they are in the same subvariety. When ADS designs are transferred to Mentor Graphics, it is recommended that Mentor Graphics be allowed to re-assign the reference designators.

Catalogs in ADS

ADS has a tool called the Library Browser. This tool is responsible for dynamically loading part definitions at the request of the design environment. The Library Browser uses files that are made up of a set of item definition files. These files are fairly analogous to the LMS catalog file. When a part is requested, the Library Browser will search its files for the first definition that matches. The files that are used are based upon a search path that is set up so that only a desired set of components will be available. For more information about how to set these files up after importing from Mentor Graphics, refer to Importing Library Parts from Mentor Graphics into ADS.

Components in ADS

In ADS, the difference between a part and a component is essentially that a part is a system wide component that is not be user editable. All ADS parts contain the same database structure. During the library import process, the parts sent from Mentor Graphics are not different from the parts from an end schematic design.

Symbols in ADS

As with Mentor Graphics, a symbol is a graphical representation of a part for use within logic based tools, such as schematic capture or VHDL code generation. After importing a library from Mentor Graphics, the symbol that is generated for a part should look as close as possible to the original Mentor Graphics symbol in terms of pin placement and symbol body graphics. ADS does allow the placement of fixed text, but does not have any interpreted symbol text. All instance specific symbol text is applied to fixed locations of the symbol through the schematic editor.

ADS does not support the concept of a mapping file. Symbols are linked to Geometries in ADS based on the symbol pin number and the geometry pin number. This does lead to problems if a geometry is shared between parts that have different pin outs. As was noted, Parts in ADS can only have a single symbol associated with them. This leads to the parts being "split" in ADS. For example, if there is a part in Mentor Graphics called 11111, which is a part type "CAP", and has two symbols called "cap_h" and "cap_v", there will be two separate parts created in ADS, called CAP_cap_h_11111, and CAP_cap_v_11111. The definitions for these parts will be identical, with the exception of the symbol that is used to represent the part in the schematic. Each symbol will have its own geometry cross mapping built into the symbol itself.

Because the geometry to symbol cross mapping can be different for each part/symbol pair, it is not possible to guarantee a correct import by reusing the same symbol between different parts. ADS is capable of doing this, but it could lead to problems that are difficult to diagnose if the specialized cases that don't obey the rule that the same symbol should always map identically, independent of the part. This does mean that if one symbol is used in Mentor, it could be duplicated hundreds of times over in ADS.

Geometries in ADS

ADS allows for two ways of representing a layout for a part. Either a fixed layout can be used, or a parameterized layout can be used. A parameterized layout means that AEL (Application Extension Language) code is written to represent the layout. A fixed layout is simply a database element.

When geometries are imported from Mentor Graphics, they are imported into fixed layouts. In many cases, it would be appropriate to simply point the ADS part that uses the geometry to that fixed layout. However, Mentor Graphics does allow multiple geometries to be used for some parts. The goal of the specialized LMS library import (see Importing Library Parts from Mentor Graphics into ADS) is to minimize the amount of manual work required by a librarian, as well as to minimize the amount of internal ADS library knowledge needed by a Mentor librarian.

To cover the cases where multiple geometries can be specified based on the GEOM parameter, parts that are imported from Mentor Graphics are actually represented as parameterized layouts. A special AEL function has been written for ADS which is able to open a fixed layout database and draw the graphics in the database into the parameterized layout instance. Currently, this function only supports drawing non-hierarchical fixed layouts. This can be a problem where pad stacks are represented hierarchically in Mentor Graphics geometries.

Menus in ADS

As was noted in the section Catalogs in ADS, ADS has a tool called the Library Browser that is responsible for dynamically loading part definitions into memory for use with the ADS design environment. This tool also provides a graphical interface for selecting which parts are to be placed. Along with the concatenated Item Definition File (IDF), there will also be a record file, which contains a listing of the parts in the IDF file, as well as some descriptive information about each part.

Unfortunately, the record file is not quite the same as the Mentor Graphics LMS menu files. Both are text based, but, in ADS, there is no capability to have nested menus. Parts can be grouped together to form a single tree selection (a library). Additionally, groups of libraries can be grouped together (a library of libraries).

Customization Code in ADS

ADS has a C-like interpreted language called AEL (short for Application Extension Language). Like Ample, AEL allows the design tools to be modified. Menus can be added. Database traversal routines can be written that perform specialized checks. Speaking generally, any modification to the Mentor Graphics User Interface that is done via Ample can be done via AEL. Unfortunately, there is no tool that will translate Ample code into equivalent AEL code. Ample to AEL code conversion is beyond the scope of this manual, and will not be discussed.

In addition to converting code, it may be necessary to write certain functions in order to support a Mentor Graphics library in ADS. This can include writing netlisting functions for specialized components, and writing code that will alter certain properties on instances in order to do IFF export. If this is required, you will currently need to contact Agilent EEsof Solution Services in order to get special training on the process involved in this. This topic is beyond the scope of this manual. In most cases, it should not be necessary to write your own customization code.

Steps for Transferring an LMS Managed Library to ADS

The following is a short check list for transferring an LMS managed library from Mentor Graphics to ADS. Each of these topics is covered in fuller detail within its own chapter.

  1. Make sure your environment is set up properly to do LMS exports from Mentor Graphics, and LMS imports into ADS. Details on this process are covered in Setting Up Your Environment.
  2. Export your library parts from Mentor Graphics. The files will be exported to two separate IFF files, one for the geometries (LMSgeoms.iff), one for the symbols (LMSsymbols.iff). There will be an additional third file that contains the information about how the parts, symbols, and geometries are associated to each other (parts_mapping_file.txt). The procedure for making these files is covered in Exporting Library Parts from Mentor Graphics.
  3. Prior to importing the library parts from Mentor Graphics into ADS, it can be desirable to add information into the IFF files that will tell ADS how to simulate the parts. It can be better to do this prior to the ADS import, because, at this stage, the parts have not been exploded into one item definition per file. At this stage, the same item definition setup will be applied to all parts that are considered to be a part of the same family. In some cases, this may not be appropriate, and this step would be skipped. This process is covered in Adding Simulation Setups to an IFF File.
  4. The next step is to actually import the IFF files created in step 2 into ADS. Because there are certain properties that are inherent to all LMS managed libraries, there are some extra automation steps that can be done in addition to the standard IFF import. A special LMS import process is available to handle this extra automation. In Importing Library Parts from Mentor Graphics into ADS, the user interface for the LMS import process is covered, as well as what the LMS import process is doing in addition to the standard IFF import.
  5. In step 3, the procedure for adding simulation setups to IFF files was covered. Some of the simulation setup cannot be completed until after the library parts exist in ADS. Setting Up Components for Simulation in ADS, covers the steps for setting up ADS library parts after they have been imported. The chapter will also cover the procedure for doing the setup of parts if step 3 was omitted.
  6. At this point, you have a library of parts that is contained within a single ADS project. Essentially, your project is private. Nobody else can see it yet. This is the ideal time to make sure that the simulation setups from steps 3 and 5 are in fact working correctly. There is no absolute method that will guarantee that your library is set up properly. In Verifying a Library, some general procedures are given that generally will show that individual parts are or are not working.
  7. Once the library has been imported and verified, it is necessary to set things up so that all ADS designers can see and use the library. This process is not covered in this manual.

For more information on converting your library into an ADS Design Kit, refer to your ADS Design Kit documentation or consult your Agilent Technologies sales representative.

 

Privacy Statement  | Terms of Use  | Legal | Contact Us  | © Agilent 2000-2008 

Contents
Additional Resources