In this article, we delve into several important topics related to VLSI Physical Design, focusing on the comparison between Layout and Schematic. We explore the overall design flow and introduce the concept of Layout Versus Schematic (LVS), including its basics, purpose, and significance. The discussion also covers the process overview, typical challenges encountered in LVS, and strategies for identifying and debugging common issues. Additionally, we introduce NETGEN, an essential tool for netlist comparison, and explain the importance of the setup file and how valid filenames are defined. The video further provides a detailed breakdown of various NETGEN command types, including those used for running the tool, manipulating netlists, and performing netlist comparisons.
In the nanometric era, designs are becoming more complex and chip sizes are growing. To make sure the design is correct, larger layout databases need to be checked during the physical verification process within the same tight project timelines. If an error is found after the design is built, it will lead to costly mask changes and delays in releasing the SoC. Physical verification ensures that the design layout matches the schematic and checks if the layout follows manufacturing rules from semiconductor fabrication labs, ensuring it can be produced correctly.
DRC: It checks if the design layout follows the rules needed for it to be successfully manufactured by the fabrication lab.
LVS: It verifies that the design layout works the same way as the schematic (blueprint) of the design.
DRC does not guarantee that the layout will work as intended. It only checks if the layout follows the fabrication rules for error-free manufacturing. DRC focuses on ensuring the layout can be made correctly, but it doesn't confirm that the circuit will perform as expected. The need for LVS came from this limitation, as LVS checks if the layout matches the intended circuit design.
Basics of LVS:
A EDA tool performs LVS using a set of code instructions. Those set of instructions are LVS rule deck. LVS rule deck guides the tool by providing necessary instructions and identifying required files for the process.
LVS is done in two steps : extraction and comparison.
The design inputs needed to run LVS include:
i. GDS layout of the design
ii. Schematic netlist of the design
iii. Cell definition file, including IP files and standard cells
iv. Pad reference file
The LVS rule deck is written in formats like SVRF i.e Standard Verification Rule Format or TVF i.e. TCL Verification Format and helps the tool extract the devices and connections of the circuit. It defines the layers used in the layout and matches layer descriptions to their locations in the GDS file to identify electrically connected regions, known as nets. The rule deck also includes definitions of the device structures.
LVS Process Overview:
Circuit designers create a schematic using fundamental devices (resistors, transistors, etc.). - The schematic is converted into a netlist (e.g., SPICE format) for simulation and comparison. - Layout engineers generate a layout based on the schematic, considering placement, sizing, and design rules. The layout is extracted into a netlist, which should represent the same circuit as the schematic.
Purpose of LVS:
Identifies errors introduced during the layout process. - The schematic is usually assumed to be correct because it's used for simulation. LVS is essential for checking manual corrections or verifying automated layout synthesis.
Challenges of LVS:
Errors in layout or synthesis can create incorrect circuits. LVS helps pinpoint these issues. Full chip verification through simulation can be time-consuming and complex, so LVS is a quicker alternative.
Layout vs. Schematic Flow:
The LVS flow works in 2 major phase : Extraction & Comparison.
i. Extraction phase :
1. Verification tool takes the GDS file and breaks it down into basic design components like transistors, diodes, capacitors, and resistors.
2. These components are identified by recognizing the layers and shapes in the GDS file or by using cell definitions from the IP blocks or the LVS rule deck.
3. The tool also extracts connectivity information between these components from the GDS file.
4. During connectivity extraction, each electrical net is given a unique node number for easy identification. Net names can also be assigned based on text objects in the layout or control file.
5. This device and connectivity information is written into a layout netlist file, also called the layout extracted netlist. This step is known as extraction.
ii. Comparison phase:
1. The verification tool compares the electrical circuits from the schematic netlist and the layout extracted netlist using the LVS rule deck.
2. After a successful comparison, a one-to-one match between elements (like instances, nets, ports, and pins) in both netlists is established.
3. The goal is to ensure the layout accurately represents the functionality in the schematic.
4. If the netlists don't match, discrepancies are reported in an LVS result database, listing issues like incorrect nets, ports, or instances for debugging.
LVS Issues & Debug :
The source SPICE netlist should match the SPICE netlist extracted from the layout.
Common LVS Checks :
1. Compare the number of devices in both the schematic and layout.
2. Check the types of devices in the layout and schematic.
3. Compare the number of nets in the schematic and layout.
4. Compare the number of ports
5. Connectivity issues
6. Ambiguity points in the design
7. Cell comparison
Common LVS Issues:
1. Short : Shorts between different nets.
2. Power Short
3. Power Open
4. Power Short with signal : Multiple wires that should not be connected together become connected.
5. Signal Open: Wires/components that required to be connected are left floating/ partially connected
6. Deleted Instance : Accidental deletion of some particular instance
7. Missing Well Tap : Tap cells provide a substrate connection: n-well to VDD and p-sub to VSS.
8. Overlapping filler cells
9. Missing Filler Cells: Since filler cells provide power/ground and n-well continuity, missing filler cells will result in power/ground opens between the standard cells.
About Netgen:
Netgen is a Free and Open source tool. You can find all related information here.
Netgen is a tool with two main functions:
i. Convert netlists between different formats.
ii. Compare netlists to check if they are equivalent or identify differences.
Netlist Conversion is a simple process since most netlist formats are similar. Netlist Comparison (LVS) ensures that a VLSI layout matches the original schematic design. Netgen version 1.5 is considered complete and competitive with commercial-grade tools. Netgen Version 1.5.76 completes the major development of netgen as a commercial-grade tool. All remaining revisions will be bug fixes or minor enhancements.
Netgen was written by Massimo Sivilotti, and eventually incorporated into the beginnings of the Tanner L-Edit suite of tools. However, the original code was left open source so it has been incorporated into the Tcl-based suite of tools like magic, IRSIM, and xcircuit by Tim Edwards, the owner of OpenCircuitDesign domain.
Our special Thanks goes to Tim Edwards.
Linux and Windows compatible versions are available at : http://opencircuitdesign.com/netgen/
We will work with Linux version only.
Running Netgen:
=> Command-line invocation:
- netgen
-With no arguments, netgen will bring up a Tk console window with an interpreter prompt, waiting for command input from the user
- netgen [-noconsole] [command_line]
- With argument -noconsole, there will be no console window, and the interpreter prompt will be in the terminal
- netgen lvs circuit1.spc circuit2.spc
- For batch-mode processing of multiple commands, put the commands into a file and source that file through the command line.
- netgen source batch_script.tcl
- For batch-mode processing of multiple commands, put the commands into a file and source that file through the command line
- Batch script will end by returning to the Tcl interpreter unless it ends with a "quit"
=> Running with Tk console :
- lvs circuit1 circuit2 [setup_file ] [logfile]
Netlist Manipulation Commands:
- canonical valid_cellname
- Return a 2-item list containing the cell name and the file number of the cell indicated by valid_cellname.
- readnet [format] filename [filenum]
- Read a netlist file .
- Auto-detection first looks for files with standard extensions. If no file is found with a standard extention, then the file is checked for the initial character, which is always "*" in SPICE files and "|" in .sim files.
- readlib format [filenum]
- Initialize a library module definition, where format is one of actel, spice, or xilinx. The library definitions need to be initialized prior to reading any netlist file that is to be rewritten as "writenet actel filename", "writenet xilinx filename", or as a SPICE netlist with the definitions from the library included in the file.
- writenet format filename
- Write a netlist file
- flatten valid_cellname
- Flatten a hierarchical cell.
- flatten class [cellname] valid_cellname
- In this form of the flatten command, the whole cell database is searched for instances of the cell valid_cellname, which are then flattened by merging them into the parent cell.
- model valid_cellname [model]
- Declare a cell to be specific model type.
- The supported low-level device model types are: nmos (3 or 4 port), pmos (3 or 4 port), pnp, npn, resistor, capacitor, diode, inductor, or xline. A low-level device can be treated as a subcircuit by declaring model to be subcircuit.
- A circuit declared to be model blackbox will only recognize the pin names and pin order but will otherwise ignore the subcell contents.
- compare valid_cellname1 valid_cellname2
- Declare two cells for netlist comparison. Subcircuits that are not declared equivalent or that do not have the same name in both cells are flattened. Otherwise, subcircuit instances will be compared as black-box devices, without comparison of their contents.
- compare hierarchical [valid_cellname1 valid_cellname2]
- Do a full hierarchical comparison.
- The first call must declare the two top-level cells valid_cellname1 and valid_cellname2.
- The cell hierarchy will be searched; all cells with matching names or cells that are declared equivalent will be saved in a stack.
- equate [-list] [-unique] [elements|nodes|classes] name1 name2
- with option elements: equate two elements
- with option nodes: equate two nodes
- with option classes: equate two device classes.
In all cases the values of cell name2 are altered to match those of name1
- global valid_cellname netname [...]
- This command makes the net named netname in the hierarchy of cell valid_cellname into a global
node. The cell valid_cellname must exist in the database.
- permute default
- This command is implicitly run at the beginning of every LVS run unless the setup file contains any "permute" command, in which case all permutations must be declared in the setup file. If the intent of the setup file is to modify the default values, then permute default should be put in the setup file before all other permute statements.
- permute [transistors|resistors|capacitors]
- permute [pins] valid_cellname pin1 pin2
- permute forget valid_cellname pin1 pin2
- With option pins: permute pins pin1 and pin2 on device valid_cellname. If more than two pins may be permuted, this command may be issued multiple times between pairs of pins.
- With option forget: remove any permutation between pins pin1 and pin2 on device valid_cellname.
- With option transistors: enable transistor source/drain permutations for any device recognized as a MOSFET.
- With option resistors: enable permutations of resistor endpoints.
- With option capacitors: enable permutations of capacitor top and bottom plates. Because capacitor top and bottom plates have different parasitics, capacitor plate permutation is not normally enabled.
- With no options: enable transistor source/drain and resistor endpoint permutations.
- property default
- This command is implicitly run at the beginning of every LVS run unless the setup file contains any "property" command, in which case all properties must be declared in the setup file. If the intent of the setup file is to modify the default values, then property default should be put in the setup file before all other property statements.
- property valid_cellname|device_name
- property valid_cellname|device_name add { key type tolerance } ...
- property valid_cellname|device_name remove [key ... ]
- property valid_cellname|device_name tolerance { key tolerance } ...
- property valid_cellname|device_name associate { key pin_name } ...
- property parallel none|all
- property parallel connected|open
- property series none|all
- property valid_cellname|device_name series|parallel enable|disable
- property valid_cellname|device_name series|parallel { key combine_type } ...
- property topology strict|relaxed
- with no options other than a valid cellname, return a list of triplets, each triplet being a list of three items representing a property of the cell. Items are, in order, the name (key) of the property, the type of property (which is one of string, integer, double, value, or expression), and the tolerance for checking (which is type-dependent). Note that properties of cells, as opposed to instances of cells, do not have values. The main purpose of the property command is to establish which device properties will be compared, and what will be the criterion for comparison. When no tolerance value is given, then the default tolerances of 0, for integer values, and 0.01 (1 percent) for floating-point values, will be assigned.
Watch the video lecture here:
Courtesy: Image by www.pngegg.com
