Working with File-based Component Libraries in Altium NEXUS

Parent page: Building & Maintaining Your Components and Libraries

The components and how they are connected are what creates your unique, electronic product. The components are the basic building blocks of that product. So what exactly is a component and where are they stored?

In the real world, components are tangible objects and are, therefore, relatively easy to identify. But in the virtual world of design, components have to be abstracted into a range of models that can be used across the various design domains. During the design capture and implementation processes, a component is represented as a symbol on the schematic, as a footprint on the PCB, as a SPICE model for simulation, as a signal integrity description to analyze the quality of the signals, and as a three-dimensional model for 3D component and PCB visualization. One component, with a different representation for each design domain.

Each design domain requires a specialized model. For schematic capture, the model is referred to as a symbol. Because the design environment is built around the idea that the design starts with the schematic, the schematic symbol is used to tie the various models together.

Parameters then add the additional detail needed to identify the real-world physical component, such as the wattage, tolerance, purchasing details, datasheet references, etc.

The symbol model links to the other models to fully describe that component in each domain. The 3D model is actually placed within the footprint.

Models and Model Libraries

Each type of model and component needs to be stored in a model file or library. Some of these use a standardized file format, like SPICE, while others use a proprietary format, like the schematic library file, which is used to store schematic symbols or components.

Some model kinds, like SPICE, are stored one-model-per-file, these are referred to as model files. Others, like PCB footprints, are stored in a file that accepts one or many footprints. These are referred to as model libraries.

Summary of the Model and Library Types

Supporting the broad range of the design tasks performed through the electronic development process requires numerous model kinds and library formats.

Below is a summary of each model and library kind.

The Component

A component can range from something simple, like a two-pin resistor, to a large connector with hundreds and hundreds of pins. To give flexibility over how the components can be organized on the schematic sheets, the software includes a number of useful, display-related features. 

Is it a Symbol or a Component?

Once you have linked in other domain models and added parameters, the symbol becomes a component. Many designers continue to refer to it as a symbol when they see it on the schematic because that's what they see but attached to that symbol are the other domain models and parametric details that define it as a component. This document uses the term symbol to describe the graphical objects and pins that are placed in the schematic library editor. In all other situations, it is referred to as the component.

The symbol is created in the schematic library editor. As soon as you add a link in models and add parameters, it becomes a component. The component detail can be added in the schematic library editor, or if you use a DbLink or DbLib type library, the detail can be extracted from a database and added to the symbol during placement on the schematic (more on these later). Alternatively, the detail can be added after the symbol has been placed on the schematic sheet.

The Symbol

The symbol is created in the schematic library editor. It is created by placing graphical objects to build the required shape then the pins are added. It is the pins that bring electrical intelligence to the component. They are what the software identifies as the electrical connection points and what is mapped to the pads on the PCB footprint.

 
Symbols can range from the small and simple to high pin-count components created over multiple parts.

The File-based Libraries

Altium NEXUS supports a number of different types of file-based libraries described below.

Schematic and PCB Models and Model Libraries

Main page: Working with Schematic Libraries, Working with PCB Libraries

In the early days of electronic design automation, there were two design domains: schematic capture and PCB layout. The outputs from schematic capture were a set of printed schematic sheets and the outputs from the PCB layout were the PCB fabrication and assembly files.

To support this, the designer needed to be able to create and store the schematic symbols, ready to be placed on the schematic sheet. Details such as the component's value, voltage, wattage, footprint, etc., were often added after the symbol was placed from the symbol library onto the schematic sheet.

As for the footprints, the focus of the editing capabilities was implementing the design as a set of layers that contain the shapes needed for the photo tools. This output-driven focus dictated what shapes were supported, down to the font used for the designator and other silkscreen strings.

These simple symbols and footprints were created and stored in libraries, with both types initially having the file extension *.Lib. Once Windows relaxed the three-character limit on file extensions, these were changed to *.SchLib for schematic symbols and *.PcbLib for footprints. 

Schematic and PCB libraries are storage containers for models. 

The Integrated Library

Main page: Working with Integrated Libraries

Over time, there was a growing desire to be able to separate the component creation process from the product design process. Instead of adding the component detail after the symbol had been placed on the schematic sheet, design teams wanted to fully define the component in the library. Other design domains, such as circuit simulation, were also being developed, and therefore, models for these domains also needed to be supported. As part of creating ready-to-use components, you also need to be able to verify the symbol-to-model mapping, then deliver these components in a single, ready-to-use library file.

To satisfy these requirements, the integrated library (*.IntLib) was developed. The integrated library carries all model kinds in a single file. The source for an integrated library is a library package (*.LibPkg), which is a design project that brings together the source symbols, footprints and simulation models. When the library package project is compiled, the symbol-to-model mapping is verified and the Integrated Library is created. Using an IntLib means that the library becomes something from which you place ready-to-use components, which delivers a good solution for medium to large organizations that want to separate component creation from product design.

Glossary