A cloud based virtual training workshop conducted by VSD-IAT for Physical-Verification-using-SKY130.
-
Day 1 - Introduction to SkyWater SKY130 and Open-Source EDA Tools
-
Day 2 - Design Rule Checks and Layout Vs. Simulation
- Fundamentals of Physical Verification
- Layout file formats and GDSII format
- Extraction commands Styles and Options in Magic
- GDS Reading and Writing in Magic
- DRC Rules in Magic
- LVS Setup for Netgen
- Verification by XOR
- Lab - GDS read
- Lab - Ports
- Lab - Abstract Views
- Lab - Basic Extraction
- lab - Setup for DRC
- Lab - Setup for LVS
- Lab - Setup for XOR
-
Day 4 - Understanding PNR and Physical verification with openlane flow
The SkyWater open PDK public repository and documentation link:
Steps to install SKY130 PDKs and openpdk: First clone the repository and for this run the following commands.
git clone https://github.com/RTimothyEdwards/open_pdks
cd open_pdks
configure --enable-sky130-pdk
make
sudo make install
The "make" process grabs the SKY130 repository and submodules, as well as a few third party repositories to use in the install. It then builds the libraries from these various repositories.
Open_PDKs is a Makefile based installer that takes files from the SkyWater PDKs and reformats them for a number of open source EDA tools as listed below:
- Magic
- Klayout
- Openlane
- Xschem
- Netgen
- Ngspice
- IVerilog
- qflow
- IRSIM
- xcircuit
The libraries supported by open_pdks are:
- Digital standard cells (ex: sky130_fd_sc_hd)
- Primitive devices/analog (ex: sky130_fd_pr)
- I/O cells (ex: sky130_fd_io)
- 3rd party libraries (ex: sky130_ml_xx_hd) sky130_ml_xx_hd : This contains set of layout for alphanumeric layout used for putting text on layout whihc can be seen under microscope.
-
Inverter testbench
-
Inverter testbench spice file:
-
Simulation Result
-
Layout imported from spice file: file -> import spice
-
Layout after connecting pins
-
Postlayout simulation result
The two primary aspects of physical verification are as follows:
- Design Rule Checks (DRC)
- This make sures that the design layout meets all the silicon foundry rules for mask making.
- Layout vs. Schematic (LVS)
- This makes sure that the design layout matches a simulatable netlist by electrical connectivity and number of devices,pins. This matches the design layout to others forms that electrically matches the design and shows electrical description of circuits which is independent of layout.
LVS is based on principle that if we have multiple version of something derived from independent sources then those version can be cross checked to find errors in each other. So the more the independent sources, the more robust result, although LVS uses only two sources:
- Checking From independent source
- Extracted Layout is compared with schematic netlist or vice versa.
- Checking From Dependent sources In the modern practice of automation where chips are designed from a single source (RTL design), the LVS process is the matter of checking the design through different flows; one starting at the RTL source and working forwards and the other starting at the finished layout and working backwards.
Layout file formats are: These formats must describe both data (rectangles, subcells, polygons) and metadata (labels, cell boundaries and instance names, etc.) regarding IC layouts.
- Caltech Intermediate form (.cif)
- GDSII stream format
- Open Artwork System Interchange Standard (OASIS) : It is supposed to form much smalle file than GDS.
The GDSII format is preferred format for mask making. In magic the commands to generate mask data include a mixture of cif and calma. The Layer:purpose pairs distinguishes GDS from other formats. Instead of describing each layer with a name such as DIFF for diffusion, it describes them as a pair of numbers, seperated by a colon (ex. 65:20). Here, one number denotes the layer (such as diffusion, metal1, poly), while the other number denotes the purpose (such as blockage, net, drawing, label, pin, ,etc.). Though, layer:purpose pairs may be inconsistent across foundries.
The chip layout file formats do not contain much metadata mud that includes any concept of netlist that corresponds to layout.The layout tool must be able to independently generate the circuit netlist equivalent by looking at mask geometry of the layout. This process is known as extraction.
- Extraction in magic :
Layout -> Intermediate form -> Netlist
.mag file -> .ext file -> spice file
There is one ext file per cell in the design. The enumerates all electriced nets in the layout, all the devices (transistors, capacitors, resistors) and all instances of cell, ext file. all connection from cell down to subrell, parasities cap. blw nets.
Netlist -> Simulator -> Data plot
- Full R-C extraction command in magic
extract all
extresist tolerance 10
extresist all
extspice lvs
ext2spice cthresh 0
ext2spice extresist on
ext2spice
- To read a GDS file in magic use :
gds read file_name
- The other read commands for gds files are:
gds readonly true/false
gds flatglob expression
gds flatten true
gds noduplicates true
- GDS writing, input , output styles:
- GDS Writing: The gds write commands from layout are below:
gds write filename
gds libraru true
gds addendum true
gds merge true/false
- GDS input styles Magic techfile "cifinput" section (for cif and gds)
- style sky130 variants (), (vendor)
- style rdl import
Magic command:
cif style sky130()
cif style sky130(vendor)
- GDS output styles Magic techfile "cifoutput" section (for cif and gds)
Magic commands:
style gdsii
style drc
style density
style waffelfill
- Openpdk scripts for using special cifoutput styles: Location: sky130/custom/scripts
style density : check_density.py
style wafflefill : generate_fill.py
- GDS output issues: Error : " Parent and child disagree on CIF " : It occurs if ruls generate more shapes in a child cell alone than in the child + parent cell.
-
Magic shows an interactive DRC.
-
Magic run drc engine as ideal process that runs when everything is idle .A ocess is computationally expensive, magic uses 3 styles for running DRC, namely: style drc variants (fast), (full), (routing)
DRC styles in order of speed :
drc(full) - complete DRC check (slow)
drc(fast) - typical checks (fast)
drc(routing) - metal checks (fastest), check only metal layer/wire rules
drc off - can be used to turn the DRC interactive engine off
- Main DRC rule checking methods:
- Edge-based rules : It includes spacing, width, surround, extend rules
- Boolean geometry rules : It includes two dimensional logic operation(AND, XOR, GROW, SQUARES, etc.) on two different planes.
- Netgen is a tool used for running LVS checks.
- The tool knows nothing about layouts, it only knows about netlists and how to read and compare them.
- The LVS tool must be able to figure out permutable pins of resistors, source and drain of transistors.
- Netgen does not need to know anything about any components in the design, it juts needs to know whether there is match in the layout and schematic netlist.
- The technology setup file tells the LVS tool what all devide names are, how they should be combined in parallel, which pins of device are permutable, which properties are of interest for comparing between netlist and which are not.
- If the hierarchy of layout netlist and schematic netlist does not match, LVS tool will not be able to match the circuits.
Netgen commands used in th setup file are:
propertyignorepermuteequate
- Layout Vs. Verilog
- We can run LVS on verilog output netlist of digital synthesis flow.LVS does comparison by gate, not by transistors. So from perspective of LVS all the logoc gates have been blackboxed.
- In this boolean XOR operatot is used to compare teo layouts.
- ON applying XOR operation on two mask layers, as per the rule the output is nothing where both mask share same geometry. We have some output on the layout where one mask has something and other has nothing.
- It isused ot find out difference in the layouts, mask revision
- We can use klayout to do mask level XOR verification
Magic command for running XOR operation, we can use the following commands. let layout1 is : and2_2 and layout2 is : and2_2_alt , destination : xor_test Then for (and2_2) XOR (and2_2_alt) = xor_test
load layout1_name
flatten destination_name
load layout2_name
xor destination_name
To check input style check below commands in tch=kon window:
-
To check input cif styles
-
GDS file read for input style sky130(vendor)
-
GDS file read for input style sky130() :
-
GDS read after making " gds duplicates true" :
To check port details : standard cell used : sky130_fd_sc_hd__and2_1
-
Select port and the check index
-
Port details
-
Port detials after reading LEF file
-
Port detials after reading spice file
To conduct XOR verification on masks, we will checkby loading and2_1 locally so that it can be edited.
-
Loading and2_1.mag and saving it locally
-
Loading altered and2_1 ,editing the layout and performing XOR operation
-
Loading XOR operation output
DRC checks do the physica; verification of mask data layout against foundry design rules.
Some of the foundry design rules for DRC clean layout are :
-
The width rule :
-
Spacing rule :
-
The Notch rule :
The aspect ratio of any uncontacted local interconnect layer should generally be greater than 1:10.
These are rules that are device specific, and generally need to be handled with care while designing standard cells or designing special layouts .
-
Antenna rule:
-
Latchup rule:
- Width rule
- Contact cut
- Minimum hole
- OpenLane Design Stages OpenLane flow consists of several stages. By default all flow steps are run in sequence. Each stage may consist of multiple sub-stages. OpenLane can also be run interactively as shown here.
- Synthesis
yosys/abc - Perform RTL synthesis and technology mapping.
OpenSTA - Performs static timing analysis on the resulting netlist to generate timing reports
- Floorplaning
init_fp - Defines the core area for the macro as well as the rows (used for placement) and the tracks (used for routing)
ioplacer - Places the macro input and output ports
pdngen - Generates the power distribution network
tapcell - Inserts welltap and decap cells in the floorplan
- Placement
RePLace - Performs global placement
Resizer - Performs optional optimizations on the design
OpenDP - Perfroms detailed placement to legalize the globally placed components
- CTS
TritonCTS - Synthesizes the clock distribution network (the clock tree)
- Routing
FastRoute - Performs global routing to generate a guide file for the detailed router
TritonRoute - Performs detailed routing
OpenRCX - Performs SPEF extraction
- Tapeout
Magic - Streams out the final GDSII layout file from the routed def
KLayout - Streams out the final GDSII layout file from the routed def as a back-up
- Signoff
Magic - Performs DRC Checks & Antenna Checks
KLayout - Performs DRC Checks
Netgen - Performs LVS Checks
CVC - Performs Circuit Validity Checks
-
RTL Synthesis, Technology Mapping, and Formal Verification : yosys + abc
-
Static Timing Analysis: OpenSTA
-
Floor Planning: init_fp, ioPlacer, pdn and tapcell
-
Placement: RePLace (Global), Resizer and OpenPhySyn (formerly), and OpenDP (Detailed)
-
Clock Tree Synthesis: TritonCTS
-
Fill Insertion: OpenDP/filler_placement
-
Routing: FastRoute or CU-GR (formerly) and TritonRoute (Detailed) or DR-CU
-
SPEF Extraction: OpenRCX or SPEF-Extractor (formerly)
-
GDSII Streaming out: Magic and KLayout
-
DRC Checks: Magic and KLayout
-
LVS check: Netgen
-
Antenna Checks: Magic
-
Circuit Validity Checker: CVC
LVS and DRC are the main principle forms of sign-off validation before sending a chip for fabrication to the foundry. While the foundry will perform a full DRC on our design, they do not perform LVS, since the foundry has no way of knowing the behaviour/function of our design or what it is supposed to do. Even if our design does not meet LVS, it has the potential to come back from manufacturing just as dead as a chip that fails DRC.
Mostly all LVS tool needs the schematic and layout netlists, and usually, netlists used for this purpose are in .spice format, though any format with gives enough information about the circuit will work just fine (lef/def, verilog, blif, etc). Netgen accepts spice and verilog formats, both of which can be simulated(spice file with ngspice and verilog file with iverilog).
| Netlist for LVS | Netlist for Simulation |
|---|---|
| Devices in design | Devices in design |
| Basic parameters | All parameters |
| Parasitic capacitors | |
| Parasitic resistors | |
| Nets in design | Nets rewired around parasitic resistors |
| Parasitic Inductors | |
| Parasitic mutual inductance |
Magic commands to extract netlists for LVS run, we use the following extraction commands.
extract do local
extract all
ext2spice lvs
ext2spice
Netgen is an extension Tcl/Tk interpreter language, and as such, all netgen commands share Tcl/Tk syntax.
The shell command for running netgen is shown below.
netgen -batch lvs "filename1 subcircuit1" "filename2 subcircuit2" setup_file output_file
We need to first git clone the repo to obtain all files necessary for the this lab.
git clone https://github.com/RTimothyEdwards/vsd_lvs_lab.git
- Kunal Ghosh, Co-Founder (VSD Corp. Pvt Ltd)
- Tim Edwards, Efabless