ASIC design flow: File extensions

I would like to describe some of the known file extensions that we usually come across while during the entire cycle of chip design. Mostly are the file formats used by Synopsis tools.

Here are the extensions, let me know if I missed out something 🙂

.LEF 

An ASCII data format, used to describe a standard cell library. Includes the design rules for routing and the Abstract of the cells, no information about the internal netlist of the cells. A LEF file contains the following sections:


􀂄 Technology: layer, design rules, via definitions, metal capacitance

􀂄 Site: Site extension

􀂄 Macros: cell descriptions, cell dimensions, layout of pins and blockages, capacitances.

 lef is used to design an IC process and a logic cell library .lef is used to describe a gate array i.e.base cells, legal sites for base cells, logic macros, interconnect layer and other information to set up the data base that physical design tools need.

.DEF

.def is used to describe all the physical aspects of a particular file including netlist an the physical location of the chip. Example: if we have a complete placement from a floorplanning tool and want to exchange information with cadence cell ensemble or cell3 ensemble, use a .def file

 .CIR

The CIR file type is primarily associated with ‘PSpice’ by Cadence Design Systems,  PSpice is a SPICE analog circuit and digital logic simulation software that runs on personal computers (thus the first letter P in its name). It was developed by Micro Sim and used in electronic design automation. MicroSim was bought by Or CAD which was subsequently purchased by Cadence Design Systems. The name is an acronym for Personal Simulation Program with Integrated Circuit Emphasis. Today it has evolved into a analog mixed signal simulator.

 .sch

The SCH extension is a schematic, or visual diagram file of a PCB created with EAGLE PCB design software. It includes symbols for logic gates connected by lines, which represent buses, and is used for creating a actual circuit board file. EAGLE stands for “Easily Applicable Graphical Layout Editor.”

.v

.v extension used for Verilog files, netlist.

*.v – Verilog source file. Normally it’s a source file your write. Design Compiler, and IC Compiler can use this format for the gate-level netlist.

*.vg, .g.v – Verilog gate-level netlist file. Sometimes people use these file extension to differentiate source files and gate-level netlists.

*.svf

Automated setup file. This file helps Formality process design changes caused by other tools used in the design flow. Formality uses this file to assist the compare point matching and verification process. This information facilitates alignment of compare points in the designs that you are verifying. For each automated setup file that you load, Formality processes the content and stores the information for use during the name-based compare point matching period.

 *.ddc

Synopsys internal database format. This format is recommended by Synopsys to hand gate-level netlists.

 *.vcd

Value Change Dump format. This format is used to save signal transition trace information. This format is in text format, therefore, the trace file in this format can get very large quickly. There are tools like vcd2vpd, vpd2vcd, and vcd2saif switch back and forth between different formats.

*.vpd

VCD Plus. This is a proprietary compressed binary trace format from Synopsys. This file format is used to save signal transition trace information as well.

*.saif

Switching Activity Interchange Format. It’s another format to save signal transition trace information. SAIF files support signals and ports for monitoring as well as constructs such as generates, enumerated types, records, array of arrays, and integers.

 *.tcl

Tool Command Language (Tcl) scripts. Tcl is used to drive Synopsys tools.

 *.sdc

Synopsys Design Constraints. SDC is a Tcl-based format. All commands in an SDC file conform to the Tcl syntax rules. You use an SDC file to communicate the design intent, including timing and area requirements between EDA tools. An SDC file contains the following information: SDC version, SDC units, design constraints, and comments.

 *.lib

Technology Library source file. Technology libraries contain information about the characteristics and functions of each cell provided in a semiconductor vendor’s library. Semiconductor vendors maintain and distribute the technology libraries. In our case the vendor is Synopsys. Cell characteristics include information such as cell names, pin names, area, delay arcs, and pin loading. The technology library also defines the conditions that must be met for a functional design (for example, the maximum transition time for nets). These conditions are called design rule constraints. In addition to cell information and design rule constraints, technology libraries specify the operating conditions and wire load models specific to that technology.

 *.db

Technology Library. This is a compiled version of *.lib in Synopsys database format.

 *.plib

