There are different type of the files generated during a design cycle or data received by the library vendor/foundry. Few of them having specific extension. Just to know the extension, you can easily identity the type of content in that file.
*.ddc - Synopsys internal database format. This format is recommended by Synopsys to hand gate-level netlists.File Extensions:
*.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.
*.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.
No comments:
Post a Comment