Physical Library source file. Physical libraries contain process information, and physical layout information of the cells. This information is required for floor planning, RC estimation and extraction, placement, and routing.

 *.pdb

Physical Library. This is a compiled version of *.plib in Synopsys database format.

 *.slib

Symbol Library source file. Symbol libraries contain definitions of the graphic symbols that represent library cells in the design schematics. Semiconductor vendors maintain and distribute the symbol libraries. Design Compiler uses symbol libraries to generate the design schematic. You must use Design Vision to view the design schematic. When you generate the design schematic, Design Compiler performs a one-to-one mapping of cells in the netlist to cells in the symbol library.

 *.sdb

Symbol Library. This is a compiled version of *.slib in Synopsys database format.

 *.sldb

DesignWare Library. This file contains information about DesignWare libraries.

 *.def

Design Exchange Format. This format is often used in Cadence tools to represent physical layout. Synopsys tools normally use Milkyway format to save designs.

 *.lef

Library Exchange Format. Standard cells are often saved in this format. Cadence tools also often use this format. Synopsys tools normally use Milkyway format for standard cells.

 *.rpt

Reports. This is not a proprietary format, it’s just a text format which saves generated reports by the tools when you use the automated makefiles and scripts.

 *.tf

Vendor Technology File. This file contains technology-specific information such as the names, characteristics (physical and electrical) for each metal layer, and design rules. These information are required to route a design.

 *.itf

Interconnect Technology File. This file contains a description of the process crosssection and connectivity section. It also describes the thicknesses and physical attributes of the conductor and dielectric layers.

 *.map

Mapping file. This file aligns names in the vendor technology file with the names in the process *.itf file.

 *.tluplus

TLU+ file. These files are generated from the *.itf files. TLUPlus models are a set of models containing advanced process effects that can be used by the parasitic extractors in Synopsys place-and-route tools for modeling.

 *.spef 

Standard Parasitic Exchange Format. File format to save parasitic information extracted by the place and route tool.

 *.sbpf

Synopsys Binary Parasitic Format. A Synopsys proprietary compressed binary format of the *.spef. Size of the file shrinks quite a bit using this format.

*.mw

Milkyway database. The Milkyway database consists of libraries that contain information about your design. Libraries contain information about design cells, standard cells, macro cells, and so on. They contain physical descriptions, such as metal, diffusion, and polygon geometries. Libraries also contain logical information (functionality and timing characteristics) for every cell in the library. Finally, libraries contain technology information required for design and fabrication. Milkyway provides two types of libraries that you can use: reference libraries and design libraries. Reference libraries contain standard cells and hard or soft macro cells, which are typically created by vendors. Reference libraries contain physical information necessary for design implementation. Physical information includes the routing directions and the placement unit tile dimensions, which is the width and height of the smallest instance that can be placed. A design library contains a design cell. The design cell might contain references to multiple reference libraries (standard cells and macro cells). Also, a design library can be a reference library for another design library. The Milkyway library is stored as a UNIX directory with subdirectories, and every library is managed by the Milkyway Environment. The top-level directory name corresponds to the name of the Milkyway library. Library subdirectories are classified into different views containing the appropriate information relevant to the library cells or the designs. In a Milkyway library there are different views for each cell, for example, NOR1.CEL and NOR1.FRAM. This is unlike a .db formatted library where all the cells are in a single binary file. With a .db library, the entire library has to be read into memory. In the Milkyway Environment, the Synopsys tool loads the library data relevant to the design as needed, reducing memory usage. The most commonly used Milkyway views are CEL and FRAM. CEL is the full layout view, and FRAM is the abstract view for place and route operations.

 simv

Compiled simulator. This is the output of vcs. In order to simulate, run the simulator by ./simv at the command line.

alib-52

Characterized target technology library. A pseudo library which has mappings from Boolean functional circuits to actual gates from the target library. This library provides Design Compiler with greater flexibility and a larger solution space to explore tradeoffs between area and delay during optimization.

2 responses

  1. Hi Sharvil,

    Please continue writing the blogs, they are useful!!!

    Thanks

    Liked by 1 person

    1. Thanks! Nice to see that it was useful 🙂

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: